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
I double checked the OpenCL settings. The export works again when enabled. The jpg is OK. When disabled with the black box as attached. Weird indeed.
No problems here with Aureliens bug fixings for guided laplacians:
darktable 3.9.0~git1593.a4b33145-1
Kubuntu Linux 20.04
NVIDIA GeForce GTX 1070
NVIDIA Driver Version: 470.129.06
OpenCl enabled
The CPU processing is different than OpenCL. What OS? It might be a bug.
Fedora release 37 (Rawhide)
uname -a says
Linux kirk 5.18.0-60.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Mon May 23 14:13:01 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
There was an opportunity for division by zero that I fixed today. I noticed the same issue as you while writing the doc of the feature. (Another benefit of writing docs…).
4 Likes