ITK Release 4.0 Orientation by Kent

The other solution proposed -- making Get/SetDirection do nothing in
itk::Image, but do something in itk::OrientedImage breaks things for another
class of applications -- those that primarily use direction cosines to
recover the patient orientation when they read an image.  Once images are
read and oriented to a common frame, the application is free to assume that
all images so oriented are nominally consistent in their anatomical
orientation.

Programs written to that paradigm basically ignore the direction cosines
mostly or completely, once all the noses are pointing the same way.

There's three concepts that collide when it comes to orientation. In order
to form a more perfect ITK, need to be considered.

1. Gross anatomical orientation -- you want to compare two volumes, one
acquired head first, and another feet first.  This is addressed by
* itk::SpatialOrientation (defines all 48 possible orientations)
* itk::SpatialOrientationAdapter (converts between spatial oriention codes
and direction cosines)
* Direction cosines (orientation info recovered from image files is
converted and stored therein)

2. Actual orientation ‹ the orientation info recovered can be from oblique
scans and it is stored in direction cosines.  This conflicts (somewhat) with
concept #1, in that going from the actual orientation to the gross
anatomical orientation squares up the direction cosines and loses the
rotational information.

3. General spatial transforms, addressed by itk::Transform and it¹s
children.  These are what are used by Registration and SpatialObjects to
move anatomy or geometry around.

There is a head-on collision between concept #3 and concept #1 and #2 in the
case of itk::Image and itk::OrientedImage participating in the SpatialObject
hierachy.  SpatialObjects live in a nested set of reference frames,  the
outermost of which is the traditionally (and dubiously) named ŒWorld¹
coordinate system.  Anyone who has to deal with this stuff eventually gets a
headache, because you always want to get ahold of some transform T, and have
to pace the corridor for 15 minutes to figure out which direction ŒT¹ has to
go ‹ world to local, local to world? -- and which order transforms need to
be multiplied to get the results you want.

The cream of the jest is that concept 3 defines the world coordinate system
is represented by the identity matrix, but concept 1 and 2 think the
identity matrix is one of 48 different ways to define how voxels are
organized in memory with respect to anatomy, the one labeled 'RAI.'

What needs to be worked out ‹ and believe me I have no idea right now how to
do it ‹ is to find a way to keep these concepts separated in ITK.  I don¹t
entirely follow the problems that direction cosines are causing in Spatial
Objects,  but it is obvious to me that we¹re making the direction cosines do
double duty in a way that isn¹t working.

At any rate, the state of play is this: 1) The status quo is a priori
backwards compatible, but broken 2) Both proposed solutions will break
backwards compatibility. 3) The proposed solutions are mutually
incompatible.

So perhaps it's right to table it for the moment and see if anyone comes up
with a bright idea to resolve things.

Kent Williams