[Insight-developers] changes to image transforms

[Luis Ibanez]

Hi Damion,

That sounds good !

---

A couple of comments:

1) If the transform member variables are removed
    the Set/Get macros should go too since they
    rely on the variables to be there. (this is
    probably the cleanest way to remove this code)


2) I would guess that you will not have much
    conflict with other filters since few of them
    use the image methods for converting indices
    to points.



BTW, the repository has been tagged. So, please
feel free to proceed with any changes/modifications
if you wish.


    Luis


----------------------------


Damion Shelton wrote:

> 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-
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>