Feature Request: Toggle in Raw Over Exposure Indicator to show "real" clipped pixels

[juhavlintula]

Is your feature request related to a problem? Please describe. The Raw Exposure Indicator in darkroom is showing the channels values > 1.0 after the white balance coefficients have been applied. If I have understood it correctly, in the scene referred workflow this shouldn't be an issue if you are using the linear modules.

Describe the solution you'd like Add a toggle in Raw Exposure Indicator settings that will the indicator show the clipped pixels after white balance compensation or the "real" clipped raw pixels.

Alternatives Alternative that was proposed, was to disable the White Balance module and turn the Raw Clipping indicator on. If the comment in the code that Matt had picked stating the clipping is detected as >1.0 after white level normalization, that work-around doesn't work, as the max value from the sensor is 1.0.

Additional context See some discussion in pixls.us.

[parafin]

Duplicate of #4587, which was closed. Please read it and close if you agree with the arguments there.

[juhavlintula]

I'm not convinced. If I have understood correctly, in the linear workflow there is clipping only before you enter the pixelpipe or when you exit from linear to display-referred. The first part happens in the sensor (signal below S/N level or fully saturated pixel) and the second when you compress your linear HDR image to LDR display. Please correct, if I'm wrong. IMO having a check on what data enters into the linear workflow, makes sense.

[parafin]

You're wrong if highlight reconstruction module is enabled and it is enabled by default - it will clip some channels (because that's its job). On the other hand filmic iop also has highlight recovery functionality which may allow to disable highlight reconstruction iop, so let's ask @aurelienpierre what does he think. But the principle should remain the same - you might have to clip even non-saturated channels due to white balance if some other channel is saturated.

[aurelienpierre]

I just had a look, actually the rawoverexposure.c module comes toward the very end of the pipe but reloads the original raw straight from the file while undoing WB and black/white raw levels, so it shows the real clipped pixels at the sensor level. In fact, it just does what it says.

[parafin]

Please read the discussion in the #4587, it’s not as simple as that, because it takes wb settings into account, that’s the topic being discussed.

[aurelienpierre]

