Running the script below shows that in the presence of non-isotropic scale factors, shear and scales are not correctly recovered from the transformation matrix.

As a result, the computed rotation angles are also not correct in this case.

#!/usr/bin/env bash
# The idea of this script is to do a round trip test on a CMTK affine
# registration using the dof2mat/mat2dof tools
mkdir -p testinit.list
cat << EOF > testinit.list/registration
! TYPEDSTREAM 1.1
registration {
reference_study "reference"
floating_study "floating"
affine_xform {
xlate 100 50 50
rotate 3 3 3
scale 1 1.1 1.1
shear 0 0 0
center 0 0 0
}
}
EOF
cat << EOF > testinit.list/studylist
! TYPEDSTREAM 1.1
source {
studyname "reference"
}
source {
studyname "floating"
}
EOF
# Set if required
DOF2MAT="${CMTKBIN}dof2mat"
MAT2DOF="${CMTKBIN}mat2dof"
$DOF2MAT testinit.list | $MAT2DOF --list testroundtrip.list
gunzip -f testroundtrip.list/registration.gz
diff testinit.list testroundtrip.list

The root of the problem is that affine matrices with non-zero shear were not created correctly. Thus, scale factors and shear coefficients could then not unambiguously recovered.

This also applies to transformations without shear, but anisotropic scale, if these were inverted (thus introducing shear in the inverse transformation).

Most previously-computed transformations should be correct, with the exception of transformations fitted to landmarks or computed using principal axes (these create the matrix directly, then derive canonical parameters).

SVN trunk r5048 should fix all this in the following way:

- Newly-created transformations are now (hopefully) correct - this required a re-definition of the meaning of shear coefficients (also more logical now).

- Exiting transformation parameter files will continue to be read and create the same matrix representation as before (although that representation may be flawed; see above).

- New transformation files will look identical to old ones but use a different meaning of the "shear" coefficients. To distinguish old from new files, the release code in the first line of the transformation files has been changed from "1.1" to "2.4", thus showing that the respective files require at least CMTK 2.4 to be read correctly.

THIS HAS NOT YET BEEN THOROUGHLY TESTED, so r5048 should NOT be used in production mode just yet! (This bug will be left open until I am confident that this is now properly working.)

It seems the primary problem is with the anisotropic scale factors - a matrix with shears but isotropic scale decomposes correctly (up to the limits of numerical precision).