[Insight-developers] orientation

[Stephen Aylward]

Orientation comments have been added to the wiki...

http://www.itk.org/Wiki/ITK_Release_4.0#Oriented_Images

Feel free to add more...

s

On Fri, Aug 8, 2008 at 2:41 PM, Michael Halle <mhalle at bwh.harvard.edu> 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
>
>
>
>
> Torsten Rohlfing wrote:
>>
>> Hi everyone.
>>
>> While I won't claim I fully understand the current status quo in ITK, I
>> have a comment regarding Kent's list of options:
>>>
>>> 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.
>>>
>>>
>>
>> For what it's worth, I recently had to reconcile options #1 and #2 in my
>> own library, and I thought I'd share my experience. To be very clear:
>> what I am going to say relates ONLY to my own software, which is
>> completely separate from ITK.
>>
>> Historically, I have been following Option #1 above, then added Option
>> #2 for non-human images (bees don't live in RAS etc. space), but
>> recently needed to support direction cosines also for human data (from
>> DICOM). Obviously, I didn't want to break compatibility with
>> registrations computed over the past 10 years, so it was important to
>> come up with an implementation that achieves that.
>>
>> So here's what I did, based on the space abstraction laid out by Gordon
>> Kindlman in the Nrrd file format specification.
>>
>> All images are read living in some physical space. For DICOM, that's
>> LPS. For Nrrd, it's what's in the Nrrd "space:" field. For Analyze, it's
>> whatever the Analyze orientation field is supposed to mean in my reading
>> of the file format documentation.
>>
>> My software uses RAS coordinates for all images internally.
>> Historically, everything was reoriented into RAS, i.e., for (i,j,k)
>> pixel index, i after reorientation increases from L to R.
>>
>> Now -- here's the workflow when I read an image:
>>
>> 1. image data is read as stored in file, and coordinate space is set as
>> described above. Direction cosines are taken from input if they exist
>> (DICOM, Nrrd), or initialized as identity matrix (Analyze). Basically,
>> for the Analyze case, I am faking the anatomical orientation to be
>> identical to the space definition.
>>
>> 2. coordinate space is changed to RAS. That does not affect the storage
>> order of image pixels, but it changes the direction cosines by
>> permutation and negation. As an example, "LPS" to "RAS" means x becomes
>> -x, y becomes -y, and z stays z. This also applies to the coordinate
>> space origin. Different example: "ARS" to "RAS" means first and second
>> direction vector are exchanged.
>>
>> 3. determine coarse anatomical orientation of image from direction
>> vectors and coordinate space (the latter now RAS). Based on this,
>> reorient image so that pixel storage is (i,j,k)<=>(L/R,P/A,I/S).
>> Direction cosines and space origin are modified accordingly so that the
>> every pixel remains in the same physical position. That means
>> permutation of direction vectors, negation of direction vectors plus
>> adding offset to space origin that corresponds to opposite end of image
>> w.r.t. given index.
>>
>> After these steps, the image lives in RAS space, is coaresly stored in
>> RAS order, but has the same physical space coordinates for each pixel as
>> was stored in the original image file, i.e., all physical space
>> transformations between two images remain correct (when taking into
>> consideration that space axes may have been negated in step 2.
>>
>> When images are written to a file, the procedure is repeated in reverse
>> order. For that, each image object has meta information that stores its
>> original coordinate space and storage order, so the original order and
>> space can be recovered. The original direction cosines are also
>> recovered in the process.
>>
>> I am not saying this whole, slightly messy, procedure would be a good
>> idea for ITK, but it seems to reconcile Options #1 and #2 on Kent's
>> list, and it's working for me.
>>
>> Best,
>>  Torsten
>>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>



-- 
Stephen R. Aylward, Ph.D.
Chief Medical Scientist
Kitware, Inc. - North Carolina Office
http://www.kitware.com
(518) 371-3971 x300