Magenta highlights vs raw clipping indicator vs filmic white level

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

@flannelhead see Guided laplacian bugfixes by aurelienpierre · Pull Request #11817 · darktable-org/darktable · GitHub

1 Like

Thanks! Going to have a look soon.

Which settings did you use for the latest image? Could you please share the XMP?

2022-05-01_20-04-21_P1070278.RW2.xmp (72,6 Ko)

I don’t remember exactly how many iterations I used, but the more the better.