Even useless things can teach us something, not least the very fact that they are useless 
@Claes That would be a difference of just 0.10 stop I think
Can you elaborate about that a bit more? It’s not clear to me what you think is useless?
@heckflosse
For one thing, logarithmic scales in pixel distribution histograms, both horizontal and vertical. What do they tell us that a linear scale can’t do? Moreover we can even switch from linear/linear to log/linear to log/log, is that a game or what? A logarithmic y-axis to count pixels? 
They give finer granularity when viewing the raw histogram because at raw level the first ev would have only 2 values, the second ev also 2, the third ev 4 and then doubling for each ev. Giving each of the ev steps the same horizontal range would waste a lot of space in gui.
Maybe we talk about different things. For raw histogram I prefer the linear histogram but with the vertical lines placed at ev stops beginning from right to left (which means logarithmic for the vertical lines). For me that gives the best feedback (only for raw histogram, in case I want to see, whether I could improve shooting exposure to the right)
1 Like
The problem with such an approach is that you need to set a bunch of buttons for each different case, making the tool more complicated than it should be. Some combinations are useful, others are useless, but nonetheless they are there and you have to pay attention to each setting each time. For example, RGB channels and luminance mix up when displayed together, they tell different things one over the other.
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.
