[Insight-developers] ITK 3.10 : TurningITK_IMAGE_BEHAVES_AS_ORIENTED_IMAGE = ON by default

[Luis Ibanez]

Hi Jeoren,

Thanks for the report.

It is good to know that the registration framework has been working for you.

It is however surprising to hear that it works even for non-orthogonal
axis. I would suspect that when it comes to computing derivatives, we
are not doing the correct computation for non-orthogonal axis.

This is one of the cases where the need for using CovariantVectors for
representing derivatives becomes more obvious. The orientation of the
derivatives should be given by the dual vector basis of the coordinates
vector basis.

It may be worth to log a feature request and/or a bug report for this
issue.

Processes such as distance computation will also be performed
incorrectly by ITK in non-orthogonal spaces, since the distance
computation code assumes an euclidean and orthogonal space
(e.g. there is not tensor metric).


    Regards,


       Luis


----------------------------
J.S.Wijnhout at lumc.nl wrote:
> Hi,
> 
> For what it is worth: I'm using ITK 3.6 and itk::OrientedImage
> extensively in combination with the registration framework (Exhaustive
> optimizer, Versor optimizer, NMI and NCC metrics). The images I work
> with have double oblique orientation with respect to each other (meaning
> that none of the principal axes are parallel). Registration works on
> these data sets. Assuming nothing got broken in the mean time, it should
> work in ITK 3.10 as well. Of course it would be a good idea to
> explicitly test this.
> 
> Best,
> Jeroen 
> 
> -----Original Message-----
> From: insight-developers-bounces at itk.org
> [mailto:insight-developers-bounces at itk.org] On Behalf Of Tom Vercauteren
> Sent: vrijdag 17 oktober 2008 15:33
> To: Luis Ibanez
> Cc: Insight Developers
> Subject: Re: [Insight-developers] ITK 3.10 :
> TurningITK_IMAGE_BEHAVES_AS_ORIENTED_IMAGE = ON by default
> 
> Hi Luis,
> 
> I need to clarify my first question :)
> 
> I am wondering whether the current registration unit tests actully use
> images that have a non-identity orientation. If I remember correctly,
> so far the registration tests were only using images that had an
> identity orientation. In that case, using (or not using) the
> orientation information should of course not change the result.
> 
> To rephrase it: Are there any tests that now fail only if the flag is
> set to OFF? I would indeed expect that since orientation is not used
> within registration when the flag is OFF (old behavior), registering
> two images with non-identity orientation should fail. The same tests
> should however pass with the flag set to ON (new behavior).
> 
> Am I missing something?
> 
> Best,
> Tom
> 
> On Fri, Oct 17, 2008 at 3:05 PM, Luis Ibanez <luis.ibanez at kitware.com>
> wrote:
> 
>>Hi Tom,
>>
>>
>>Excellent question.
>>
>>
>>              Fortunately the answer is:  Yes !
>>
>>
>>We have been testing the toolkit with this flag ON for several weeks
>>now in specific machines. (Redwall, Zion, Camelot), and they have been
>>producing green builds.
>>
>>
>>As further confirmation, we turned the flag ON, yesterday, so today's
>>Nightly builds are all (unless they explicitly turned the flag OFF)
>>reporting results by having the itk::Image behave just like the
>>itk::OrientedImage.
>>
>>
>>Unfortunately, I broke the build while fixing coding style violations
>>in Code/Common, so we will have to wait for tomorrow's Dashboard to
>>have a clear picture of the effect of turning the flag ON in all the
>>Nightly submissions.
>>
>>
>>Point taken about the Software Guide, and update of the book is
> 
> overdue.
> 
>>
>> Regards,
>>
>>
>>     Luis
>>
>>
>>----------------------
>>Tom Vercauteren wrote:
>>
>>>Hi Luis,
>>>
>>>It's great to see ITK becoming more consistent with respect to image
>>>orientation!
>>>
>>>Out of curiosity, I am wondering whether the correct behavior of the
>>>registration (parametric or not) with oriented images is already
> 
> being
> 
>>>tested by the unit tests?
>>>
>>>Also I think that once the orientation framework becomes stable, it
>>>would be worth updating the ITK user guide to explain how orientation
>>>information is used (or should be) in ITK.
>>>
>>>Just my two cents.
>>>
>>>Regards,
>>>Tom
>>>
>>>On Thu, Oct 16, 2008 at 7:42 PM, Luis Ibanez
> 
> <luis.ibanez at kitware.com>
> 
>>>wrote:
>>>
>>>
>>>>Hi Leila,
>>>>
>>>>Thanks for the feedback.
>>>>
>>>>BTW,
>>>>to make the fix complete we will also turn ON by default the
>>>>CMake variable
>>>>
>>>>         ITK_USE_ORIENTED_IMAGE_DIRECTION
>>>>
>>>>
>>>>This flag is used by gradient computation classes, to make the
>>>>gradient orientations consistent with the image orientation.
>>>>
>>>>This fixes an long standing bug in the registration framework.
>>>>
>>>>
>>>>Regards,
>>>>
>>>>
>>>> Luis
>>>>
>>>>
>>>>------------------------
>>>>Leila Baghdadi wrote:
>>>>
>>>>
>>>>>Hi Luis,
>>>>>
>>>>>It sounds like a great plan. If the direction cosines are taken
> 
> into
> 
>>>>>account the image is read ( this is the behavior of all the
> 
> software
> 
>>>>>that we have in our center), then there is nothing to worry about.
>>>>>
>>>>>I also like the idea that the cmake flag gets rid of alot of
> 
> confusion
> 
>>>>>for the developers.
>>>>>
>>>>>Leila
>>>>>
>>>>>On Thu, 2008-10-16 at 09:03 -0400, Luis Ibanez wrote:
>>>>>
>>>>>
>>>>>
>>>>>>In preparation for the release of ITK 3.10,
>>>>>>
>>>>>>
>>>>>>We are proposing to turn ON by default the CMake flag:
>>>>>>
>>>>>>
>>>>>>        ITK_IMAGE_BEHAVES_AS_ORIENTED_IMAGE
>>>>>>
>>>>>>
>>>>>>When this flag is ON, the itk::Image provides a behavior identical
>>>>>>to the itk::OrientedImage. Essentially taking the image direction
>>>>>>into account when converting Indices to Physical Points and back.
>>>>>>
>>>>>>
>>>>>>The itk::OrientedImage should be retained for backward
> 
> compatibility,
> 
>>>>>>despite of becoming redundant at this point.
>>>>>>
>>>>>>
>>>>>>The rational for turning this flag ON by default is that this is
>>>>>>the correct behavior to expect from a medical image, while
> 
> ignoring
> 
>>>>>>the direction when converting indices to points is actually a bug.
>>>>>>
>>>>>>
>>>>>>The buggy behavior will still be available as an option, to those
>>>>>>who require a backward compatible frame (e.g. applications that
>>>>>>have already worked around the previous bug). In those cases you
>>>>>>should simply turn the flag OFF, in order to get the old behavior.
>>>>>>
>>>>>>
>>>>>>Please let us know if you have any questions or concerns.
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>>   Luis
>>>>>>
>>>>>>
>>>>>>
>>>>>>-------------------------
>>>>>>Karthik Krishnan wrote:
>>>>>>Perhaps that
>>>>>>
>>>>>>
>>>>>>
>>>>>>>could be on the list of things ToDo whenever the next lengthy
>>>>>>>discussion on Orientation comes up in ITK. I think we have one
>>>>>>>every month. :)
>>>>>>>
>>>>>>>Thanks
>>>>>>>
>>>>>>
>>>>>>_______________________________________________
>>>>>>Insight-developers mailing list
>>>>>>Insight-developers at itk.org
>>>>>>http://www.itk.org/mailman/listinfo/insight-developers
>>>>>
>>>>>
>>>>>
>>>>_______________________________________________
>>>>Insight-developers mailing list
>>>>Insight-developers at itk.org
>>>>http://www.itk.org/mailman/listinfo/insight-developers
>>>>
>>>
>>>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>