[Insight-users] Re: direction API misleading

[Bill Lorensen]

Simon,
Agreed that having unused directions in itkImage is misleading, but I'm
afraid we are stuck with it. We cannot break backward compatibility by
introducing compile errors. Runtime feedback to the user is appropriate. I
like your idea about notifying the user if orientation is not identity for
itkImage's.

There is another possibility. One reason we added a new itkOrientedImage was
because there was a large performance hit on the TransformXtoY methods. A
while back, I used metatemplate programming to improve the performance of
the transform mehods for OrientedImage. I've been looking at timing results
(in Testing/Code/Common/itkTimeProbesTest). It looks like optimized builds
actually perfrom those methods faster for OrientedImage than Image. Debug
builds are sitgnificasntly slower for OrientedImage versus Image. But, in
general, itk can have a huge (5-30) performance hit for debug builds. On
gnu, performance improvements on optimized builds holds up to dimension 6.
After that, there is a big performance hit. I think this is due to template
depth limitations.

It may be possible (after this next release) to make the OrientedImage and
Image identical. We have to think about the ramifications of this. And, of
course, we have to make sure that directions are properly handled throughout
itk's algorithms.

Anyway, this discussion is certainly healthy and necessary.

Bill

On Fri, Feb 1, 2008 at 1:29 PM, Simon Warfield <
simon.warfield at childrens.harvard.edu> wrote:

> 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
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/insight-users/attachments/20080201/2a6137e7/attachment.html