Magenta highlights vs raw clipping indicator vs filmic white level

[aurelienpierre (Aurélien Pierre)]

@kofa

Letting the Sun clip is hardly a mistake in exposing the photo, unless one wants to study the Sun.

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.

@kofa

I’m still puzzled by the extreme luminance saturation slider affecting those magenta highlights if they are dark according to the norm. But well, there are many things I’ll never understand, so I can live with that.

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.

[davidvj (David Vincent-Jones)]

The dropdown has no option for laplacian
I am running the latest git version on Manjaro/Arch

[paolod (Paolo)]

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

[priort (Todd Prior)]

So if you hit the drop down you don’t see it??

[RawConvert (Andrew)]

@aurelienpierre , 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)

[aurelienpierre (Aurélien Pierre)]

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 ?

[afre (Alan)]

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

[paolod (Paolo)]

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

[g-man]

I cant replicate on 3.9.0+1468~g0e64b4646

[RawConvert (Andrew)]

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.

[kofa (István Kovács)]

@aurelienpierre

Does anybody else reproduce ?

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

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

OpenCL with NVidia 470.103.01: no magenta.

Without OpenCL: yes, reproducible.

[RawConvert (Andrew)]

phew!

[sgotti (Simone Gotti)]

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

[priort (Todd Prior)]

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

[g-man]

I can replicate on CPU. OpenCL it looks correct.

[priort (Todd Prior)]

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

EDIT

[kofa (István Kovács)]

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.

[priort (Todd Prior)]

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…

[afre (Alan)]

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

[priort (Todd Prior)]

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