I see from: http://nifti.nimh.nih.gov/pub/dist/src/niftilib/nifti1.h that NIfTI allows a displacement vector intent code (snippet at end of email). However, I think different software/research-groups have different interpretations of what a "displacement vector" actually is... For example, SPM5's HDW toolbox stores non-rigid transformations in 5D NIfTI files, with code 1006. The vectors actually stored are the world/mm coordinates that each voxel maps to ("mapping"), not the displacement ("offset") in mm from the world coordinates given by the q/s-form and the desired end-points. Other software might store the latter (for example, implementations of Freeborough/Crum fluid registration that I have access to do this), which means that the identity transformation is stored as zeros. It might also be useful to allow the vectors stored to be the displacements of control-points/knots for a B-spline FFD style non-rigid transformation. Another option is whether mappings/offsets are in voxels or world-coordinates. Perhaps the currently unused parameter fields could be standardised to allow these different options. E.g.
intent_p1 = 0 for SPM5-HDW style mapping (if this is the default, existing SPM5 y_ fields would be "correct")
intent_p1 = 1 for displacement offsets
intent_p1 = 2 for control-point mappings
intent_p1 = 3 for control-point offsets
intent_p2 = 0 for world-space (if this is the default, existing SPM5 y_ fields would be "correct")
intent_p2 = 1 for voxel-space
Or similar. What do people think?
All the best,
Ged.
/*! To signify that the vector value at each voxel is to be taken
as a displacement field or vector:
- dataset must have a 5th dimension
- intent_code must be NIFTI_INTENT_DISPVECT
- dim[5] must be the dimensionality of the displacment
vector (e.g., 3 for spatial displacement, 2 for in-plane) */
#define NIFTI_INTENT_DISPVECT 1006 /* specifically for displacements */
#define NIFTI_INTENT_VECTOR 1007 /* for any other type of vector */
