Waiting for a Windows build, or 2.8, whichever comes first. 
Maybe @gaaned92 or @Carmelo_DrRaw can include the ‘capture_sharpening’ branch in the nightly builds.
It is now done, both for the AppImage and the Win64 builds 
1 Like
Thanks. What is the link?
3 Likes
Thanks for working on this. I tried it out with an X-Trans raw (Fuji X-T20) and here what i found.
- Very slow to process, every time I moved a slider it re-went through demosaicing. Is this what it is supposed to do?
*Sliders had very minimal bearing on the output, even when pushed to their min or max.
*Further gains can be had using standard RL deconvolution on top of Capture Sharpening
Here is the raw I tried it on [Play Raw] Sunlit pink blooms
That will be fixed later by adding some buffers.
That sounds something is wrong. Using standard RL on top of Capture Sharpening leads to ugly oversharpening in my tests. And at least the radius adjuster has a quite big impact on the result.
Can you post the pp3 you used?
Here is a simple test case. I set capture sharpening sliders to an arbitrary high value and further sharpened with RL-D. (3-pass + fast and auto match tone curve)
DSCF9442-test.jpg.out.pp3 (12.1 KB)
@chaimav I used your sharpening settings. Left is only capture sharpening enabled, right capture sharpening and RL-Sharpening in details tab are enabled. imho ugly artifacts at right
Left is with your capture sharpening settings. Right is with the default settings. No RL in details tab applied for both. Clearly more halos at the left.
Edit: for reference, left with default settings, right without sharpening
1 Like
I agree that capture sharpening does indeed sharpen the image, and that it is possible to overdo the sliders.
For the pp3 i posted, i just raised to an arbitrary high value.I guess I am just used to the regular RL tool where when I move a slider a small amount, there are big changes to the output. With capture sharpening, big slider changes are needed for me to perceive any difference.
I just pushed some changes.
1 Like
I like the results very much.
I used to use Unsharp mask sharpening followed with RL sharpening when downsizing. Now, I replace the USM with Capture sharpening at default settings, and I get slightly better detail.
Good job!
1 Like
@heckflosse Maybe it’s already working like this, but since the capture sharpening takes place on demosaiced data, shouldn’t it also be possible to let this tool work on non-raw images?
That should be possible, but does it make sense? We know nothing about the things already done to non-raw images…
Something that has been on my mind for a couple of weeks is an R-L deconvolution using a guided-filter as surface blur (e.g. a guided filter where guiding mask == guided image), possibly using a multi-resolution pyramid, and, why not, a total variation regularization.
That would avoid edges (aka no halos) and noise sharpening altogether.
Still no time to test that.
Fair enough, but do we need to reassess the way we sharpen non-raw images using RL, since this formally has to happen on ‘linear’ data. Somehow?
It matters where in the workflow you do RL and in which space. I have always considered RL as deblurring rather than sharpening, so I would do it very early if I decide to use it, regardless of whether it is a raw file or not. As for USM, I don’t use it at all or understand why it is lumped with RL.
I have had similar thoughts brewing for a few years. Would be good to see real life results.
All you have to do is ensure non-raw images have their gamma decoded at the beginning of the pipe, and re-encode them at the end.
Not only for RL, also for unsharp mask we could allow to use Y instead of Lab L.
Because it was this way from the beginning and noone thought about it.