Magenta highlights vs raw clipping indicator vs filmic white level

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.

3 Likes

Screenshot_2022-05-11_18-47-24
The dropdown has no option for laplacian
I am running the latest git version on Manjaro/Arch

It is only supported for cameras that have the usual Bayer sensor pattern. It will be hidden for Fuji X-Trans cameras.

1 Like

So if you hit the drop down you don’t see 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.

P1070278-sun-disc-16-iterations.xmp (65.1 KB)

I tried your XMP with 9 to 16 iterations, and I never get the magenta blob. Does anybody else reproduce ?

What is your hardware & driver ?

Also, why do you have rawprepare v2 ?

@RawConvert Also, when and for which commit did you start noticing this? As well, did you change the compiling method or anything in your system?

I made a recent change to rawprepare params for this PR: DNG GainMap support by paolodepetrillo · Pull Request #10289 · darktable-org/darktable · GitHub

I cant replicate on 3.9.0+1468~g0e64b4646

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 ! ?

  1. I did “sudo git config --global --add safe.directory /home/user/DT-top/DT-Mast-12May22/darktable-code” just before the cmake, this seemed a good idea in the light of
    dt unknown-version? ["solved" -- sort of] - #16 by pehar

  2. 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.

I already have, 3 times. 2 girls and a boy. :smiley:

3.9.0+1484~gdc929e1f9, Linux, ‘Release’ build.

OpenCL with NVidia 470.103.01: no magenta.

Without OpenCL: yes, reproducible.

1 Like

phew!

I can reproduce the issue only when using the CPU but not when using OpenCL.

The xmp I loaded 60 min or so ago had WB on reference with no CC module…was that my bad loading…does that impact the end result if not??

I can replicate on CPU. OpenCL it looks correct.

Interesting the Raw WP is something like 3971 which seems arbitrary but could be right…changing it to 4096 removes the issue…

EDIT

image

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…

image

@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??