Hi! I am aiming to use 3DSlicer to visualize the effects of 3d transforms created with antsRegistration. The registration didn’t include any rigid or affine stages, just one SyN stage. I’ve confirmed that the forward and inverse transform .mat files are identity transforms. I know that the actual displacements in the forward and inverse warp nifti files are the reverse of the “intuition” in antsApplyTransforms. Specifically, the movingToFixedWarp.nii.gz is defined in the Fixed image space with the displacements pointing to each voxels corresponding location in the moving image. I noticed when loading the moving image as the background and overlaying the movingToFixed transform that arrows correspond to my intuition of how that transform affects the moving image, _not_ how the vectors exist in the warp file. Is it correct to interpret the glyph arrows as indicating the intuitive direction that “moving” is deformed to match “fixed”? Thanks for any insight!
Arrows that are shown if you visualize using Transforms module’s Display section show the transformation from the transformed coordinate system to the parent coordinate system. This is also known as “to parent” transform or “modeling” transform.
There is a small but important technical detail that for transforming images you actually need to be able to compute the inverse of the “to parent” transform, i.e., “from parent” or “resampling” transform.
Slicer (using VTK) can compute the inverse transform on the fly, so it does not matter if you have a modeling or resampling transform, you can use them in Slicer to transform any objects (images, models, markups, etc.).
To make the nomenclature clear and how it appears in Slicer:
Is it correct to interpret the glyph arrows as indicating the intuitive direction that “moving” is deformed to match “fixed”?
Yes. Due to origins of ITK (it was born as an image registration toolkit), when it writes a transform to file, it is the resampling (a.k. “from parent”) transform. Slicer knows this, and it interprets ITK transform files and displacement field files as such. ITK transform files should have a flag that specifies if the transform is “modeling” or “resampling” instead of just assuming it is always “resampling”, but ITK developers did not or could not implement this.
General-purpose software, such as Slicer must be able to store transform in either directions (because inversion may be computationally expensive and often lossy), so we extended ITK-based file formats with the ability to tell the transform type:
- for ITK transform types, we introduced new class names (
InverseDisplacementFieldTransform,InverseBSplineTransform,InverseThinPlateSplineKernelTransform) - for displacement fields in NRRD format we introduced
displacement field typecustom field
Awesome, thank you so much!!
Recently, I was trying to understand the details of how grid transforms function in Slicer and how transforms generated using ANTs in Slicer differ from those generated using ANTs at the command line. In addition to the issues that @lassoan very nicely explained above, there are a few other subtleties that I found confusing and took me a while to sort out. I am attaching my summary notes from that exploration in case they will be useful to you or others coming across this thread in the future.