So maybe OP's FR has merit. It's not difficult to code anyway (one line of pixel code, many lines of Gtk widgets declarations but it's basically copy-pasting of overexposure GUI).

[elstoc]

Does the raw overexposed indicator show actual sensor clipping if you disable the white balance module (as I often do for IR photography)?

[aurelienpierre]

Yes.

[parafin]

I think having ability to show raw overexposed pixels while taking WB into account is useful, because they will be clipped by highlights reconstruction iop. So from practical point of view these pixels are overexposed even if no channel is saturated. The question is whether with scene-referred workflow and filmic iop things changed - is highlights reconstruction still necessary? If not, how the overexposure situation is handled and is logic any different? I suspect not.

Now, having ability to show only saturated pixels may also be useful. Right now it's achievable by disabling WB iop, but maybe a separate checkbox or smth should be added.

[ralfbrown]

I would be in favor of an option to show the sensor-clipped pixels without having to turn off the WB module. That makes it easier to step through bracketed shots to determine the optimal ETTR shot.

[github-actions[bot]]

This issue did not get any activity in the past 30 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[wpferguson]

The raw overexposed indicator shows the pixels that are above whatever value you set in the indicator. Highlight reconstruction, set to clip, restricts the data that will be processed. I shot some raws and ran them through RawDigger to see where the sensor really clipped. Then I took the same raws into darktable and adjusted the overexposed setting to get the same indications. I ended up with a setting of 1.8. When I set highlight reconstruction to 1.8 I got good data. I think the 1.0 threshold was about the display referred processing where values >1.0 caused problems. For details see https://discuss.pixls.us/t/unlock-more-dynamic-range-in-darktable

[parafin]

See my analysis here: https://github.com/darktable-org/darktable/issues/4587#issuecomment-608640954 Indeed you may recover some dynamic range by disabling highlight reconstruction, but that's assuming that sensor doesn't clip. Having 1.0 threshold is the most straightforward way to ensure that colors are correct, any other logic might introduce strange results, like white having lower maximum brightness than blue or red.

[wpferguson]

I think I've discovered the problem with the raw overexposure indicator. It is exactly what it says it is. It is not sensor clipping. So while sensor clipped = raw overexposed, raw overexposed != sensor clipped.

Can you use the raw overexposed indicator to figure out if the sensor clipped? I believe so. If you set the clipping threshold to 2.0 in the raw overexposed indicator and highlight reconstruction to 2.0 and reconstruct in Lch, then anything that shows as raw overexposed is blown in 3 (2 greens and something else) or more channels and anything showing in magenta is blown in 1 channel.

I took an image that showed raw overexposed areas. I used dcraw to extract the sensor data, then octave to play with the individual channels. I used the black and white levels from the raw file to determine what was clipped. Setting the indicators in darktable to 2.0 and reconstruct in Lch showed magenta in the areas where only the green channels were blown and raw overexposed in the areas where red, green, and sometimes blue were blown. Looking at the raw sensor data it seems that the green channels always saturate first, then red, and finally blue.

[parafin]

The way to see sensor clipped has been already described - just disable WB iop and raw overexposed will show sensor clipping. Your way seems convoluted and unreliable.

[kofa73]

I'm adding it here, although it's not about the raw over-exposure indicator, rather about what's clipped and what's not. Sorry about the multiple updates -- I'm quite tired and discovered a number of silly mistakes in the comment.

I've uploaded a few files here: https://tech.kovacs-telekes.org/files/dt-issue-6596/ I took a raw file that contains a large blown-out area. I exported the raw data using dcraw -4 -W -T into a tiff file, and ran it through a tool I have started to code in order to understand raw development a bit more.

The tool does the following:

• applies the black and white points I took from darktable's raw black/white point module
• applies the WB coefficients taken from darktable's WB module
• performs a simple demosaic by interpolating values from neighbouring pixels for the missing components (is that bilinear? I don't even know).
• finally, it greys out the pixels that are affected by any of the blown pixels (raw value > max value, taken from darktable's raw black/white level module). So, if a single pixel is blown, it will grey out both the RGB pixel located at the same coordinates, plus all 8 neighbours. The greying is done by simply averaging the RGB components. The output of those steps is in https://tech.kovacs-telekes.org/files/dt-issue-6596/raw-naive.png.

I then loaded this into darktable, and assigned linear Rec2020 as input profile (my tool does not support camera matrices), and exported the result -> https://tech.kovacs-telekes.org/files/dt-issue-6596/naive.jpg I loaded the raw into darktable, disabled all the non-linear modules (no filmic etc.), replaced the input colour profile with linear Rec2020 to match the other version and adjusted the exposure to match my naive development's result, and tried both clip and reconstruct modes in darktable's highlight reconstruction (https://tech.kovacs-telekes.org/files/dt-issue-6596/clip-dt.jpg and https://tech.kovacs-telekes.org/files/dt-issue-6596/reconstruct-lch-dt.jpg). For the blown part, dt's clipping loses all details; reconstruct-lch and my naive method seem to give comparable results. With exposure increased and filmic applied, the differences are perhaps even smaller (https://tech.kovacs-telekes.org/files/dt-issue-6596/bright-dt.jpg and https://tech.kovacs-telekes.org/files/dt-issue-6596/bright-naive.jpg).

I guess I have 'discovered' something blatantly obvious - but in the non-brightened version, I think the leaves on the branch above the large bright spot in the bottom right have a reddish tint (reconstruct-lch-dt.jpg), while the naïve version (naive.jpg) looks (to my eyes) a tad more natural, even if I restore the correct camera matrix as input profile of the raw file (reconstruct-lch-with-camera-profile.jpg).

[wpferguson]

@parafin I understand now. I was selecting original image at the bottom of the history stack figuring that I got the image before the white balance was applied. I created a duplicate, selected original image, turned off white balance and color calibration, and then saw the clipped sensor pixels and they agree with the raw sensor data I extracted from the image and checked. And, you're correct. Your way is much simpler than mine :smile:

[github-actions[bot]]

This issue did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[esq4]

I have read this and other discussions mentioned here. I reread the name of the module "raw overexposed warning" and compared it with the help text: "Highlight areas of the image where color channels of the raw input file are clipped". The name implies, and the help clearly indicates that the module shows clipping in the raw input file. And nowhere is there even a hint that it takes into account the impact of other modules, for example, the WB.

Change the name, correct the help and no one will have such questions.

In the meantime, you are misleading many users. And they believe that they see clipping from the sensor (raw file). It's just that many of those who have noticed are unaware of the possibility or don't have the time/inclination to let the developers know.

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[jandren]

@TurboGit This issue was closed with this PR: https://github.com/darktable-org/darktable/pull/11391

[TurboGit]

I'm closing then. Thanks!