[Insight-developers] orientation

[Stephen Aylward]

We've started a wish-list for ITK 4.0 at
http://www.itk.org/Wiki/ITK_Release_4.0

Please add your comments about oriented images, FEM classes,
statistics refactoring, and whatever else you'd like to see updated in
ITK.

Feature requests, design flaws, etc are welcome.

Stephen

On Wed, Aug 6, 2008 at 12:43 PM, Luca Antiga <luca.antiga at gmail.com> wrote:
> 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
> _______________________________________________
> 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. - Chapel Hill Office
http://www.kitware.com
(518) 371-3971 x300