[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-