[Insight-developers] Image as an OrientedImage Progress : Introducing Coordinate System Tree ?

[Luis Ibanez]

Here is a proposal:


It seems that we could go around the challenges of the ImageOrientation
by introducing in ITK a formal representation of coordinate system
hierarchies. (most of which is already implemented in SpatialObjects).


This is something that has been done already in Slicer (with the MRML 
tree), and in IGSTK with the coordinate system representation classes.


Here is how it could work:

Case A: Image 2D embedded in a 3D Space:
========================================

    The image Directions will be 2D x 2D, and the image will
    be the child node of another node that represents the
    3D host space. The link between the two nodes will contain
    a 2D x 3D matrix transform mapping the two coordinate axes
    of the 2D image to the 3D host space.

    When reading a 2D image from an Analyze file, the 3D direction
    cosines will go to the transform between the image node and
    the host space node.


Case B: Image 3D embedded in a 3D space:
========================================

    The image directions will be 3D x 3D.
    There is no need of parent node, but for consistency we could
    always have a parent node representing the 3D host space.
    The transform between the image node and the host space node
    will be an identity transform of 3Dx3D.


Case C: Image 4D embedded in a 3D space:
=========================================

    The image directions will be 4Dx4D and they will represent
    the concept of "simultaneity of acquisition" from the scanner.

    The image node will be a child of the parent host space node.
    and the transform relating them will be a 4D x 3D transform,
    that will represent the actual orientation of the dataset
    in the 3D world.


In the context of IGSTK and MRML we have found that using a
"scene graph" representation for describing the spatial relationships
of objects in space is a great way of simplifying applications and
ensuring the consistent representation of their relative positions.

In ITK we already have the coordinate systems of the SpatialObject,
and they could be a base for representing this SceneGraph.


One way to proceed could be to have the itk::ImageSpatialObject
become the type that Readers will actually return. In this way,
the ImageSpatialObject internally holds an itk::Image, and also
is connected to the parent host space.


    Luis