Proposal for Revised Framework: Difference between revisions
No edit summary |
No edit summary |
||
(4 intermediate revisions by the same user not shown) | |||
Line 3: | Line 3: | ||
There are a few key ingredients we need: | There are a few key ingredients we need: | ||
1. itkComposeTransform class , derived from itkTransform | 1. itkComposeTransform class , derived from itkTransform ( look at vtkGeneralTransform , functions as a pipeline i.e. if you change one transform then the composition is updated) | ||
2. itkDeformationFieldTransform class , derived from itkTransform (add Trait IsInvertible , throw exception ) | 2. itkDeformationFieldTransform class , derived from itkTransform (add Trait IsInvertible , throw exception ) | ||
3. itkTransformImageFilter --- takes itkTransform as input | 3. itkTransformImageFilter --- takes itkTransform as input | ||
4. itkCreateComposedTransformFilter --- figure out details later | |||
Hans: in itkV4 we need to read/write composed mappings with a standardized I/O for transformations. | |||
Then , pseudocode for a registration is: | Then , pseudocode for a registration is: | ||
Line 46: | Line 50: | ||
Finally, note that this framework is general for other objects (Meshes) but, to support this, we may | Finally, note that this framework is general for other objects (Meshes) but, to support this, we may | ||
need generalized iterators (e.g. random iterator over meshes looks the same as random iterator over images). | need generalized iterators (e.g. random iterator over meshes looks the same as random iterator over images). | ||
Metrics in ITK should have consistent maximum/minimum metric values along with the optimizers. |
Latest revision as of 15:33, 14 September 2010
Let us suppose we want to perform a registration with the new framework.
There are a few key ingredients we need:
1. itkComposeTransform class , derived from itkTransform ( look at vtkGeneralTransform , functions as a pipeline i.e. if you change one transform then the composition is updated)
2. itkDeformationFieldTransform class , derived from itkTransform (add Trait IsInvertible , throw exception )
3. itkTransformImageFilter --- takes itkTransform as input
4. itkCreateComposedTransformFilter --- figure out details later
Hans: in itkV4 we need to read/write composed mappings with a standardized I/O for transformations.
Then , pseudocode for a registration is:
1. Set up a multi-resolution optimization over the TransformImageFilter
--- note that we can control the resolution of the TransformImageFilter output.
2. For each transform within itkComposeTransform
--- Optimize: the metric(s) associated with that transform for n iterations or convergence
3. go to next level
In the case of a symmetric registration, pseudocode :
1. Set up a multi-resolution optimization over the TransformImageFilter1 and TransformImageFilter2
--- we usually would set up these filter symmetrically i.e. both have (affine,deformation) maps within and we optimize each pair together
2. For each transform pair taken from ComposeTransform1 and ComposeTransform2
--- Optimize: the metric(s) associated with that transform for n iterations or convergence
3. go to next level
For the Optimize step:
for each transform within ComposeTransform :
--- compute the update to the transform given its associated metric(s)
--- the update may be one-sided (asymmetric) or two-sided (symmetric)
--- note: the metrics do not need access to the transform. they only access outputs of ComposeTransform objects.
Finally, note that this framework is general for other objects (Meshes) but, to support this, we may
need generalized iterators (e.g. random iterator over meshes looks the same as random iterator over images).
Metrics in ITK should have consistent maximum/minimum metric values along with the optimizers.