Fixing clipped highlights? (moonrise over the ocean)

Using DT 4.0

I’m struggling with highlight reconstruction on this. Screen shot is as-opened with raw over-exposed toggle on (minimal). I fiddled with both highlight reconstruction and filmic but can’t get something that looks good.

DSC08008.ARW (23.5 MB)

This file is licensed Creative Commons, By-Attribution-Non Commercial, Share-Alike.

1 Like

Not great…no filmic just tone eq and new segmentation HLR

I guess you could try more…

DSC08008.ARW.xmp (7.5 KB)

I would have used the new highlight recovery (looks good Todd), but I don’t have a dt version with it installed at the moment. The fact that the raw clipping indicator doesn’t show much makes me think this is one of the images where dt sets the incorrect white level. But I don’t quite understand why reconstruct colour or LCH in highlight reconstruction doesn’t get rid of the colours, even if I tweak the threshold. (to ‘correct’ for the white level).
Anyway, I took the easy way out and switched filmic to V5, then pulled the white relative exp. down just enough to desaturate the highlights… oh well! Not very commendable… I also used tone eq and color balance rgb

DSC08008.ARW.xmp (11.3 KB)


White level indeed should be set at 15360, not at the 16xxx DT picks by default here (at least on my setup).

It’s one of those images where - even with good white levels set - the reconstruct-LCH or reconstruct-color don’t seem to give usable results. And the area is just a bit too big to use laplacian-reconstruct (I need 256px or more with loads of iterations, making it all very slow).

So yes, a perfect candidate for the new segmentation-based recovery, which works as a treat here (I raised the ‘candidates’ till the colors are more to what I would like, but that’s personal, and I don’t have a feeling I know what I’m doing yet with the sliders in the segmentation-based recovery).

You could also just leave highlight-recovery disabled, and use the filmic settings. Raising the iterations in the filmic options tab a bit, and then lowering the threshold to just under 0ev somewhere. Then play with the sliders to see what they do. I find that if you start lowering the ‘bloom’ slider bit by bit, you’ll get a smooth result at one point that’s very usable.

But start by setting the white level to 15360.
exiftool -a -u -g 1 DSC8008.ARW | find /i "white"
exiftool -a -u -g1 DSC8008.ARW | grep -i white

or some other form, I’m just used to finding it like this.

Segmentation-based example:

Just filmic example:

Just filmic sidecar: DSC08008.ARW.xmp (29.7 KB)

1 Like

I am getting this, too. Manually setting the white point to 15360 showed the moon “properly” over-exposed. I didn’t understand @AxelG github bug that says this is not a bug? It would be nice for DT to set the proper white point for Sony ARW.

I found this separately. I’m not a heavy DT user, so I don’t have a feel for “slow”.

Will this be associated with highlight recovery, filmic, or a different module?

Thanks @123sg and @jorismak for your examples, I’ll look at your files this weekend. I have a general dislike for filmic. I tend to take shots with lots of bright or lots of contrast. The default s-curve of filmic eliminates a lot of detail that caught my eye. I’ve tried messing with filmic settings and other modules to bring back the detail that filmic loses, but haven’t settled on anything that makes me comfortable.

For this image, I tried highlight recovery in filmic. I got something that blended the over-exposed area. I didn’t play with it much, but I noticed highlight recovery was starting to lose detail in the clouds and in the moon’s reflection in the water. The span between “too much” and “too little” seems quite narrow. I noticed when I was using other modules the filmic highlight recovery became over-done or under-done because the white point, threshold were changing. Kind of annoying. Fixing this with highlight recovery at the front of the pipeline does take less fiddling than fixing it with filmic at the end of the pipeline.

Its just another HLR mode option…in that module… If you are on windows or dual boot it should now be part of @wpferguson Bills weekly windows builds that you can download from here each Sunday…

1 Like

The candidates slider effect can’t be predicted due to the algorithm. You have to “play” with it.

Sorry I keep a bit mean with words. Still too many things to be done IRL

It is not a bug for the dt team, because the problem is caused by a library, they used. So the problem is upstream, that is my understanding, at least :slight_smile:

actually that problem is not filmic’s fault, you find the same behaviour in basevurve

Maybe this is not intentionally, but I just used fiilmic with a gradient mask and then it looks like this (can be attenuated better, indeed):

The raw over-exposed indication is working “right” in 3.8.1 but “wrong” in 4.0". For this image I put screen shots of the two versions in github. This is maybe a separate issue than the white point value?

It is my understanding that raw indication is working correctly. It will indicate values above the white point limit from your camera. If the white point is incorrect, then garbage in garbage out, thus the indication would be incorrect.

Definitely a difference between the two versions. 3.8.1 shows raw over-exposure as-expected. 4.0 is confusing (wrong?).

I probably wouldn’t have started an edit on this image (in 4.0) if I realized so much of it was over-exposed.

DT 3.8.1

DT 4.0

3.8 is wrong, 4.0 is correct. Your image could have the wrong white point.

More in detail, up to dt 3.8, clipping was determined after the whitebalance coefficients were applied.
Those coefficients are (much) larger than 1.0 for red and blue (for red, >2 isn’t unusual)
That means (in practice) that red and blue were often marked as clipped while the sensor values were still perfectly valid. Since 4.0, that has been corrected.

A side effect of that is, that a wrong default whitepoint (in general, too high), was more or less hidden in 3.8, as red and blue were marked as clipped well below the real white point anyway.
Example: my camera has an “EXIF whitepoint” of 15360, dt used 16300. The WB coefficients (for “camera reference”) are 2.958, 1.000, and 1.572 for R,G, and B. resp). So the red channel pixels were marked as clipped for raw values above ~5500…

Correcting one bug made another one visible…

I haven’t been able to extract the whitepoint value from the raw file with exiv2, exiftool did provide the correct value (hidden somewhere in the “makernote” section?). So I made an auto-applied preset for the raw black/white point module, which solves the issue…
(Would it be useful to report this as a bug against rawspeed, or is it rather a problem with Exiv2? Or just unsolvable within current structures?)

EDIT: @akgt94 : for your image, dt 4.0 indeed uses a wrong raw white point. Setting it to 15360 helps a lot…


Darktable is using a component to read raw files. I believe the issue of the white point not properly being set is coming from updates in this component.

So team-darktable is not responsible for the bug, but team-rawspeed. (Even if they might be the same people :wink: )

The over exposure indicator (and algorithms like recovery) depend on the value of the white level. So wrong white level, wrong exposure indicator.

You might argue if Darktable could go back a version, but then other new features would go back again.

1 Like

(There might also be a chance that this is not because of a change in rawspeed, but actually has been an issue for quite some time, but only now becomes known.

Sony cameras that have a 14bit white-level set in EXIF, but some other value that appears to be the real white-level of the sensor in their MakerNotes might always be the case, we just didn’t notice it).

The attention to how filmic v6 handles highlights and the highlight-recovery options in Darktable that have been going round lately might have just uncovered this bug.

)I don’t know this, I’m just speculating).

I think you may be right here, At least i became aware of this while working on highlights recovery and collected many samples from different cameras for evaluation.