Automatic CA correction failure

[paolodepetrillo]

The automatic CA correction under "Sensor with Bayer Matrix" fails for one specific raw file. This file was taken with a sharp macro lens so doesn't really need any correction. I understand the algorithm isn't expected to work perfectly in all cases but I suspect this might be worth looking into.

These screenshots show the file opened and zoomed to 1:1 with Neutral profile and the auto CA correction turned on and off. Note the red and green artifacts on edges in the first image:

The raw file from my Olympus E-P5 is at:
https://paolodepetrillo.github.io/P6124975.orf
https://paolodepetrillo.github.io/P6124975.orf.pp3

I am using version 5.8, but the problem also occurred with the AppImages of 5.4 and 5.5, and also with Darktable which uses the same CA correction code.

Version: 5.8
Branch: releases
Commit: 9a9e0acbf
Commit date: 2020-02-04
Compiler: cc 9.2.0
Processor: x86_64
System: Linux
Bit depth: 64 bits
Gtkmm: V3.24.2
Lensfun: V0.3.95.0
Build type: Release
Build flags: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -std=c++11  -Werror=unused-label -Werror=delete-incomplete -Wall -Wuninitialized -Wcast-qual -Wno-deprecated-declarations -Wno-unused-result -fopenmp -Werror=unknown-pragmas -O3 -DNDEBUG -ftree-vectorize
Link flags: -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
OpenMP support: ON
MMAP support: ON

Linux paolo-desktop 5.7.2-arch1-1 #1 SMP PREEMPT Wed, 10 Jun 2020 20:36:24 +0000 x86_64 GNU/Linux

I'm not familiar with how the algorithm works, but I think the problem might be occurring here:

RawTherapee/rtengine/CA_correct_RT.cc

Line 809 in d033dbc

//if too few data points, restrict the order of the fit to linear

For my image, on the first pass, numblox[1] is 27. This value falls between 32 and 10, so it changes polyord and numpar but leaves processpasstwo true.
If I comment this out so that it does not change polyord and numpar, then the problem does not occur and it makes almost no change to the image, as expected since the image doesn't seem to need any CA correction.

[heckflosse]

Using a 5.8 dev build you can use this

[paolodepetrillo]

Thanks! That does fix the problem for my image with the latest version in dev. It results in a much larger value of numblox[1] avoiding the code that caused the problem originally.

I suspect that there might still be something wrong in the case where numblox[1] < 32, although I might just be misunderstanding what it's doing.
It looks like the loop on lines 784-806 sets up polymat[c][dir] as a 16x16 matrix flattened into a 256 element array, and shiftmat[c][dir] as a 16 element array, where each element of shiftmat corresponds to a row of polymat.
When 10 <= numblox[1] < 32, numpar is changed from 16 to 4, and then LinEqSolve with numpar=4 interprets the first 16 elements of polymat[c][dir] as if it were a 4x4 matrix flattened into a 16 element array, when it's really just the first row of the 16x16 matrix.

[heckflosse]

To get a good result from raw ca-correction, you need a good preprocessing white balance. That's also the case for a good demosaic result. If you shoot for example uniwb (fixed white balance in camera), RT has to use preprocessing auto-wb before, because in this case the wb reported by the camera will be wrong.

If you set your Camera to Auto-Wb, the new feature will use this wb for prepocessing and demosaic, and if the wb is good, you will get good results.

Imho there no changes needes to the current raw-ca-correction algorithm. Better to get correct input for correct output.

But that maybe only my point of view.

Ingo