[Insight-users] Re: direction API misleading

[Simon Warfield]

Karthik Krishnan wrote:
> On 2/1/08, *Simon Warfield* <simon.warfield at childrens.harvard.edu 
> <mailto:simon.warfield at childrens.harvard.edu>> wrote:
>
>
>     The problem is that itk::Image inherits an API from itk::ImageBase to
>     store and manipulate Directions, just like an OrientedImage,
>     but doesn't act on them.  It is particularly confusing for new users -
>     what developer would expect us to design an image class that has
>     directions but ignores them ?
>
>
> I agree. It would have been great if itk::Image was an OrientedImage 
> to start from, but that isn't the case. The fact remains that 
> itk::Image is the predominant way to represent images ion in ITK. 
>
> Direction in itk::ImageBase should simply be treated as MetaData.  It 
> is present in the superclass so as to preserve this meta-data, so that 
> direction information can be propagated through the pipeline. A 
> ImageWriter or filter that deems it fit to use the direction info uses 
> it, while several others ignore it. Please see
>
>    itk::ImageBase::CopyInformation(...)
>
> OrientedImage is one of the subclasses that uses the direction 
> information correctly. Filters that operate on OrientedImage should 
> take the direction cosines into consideration.
>
>     ImageAdaptor now supports the correct storing and passing of direction
>     information,  but inherits the transforming of physical indexes
>     from the
>     base image type.  If the base image type is OrientedImage then
>     direction
>     information is utilized, and physical coordinates can be used
>     correctly.
>     However, a VectorImageToImageAdaptor 
>
>  
> VectorImageToImageAdaptor, like ImageAdaptor simply needs to override 
> the SetDirection and GetDirection methods from itk::ImageBase and 
> delegate the responsibility to the image its provide facade to. Is 
> that right ?
No, the possibility to set a direction in an image class that doesn't 
use the direction information needs to be removed.
It should be a compile time error.

The direction information should be held in the derived classes that 
support orientation, not in the base class. In the base class it is 
extraneous and misleading.
The constraints on the pipeline for dealing with metadata shouldn't 
require the injection of a set of method calls that don't function into 
the base class.

> I'll commit the fix.
If you want to preserve the current misleading design then in order to 
provide a TransformPhysical... and a TransformIndex... that uses the 
orientation information then we need to have
an OrientedVectorImage class and an OrientedVariableLengthVectorImage class.

And it should be a run-time error to call TransformPhysical... etc. on 
an unoriented image with non-identity direction information.

>
> Thanks
> --
> karthik


-- 
Simon K. Warfield, Ph.D.   simon.warfield at childrens.harvard.edu
Associate Professor of Radiology,     Harvard Medical School
Director, Computational Radiology Laboratory,
Wolbach 215, Department of Radiology, 
Children's Hospital Boston
300 Longwood Avenue Boston MA 02115
Phone: 617-355-4566                           FAX: 617-730-0635