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

[Steve M. Robbins]

Hi Luis et al.,

I'm still trying to get my head around your proposal.

Incidentally, what is the status of
http://www.itk.org/Wiki/Proposals:Orientation?  The basic proposal
appears to be "add direction cosines to itk::Image", which is now
done, right?


On Tue, Sep 23, 2008 at 11:01:03AM -0400, Luis Ibanez wrote:
>
> 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).

What does this proposal mean for itk::OrientedImage?  Would it be
deprecated?  Discouraged in favour of ImageSpatialObject?


> 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.

Do I understand correctly that the Image would be instantiated with
TDimension=2?  Does this image hold the pixel spacing and handle
conversion from IndexType to a (2D) "physical point";
i.e. Image::TransformIndexToPhysicalPoint()?  What is the Origin set
to?  What are the direction cosines set to?

Naively, it seems that you have to leave the 3D origin and 3D
direction cosine information in the child-to-parent transformation.
The 2D origin and directions would be fixed to (0,0) and the identity?

Currently, it looks like ImageSpatialObject always contains an image
of the same dimension, so the spatial object would have to be 2D.  It
also appears that a child SpatialObject is always the same dimension
as its parent.  In order to have a 2D image in a 3D SpatialObject,
would you relax one or both of these constraints?



> 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.

Alternatively -- for consistency with Case A -- you could keep the
origin and direction information in the child-to-parent
transformation.

Introducing the SpatialObject means that for the "ND image in an ND
space" case, there are two places to store the index-to-world
transformation.  I worry that this makes it too easy to get it wrong.


> 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.

Suppose the 4D data is a time series of 3D volumes.  The data may not
be sampled uniformly in time.  What is the Image's spacing set to?


-Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20081006/0bc97697/attachment.pgp>