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

[Michael Halle]

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

As I mentioned in the quoted email below, I would propose a named, 
graph-based structure rather than a hierarchy-based one, which would at 
the same time accommodate multiple coordinate systems per image for 
those applications that need it.

For example, registration (creating a transform relationship between two 
different coordinate spaces) is probably better described using an 
general graph than a hierarchy: transforms link one space to another 
without necessarily forming a hierarchical structure.

Transform hierarchies have been dominant in computer graphics and CAD in 
part because everything is relatively simple, nested, and ordered; 
arbitrary medical image analysis can be much more complicated, and thus 
can benefit from a general graph structure.

--Mike

On August 8, 2008, Michael Halle wrote:

I would propose that if you're really going to rethink orientation, you
might use the named coordinate space idea we've bopped around as part of
NA-MIC/Slicer for some time now.  This step would be very useful for
those of us interested in using ITK outside of medicine, but it's also
good for more complex medical imaging problems as well.

At a very high level:

* Every image can potentially be interpreted in multiple coordinate
spaces, most of which are domain- or application-specific.  These spaces
are usually easy for people to name (think, "strings" or "constants").

* Transforms describe the relationship between coordinate spaces.

* Image readers have the domain knowledge to instance coordinate spaces
and the transforms that relate them. DICOM readers, for example, may
know about multiple coordinate spaces after reading a stream, and can
instance those coordinate spaces and transforms accordingly.  This
property allows domain-specific knowledge to be encapsulated at the IO
level, keeping it out of the ITK core.

* For sample-based images, at least one transform (or chain of
transform) needs to relate the image's pixel coordinate space to the
other coordinate spaces.  Continuous fields and interpolated images must
similarly have some transform into their field value coordinate space.

* Different medical/scientific domains may define their own set of
standard spaces.  The examples here (gross anatomical orientation, RAS
space) are standard medical ones.  Other fields have other conventions.
There's a limit to how much you can shoehorn these conventions together.

* Some transforms may need to have specific numeric implementations for
efficiency (a direction cosine implementation, for example).

* In almost all cases, there is no single world coordinate space, only
relative or shared coordinate spaces.  The assumption of a world
coordinate space is often misleading and potentially dangerous.

* Registration algorithms provide transforms that relate the coordinate
spaces of different images.  This transform may be exact or approximate.
  Another way to think about registration is that it defines a new
coordinate space (a "registration coordinate space") and relates one or
more image coordinate spaces to that space.

* Coordinate spaces may have other properties: numerical accuracy, for
example.  Registration coordinate spaces, for instance, are natural
places to store numerical error bounds associated with the registration
algorithm.

* Computers are better than people at managing the complex relationships
between multiple coordinate spaces.  Getting transform chains right is
hard.  It's much easier for people to figure out simple transforms, then
ask, "give me the transform that takes me from pixel space of image X to
pixel space of image Y using the registration space R".


Yes, it might be hard to retrofit this structure into ITK with
compatibility.  The model is clean and general though, so with any luck
it should be possible to solve the orientation and transform problems
once and for all.

--Mike