Simon,<br>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.<br>
<br>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.<br>
<br>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.<br>
<br>Anyway, this discussion is certainly healthy and necessary.<br><br>Bill<br><br><div class="gmail_quote">On Fri, Feb 1, 2008 at 1:29 PM, Simon Warfield <<a href="mailto:simon.warfield@childrens.harvard.edu">simon.warfield@childrens.harvard.edu</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">Karthik Krishnan wrote:<br>
> On 2/1/08, *Simon Warfield* <<a href="mailto:simon.warfield@childrens.harvard.edu">simon.warfield@childrens.harvard.edu</a><br>
</div><div><div></div><div class="Wj3C7c">> <mailto:<a href="mailto:simon.warfield@childrens.harvard.edu">simon.warfield@childrens.harvard.edu</a>>> wrote:<br>
><br>
><br>
> The problem is that itk::Image inherits an API from itk::ImageBase to<br>
> store and manipulate Directions, just like an OrientedImage,<br>
> but doesn't act on them. It is particularly confusing for new users -<br>
> what developer would expect us to design an image class that has<br>
> directions but ignores them ?<br>
><br>
><br>
> I agree. It would have been great if itk::Image was an OrientedImage<br>
> to start from, but that isn't the case. The fact remains that<br>
> itk::Image is the predominant way to represent images ion in ITK.<br>
><br>
> Direction in itk::ImageBase should simply be treated as MetaData. It<br>
> is present in the superclass so as to preserve this meta-data, so that<br>
> direction information can be propagated through the pipeline. A<br>
> ImageWriter or filter that deems it fit to use the direction info uses<br>
> it, while several others ignore it. Please see<br>
><br>
> itk::ImageBase::CopyInformation(...)<br>
><br>
> OrientedImage is one of the subclasses that uses the direction<br>
> information correctly. Filters that operate on OrientedImage should<br>
> take the direction cosines into consideration.<br>
><br>
> ImageAdaptor now supports the correct storing and passing of direction<br>
> information, but inherits the transforming of physical indexes<br>
> from the<br>
> base image type. If the base image type is OrientedImage then<br>
> direction<br>
> information is utilized, and physical coordinates can be used<br>
> correctly.<br>
> However, a VectorImageToImageAdaptor<br>
><br>
><br>
> VectorImageToImageAdaptor, like ImageAdaptor simply needs to override<br>
> the SetDirection and GetDirection methods from itk::ImageBase and<br>
> delegate the responsibility to the image its provide facade to. Is<br>
> that right ?<br>
</div></div>No, the possibility to set a direction in an image class that doesn't<br>
use the direction information needs to be removed.<br>
It should be a compile time error.<br>
<br>
The direction information should be held in the derived classes that<br>
support orientation, not in the base class. In the base class it is<br>
extraneous and misleading.<br>
The constraints on the pipeline for dealing with metadata shouldn't<br>
require the injection of a set of method calls that don't function into<br>
the base class.<br>
<div class="Ih2E3d"><br>
> I'll commit the fix.<br>
</div>If you want to preserve the current misleading design then in order to<br>
provide a TransformPhysical... and a TransformIndex... that uses the<br>
orientation information then we need to have<br>
an OrientedVectorImage class and an OrientedVariableLengthVectorImage class.<br>
<br>
And it should be a run-time error to call TransformPhysical... etc. on<br>
an unoriented image with non-identity direction information.<br>
<br>
><br>
> Thanks<br>
> --<br>
> karthik<br>
<font color="#888888"><br>
<br>
--<br>
Simon K. Warfield, Ph.D. <a href="mailto:simon.warfield@childrens.harvard.edu">simon.warfield@childrens.harvard.edu</a><br>
Associate Professor of Radiology, Harvard Medical School<br>
Director, Computational Radiology Laboratory,<br>
Wolbach 215, Department of Radiology,<br>
Children's Hospital Boston<br>
300 Longwood Avenue Boston MA 02115<br>
Phone: 617-355-4566 FAX: 617-730-0635<br>
</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
Insight-users mailing list<br>
<a href="mailto:Insight-users@itk.org">Insight-users@itk.org</a><br>
<a href="http://www.itk.org/mailman/listinfo/insight-users" target="_blank">http://www.itk.org/mailman/listinfo/insight-users</a><br>
</div></div></blockquote></div><br>