[Insight-developers] Proposal: refactoring of image class hierarchy in ITK v4

[Cory Quammen]

Gaëtan,

Thank you for your thoughtful comments. You raise several good points
I hadn't considered.

> PhysicalImageBase then become less obvious. I think that all the images are
> physically placed in ITK - any idea of non physically placed image?

I pulled the notion of a non-physical image from these notes:
http://itk.org/Wiki/ITK_Release_4/Discussion_Points. I suppose a mask
image could be considered a non-physically embedded image, but
including a separate image type for just that seems like overkill.
There may be other use cases others could point to.

> While I understand that non regular spacing may be useful, I'm not sure that
> implementing that feature in a new class is the way to go.
>
> How would we avoid code duplication between similar classes? Excepted the
> physical coordinates, Image and RectilinearImage would be very similar.
> And there is no reason the LabelMap could not store the data of an image
> with an irregular spacing. Should we add a RectilinearLabelMap?
> I guess that's also true for Dan's classes (slice contiguous and single bit
> binary images) - should they also be defined as Regular and Rectilinear?

Composition would be a better overall strategy to avoid the
combinatorial class explosion you identify. I originally considered an
approach where image types would use a delegate class for representing
the mapping between indices and physical points. You could switch the
delegate from, say, a RegularIndexTransformation to a
RectilinearIndexTransformation to get the Image class to behave like a
RectilinearImage. The major downside of this approach is that the
methods TransformIndexToPhysicalPoint etc. in the delegate would need
to be virtual and performance would suffer relative to what the
existing inlined non-virtual methods provide. That said, it is
interesting to note that the Transform class methods TransformPoint()
and TransformVector() are virtual functions.

Alternatively, another template parameter could be added to the
existing image classes to avoid the performance overhead of virtual
function calls. This gets you back to a combinatorial explosion in
wrapping, though.

> I also think that we should try to keep the number of image classes quite
> low to be able to have them in the wrapping projects - wrapitk and
> simpleitk. Because they are base classes, having Image and RectilinearImage
> would make wrapitk twice as big as it is now, twice as long to build, ...

Yes, this should be avoided. I hadn't considered the implications on
wrapping. Perhaps wrapping of these image types could be optional (off
by default). I suspect that would probably be more difficult to do
that it is to say, however.

> Would it be possible to implement the non regular spacing feature in
> ImageBase without too much performance penalties?
> Get/SetSpacing may be used, for example, for a mean spacing, instead of
> doing nothing as in the example you give on the wiki.

Perhaps this would be possible to satisfy my requirements, but I think
a general solution that applies to image types with other
index-to-physical-point transformations -- such as
PhasedArray3DSpecialCoordinatesImage -- would be preferable.

Thanks again for the comments,
Cory

>
> Le 5 oct. 10 à 18:12, Cory Quammen a écrit :
>
>> Dear all,
>>
>> I've drafted a proposal for refactoring the image class hierarchy in
>> ITK v4, which can be found here:
>>
>> http://www.itk.org/Wiki/ITK_Release_4/Image_Class_Hierarchy_Refactoring
>>
>> Please feel free to modify the wiki page to address things I've
>> overlooked, suggest nomenclature improvements, or correct things I
>> have gotten wrong.
>>
>> Thank you,
>> Cory
>>
>> --
>> Cory Quammen
>> Computer Integrated Systems for Microscopy and Manipulation (CISMM)
>> Department of Computer Science
>> University of North Carolina at Chapel Hill
>> http://www.cs.unc.edu/~cquammen
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.html
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers
>
> --
> Gaëtan Lehmann
> Biologie du Développement et de la Reproduction
> INRA de Jouy-en-Josas (France)
> tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
> http://voxel.jouy.inra.fr  http://www.itk.org
> http://www.mandriva.org  http://www.bepo.fr
>
>



-- 
Cory Quammen
Computer Integrated Systems for Microscopy and Manipulation (CISMM)
Department of Computer Science
University of North Carolina at Chapel Hill
http://www.cs.unc.edu/~cquammen