[Insight-developers] orientation

[Simon Warfield]

Bill Lorensen wrote:
> Simon,
> I'm surprised that OrientedImage does not work in > 3 dimensions.
> OrientedImage has no notion of a 3 letter code as far as I know. There
> is a filter itkOrientImageFilter that uses 3 letter codes, but it is
> independent of OrientImage.
>   
Yes, my particular problem in this case was in re-using code written for 
3 dimensions in other dimensions.
The itkOrientImageFilter makes use of 3 letter codes and doesn't work if 
the dimension is not 3.

> As Stephen suggested, maybe we should treat all images the same. In
> effect, Image would become Oriented image.

>  We could address the
> deprecation of OrientedImage in a separate discussion. For non-debug
> builds, I think the performance of the transform methods in
> OrientedImage are quite fast. I coded them using meta template
> programming. There is little to no performance degradation from the
> Image's implementaion of the transforms.
>
> I don't think we can remove methods though. This will cause cryptic
> compilation errors.
>   
At the moment the methods appear to set and get directions in the 
itkImage class, and although they generate no warning message, they fail 
to modify the index to physical transform,
and the physical to index transform etc.  This is particularly misleading.

If they acted as itkOrientedImage does, that would be fine. The 
misleading behaviour would be gone.

--
Simon

> Bill
>
> 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
>>
>>     
>
>   


-- 
Simon