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):
- Never darken a channel in the guided Laplacian reconstruction
- 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.
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.
Is it me or something else? Today I checked out the git version a4b3314-dirty incl. Aureliens bug fixings for guided laplacians.
I applied guided laplacians to the photo and get a large black box when I export the image to jpg. Am I missing something?
btw: Fortschritt means ‘progress’.
L1000184.DNG.xmp (17.8 KB)
Files attached.
L1000184.DNG (25.9 MB)
Check your OpenCL. Same results without OpenCL? What OS? What drivers?
When I enable OpenCL the export to jpg does not work at all.
NVIDIA-Linux-x86_64-515.43.04