I think I expressed my thinking quite well. Can you please also express your thinking in a clear way without having us to assume what you suggest?
Edit: My comment was just abut the raw histogram.
@geldo I am not convinced whenever someone uses a blanket term such as useless.
Being able to change the scale of an axis is a benefit. So is having handy buttons close by to configure the histogram. I don’t see why these features are useless.
Options are good and you don’t have to use every single feature. No one does anyway.
Finally, different scales are used in the math, science, engineering and business worlds all of the time. There is nothing unusual about them.
That said, I am glad this conversation is going on. I am sure that someone would benefit from @heckflosse’s patience. Maybe this is the beginning of an article on RawPedia. 
1 Like
I’m enjoying this thread quite a bit. I’m checking histograms all the time, but can’t figure out why GIMP and RT give such different looking ones. This thread is helping me quite a bit.
@geldo’s picture showing the grey card at 3 different exposures 2 stops apart was particularly eye-opening for me. I still don’t know what to make of it, but I would not have guessed that there’s only 2 stops different between those three shots.
Man puts on a welding helmet and complains that everything looks dark.
3 Likes
Gray card - Output luminance histogram - gamma (2.4) corrected:
Gamma correction is applied to the output file, then re-eliminated by the display device to match the original file (the one before gamma was applied). This may seem a little strange.
Gray card - Output luminance histogram - no gamma correction:
As I see it, raw histograms could be the best representation of the scene dinamic range, before any alteration to the contrast (in post-processing).
The problem is knowing whether such a scene can be reproduced in print, which is the reference output in photography. So a raw histogram should show the dynamic range of a scene in terms of EV’s (-8…+8?).
Once you know the dynamic range of your printer/paper/viewing condition, then you can tell how much tones (and which ones) you should compress from the raw to print, hopefully without loosing that beautiful natural contrast in the subject of your photo.
Are we saying the same thing?
2 Likes
@geldo, you’ve made me think about my histogram regarding, and I think it comes down to this:
- First regard: The data bounds. And that’s not just simple max/min, it’s where the “clump” begins and ends, because things like specular highlights can vex the simple statistics. There are a surprising number of factors to consider in the bounds, first one being how the exposure was captured, but also where the data sits in the container. For instance, if one is capturing 14-bit raws, you have a couple of stops of leeway as you mangle your data toward the 16-bit integer bound, if your software is using 16-bit integers internally. One of the reasons floating point is good; that boundary doesn’t exist there.
- Second Regard: The “clump’s topology”, how the tones are spread between max and min. Data as measured by the camera is decidedly “left leaning” due to the linear relationship of the light measurements. Once you start scaling that data out of linear, the shape of the clump starts to, for lack of a better term, “lean to the right” as the tones move toward a scale more suited to display and printing. This lean can come from curves, gamma transforms in ICC profiles, OCIO look LUTs, anything that will scale the data from its original linear relationships.
I too have found this thread to be quite insightful, particularly with regard to constructing my histogram tools…
2 Likes
Although additional features or the removal of features may help, for me at least, learning the basics and being knowledgeable of what the histogram is telling me has been the most helpful.
This is what I mean: an experienced photographer is able to look at the frame, glance at the histogram for confirmation of certain things and then take the snapshot with the light, colour and composition in mind, picturing how that would pan out from cradle (preparation) to grave (media).
Not all are masters (I am a “beginner” myself) but my point is that we need to know what the histogram is and isn’t meant for, and within that scope decide what is really a feature and what really isn’t.
I am interested in @ggbutcher adventures; what I am saying is that they won’t blow your mind, except to help you appreciate what the histogram is.
The trouble here is that you have no idea what the statistics mean, The only thing you can do as a dev is provide the user with the tools to inspect the data, set the boundaries and define the terms (e.g., specular highlights; maybe the metadata would help too), but then you get into the data analysis quandary: are people coming for the raw processing or the analysis?
This is the second rung of data analysis: what is going on, how to represent it and how to make sense of it? I think part of my excitement for OCIO et al. is that they allow you to represent the data in the way the person querying the data sees fit. Of course, it is nowhere as robust as the more technical or scientific fields… but yeah, the more I speak the more I am digressing… 
Ah, you hit on a thing I realized in reworking my histogram: making decisions in raw processing doesn’t require the sort of fidelity you get in a tool like Histogramerr or RawDigger, at least I don’t. Really, I need to know the bounds and topology as I described to make tone decisions. Now, color actually requires a third regard, that being the channel relationships. I’ve put such to work in both white balance and color negative conversion to good results, determining shifts in the individual channels as evidence of a color cast.
I may yet write a separate raw histogram tool. But, due to the internals of rawproc and the distinct considerations of analysis, it would be that, a separate tool.
٩(^ᴗ^)۶
2 Likes
Exactly, and for this case a raw histogram where the x-axis is linear, but the vertical lines show ev steps (logarithmic) is the best representation imho. Because the raw data usually is integer (except for hdrmerge raw data) the lowest ev step has only 2 values (zero and one), the second lowests also has only 2 values (two and three), the third lowest ev step has 4 values (4 to 7) and so on. Giving the ev stops in raw histogram equal space would waste a lot of space in gui.
1 Like
But there’s no such a thing in RT, I think.
Ok I see, I didn’t understand what you meant, sorry…
but I’ll keep hiding histograms in RT as possible, I know it’s my fault 
My own personal opinion, darktable histograms seem no better to me, or better still even worse (if possible):
…but I haven’t a clue of what a waveform histogram is, I think I must do some homework.
I could explain but dt already has a lovely article.
1 Like
@afre thank you for the interesting link.
Well, had they been satisfied with histograms, there wouldn’t have been the need of any waveform I think. So I take some comfort from this, after all I’m not alone in criticizing histograms.
The fact is I like waveforms even less than I like histograms, and that’s really a problem. Should I switch back to film photography then? 
RawTherapee - Tonal distribution in a luminance histogram (linear with gamma correction):
To achieve real blacks and whites, both extremities next to clipping appear to be relevant. The most part of the x-axis refers to the interval -2/+2 EV, with the darkest tones here represented at -3 EV.
We can say that the -2/+2 EV interval (a small interval indeed compared to the real world luminance) is the descriptive part of the photograph, while the extremes are its glory.
But be careful to clipping.