From KitwarePublic
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
