The following is a histogram in software ‘X’:
The following are the histograms of the same photo in RawTherapee (with different scaling):
As I see it, there are obvious differences between the four, as a matter of semplicity, photographic informations and easyness of reading. What do you think?
While not as faithful to the “bar chart” paradigm that is a histogram, I prefer the line rendition of the three channels to the overlaid bars of the first screenshot, makes it easier to see what all three channels are doing at a given tone.
I’ve not warmed to log scales, so the last two are not my cup of tea.
Thing is, at this scale either of the first two meet my needs, which is 1) determining the pileup at the display limits and 2) the overall topology of the data distribution.
I just finished an overhaul of my hack software’s histogram, and it looks mostly like #2.
It is not very pretty, but it’s rather informative:
The EV scale can be set to put EV0 whereever, right now it’s at 0.18. The other solid line is a cursor that moves with the mouse, and shows either the 0.0-1.0 native value or a bin number. The depicted scale is “display”, where the left and right extents are 0.0 and 1.0 respectively, and out-of-bound data just piles up at the limits. The other scale is “data”, which puts the left and right limits at the ends of the data, including out-of-display data. The texts and lines can be toggled off so the channel lines can be seen in all their glory.
This will be in rawproc 0.9, or it’s currently in the master branch at github.
That’s interesting. I am not sure of the use of the second solid line in such a context.
That would certainly be the merit of the grey background 
I use it quite a bit to adjust tone. If I switch it to display the bin, and the number of bins is 256, I can slide it around to find where something like the max data is, and use that to set the white point. For a curve, it tells me where to put a control point to center it on a particular part of the data. Doesn’t show up in the screenshot, but when the mouse cursor is in the histogram, that line follows it around and the number changes to reflect its position.
@ggbutcher I have the feeling that we have had this discussion before: how did you handle the peaks to the left? They aren’t as sharp as @geldo’s examples.
Edit: I realize that it is based on a different image but it is still relevant to our discussion.
Ok, so it isn’t related to the RGB lines.
@geldo’s histogram reflects an image with a decided color cast, probably related to white balance. I posted an example of correcting that at dpreview last week, here’s a fuller illustration with the whole program. First, the starting image and its histogram:
The image has a bit of a blue cast, and the histogram shows it in the offset of the blue channel, particularly the rightmost peak. Here’s a blue curve to correct that:
More neutral. The red channel could use a bit of lift:
Simple use of per-channel curves, informed by the histogram.
Back to the solid black line with the number, it essentially labels the bin over which it’s situated. I’ve considered putting in the bin heights for each of the channels, but it starts to clutter the already-small window and I just didn’t need to know it that badly…
I am talking about how rawproc handles peaks in the histogram. Software ‘X’ lops them; whereas RT keeps them, but in doing so squashes the mid tones’ and highlights’.
Getting rid of the least useful bit of information to preserve all the rest, it seems to me the right thing to do.
My fellow Canadians use wave forms in our igloos.
Ah, sorry, I’m multitasking and it’s not going well… 
Until I reworked the rawproc histogram, it used the average height of the bins to vertically scale the histogram, because I didn’t like how they flattened when large clipping piled up at the top or bottom. But i came to realize that this was only occuring in the leftmost and rightmost bins, so I rewrote the scaling to exclude those bins from the average. After all, clipping is clipping, and after a point I don’t care how high clip bins go…
When folk complain about their histogram “going flat”, that’s what’s probably happening, one or both of the “clip bins” is dominating the vertical scale.
I’m investigating that, but haven’t found a sufficiently succinct definition to start coding from.
Which part? Chris Niccolls is quite handsome.
Joking aside, I would love to see more apps feature more representations of the data, including the wave form and vector scope, and the many derivatives of them.
Just in case, here is the image which generated all the histograms:
My only steps in RT were white balance from the ColorChecker and a +0.3 exposure compensation (to match the software ‘X’ rendition).
Original file here.
The same image histogram passed on from RT to Gimp: (four flavours)
The following are luminance histograms in RT referring to a grey card (in order): well exposed, over-exposed (+2 EV), under-exposed (-2 EV).
From a photographycal (art) point of view, I think there is a strong bias, in fact we have an x-axis dedicated almost entirely to shadows.
Indeed.
Now, one thing to note, the X axis in the recent histograms appears to be log-scaled, so keep that in mind when comparing what you see on the right with the left.
By clicking on the gray and white button on the left hand side (2nd bottom from below), one can switch between log-log, log-linear, and linear histograms.
Hi @geldo,
If I remember it properly, correct exposure would be when the bottom-left square (the white one) is close to Lab 96 x x.
Yours is 99.5 x x
Have fun!
Claes in Lund, Sweden
