unsharpness of colour channels created by ca-correction

[Raoul-Kima]

I noticed that CA-Correction can make the colour channels in the image noticeably softer. I think that to some degree this is unaviodable because CA-correction involves shifting image content by fractional pixels. However, I wondered if the blur created by the RT CA-Correction is more than necessary.

To be clear, I'm not sure if this can be improved, and I probably wouldn't have opened an issue for it if I hadn't been asked to do it in discussion #4774 .

To illustrate the effect, here's an Image that shows it in the red channel. Left with manual CA-Correction, right without CA-correction.

Raw available in this folder: https://filebin.net/dr8c0mubb95zixtp It's file number 6060.

Seen In full colour this has the result that the red colour bleeds into adjacent regions, making the finer black lines in the image slightly red.

I compared different CA-correction methods using the rawcacorrection_iterate branch version 5.4-798-g5fcb64634 from 2018-09-05.

Here are some comparison images: https://filebin.net/rralgqld2bc9jxdl

From the red-channel example above it can be seen that the channel is sharper if no CA-Correction is applied, so the unsharpness is most likely not caused by demosaicing problems caused by the CA. For this reason I would have expected that the post-demosaic correction examples would suffer least from the unsharpness caused by fractional pixel shifts, for the simple reason that in a RAW-image not all pixels are "red" and thus the shifts cannot be represented as accurately in RAW. However, the full colour comparison images show that the bleeding of red into the letters is strongest in the post-demosaicing CA correction done with RT. The two pre-demosaicing images show less of this "reddening" of the letters, but at the same time the letters seem slightly less crisp in the affected areas. Therefore I'm not sure if the pre-demosaicing CA correction fares better, or just trades of the artefacts differently. Perhaps surprisingly, the naive correction in GIMP fares relatively well in terms of perceived image sharpness, but of course has it's own artefacts (thin lines have a green hue) because I didn't do the correction in the right colourspace, but just shifted the RGB channels around.

While in these images the two pre-demosaicing CA correction methods look quite similar, this is not always the case, as the red channel of the following image shows: Left is manual pre-demosaic CA-correction, right is 1-iteration pre-demosaic automatic correction.

raw file is here: https://filebin.net/gw0fg7ttvhelhu1x

