Magenta highlights vs raw clipping indicator vs filmic white level

Aurélien, I read the code already. It’s not the individual C statements that I don’t understand (though you did cause me a few fun moments by referring to filmic v6 as v4 in the code :slight_smile: ), it’s the colour manipulation behind it; but I’ll leave that to you. :smiley:

There are images where the v6 colour science shines (no pun intended), out of the box: bright flowers and the like. And there are situations where I’ll have to learn how to use it.
I think currently there’s a discrepancy: one may use the white relative exposure picker, and then after using it on the whole image, something surprising may result. I know, the i-word… So I guess instead of sampling the (clipped) Sun disc, I’ll have to:

  • adjust the white level manually, or
  • use another norm, like luminance Y,
  • use v5 and its desaturation,
  • use something else.

No big deal.

As always, thanks!

No highlight reconstruction module, no reconstruct in filmic. v6 + maxRGB. Highlights desaturated in color balance rgb.
2022-05-01_20-04-21_P1070278_08.RW2.xmp (7.3 KB)

3 Likes

It took me the whole day and part of last evening, but I finally nuked the part of the problem affecting the color diffusion. Now on the guided laplacian one…

3 Likes

There’s a typo here: darktable/basic.cl at 730151cd871a5acfc9090c6309b2327c2747c0ae · darktable-org/darktable · GitHub

it should read k < 9 instead of k < 0.

1 Like

yeah, I fixed that one already, but there is more :smiley:

Is the cpu path still an issue…If so one thing I notice from a day or so ago is the artifacts that show on the CPU path, ie with OPENCL disabled will show for me with opencl enabled while I am zooming and the preview is updating…When the preview completes the artifacts disappear as the screen display completes it update… I am not sure if this provides any useful information…I see you have made some changes by the sound of it so I should check that out first…

That’s because the low-res preview may be computed on CPU depending on your prefs, even though OpenCL is enabled.

For sure here at work when I tested on my office PC…I thought I had my home box on GPU only but I had been messing around with settings a couple of weeks ago and I might have gone back to default scheduling….Thx

Isn’t there also a typo here in the WB normalization after interpolation - shouldn’t it be RGB[k] / wb[k]? At least it does a different thing than the corresponding OpenCL line.

Another thing I noticed: 5x5 box blur is applied on the binary clipping mask. Doesn’t it cause some of the clipped pixels to get less than full opacity? Would it be good to first dilate the mask by a few pixels and then blur to get 100% opacity on all clipped pixels and a smooth roll-off into the non-clipped surroundings?

(Also, is there a chance of the divisor to be zero here?)

3 Likes

Ooops you are right.

It’s already extended, at the demosaicing step, any pixel interpolated from a clipped pixel is also flagged as clipped.

Without the 5×5 blur, I had weird border effects.

Yes, but the fmaxf(NAN, 0.f) should clip it to 0.

Thanks for your help.

2 Likes

@anon41087856 a couple of things I tried and found probably beneficial (at least removed dark fringes I previously saw):

  1. Never darken a channel in the guided Laplacian reconstruction
  2. Don’t alter a channel if it’s not clipped in the guided Laplacian reconstruction

See highlights_diff.txt (1.5 KB)

I think it might be also beneficial to disregard the center sample when computing the regression. The data in one channel is clipped anyway, so that data point can be thought of as an outlier.

2 Likes

This seems risky because we are working with laplacians in a quasi-Fourier space here, not with the actual image, so there is no definition of dark or bright, only oscillations around average value. Dark or bright appear after we collapse (sum back) all wavelets scales.

After some tests, it seems to move the problem elsewhere, but does not yield smooth reconstruction. Basically, the current dark fringes may appear when the radius of reconstruction is too large, so the darker sky is inpainted into the sun disc.

Right, that makes sense. Perhaps one could try to avoid darkening the image instead when forming the reconstructed image at the last wavelet scale (I don’t remember if the original image is available at that point).

The original image is not available at that point (I could make it, but that comes with RAM penalty). However, I’m exploring a scale coefficient that would soften the correction as we reconstruct farther.

Bingo ! Seems to work

Now remains that bright fringe…

3 Likes

Nice! One thing I also had in mind: the color diffusion on norms doesn’t necessary preserve the norm as one - should you renormalize the ratios before recostructing from the saved norm?

1 Like

No, I tried it and it’s worse. I think that’s because the original norm is already wrong in relation to the neighbourhood, so we use it only as some “high-frequency” metric that let us blur the “low-frequency” ratios without damaging details.

1 Like

I see. Btw would you mind pushing a branch with the latest improvements so I could also have a look this week?

Sure, I will do that tonight.

BTW, you were right about renormalizing ratios. When I tried it, the wavelets processing happened bottom to top and I renormalized scale by scale, which was bad. This is what I get by renormalizing only once on the collapsed wavelets (at the end instead of in-between):

So, pretty much there.

8 Likes