[Insight-developers] changes to image transforms

Damion Shelton beowulf@cs.cmu.edu
Sun, 9 Feb 2003 21:01:10 -0500


Per the meeting, I'll be removing the ability to set arbitrary 
transforms in the Image class, and moving this capability to a more 
specialized derived class. It looks like this will involve removing the 
following from Image:

Functions:

   itkSetObjectMacro(IndexToPhysicalTransform, TransformType );
   itkSetObjectMacro(PhysicalToIndexTransform, TransformType );
   virtual void RebuildTransforms(void) throw ( std::exception );

Member variables:

   TransformPointer  m_IndexToPhysicalTransform;
   TransformPointer  m_PhysicalToIndexTransform;

I propose keeping the 4 transform functions, which will be changed to 
virtual and not actually rely on transforms in the Image implementation 
(they will use origin and spacing directly). It may also be worthwhile 
to leave:

   /** Gets and sets for affine transforms. */
   itkSetObjectMacro(IndexToPhysicalTransform, TransformType );
   itkSetObjectMacro(PhysicalToIndexTransform, TransformType );

which in default implementation could create and return 
affine/similarity transforms as a more convenient way of accessing 
origin/spacing information.

As far as a subclass of Image goes, how about 
itk::ImageWithExplicitTransform? Subclassed from that would be 
itk::RT3DUltrasoundImage, and any other images which require transforms 
more complex than what can be represented with origin and spacing.

It may be also be useful to look through the code and determine which 
filters are general enough that using the 4 transform functions 
included in Image is appropriate. I.e., if the filter's behavior does 
not rely on an assumption of rectilinear space, it should probably use 
the transforms rather than computing pixel position from origin and 
spacing. Since the default implementation will no longer compute 
transforms using transform objects, it should be relatively fast.

Any suggestions/comments are welcome.

-Damion-