Estimated inverses should be more robust

[bogovicj]

Iterative estimation of inverses can behave poorly at times.

It seems more likely to occur when the transformation has a large scale component.

See
https://forum.image.sc/t/how-to-transform-points-locations-csv-with-bigwarp/35368/21?u=bogovicj

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/how-to-transform-points-locations-csv-with-bigwarp/35368/24

[NicoKiaru]

I've had the same issue while trying to adapt my code to the new BigWarp version.

The use case is a bit different I think. I have to double check. The jacobian is not invertible - the third column is 0 0 0 0.

it pops up in the "VOLUME" bounding box estimator - I don't have the full stack trace, but it fails in:

• InverseRealTransformGradientDescent#inverseTol
• RealTransformFiniteDerivatives#jacobian
• this.jacobian.set(newjac); -> newjac is not invertible.

[bogovicj]

Started some work toward this here:
https://github.com/imglib/imglib2-realtransform/tree/inverseRefactorEjml
but needs testing.

Most immediately relevant for the "The jacobian is not invertible" is that I now use an EJML DMatrixRMaj to store the jacobian rather than an AffineTransform. The latter complains when its not invertible.

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/bigwarp-no-brightness-colour/95092/2