set the EV0 value by clicking on a point (a grey card?) in the preview window

leave some breathing room to both left and right to better view clipped shadows/highlights

move over the preview to show the correspondent x-axis value, to evaluate the relation between the image object/subject and its exposure

keep in mind we are talking about raw, so any preview should be blocked to a ‘neutral’ working profile just for mouse positioning and image parts recognition

keep in mind we are talking about raw, so any exposure value (x-axis) should come directly from the a/d converter for each photosite (e.g. 0-4096)

This should be a good starting point for a deliberate and informed post-production.

Well-described, thanks. My musings to date have focused on #3, but I’ve gradually come to realize the key relationship to consider within the “data pile” is EV. #6 is challenging, because for 14-bit raws the histogram buckets would be 0-16383. That’s a lot of buckets, and I’ve had to do “stupid pet tricks” to make such a histogram navigable without stuttering and blocking. Thinking about how I’ve had to recently consider my exposures, #2 in some form is going to be my new muse…

I’m struggling with #5. Typically when I consider a histogram, I want it to be collected from the working image, the one upon which I’m going to apply the next edit. That’s not necessarily what I’m seeing, as that has been pumped through the display profile. Although, there are times I want to see the result, so the output/display histogram is pertinent to an upstream edit. I’m also thinking this in terms of my software, which is not RawTherapee; I have a lot of (maybe, too much) discretion in where I work and view.

#6 is challenging, because for 14-bit raws the histogram buckets would be 0-16383. That’s a lot of buckets, and I’ve had to do “stupid pet tricks” to make such a histogram navigable without stuttering and blocking.

I think of histograms as photographic tools, so that a ‘1/3 stop’ resolution would be enough. Speaking of raw histograms a 14-bit 24MP sensor would then generate 24 million values (no colors yet) in the range -10 : +10 stops in 1/3 stop so we have around 60 possible values for each pixel (not really a pixel yet).

ggbutcher:

I’m struggling with #5. Typically when I consider a histogram, I want it to be collected from the working image, the one upon which I’m going to apply the next edit.

That’s correct. But I think we should differentiate between the exposure and post-production, they are very different things: the former relates to lighting, shutter speeds, lens apertures and iso values, while the latter is just a mathematical trick, powerful as is but just a mathematical trick.

So here are the settings to get the closest match between raw and output histograms:

reset to ‘neutral’ working profile;

disable white balance;

select ‘no profile’ as input profile;

select sRGB as working profile;

select sRGB as output profile;

tone response curve = custom, gamma = 1

For some obscure reason (at least for me) selecting sRGB at points 4 and 5 leads to a closest match than ProPhoto.
Also, even if the raw histogram refers to RGB data before demosaicing and the output histogram refers to data after demosaicing, results are almost identical.

As you can see, losing our time on useless questions does not make us any better. (But maybe just happier )

@geldo I’m absolutely not against improving the raw histogram in RT (as you can see for example here). But I didn’t (and still don’t) understand your approach to match the raw histogram with the non-raw histogram.

But I didn’t (and still don’t) understand your approach to match the raw histogram with the non-raw histogram.

I do not know either, I was only trying to learn RT which I think is really a great piece of software. As a matter of logic I was starting from the beginning (or what I thought to be the beginning) that is the raw file, so I have come to the raw histogram. In particular I was interested in the behaviour of the histogram through the various steps of digital elaboration. I asked myself what useful info could I get from the histogram, info that I haven’t got yet by looking at the image preview. Nothing new, was the answer.

In the end I chose to hide the histogram (both raw and non-raw) by moving it in the left panel which I usually keep closed.
I think two things annoy me in particular about histograms: the absence of true photographic informations and the fact that they change even when the image does not (from a visual point of view).
Anyway I think I have learned a lot of things, thanks to RT and of course those of you who took the time to try and follow me.

Right now I am battling with input, working and output profiles (I received my ColorChecker today) and then I will move to WhiteBalance County. So please keep looking for further (silly) questions soon.

By the way, I think it could be useful to show a simple RGB values window (as a tooltip) while moving the mouse around. Maybe partially transparent and only upon request, of course.

I think two things annoy me in particular about histograms: the absence of true photographic informations and the fact that they change even when the image does not (from a visual point of view).

I’ve been messing with the histogram in my hack software, somewhat spurred by this discussion. To your two points above: 1) I’d be curious regarding what you think is missing; 2) I get that, bothered me early on too until I dug into what was really happening when the histogram changed. Sometimes, it was a visual contrivance, designed by the programmer to make the data presentable, sometimes though, it was my data and the histogram was really trying to tell me something important.

For instance, if you apply an edit and the histogram goes flat, it may be that more of your image is going out of display range, getting clipped, and the histogram collection logic is just tallying all those clipped pixels in the uppermost bucket, at display-white. Then, the scaling part of the histogram logic kicks in to fit the presentation in the little window, and the clip bucket dominates the scale. I just put in a setting to take the uppermost and lowermost buckets out of the scaling consideration for just that purpose. After all, a clip bucket only has to get so tall before you get the message…

LIke any other statistical tool I know, histograms will tell you something to consider in almost any way they come out, intuitive or not. You just need to understand the particular rules with which they are developed…

@ggbutcher
Not that I am against histograms tout court, in fact I do appreciate the one in background in the tone curve tool, I find it to be discrete enough and even useful, and I love the fact that when I close that tool (or just when I scroll it up or down), it humbly disappears.

But normally I feel as I was walking a dog, from the very moment I take a photo until I click on the save button at the end of a long post-production session every time I turn around I see it.

Enough is enough. I can live without a pixel distribution histogram I am sure, to the point that I could even look at the image preview with ‘clipped shadows/highlights’ indicators turned on. In the end what else does the histogram tell me other than I clipped some highlights?

In the same physical space I would like to see maybe an exposure histogram, but this is just an idea. Thirty vertical bars from -5EV to +5EV at intervals of 1/3 of a stop, and the possibility to set the 0EV value by clicking on the preview image.

Then I can click on one of the thirty bars, and the corresponding pixels will show up in the preview image (beware to automatically switch off clipping indicators until I click again the bar).

But that is just an idea, I am sure others could contribute their own ideas to fill the space left by our beloved pixel distribution histogram.