Lalith: Understanding the discrepency between ITK-snap transformation/rotation parameters and c3d_affine_tool

[shiyam...@gmail.com]

Hi Paul, 

Huge fan of your work (c3d, greedy and we absolutely love the itk-snap 4.0 (alpha) in our lab). Currently, we are performing an experiment, where we impose a rigid motion (translation + rotation) on a brain digital phantom pair (rigid transform applied to the moving image) and try to recover the motion using greedy (rigid alignment between the fixed and moving image with applied rigid transform). Our goal is to see if the recovered motion ~= the applied motion. We applied the rigid motion using simpleITK (translation (mm) = 7, 3 ,4 and rotation(deg) = 1.14, 0.57, 1.71) and later used greedy to perform the registration and generate the 'rigid.mat' file. When I use c3d_affine_tool -info-full functionality on the rigid.mat file, to check the Affine parameters, the rotation parameters are close (1.14, 0.56, 1.72) but the translation parameters are way off (-18.9, 10.60, -0.75). However, when I use the ITK-snap registration GUI to load the 'rigid.mat' as a c3d transform file and visualize the motion parameters, they are remarkably close to the applied motion (please refer to the attachment). The translation is 7.02, 2.91, 4.03 and the rotation is 1.12, 0.6 and 1.73. 

I was wondering if the decomposition of the transformation matrix is done differently in the ITK-snap in comparison to the c3d_affine_tool. I apologise if the question is naive, I really would like to understand the discrepancy (obviously I am missing something). The idea is to recreate whatever itk-snap does in the command line, so that we can bypass the manual verification using itk-snap.

Looking forward to hearing from you! 

Cheers,

Lalith 

[hmk...@yahoo.dk]

The big shift in the translation parameters is probably due to the centre of rotation. In some programs, that is accounted for a separate vector and in others its "added" to the translation parameters. Also be aware of what the default centre of rotation is assumed to be - sometimes the centre voxel, sometimes the centre coordinate ... I find transformations to be quite confusing and hard to debug - but I am starting to have a good grasp of how to decompose the output from ITK-snap, if this is still relevant for you

\Martin

[shiyam...@gmail.com]

Hi Martin, 

I feel so silly. Sorry about not responding earlier. Absolutely - this is still relevant for me. Can you help me out? 

My active mail-id: Lalith.sh...@meduniwien.ac.at