ITK Release 4.0 Orientation by Michael

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