Raw overexposed warning depends on white balance

[RawConvert]

I noticed the raw over-exposure indication (lower right icon with green, red and blue does) depends on what white balance you select. I thought the indication would be purely a function of the raw file, independent of any editing changes.

Platform

• Darktable Version: 3.0.1+dirty
• OS: Ubuntu 18.04

[jenshannoschwalm]

Technically you are right. But as the white balance changes the matrix holding coefficients for all rgb channels we might be out of the range and that's what is shown by the indication intentionally.

This decision might be debatable but it's a good way to check while developing.

[RawConvert]

Please could you explain a little more. If areas of the image go out of range, that is shown by the clipping button next to the raw button. Why would this out of range need to be covered by both functions? A nice thing about having a pure raw indication is that it helps photographers to get exposure how they want. As you no doubt know, the camera indication is usually only approximate, so it's good to have a truly accurate indication in dt. But if it depends on white balance and perhaps other factors, you can't trust it quite the same.

[elstoc]

I agree. I'm starting out doing infrared photography and if there's one thing that's always wildly out (or at least subject to artistic interpretation) it's the white balance. In-camera exposure histograms are based on a white-balanced jpeg (so can be very difficult to judge) and I had assumed that the raw overexposure indicator would be a better indication since it was looking at maxed out pixels in the raw file. If it's not, how can I get info about the exposure of the original raw file?

[jenshannoschwalm]

As i said the implementation is debatable. My comment was just about how the code has been implemented and currently works.

I am not sure what way is the more informative one.

1. Now we check for pixels where the rgb data after applying a 'correct' matrix are 'out of bounds' or have a wrong color. This is what the manual says Clicking the icon warns you about areas of your raw input image with clipped color channels. Clipped color channels imply an overexposed image with loss of information in the affected areas
2. You request it to check for sensor saturation. Currently you would have to switch of the white balance module.

[elstoc]

Do you know what "out of bounds" means here? Is it camera specific?

[jenshannoschwalm]

iop/rawoverexposed.c lines 96 ... (source is the best doc we have :-)

[LebedevRI]

https://github.com/darktable-org/darktable/blob/1dbdbf019ea9fdcc63bc2141254fa24041bbb385/src/iop/rawoverexposed.c#L96-L111 is pretty self-explanatory i hoped

[elstoc]

Yes all clear, thanks. I just didn't know where to look (and I'm not used to seeing detailed explanatory comments in code!)

[RawConvert]

In summary, I can see this is more complicated that I first thought. I vaguely understand there is a white point relating to sensor values which varies by ISO and sensor type and perhaps by camera instance. So it's not an absolute value, and so I can see determining what is clipped in the raw file might be complicated or impossible. I see rawtherapee doesn't give raw clipping, just the raw histogram. So thanks for the input, let's not spend any more time on this, I'll close it.

[parafin]

@LebedevRI, I'm not so sure that logic in the source code comment is correct. I've read your original explanation here too: https://www.darktable.org/2016/10/raw-overexposed/

So let's say there's no sensor clipping, but after wb red and blue channels go above 1.0. Then we apply negative exposure correction bringing these values back under 1.0 (we have turned off highlights reconstruction). Color indeed might be pink, but that's because it is pink - sensor didn't clip, so it captured the real color, which can be recovered just by bringing exposure down. But rawoverexposed iop still will mark it as overexposed. The same can be achieved without exposure iop, by manually adjusting wb, so that it's normalized to 1.0 as maximum, not minimum value of RGB coefficients.

So what exactly is the meaning of "raw overexposed"? It makes sense if we take enabled-by-default highlights reconstruction iop into consideration - it does indeed consider such pixels as clipped and make them white. In that sense such areas are overexposed - with current WB settings and default processing marked areas are indeed blown. You still might be able to recover these areas if sensor is not clipping, but it's not a straight-forward operation, since disabling highlights reconstruction iop is not a very good idea.

To summarize - I think source code comment is wrong, but how rawoverexposed iop works indeed makes sense.