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

[Bill Lorensen]

Luis,

I haven't looked in detail at your proposal, but here is a quick thought.

I think that itk should keep a simple notion of orientation but have
enough functionality to permit applications to select a more
sophisticated approach.

I'm concerned about adding too much complexity.

Bill

On Mon, Oct 6, 2008 at 9:39 AM, Michael Halle <mhalle at bwh.harvard.edu> wrote:
> 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
>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>