NAMIC Wiki:Community Registration

Slicer registration framework

Goals and Requirements

Goal: Provide complete registration functionality for the NAMIC data in Slicer for end users. Should satisfy the following requirements:

• Register two structural MRI images.

• Register two DTI (Tensor-valued) images.

• Register DTI image to structural MRI image (Tensor to Scalar registration?)

• Register images using multiple channels (both scalar and tensors). E.g. atlas to subject.

• Register CT and MRI images.

• Allow user to perform Translation, Rigid, Affine, and Deformable registrations or any combination of above.

• Allow non-expert user to control the speed and quality of registration without knowing the details.

• Allow expert users to fine tune registration and optimization parameters.

Proposed Architecture and Design

1. The registration framework is designed to support translation, rigid, affine, and deformable forms of registration between images in Slicer.
2. Registration framework is implemented in four levels of Slicer architecture: ITK Registration Wrappers, VTK Registration Wrappers, TCL Registration Widget, and Slicer Registration Module.

ITK Wrappers

1. A set of ITK classes are created that wrap the itk registration pipelines consisting of multiple ITK components. These classes are derived from itk::ImageToImageFilter and have two inputs (Fixed image and Moving image) and one output (Transformed image). In addition deformable registration classes will output a Deformation Field image.
2. The internal pipeline will use ITK MiniPipeline and GraftOutput method to redirect the output of the internal pipeline.
3. The internal pipeline for Transformer based registrations will include Optimizers, Transformers, Metric, Interpolator, and Registration.
4. The registration pipeline will utilize multi-resolution Image Pyramid (Re-sampling, Luis?)[Luis comment: We should add to ITK a helper class for computing the levels of a pyramid on request, not all at the same time, and use only the resample image filter without any smoothing.]
5. To deal with a variety of optimizers and transformation classes for transformer based registrations in ITK we propose the following approach: Matrix based ITK registration classes (translation, rigid, affine) inherit from an abstract registration class templated by Optimizer type and Transformation type:

template <class TOptimizerClass, class TTransformerClass >
class ITK_EXPORT itkTransformationRegistration : public itk::ImageToImageFilter

The subclass of this class is an optimizer specific class that implement methods necessary for setting parameters of a specific optimizer type. The subclass will include the following class(s) templated by transformer type (currently only RegularStepGradientDescentOptimizer is considered, any others???) : [Luis Comment: We recently have very good results using the itk::Amoeba optimizer and the MutualInformationHistogramImageMetric]

template <class TTransformerClass >
class ITK_EXPORT itkGradientOptimizerTransformRegistrationFilter : public itk::itkTransformationRegistration <itk::RegularStepGradientDescentOptimizer, TTransformerClass >

The following subclasses have only one type of Transformer which goes with the only Optimizer type:

class ITK_EXPORT itkVersorOptimizerTransformRegistrationFilter : public itk::itkTransformationRegistration <itk::VersorRigid3DTransformOptimizer, itk::VersorRigid3DTransform>

class ITK_EXPORT itkQuaternionOptimizerTransformRegistrationFilter : public itk:: itkTransformationRegistration <itk:: QuaternionRigidTransformGradientDescentOptimizer, QuaternionRigidTransform>

[Luis comment: I would replace Quaternions with Versors. Versors are unit quaternions and therefore they take care of their internal normalization. Generic quaternions can apply both rotation and scaling.].

The following classes will instantiate the templates for Transformer specific types:

class ITK_EXPORT itkGradientTranslateionRegistrationFilter : public itk::itkGradientOptimizerTransformRegistrationFilter <itk::TranslationTransform>

class ITK_EXPORT itkGradientAffineRegistrationFilter : public itk::itkGradientOptTransformRegistrationFilter <itk::AffineTransform>

All different types of Optimizer classes will have methods for setting specific optimizer parameters.

• For Deformation Field registration two ITK wrapper classes will be created, both derived from itk::ImageToImageFilter :

itkDemonsRegistrationImageFilter : will use itk::DemonsRegitration filter.
itkBSplineRegistrationImageFilter: will use the same pipeline as matrix based registration wrappers, will apply resulting BSpline transformation to the moving image and it’s difference with fixed image  to compute Deformation Field output.

[Luis Comment: Specification about the ImageMetric to use seems to be missing here. The type of the Metric is fundamental on the choice of the optimizer. It is almost always the case that once we choose the Transform and the Metric, the choice of the optimizer becomes very restricted.]

• The following leaf ITK classes will be used inside the VTK wrappers:

1. itkGradientTranslationRegistrationFilter
2. itkGradientAffineRegistrationFilter
3. itkVersorOptimizerTransformRegistrationFilter
4. itkQuaternionOptimizerTransformRegistrationFilter
5. itkDemonsRegistrationImageFilter
6. itkBSplineRegistrationImageFilter

VTK Wrappers

1. The VTK wrappers will provide the pipeline connections between the VTK input/output images and the ITK wrapper classes used internally.
2. A hierarchy of VTK classes is designed for this purpose as shown on the diagram below. The classes are derived from vtkITKImageToImageFilter. They have two inputs (Fixed image and Moving image) and one output (Transformed image). In addition deformable registration classes will output a Deformation Field image. The leaves of the hierarchy implement registration algorithms using ITK registration wrapper classes. The ITK registration wrappers inherit from itk::ImageToImageFilter class.

Slicer TCL Registration Widget

1. VTK wrappers described above will be used in isRegistration widget as the replacement for vtkRigidIntensityRegistration class.
2. Currently vtkRigidIntensityRegistration only supports rigid transformation registration. It will be extended to support any combination of translation, rotation, affine, and deformable transformations.
3. It will support settings of optimization/registration parameters for multiple levels of resolution and multiple levels of quality.

Slicer Registration Module

1. The advance UI should reflect new options for selecting registration types and fine tuning the parameters.

Tensor Image Registration

1. Tensor pixel type should be supported in ITK.
2. Tensor to Tensor metric should be developed in ITK.
3. What about Tensor to Scalar ???
4. Tensor transformations and interpolation should be implemented in ITK.

[Luis: All this combinations are poosible, thanks to the generic programming approach used in ITK. What we will have to do is to come up with ImageMetrics for comparing Tensor-Tensor and Tensor-Scalar, as well as with interpolators for Tensors].

Multi-channel Registration

1. Can we use vector pixel type?
2. Are metric/interpolator/transformer supported for vector?

[Luis comment: It is possible, but certain classes must be added to ITK. Jeffrey Duda has a good set of classes for supporting Vector and Tensor registration. We should integrate his code into ITK.]

Prototype implementation

The examples of itkDemonsRegistrationImageFilter, vtkITKRegistrationFilter, vtkITKDeformableRegistrationFilter, vtkITKDemonsRegistrationFilter are in CVS::Slicer2 in slicer2/Modules/vtkITK/cxx