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