Here the image of the manual method looks noticeably more natural and detailed than that of the automatic method, suggesting that the automatic method could be improved. (Note: I didn't check if this applies to the blue channel as well.)

What dou you think, could it be worth pursuing this further at this point?

[heckflosse]

@Raoul-Kima Can you please retest with latest code from rawcacorrection_iterate branch? The old bug in raw ca correction I fixed in that branch gave a wrong interpolation for negative shifts (left or up).

[Raoul-Kima]

@heckflosse If I understand you correctly I need to compile RawTherapee myself to do so. I tried setting up the necessary tools following http://rawpedia.rawtherapee.com/Windows today, but failed. Probably because I tried doing it in a Sandbox? I'm not sure If I can solve this issue soon (don't want to install stuff I don't know outside the sandbox). Certainly not before monday. Is there any other way to test your bugfix? (I feel this is not the right place to ask such questions, but didn't know better. I'd be happy about pointers to a better place.)

[heckflosse]

@Raoul-Kima Unfortunatly we won't get new windows builds for a while according to https://keybase.pub/gaaned92/RTW64NightlyBuilds/

travelling so no new build until october 6th

I don't make windows builds (except for my machine). Maybe @TooWaBoo can help with a x86_64 generic windows build of rawcacorrection_iterate branch meanwhile

[TooWaBoo]

@Raoul-Kima Here it comes. 😄 Rawtherapee_rawcacorrection_iterate.zip https://filebin.net/5h8llu57jw1a4drh

No installer included. Extract the folder “Rawtherapee_rawcacorrection_iterate” to e.g. your Desktop and run “rawtherapee.exe” inside this folder. Cache and settings are saved into “%localappdata%\Rawtherapee_rawcacorrection_iterate”. It leaves your current installation untouched.

[Raoul-Kima]

@TooWaBoo Thanks for the comiled version!

I tried the fix. I didn't see much if any improvement in sharpness for my examples, neither for the newspaper image nor the fence image. The vertical line artefacts when using high values of manual CA-Correction are also still there.

I then did more testing with the fence image and it turned out that:

1. The 1-iteration automatic correction (unlike I first thought) didn't correct the CA fully but left a small bit uncorrected.
2. Setting the manual version to values that achieve a partial ca-correction similar to the 1-iteration auto-correction gives a result very much like the 1-iteration auto-correction.

I conclude that my originally different results between the auto and manual corrections were not due to differences in their interpolation. Thus the kinda strange look of the red channel in this example might not be a bug?

I further found that:

3. Setting the automatic correction to a higher number of iterations makes the red channel look less strange (not sure why).
4. With auto set to >2 iterations the result is better than I can achieve with the manual correction (even if optimizing and looking at only a a small patch of the image).

Which points me in the direction that:

1. Maybe the problem was just the particluar way in which the CA was partially-corrected. I'm not sure how this is possible, as the multi-iteration result is (as far as I understood) based on the sinlge-iteration one and thus should carry forth any arfacts. Maybe an interaction of the residual CA with demosaicing?
2. As this image has only negligible amounts of non-radial CA it should be well correctable with the manual CA tool, at least for a small region of the image. But the automatic version still was a bit better. Thus, with the current correction method, applying CA-correction iteratively might in some cases actually have some image quality benefits over doing it in one step (but see mentions of strange behaviour of manuall correction in the next post).

I found that with manual correction sometimes after first becoming unsharp the red channel becomes sharper again when moving the correction value further away from zero. I guess this is expected and happens when the pixel-shifts approaches a non-fractional value.

[Raoul-Kima]

The manual CA-correction also exhibits a kind of non-linearity in its behaviour which I don't quite understand. sometimes the ca actually first gets better with increasing values, then gets worse again with even higher values. This means that sometimes the CA can't be corrected even if it appears as if the slider range would suffice.

Here's an example using the newspaper image again:

left is uncorrected, right is a correction value of 4.3 -8.

left is what was right in previous image, right is a correction value of 8 -8.

Note that the CA in image1 on the left is almost completely corrected on the right with a value of 4.3. So a value of around 5.0 should suffice to completely remove it. However, in image 2 on the right it can be seen that even with a value of 8.0 it's still present, and actually has become stronger again without changing sign.

When using high values for the manual correction I also get colour-tinted image borders. Looks a bit like the old artefacts from the "avoid desaturation" branch. Is that code also present in the built of towaboo? If so I'll mention this in the issue. Here's an image:

[Thanatomanic]

Just to add a little comment about CA correction in general: these kind of abberations are impossible to completely fix in processing due to the nature of the effect. I'm not saying there's nothing to be improved here, but it's all just pushing a little further towards a point of inevitably irretrievable information :-)

[Raoul-Kima]

I agree. That's why I metioned in the first post that I probably wouldn't have created this issue if not asked to.

[Beep6581]

@Raoul-Kima chromatic aberration correction displaces the channels, so it's normal that there is a sweet spot and everything above or below that will be wrong in one or the other direction.

[Raoul-Kima]

@Beep6581 Yes, but it's wrong in the same direction, not upposite directions as I'd have expected. This means that In the example image I could never reach the equilibrium point where errors in both directions are balanced. This is very different from the behaviour of the post-demosaicing ca-correction, which behaves as I'd expect. I don't know why this is, or whether it's a bug or actually intentional. I just mentioned it because it might have to do with the other things discussed in this issue.

[heckflosse]

@Raoul-Kima I tested only automatic raw ca correction. Maybe there's still a bug in the manual correction. About the colour tint: There should be a checkbox in gui to disable 'Avoid colour shift'. That should fix the tint. When I found a solution to avoid the tint, I will remove this checkbox...

[heckflosse]

@Raoul-Kima I confirm issues with using large values (< -4 or > 4) in manual raw ca correction. Currently the code does not handle such large values correctly and I don't intend to change the code to handle that. I will set the max allowed range for manual raw ca correction back to [-4;4]

[IainMF]

I have discovered something that might improve the sharpness after CA correction.

I have been experimenting with my own auto CA correction in GMIC. The process for adjusting the red channel on a tile by tile basis is:

1) detect red channel offset 2) demosaic green channel only. It is important this is as accurate as possible using just the green channel information. 3) shift green channel to match the red channel using whole pixels 4) get the difference between the red pixels and the shifted green pixels 5) interpolated the missing values on the difference. (I use the green channel to guide the interpolation. The diagonals are interpolated first, based on directional information from the green channel.) 6) shift the interpolated differences by the opposite amount you applied to the green shifting 7) generate a new red channel from the interpolated green and interpolated differences. 8) apply the original Bayer pattern to the new red channel 9) You now have a Bayer patterned raw image with much less CA

Whole-pixel shifts seem to be adequate on the images I am using to test. Sub-pixel shifting also works but I am yet to determine how subsequent demosaicing will be affected by the differences.