transformations
NiftyReg uses text files to save rigid and affine matrix parametrisation and relies on the NifTI file format to save all its non-linear variant. All parametrisations, whether global or local, are encoded in physical space (e.g. mm) rather than voxel space. For all executables, the physical space is defined from the NifTI file headers. If the sform_code value is greater that 0, the sto_xyz matrix is used to convert voxel indices in physical units and the sto_ijk is used to convert from physical space to voxel space. If the sform_code value is equal to 0, then the qto_xjz and qto_ijk matrices are used to transform to and from physical space.
Within NiftyReg, the reg_aladin and reg_transform executable can save rigid and affine transformation matrices. These are saved as text files containing single 4-by-4 matrix M. The matrix encode transformation applied to a coordinate x,y,z in the reference (target or fixed) image such that [x',y',z',1]' = M * [x,y,z,1]', where x',y',z' typically denotes the corresponding coordinate in the floating (source, moving) image.
Note that for 2D input images, the transformation matrices are also saved as 4-by-4 matrices.
These rigid or affine transformation files can be read by the following executables:
-
reg_alaldin- to initialise an rigid or affine transformation.
-
reg_f3d- to initialise a non-linear registration.
-
reg_resample- to apply the transformation to any image.
-
reg_transform- to generate corresponding displacement or deformation field
- to compose it to any other transformation
- to halve it
- to invert it
-
reg_average- to average (Log space) multiple transformations
-
reg_jacobian- to generate the corresponding Jacobian or Jacobian determinant image
All non-linear transformations are saved using the NifTI file format. The files are 5D files, where the first three dimensions encode the dimension along the x, y and z axis respectively, the fourth is set to one and the 5th dimension is the vector size, which is typically 2 or 3 for 2D or 3D input images. The intent_code field of the NifTI header is set to NIFTI_INTENT_VECTOR. The different type of transformations that can be generated and saved are listed with an enumerator (NREG_TRANS_TYPE), which value is stored in the intent_p1 field of the NifTI file header:
-
DEF_FIELD: voxel-wise deformation field -
DISP_FIELD: voxel-wise displacement field -
CUB_SPLINE_GRID: control point cubic B-Spline parametrisation -
DEF_VEL_FIELD: voxel-wise velocity (deformation) field -
DISP_VEL_FIELD: voxel-wise velocity (displacement) dield -
SPLINE_VEL_GRID: control point Cubic B-Spline velocity parametrisation.
Where a deformation field u directly encodes directly the corresponding position x' to a point x: x' = u(x) and a displacement field encode the differential x' = x + u(x).
For all NifTI based transformation field, the field intent_name of the header is set to NREG_TRANS.
The types DEF_FIELD, DISP_FIELD and CUB_SPLINE_GRID are encoded into an Euclidean space, whereas the DEF_VEL_FIELD, DISP_VEL_FIELD and SPLINE_VEL_GRID are stationary velocity field parametrisation that needs to be exponentiated using the scaling-and-squaring approach.
Deformation field u directly encodes the corresponding point x' of a point x: x' = u(x). Deformation field can be generated by the reg_transform executable from any other transformation type and can be read by reg_transform, reg_resample, reg_jacobian and reg_average.
Their dimension is expected to be the same as the reference image along the first three axis and its fifth dimension is expected to be 2 or 3 if the reference image is 2D or 3D respectively.
Displacement field u encodes the residual to apply to a point x to obtain its corresponding point x': x' = x + u(x). It has otherwise the same characteristic than a deformation field.
Control point parametrisation consists of a lattice of control point overlaied over the space of the reference image. The lattice is defined based on a regular spacing between control point along each axis. From the coefficients associated with each control point (2 in 2D and 3 in 3D), the deformation applied to each discrete coordinate (deformation field) are computed using the cubic B-Spline approach. To ensure that every voxel is supported by the cubic B-Spline parametrisation, one control point is added 'before' the image, and two are added after the image.
The following image illustrate a grid of control point, in red, with a control point spacing of 3 units along the x- and y-axis. The reference image, in blue, is used to define the space in which the control point NifTI image is set. The voxel with index [0, 0, 0], bottom-left, in the reference image, is aligned with the voxel of index [1, 1, 1] in the control point image.
Control point parametrisations are the default output from the reg_f3d executable and can be read by reg_transform, reg_resample, reg_jacobian and reg_average.
For all stationary velocity field parametrisations, the number of scaling-and-squaring steps needed to compute the deformation field is stored in the intent_p2 field of the NiFTI header. While the Euclidean parametrisations (deformation field, displacement field and control point cubic B-Spline parametrisation) store the global and local components of the transformation merged, they are kept separate for the stationary velocity field parametrisations.
The global transformation is stored in the NifTI header extension, where num_ext is set to 2 and the ext_list contains two identical matrices that represent half the input global transformation. This enables to apply the non-linear deformation in a mid-space.
Similarly to the deformation field described above, the deformation velocity field is defined in the reference image space.
Similarly to the displacement field described above, the displacement velocity field is defined in the reference image space.
The control point cubic B-Spline velocity parametrisation is defined as the control point cubic B-Spline parametrisation described above and is used to generate an intermediate deformation velocity field. When the symmetric approach is used (-vel argument in reg_f3d), the control point grid is defined in the largest overlap area of both input images in their mid-space, as defined by the input global transformation. If no global transformation is defined, an identity matrix is used instead.