Difference between revisions of "Proposals:Oriented Image Registration"

From KitwarePublic
Jump to navigationJump to search
 
(2 intermediate revisions by the same user not shown)
Line 35: Line 35:
Details on each one of these items follow
Details on each one of these items follow


== Adding Gradient Transformation Methods to the itk::ImageBase ==
== Adding Gradient Transformation Methods to the itk::Image & itk::OrientedImage ==
 
=== Naming Options ===


Following the naming of the existing methods
Following the naming of the existing methods
Line 42: Line 44:
* TransformPhysicalPointToIndex
* TransformPhysicalPointToIndex


we propose to add the methods
we could add the methods


* TransformIndexToPhysicalGradient
* TransformIndexToPhysicalGradient
Line 60: Line 62:
* ApplyDirectionToGradient
* ApplyDirectionToGradient
* RotateGradientsByDirectionCosines
* RotateGradientsByDirectionCosines
=== Implementation Issues ===
Given that the LevelSet framework uses image gradients commonly in connection with the computation of an Advection field, and the Vector<> type has been used for representing those fields, the method in the itk::Image that will compute the rotation of a Gradient, must be implemented in terms of a FixedArray. In practice this is not too bad, specially considering that both a Vector and a Covariant Vector will behave similarly under rotations, and therefore it makes sense to provide a method that could rotate either one.  The danger here is for a developer to attempt to use this method with any of the other classes that derive from the FixedArray<> but that do not represent Vector types, for example the itk::Point.
The current first implementation of the method is called:
  RotateArrayByDirectionCosines
and its signature is:
    template<class TCoordRep>
    void RotateArrayByDirectionCosines(
      const FixedArray<TCoordRep, VImageDimension> & inputGradient,
            FixedArray<TCoordRep, VImageDimension> & outputGradient ) const


== Adding Boolean flags to Image Gradient computation classes ==
== Adding Boolean flags to Image Gradient computation classes ==
Line 68: Line 85:
* Code/Common/itkCentralDifferenceImageFunction
* Code/Common/itkCentralDifferenceImageFunction
* Code/BasicFilters/itkGradientImageFilter
* Code/BasicFilters/itkGradientImageFilter
* Insight/Code/BasicFilters/itkBSplineInterpolateImageFunction


To each one of these classes we propose to add a private member variable, boolean flag named
To each one of these classes we propose to add a private member variable, boolean flag named
Line 87: Line 106:
== Turning on boolean flags from Image Metrics ==
== Turning on boolean flags from Image Metrics ==


We will list here all the ITK Image Metrics, in a table, to create a check list that will ensure that we visited all the Metrics and added the code to turn the boolean flags of gradient computation helper classes.
We list here all the ITK Image Metrics to provide a check list that will ensure that we visited all the Metrics and added the code to turn the boolean flags of gradient computation helper classes. Once the code is fixed we should provide tests that verify the correct behaviour of the resulting class.
 
{| border="1"
|- bgcolor="#abcdef"
! Metric !! Helper !! Code Fixed !! Fix Tested
|-
| itkCompareHistogramImageToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkCorrelationCoefficientHistogramImageToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkGradientDifferenceImageToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkHistogramImageToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkImageToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkImageToSpatialObjectMetric  ||  TBD  ||  No  ||  No
|-
| itkKappaStatisticImageToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkKullbackLeiblerCompareHistogramImageToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkMatchCardinalityImageToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkMattesMutualInformationImageToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkMeanReciprocalSquareDifferenceImageToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkMeanReciprocalSquareDifferencePointSetToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkMeanSquaresHistogramImageToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkMeanSquaresImageToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkMeanSquaresPointSetToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkMutualInformationHistogramImageToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkMutualInformationImageToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkNormalizedCorrelationImageToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkNormalizedCorrelationPointSetToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkNormalizedMutualInformationHistogramImageToImageMetric  ||  TBD  ||  No  ||  No
|-
| itkPointSetToImageMetric  ||  TBD  ||  No  ||  No
|}


== Adding a CMake Flag for preserving backward-compatibility ==
== Adding a CMake Flag for preserving backward-compatibility ==

Latest revision as of 11:05, 8 October 2007

Proposal

itkOrientedImage should be the preferred image to use for performing image registration.

Currently the direction cosines contained in this image are not used consistently by all the classes involved in image registration.

This page proposes a comprehensive approach for fixing this problem.

The Problem

Most image metrics internally compute image gradients as part of the process of computing the derivatives of the Metric. Such image gradients are currently computed in the space of the image grid, taking into account the pixel spacing but not taking into account the image direction

This issue has been logged as Bug Entry: 5081

http://public.kitware.com/Bug/view.php?id=5081

and has been discussed multiple times in the developers list (citation needed)

The Proposed Solution

The prososed solution involves modifications of the toolkit at four different levels

  1. Adding a methods to itk::ImageBase for transforming index space Gradients into physical space Gradients and back
    • These methods will be overloaded in the oriented image.
    • The methods will be implemented using Template Metaprogramming in order to reduce their impact on performance
  2. Adding boolean flags to all classes that compute image gradients
    • When the boolean flags are ON the image direction will be taken into account
    • The boolean flags will be initialized to OFF by default in order to provide backward-compatibility
  3. The ImageMetrics will turn ON the boolean flags of helper classes used for computing gradients
  4. An advanced CMake variable will enable the use of all the mechanisms defined above
    • The variable will be OFF by default in order to provide backward-compatibility

