[Insight-developers] orientation

[Luca Antiga]

Hi,
 since you're collecting ideas regarding current limitations of
oriented images, the fact that the matrix is ImageDimensions x
ImageDimensions doesn't allow a 2d image to live in 3d. Shouldn't the
matrix consider image dimensions and physical space dimensions as
separate entities, and set them equal just by default?

Luca

On 8/6/08, 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
>

-- 
Sent from Google Mail for mobile | mobile.google.com

Luca Antiga, PhD
 Biomedical Technologies Laboratory
 Bioengineering Department,
 Mario Negri Institute
mail: Villa Camozzi, 24020, Ranica (BG), Italy
phone: +39 035 4535-381
email: antiga at marionegri.it
web: http://villacamozzi.marionegri.it/~luca