USE HIGHLIGHTS RECONSTRUCTION. Signal is damaged, green clipped first, luminance is destroyed and inconsistent with neighbourhood, it needs reconstruction, aka interpolation of the texture in 2D. Saturation, tone-mapping and such are 1D. You will not patch a 2D hole with a 1D method.
If reconstructing highlights was as simple as desaturating, I wouldn’t have spent 2 months on guided laplacian.
Saturation doesn’t care about luminance and doesn’t care about norm. Desaturating keeps luminance and hue unchanged, and degrade color to the grey having the same luminance. The norm is used here to decide if there is desaturation or not, as kind of mask, but ultimately the desaturation does not use it.
@anon41087856 , hi, I’ve just built Master to try the latest changes, and I’m getting strange results with guided laplacian and the sun disc picture above. The strange things are happening as I change the iterations from 9 to 10, 11, 12 16. I’ve switched off as many modules as possible in case they were involved.
Note that 9 and 11 iterations are better than 10 and 12, that seems odd to me.
Todays’ dt is executing MUCH faster than my 1st May dt doing guided lap.
Hardware is an i7 processor (several years old model), no video card (I use the built-in graphics), 32Gb memory.
I noticed this just today using today’s Master build 3.9.0+1484~gdc929e1f9
I did two different things when building today ! ?
I copied my previous cache and config folders. That is, I ran up dt immediately after building with new folders; then quit dt; then copied the cache and config from previous 1st May build to be the new folders. When I ran dt there was a popup about updating the database, I did that, all seemed fine.
I’ll also mention that I quite commonly get a message like this in the Terminal window -
(darktable:6146): Gtk-CRITICAL **: 14:11:54.144: gtk_render_frame_gap: assertion ‘xy1_gap <= width’ failed
where the 6146 can be various numbers. I’ve not been able to spot what causes this.
Changing it to 4095 effectively disables highlight reconstruction: no pixel is brighter than that value, therefore none is considered blown, so highlight reconstruction does nothing.
How is the white value determined ?? Most cameras of often it is very close to the bits of the file saved so like 1023 for 10 bit …looks like the LX-7 is 12 bit…exif data says linear limit of 4095?? Just wondering how it comes to be 3971 in DT??
Even at 4095 the new sensor clipping will show some clipped data… moving it to 4096 would do as you say…
@priort The tag output looks about right. Although maxes may not always be at 4095, they are usually close for this kind of camera. Are there another entries that say 3971?
I could not and its a different Panasonic camera but the Puffin picture loads with 4095 which matches the exif data…so just wondering about the deviation for the LX-7??
EDIT:
Interesting with this one…if you double click the slider it will go to 3971 if you reset the module it will go to 4095??..If you do this for the LX-7 photo …both will go to 3971…I’m curious why this would differ…must be in the camera config files??