[Insight-developers] orientation

[Rupert Brooks]

Hi Simon,

I would be very interested in the test you mention.   Maybe the wiki
is the right place to post it?

Due to the problems with gradients on non-axis-aligned Oriented
images, i created my own class, FastOrientedImage.  Its in the insight
Journal somewhere.   I was not aware of oriented images having
problems in 2D and I thought I had used them successfully in the past.
 I've been planning to switch back to the more mainstream ITK approach
and retire my custom classes - thus - I'd be very interested in this
bug.

Thanks
Rupert

On Wed, Aug 6, 2008 at 12:17 PM, Simon Warfield
<simon.warfield at childrens.harvard.edu> wrote:
> 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
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>



-- 
--------------------------------------------------------------
Rupert Brooks
McGill Centre for Intelligent Machines (www.cim.mcgill.ca)
Ph.D Student, Electrical and Computer Engineering
http://www.cyberus.ca/~rbrooks