Originally posted by Cinly Ooi:
Hi,

Probably not strictly a "need", but SPM does currently use both in one situation: when images are rigidly aligned to MNI ("imported") for use with DARTEL (or the new Geodesic Shooting) registration tool, the two transforms are used so that the nonrigid transformation can be derived from the resliced images but applied to the originals (i.e. the rigid then DARTEL transformations don't involve interpolating twice). Obviously there are other ways of doing this, but I guess John did this to avoid having to save the rigid transformation anywhere other than the NIfTI image itself.

Perhaps a very simple standard format (or even simpler documentation of how to do it with the current format) specifically for saving transformations would be helpful? This is something which is not currently standardised across packages (e.g. one can't easily take flirt and/or fnirt transformations from FSL and transform an image in SPM, or use them to initialise a voxel-wise deformation), but it seems that it could and should be if they are using the same image file format.

For voxel-wise non-rigid transformations, SPM is already saving vector fields with components along the 5th dimension, as specified in the NIfTI standard, though I think the standard is a little ambiguous about whether a transformation vector field contains offsets (identity transform being all zeros) or coordinates of where voxels map to (i.e. original location plus offset), and whether these are in voxels or millimetres. A little documentation would probably suffice to standardise that.

For B-spline transformations, one could use the sform to specify the control point locations, and then use a vector field as before; again the main problem would be to document the standard and persuade different software packages to agree on it. For the simpler affine and rigid cases, presumably we could simply use NIfTI "images" without any imaging data, with all dimensions zero, and the transform just in the sform (no obvious advantage to allowing qform too?).

NIfTI2 seems like a good opportunity to try to standardise some of these usages which are already possible, without any changes to the library, just some agreement across different developers and groups. What do people think?

All the best,
Ged

P.S. Related point, while I think of it... Motion correction of 4D time-series changes the voxel-world mapping for each volume; if one doesn't want to reslice the data at this stage (e.g. because motion corrected data will be registered to a structural image and/or normalised to MNI) then this breaks the NIfTI format slightly, since the 4D series can have only one sform (and one qform, but that doesn't help here). SPM's solution to this is to save a matlab variable with the list of transformation matrices, but it would be much nicer either to allow nifti2 to have one transform per 3D volume, or to standardise the storage of transformations in NIfTI format, so that SPM could use this instead of matlab's format, and potentially allow consistency across multiple packages that do motion correction and/or subsequent processing.