[Insight-developers] orientation

[Simon Warfield]

insight-developers-request at itk.org wrote:
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 6 Aug 2008 08:24:06 -0400
> From: "Rupert Brooks" <rupe.brooks at gmail.com>
> Subject: Re: [Insight-developers] ImageSpatialObject Bug0006340
> To: "Stephen Aylward" <Stephen.Aylward at kitware.com>
> Cc: insight-developers at itk.org, Luis Ibanez <luis.ibanez at kitware.com>
> Message-ID:
> 	<a6cc33f0808060524m767ff5c8te964483f95428fde at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I decided to investigate a bit further - I wondered if the problem
> could easily occur in practice.  I found that it can.
>
> I wrote a little code to load an image and print its direction info
> with both itk::Image, and itk::OrientedImage.  In both cases the
> direction info is correct, and non-identity.  To be clear - at least
> the MetaImageIO loads direction info and puts it into an ITK image,
> which would lead directly to an image that would create the problem i
> described.  So it would be very easy for a user to accidentally do
> this, leading to mysterious, occasional failures.
>
> I'm going to try changing itk::Image to always return unit direction
> cosines.  Dont worry, i wont submit a change that huge without
> discussing here first.  But I will let everyone know how many tests it
> breaks.  This will take a few hours, i'll report back when the build
> completes.
>
> By the way - I dont have particular feelings about a solution for this
> problem.  I use orientation in all my code, so the problem will never
> affect my work.  But i guess when you adopt a stray bug, like a stray
> puppy, you end up with all its consequences.   Feel free to just tell
> me what the solution should be - thats what I was hoping for in the
> first place anyway.
>
> Rupert
>
>   
Hi Rupert,

  We have discussed on the list in the past the real problem is that 
itkImage exposes an API for the manipulation of direction cosines,
enabling the setting and getting of non-identity orientations, but the 
primary difference between itkImage and itkOrientedImage is that the 
index to and from physical transforms
of an itkImage do not utilize the direction cosine information.

  The presence of the functions to set and get direction cosines for an 
image class that doesn't and is not intended to support them is a 
frequent problem for new ITK users.
Every month or so a new user writes to the list expressing surprise at 
this. It is particularly misleading that the API has the outward 
appearance of providing means of changing the direction cosines, but 
that all calculations on an itkImage do not use this.

  In order to reduce the burden on new and existing users, I think the 
user community should remove the non-functional direction setting and 
getting API from itkImage, and have it only present in itkOrientedImage. 
This makes explicit and clear the different operation of the two image 
classes.

  This is also complicated by the fact that itkOrientedImage does not 
actually work if the image dimension is not equal to 3. There is code in 
the toolkit which assumes that a 3 letter code can be assigned to each 
orientation, and instantiating a 2D version of such an image that uses 
and attempts to e.g. orient an image, is a compile time error.

  As a concrete step, I could check in a test which uses a 2D oriented 
image but fails to compile.

  There are other orientation problems as well.  It would be good to try 
to identify as many as possible so that I plan to correct it could take 
all the known problems into account.

-- 
Simon