One may ask now: why the hell did RT use RL deconvolution on Lab L at all? : Well, that’s because it was implemented this way in 2013 (maybe even before), noone changed it and noone thought about that.
Thanks to @nik who brought that to attention we may get at better RL sharpening in RT 5.8 
It’s 2019 folks.
I keep repeating myself, but convolutions (so, deconvolutions too) are operations that need to conserve the energy of the signal. As such, they need to operate in Hilbert spaces of square integrable functions, in order to respect the Parseval’s identity.
That theorem is 215 years old, it’s about time image processing begins to care about it. In image processing, such spaces of square integrable functions are scene-referred because the energy to preserve is the one of the light spectrum. From your camera sensor to your LED screen, it’s light in/light out, so light emissions are all you need to care about.
Lens blur is modeled mathematically by a convolution, and it does not blur gamma-encoded garbage but light emissions, aka photons characterized by their energy. Light is represented in digital imagery by scene-referred/scene-linear encoded RGB sensor readings. Deconvolving the lens blur in any space that got a non-linear transfer function squeezed in it is foolish, theoritically wrong, and visually unpleasant.
Dear opensource devs, please get your maths right before opening your IDE, because image processing is just about that, so you get no choice. That stuff is part of the first 3 years in the curriculum of any applied sciences university program. It’s not new. There are way too many engineers and scientists involved in opensource image soft to excuse any corner-cutting with theory. Apply the theory, then get proper results. Don’t, and expect problems. [2]
[1] Convolutions are a large family of filters using pixels and their neighbours, including:
[2] And when you do get problems, don’t add thresholds and opacities tricks in your broken code to hide halos, fringes and funny stuff under the carpet. Go fix your models instead, or you will loose everybody’s time in the community.
Hi Aurélien. While I largely agree, I’ve found references suggesting that certain wavelet transforms are better done in a perceptually uniform space such as LAB, which is not linear.
JPEG and other lossy image compression algorithms depend on discarding information that won’t be perceived . It is vital that the data presented to a JPEG compressor be coded in a perceptually-uniform manner, so that the information discarded has minimal perceptual impact. Also, although standardized as an image compression algorithm, JPEG is so popular that it is now effectively an image interchange standard. Standardization of the transfer function is necessary in order for JPEG to meet its users’ expectations.
Do you agree? The argument may extend to e.g. guided filters for edge detection; I’m not sure.
Mostly has to do with backwards compatibility. I tend to go the gmic route, which provides a high degree of freedom, but I have to hand do everything, so I am mostly lax in getting it right all the way through, at least for the PlayRaws.
It depends on what you want to achieve. See: New shadows/highlights tool with enhanced halo control. It is only a part of what @Carmelo_DrRaw has been working on. He has a way to preserve the ratios at the end, though one might disagree with the method.
I agree with your suggestions, though changing all this old code won’t be done in one day…
These wavelets are meant to encode a file that will be later decoded, so overall, they are a no-op. It’s just a trick to compress pictures by removing high frequencies. It’s a whole different topic than what I’m taking about (aka picture editing & pixel pushing).
Guided filters for edge detection will behave erratically outside of a linear space. It’s yet another case of things that could work fairly in gamma/display-referred space, until someone finds a case where it fails badly. Scene-linear is just way more robust and simpler. Just stick to physics, and everything should be fine. That’s all we know anyway.
I have been working on a similar feature in parallel since last Christmas, also with iterative guided filters, but with a different approach. My code only makes use of linear operators, and doesn’t need thresholds to avoid halos, nor ratios preservation since it’s basically an exposure compensation.
Yes, thanks for that! I have only been able to follow it loosely so far. Will examine it further once real life is less dire. Since I am not a code, math or science wiz, it has taken me a while to process the information. Recently, I have been able to build the guided filter and extend it. Quite the feat for a newbie like me. A good exercise, with lessons that I can apply elsewhere… hopefully.
I realize this, but I don’t think it actually addresses my question. With Richardson–Lucy deconvolution, they assume a Poisson noise model, and this only makes sense physically (as photon noise) in a linear space. It’s been a while since I’ve looked at wavelets, but I don’t recall any such assumption—or any other assumption that holds only in a linear color space—in their derivation. It’s just “input signal, output wavelet coefficients”: no assumption is made on the signal’s structure (besides being in L^2).
The argument in my link is that with JPEG compression, the wavelet expansion and truncation of higher coefficients produces more pleasing results in a perceptually uniform space, since minimizing L^2 distance in that space minimizes perceptual distance (more or less), which is what we’re after with good compression.
Accepting this argument for the moment, it seems like the same reasoning applies to, say, wavelet sharpening. We are interested in enhancing high frequency detail as perceived by the viewer, which suggests the use of a wavelet decomposition in a gamma-corrected space. I don’t especially care about features that are high-frequency only in a linear space if enhancing them doesn’t improve perceptible sharpness.
So, it’s not clear to me a priori which way is correct. The JPEG example suggests a nonlinear space might be the correct one. Can you point to any features of the wavelet algorithms RT uses that demand a linear signal?
Similar remarks apply to guided filtering. I care about enhancing edges as perceived by the viewer, not edges in a liner space necessarily. Why do you believe they will work erratically outside a linear space? Again, you may be empirically correct, but I don’t recall a telltale assumption like Poisson noise that mandates this.
Even though you have lumped the three in one discussion, I view RL, wavelets and guided filtering as apples and oranges. We have already established that RL does well in linear, so I will let that go for now.
To me, wavelets are their own domain, just as there is a Fourier domain and a gradient one, etc. As long as I get to recompose and return to the original domain, all is well. Of course, it might be simpler to start from linear, as transforming one too many times may introduce discontinuities or artifacts that would shock those of us who would care about those things.
Then there is guided filtering. It and similar filters are interested in smoothing flat areas while preserving edges. Let me put it this way, what would you consider an edge? In linear space, the edges would be focused in the brightest regions and the rest would be regularized; in most cases, that is not what we want. Hence, why I linked @Carmelo_DrRaw’s work. There might be objections to the implementation details, but the idea that you need to find the edges remain.
Here’s a first screenshot from R-L deconvolution on Y-channel immediately after demosaic. Left is without R-L, middle (old) is R-L on Lab L channel after exposure compensation and tone curve, right (new) is R-L on Y channel before exposure compensation and tone curve:
Here’s a filebin with the raw and the processed tif files:
https://filebin.net/dddrkxr8dg3bmuco
still wip…
Branch capture_sharpening has a functional ui now
It’s in the raw tab as it works only on raw files atm:
Because capture sharpening is applied to the whole image (not only the part of the image you see in preview) it takes some processing time, but also allows to preview the contrast mask at zoom levels < 100%
For the same reason, when using capture sharpening you also get a sharper preview at less than 100% zoom. Left old sharpening/right new, both at 50% zoom:
There was some progress recently:
Just try it and give feedback 
I tried the new branch yesterday, so far I’m liking it. I used to not like RL very much for my camera (Fuji X-T2), but the capture sharpening looks better to me. And it’s really cool to have the sharpened preview below 1:1!
Not sure about halos, but in my blind test I preferred the top right. The image seemed to have richer colors and more contrast and visually the most appealing.
The screenshot is outdated. I will have to make a new one…
I suggest actually posting the screenshots blind when asking which is better. After receiving the input you can let us know which is which.
Ok, this time blind. One of the sharpened images is using RL-deconvolution in Details tab, the other one is using Capture sharpening right after demosaic with gamma 1. RL settings are the same for both sharpened images. In the middle for reference the unsharpened image.
Left side is better: less gradient reversals and clipping when zoomed in. When zoomed out, right side looks sharper at first glance.
I like the left sharpened images, they look a little more natural and with less halos
