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

Luis Ibanez luis.ibanez at kitware.com
Mon Oct 20 08:41:44 EDT 2008 

Hi Jeroen,

Please check the CMakeCache of your ITK Binary directory and verify
the status of the CMake variable:

                ITK_USE_ORIENTED_IMAGE_DIRECTION


If it is ON, then you should be fine, (if you are using
itk::OrientedImage).

In ITK 3.6, the computation of derivatives takes direction into
account *as long as* you turn ON the flag above, *and* use the
itk::Oriented images.

Starting with ITK 3.10, the computation of derivatives (and
conversions between indices and points) will take direction
into account *as long as* you turn on the following two flags:

        * ITK_USE_ORIENTED_IMAGE_DIRECTION
        * ITK_IMAGE_BEHAVES_AS_ORIENTED_IMAGE

and you will be safe, using the standard itk::Image class.



Regards,


     Luis



--------------------------
J.S.Wijnhout at lumc.nl wrote:
> Hi Luis,
> 
> FYI: I'm mostly using the exhaustive optimizer (which doesn't using the
> gradient of course) and the rigid transform (so no scaling). I was under
> the impression that the computation of the derivative takes into account
> the orientation (since ITK 3.6 at least). Perhaps it does not take into
> account the fact that a derivative is a contravariant vector (covariant
> in ITK terminology). But since I'm using a rigid transform, I hope I'm
> in safe waters. Can you confirm this?
> 
> Best,
> Jeroen
> 
> -----Original Message-----
> From: Luis Ibanez [mailto:luis.ibanez at kitware.com] 
> Sent: vrijdag 17 oktober 2008 16:37
> To: Wijnhout, J.S. (LKEB)
> Cc: tom.vercauteren at m4x.org; Insight-developers at itk.org
> Subject: Re: [Insight-developers] ITK 3.10 :
> TurningITK_IMAGE_BEHAVES_AS_ORIENTED_IMAGE = ON by default
> 
> 
> 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
>>
> 
>

More information about the Insight-developers mailing list