Details on each one of these items follow

Adding Gradient Transformation Methods to the itk::Image & itk::OrientedImage

Naming Options

Following the naming of the existing methods

  • TransformIndexToPhysicalPoint
  • TransformPhysicalPointToIndex

we could add the methods

  • TransformIndexToPhysicalGradient
  • TransformPhysicalGradientToIndex

or we could be more specific and say "IndexGradient"

  • TransformIndexGradientToPhysicalGradient
  • TransformPhysicalGradientToIndexGradient

to avoid the ambiguity of whether we are actually transforming indices into gradients, or transforming gradients that were computed in index space into gradient that are computed in physical space.

Note that strictly speaking, currently the gradients are not computed in index space, but in a space that takes the spacing but not the direction into account. This is not quite index space, but it is not physical space either.

We could acknowledge that fact and use a naming such as one of the following

  • ApplyDirectionToGradient
  • RotateGradientsByDirectionCosines

Implementation Issues

Given that the LevelSet framework uses image gradients commonly in connection with the computation of an Advection field, and the Vector<> type has been used for representing those fields, the method in the itk::Image that will compute the rotation of a Gradient, must be implemented in terms of a FixedArray. In practice this is not too bad, specially considering that both a Vector and a Covariant Vector will behave similarly under rotations, and therefore it makes sense to provide a method that could rotate either one. The danger here is for a developer to attempt to use this method with any of the other classes that derive from the FixedArray<> but that do not represent Vector types, for example the itk::Point.

The current first implementation of the method is called:

  RotateArrayByDirectionCosines

and its signature is:

   template<class TCoordRep>
   void RotateArrayByDirectionCosines(
     const FixedArray<TCoordRep, VImageDimension> & inputGradient,
           FixedArray<TCoordRep, VImageDimension> & outputGradient ) const

Adding Boolean flags to Image Gradient computation classes

So far we have identified the following helper classes:

  • Code/BasicFilters/itkGradientRecursiveGaussianImageFilter
  • Code/Common/itkCentralDifferenceImageFunction
  • Code/BasicFilters/itkGradientImageFilter
  • Insight/Code/BasicFilters/itkBSplineInterpolateImageFunction


To each one of these classes we propose to add a private member variable, boolean flag named

  m_UseImageDirection

along with its corresponding Set/Get methods defined by Macros

  • itkSetMacro( UseImageDirection, bool );
  • itkGetMacro( UseImageDirection, bool );
  • itkBooleanMacro( UseImageDirection );

The flag will be set to false in the constructor.

In the GenerateData() method the flag will be checked and if it is true the gradients will be passed through the itk::Image and itk::OrientedImage methods (to be named) that rotate Gradients using the image direction cosines.

The existence of this flag and its associated Set/Get method doesn't have to be controlled by conditional compilation under the CMake variable. However the use of the flag in the GenerateData() method will have to be.

Turning on boolean flags from Image Metrics

We list here all the ITK Image Metrics to provide a check list that will ensure that we visited all the Metrics and added the code to turn the boolean flags of gradient computation helper classes. Once the code is fixed we should provide tests that verify the correct behaviour of the resulting class.

Metric Helper Code Fixed Fix Tested
itkCompareHistogramImageToImageMetric TBD No No
itkCorrelationCoefficientHistogramImageToImageMetric TBD No No
itkGradientDifferenceImageToImageMetric TBD No No
itkHistogramImageToImageMetric TBD No No
itkImageToImageMetric TBD No No
itkImageToSpatialObjectMetric TBD No No
itkKappaStatisticImageToImageMetric TBD No No
itkKullbackLeiblerCompareHistogramImageToImageMetric TBD No No
itkMatchCardinalityImageToImageMetric TBD No No
itkMattesMutualInformationImageToImageMetric TBD No No
itkMeanReciprocalSquareDifferenceImageToImageMetric TBD No No
itkMeanReciprocalSquareDifferencePointSetToImageMetric TBD No No
itkMeanSquaresHistogramImageToImageMetric TBD No No
itkMeanSquaresImageToImageMetric TBD No No
itkMeanSquaresPointSetToImageMetric TBD No No
itkMutualInformationHistogramImageToImageMetric TBD No No
itkMutualInformationImageToImageMetric TBD No No
itkNormalizedCorrelationImageToImageMetric TBD No No
itkNormalizedCorrelationPointSetToImageMetric TBD No No
itkNormalizedMutualInformationHistogramImageToImageMetric TBD No No
itkPointSetToImageMetric TBD No No

Adding a CMake Flag for preserving backward-compatibility

The CMake advance variable

   ITK_USE_ORIENTED_IMAGE_DIRECTION

has been added to the files

  • Insight/CMakeLists.txt
  • Insight/itkConfigure.h.in

In this way, the symbol is now available to be used in #define statements in the code.