I have not had a picture as clear as the one you have shown, and I thought it was a smoothing that made you lose some detail. It is seen that gamma serves to minimize the halo in case of high contrast. Ok!
During the last days I worked hard on improving Capture Sharpening.
One thing which was really annoying, was the dark haloing at regions with high local contrast.
I tried a lot and finally found a solution to limit the iterations based on the local contrast.
- it’s a bit slower than before (say 10%) especially for the low radius values while it can be even faster than before for large radius values.
- It gives finer granularity when using
Corner radius offset, which definitely is a benefit.
- you don’t have to care about the iterations setting, just set it to 20 and enable the new
Auto limit iterationscheckbox will do the job
- it’s less prone to artifacts caused by too large radius values, as the iterations restriction will catch that
Some screenshots (left old code at default values, right new code at default values):
It’s in dev branch now
I have been following your improvements on github lately.
Together with Desmis’ NewLocallab dailies udpates, on his personal GIT branch, you really make me a happy Rawtherapee user
Joking aside, by any chance, have you compared your latest work with the “similar”  sharpening improvements done on PhotoFlow?
I am not a developer and this is why I am asking this question. In short, I know nothing of algorithms and other technicals stuff…
BTW, lately, on YouTube, I have watched a video  showcasing your previous improvements on this same experimental tool. The comments on this video were extremely positive.
In addition, the sharpening results, available with the tools of Rawtherapee, were considered better than the results with Lightroom.
I didn’t compare really. I tried to implement my ideas for RT and I will let the comparison to Andrea and you (the users)
For information (mainly for xtrans users): I improved the auto radius calculation for xtrans files. Now it works similar to bayer files (in past it often resulted in too low radius values).
Some background about Capture Sharpening.
Why did I code it?
RT has RL deconvolution sharpening since many years but it was known to produce (mainly bright) halos.
Based on a discussion somewhere here on pixls.us I tried to apply RL earlier in the pipeline on linear data.
That already worked better but now gave dark halos instead of bright ones.
I could partly fix the dark halos by using a more correct gaussian blur, but not complete.
As it already worked better than before, I cared about usability.
The old RL (still) has this settings:
Lots of settings to find the right ones. Let’s exclude Blur radius (which is for creative unsharpening), amount and damping as I never used them after Contrast threshold was implemented. Still 3 settings remained marked with red rectangles in this screenshot:
It turned out to be quite easy to calculate the Radius value from the green channel of the raw data (at least for bayer, since yesterday also for xtrans), means now the user can mostly stick with the auto radius and has only 2 settings to adjust.
Furthermore, as Capture sharpening works on the full size image, also the Contrast threshold could be auto-calculated => only one setting to adjust, which is the iterations setting.
I tried to find a good default value for iterations (which is 20), but I still got dark halos (we will come back later to that)
While coding all that stuff, I had the idea, to allow a radius increasing from center of the image to the corners to fight the decreasing sharpness of a lens towards the outer regions.
So I added another adjuster (Corner radius boost), which defaults to 0, but can be increased to increase sharpening towards the outer regions of an image (it can also be decreased)
So now, we again had 2 settings, though corner radius at 0 still works fine especially when using full frame (FX) lenses on APS (Dx) sensors.
The screenshot shows the two setting which were not auto calculated with red rectangles
Still, with all the improvements, there were this damn dark halos.
Fortunately I found a way to reduce them (not fix them completely) by adding an option to limit the iterations of the RL deconvolution. To do that, I had to reduce the tile size from about 194 to 32 (so that the iteration limitation is done locally, not for the whole image or large tiles)
Means we got ony more ui control (the new checkbox) which mostly allows us to keep another setting untouched. That also turned out to work quite well, so now we have this gui
And the only thing wich deserves a change (if at all) is the one marked with the red rectangle if you want to increase sharpening towards the outer regions of the image:
Just stick with default values and maybe set Corner radius boost to e.g. 0.15 and for most cases this will work just fine.
Maybe a bit rhetorical: are you a 100% positive this is not due to some error in applying the filter or procedure? Or otherwise due to the kernel?
Edit: in any case a great write-up Ingo, and even better work!
If the kernel does not match the input (e.g. input is not gaussian blurred) applying an RL gaussian deconvolution will of course not be correct.
But currently it works quite good. I tested with a lot of files (from my D700 with AA filter, Pentax K1 pixelshift shots without AA filter and without demosaic, monchrome Leica files with no CFA and most likely also no AA filter, xtrans files without AA filter and so on)
Haloing is inevitable in RL sharpening. @heckflosse has done a good job in mitigating it.
May I ask how Damping works? Is it some sort of regularization in the loss function? If so, what type? If done properly it could possibly help with the halos.
CS doesn’t have damping but info can be found here: http://rawpedia.rawtherapee.com/Sharpening#Damping.
Thank you. So how does it work?
The docs are clear to me but let me break it down a bit more for you.
If you need to use many iterations (a large number), what normally happens is the fine details tend to become exaggerated. The most distracting part of noise is fine too, so noise might be a problem. What damping does is soften these. Generally, I would avoid iterating too many times. CS adaptively limits the iterations; therefore, doesn’t require damping.
Right, thank you again but I was referring to how the damping does its job within the algorithm. Regularization in the cost function or something different? Specifically? Unfortunately I am not good at reading someone else’s code (nor often my own after a while:-) .
I am in the same boat as you: I am not responsible for the code. The last thing I would say is, based on my previous post, I doubt that dampening (at least in its current form) would mitigate haloing.
I’d be happy to try! I realise I still haven’t got out my deconvolution OpenCl code yet, but I should be able to submit this soon. If capture sharpening lends itself to doing all the iterations on GPU, as you say, then I’d be happy to build on what I’ve got now.
Where can we download the daily builds of RawTherapee, for Windows 10 (64 bit), to try your feature?
For instance, I have checked here:
It looks like the most recent branch (21 November) pertaining to your work is:
Just out of curiosity, I don’t know wheter I am supposed to download the sse4 builds or the other ones most recent SkyLake builds?
At home, I run an old Intel I7: 6500U CPU.
In all truth, I suppose I should opt for the Skylake builds
Thanks a lot in advance!