New tool "Capture Sharpening"

Though I have to say: FOSS is not democracy, means, if 1000 LRCS users not knowing RT at all would vote for whatever, I wouldn’t count them :wink:

1 Like

Indeed. And I’m right good with that.

I think of it not so much as a vote, but a viewpoint to consider. And in that, I’ll always try to provide constructive viewpoints… :smile:


Thank you!

From what I gather the tool is in the early portion of the pipeline, so I understand the data is linear to start with. RL deconvolution is certainly correctly applied in the linear domain, while this is not necessarily so once data goes non-linear. So for the avoidance of ambiguity and in the interest of keeping things intuitive/simple I would also favor removing the (round trip?) to gamma.

Yes, it works marvelously indeed. There should really only be a substantial per-channel difference at very low f-numbers. And the more one gets closer to the source, the less Gaussian the PSF starts to look, so I wonder how effective working on color channels separately would be…

About Gamma:
It makes a little smoothing losing some detail. It shows at very high increments (crops)> 500%
Almost nothing. For me it can be eliminated.

Left: Gamma min value: 0.5 - Right: Gamma max value: 6

(Crop: 600%)

If you’re referring to the dark line of pixels over the logo, even though I can’t be sure without looking at the raw file, I don’t think those are details, but an artifact (dark haloing).

If I remind correctly, the gamma slider is meant to mostly get rid of the dark haloing, but with side effects in the highlights.

As it was meant to correct an artifact, an undesired behaviour of the tool (or the algorithm itself), to my understanding it should be removed, and find a way to get rid (or at least minimize) of the dark halos. I guess that will prove to be difficult.

In the meantime, when you face a challenging image, you can control the dark haloing by:

  • changing the demosaic to RCD or RCD+VNG4: if you have a Bayer Matrix sensor, that’s the demosaic algorithm that generates the least artifacts when combined with Capture Sharpening
  • lowering the radius: as a general rule the auto-radius works fine, but sometimes the dark haloing is much more noticeable and you need to lower the radius
  • work with few iterations: working with 5-10 iterations removes most oversharpening and halos (bright and dark), but leaves you with a not so strong sharpening (sometimes barely noticeable)
  • keep processing the image, and then come back to Capture Sharpening: some other changes in post-processing have an impact in this tool. Yes, I know it’s one of the first tools in the pipeline and it doesn’t make sense that other tools applied afterwards would have an impact in the haloing, but sometimes they do. I’ve had some good side effects (improvements with dark haloing) tweaking Exposure, Defringe, and even Wavelets, so don’t hesitate to come back and check if you can further improve the sharpening done in Capture Sharpening

I see and I notice that Gamma smoothes the image to change detail. But the changes will see increases >500%.
We do not talk about the processing of this particular image, I’ll take care of that, but we talk about the difference between Gamma 0.5 vs Gamma 6.
As it is a little thing, for me, Gamma can be removed.

(I hope it has translated well what I mean)

Well, I guess I know what you’re saying, but just in case…

Sorry for not posting this image in my previous post, as it would have made things clearer:

This is a crop at 600% from a Playraw (Damselfly Macro Shot) I was playing with, and as you know, there’s a difference between gamma 0.5 (on the left) and 6.0 (on the right).

In this case I have forced the settings to make it evident: 100 iterations and auto-radius. In my post I just used radius: 0.48, instead of 0.65. And just 5 iterations, instead of 100.

But the thing is I can’t see any difference in the details. Only in the artifacts (the haloing). One could think that gamma 6.0 would be better, but in this case is obvious that the clipped highlights seem to bloom (increase their size). Not desirable to me.

We agree that the gamma slider should be removed.

Capture sharpening excludes the neighborhood of clipped pixels from sharpening, beause the data is not linear in this areas. If a pixel is >= 0.95 * whitelevel all pixels in its neighborhood with a distance <= sqrt(5) pixels are excluded from sharpening. I made a test lowering the value from 0.95 to 0.85

Here’s the result. Left using 0.95, right using 0.85

It’s also very important that RT knows the correct white levels for the camera, which I doubt is the case for the Nikon D300 which has no entry in camconst.json.

Can someone provide a completely overexposed ISO200 shot from Nikon D300?


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!

1 Like

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.

  1. 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.
  2. It gives finer granularity when using Corner radius offset, which definitely is a benefit.
  3. you don’t have to care about the iterations setting, just set it to 20 and enable the new Auto limit iterations checkbox will do the job
  4. 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


Hello @heckflosse

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 :slight_smile:

Joking aside, by any chance, have you compared your latest work with the “similar” [1] 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 [2] 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.

[1] Enhanced Unsharp Mask in PhotoFlow - please test! - #72 by Carmelo_DrRaw

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) :wink:


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 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! :smiley:


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)

1 Like

Haloing is inevitable in RL sharpening. @heckflosse has done a good job in mitigating it. :+1:



1 Like

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.