[Insight-developers] Bugs with respect to ITK_IMAGE_BEHAVES_AS_ORIENTED_IMAGE
Bill Lorensen
bill.lorensen at gmail.com
Wed Nov 12 08:06:23 EST 2008
That makes sense.
Also, don't forget the style violations:
http://www.cdash.org/CDash/testDetails.php?test=12296849&build=212532
Bill
On Wed, Nov 12, 2008 at 6:31 AM, Tom Vercauteren
<tom.vercauteren at m4x.org> wrote:
> Thanks Gaëtan,
>
> I actually didn't try the configuration that you send me:
> ITK_USE_ORIENTED_IMAGE_DIRECTION:BOOL=ON
> ITK_IMAGE_BEHAVES_AS_ORIENTED_IMAGE:BOOL=OFF
>
> As far as I understand it, it makes sense that my tests fail with such
> a configuration since I am trying to register images that have a
> non-identity orientation. But then again, I am confused with how these
> two flags interact...
>
> A simple solution would be to use non-identity orientation in the
> tests only if both ITK_USE_ORIENTED_IMAGE_DIRECTION and
> ITK_IMAGE_BEHAVES_AS_ORIENTED_IMAGE are ON. Does that make sense?
>
> Tom
>
> On Wed, Nov 12, 2008 at 12:08 PM, Gaëtan Lehmann
> <gaetan.lehmann at jouy.inra.fr> wrote:
>>
>> Le 12 nov. 08 à 11:24, Tom Vercauteren a écrit :
>>
>>> Hi all,
>>>
>>> Some tests are failing on the dashboard but I cannot reproduce them on
>>> my machine. E.g.:
>>>
>>> http://www.cdash.org/CDash/testSummary.php?project=2&name=itkDiffeomorphicDemonsRegistrationFilterTest01&date=2008-11-12
>>
>>
>> One is mine (marvin). It has consolidated morphology and use optimized
>> registration on, and is built in Debug mode.
>> I'm sending you the CMakeCache.txt in case you need more configuration
>> informations.
>>
>>
>>>
>>>
>>> The problem is that I cannot find out which flags are enabled on these
>>> machines. Problems might indeed arise only on certain configurations.
>>>
>>> Can someone help?
>>>
>>> Tom
>>>
>>> On Mon, Nov 10, 2008 at 2:17 PM, Hans Johnson <hans-johnson at uiowa.edu>
>>> wrote:
>>>>
>>>> Oops,
>>>>
>>>> Sorry about this. I just realized that this code was correctly placed in
>>>> the test driver, and not in the filter itself!
>>>>
>>>> Thank you very much for addressing this issue quickly, I've been fighting
>>>> with it all weekend. I have a few more changes to submit with regards to
>>>> making all of ITK work consistently with OrientedImages, but I am running
>>>> some more extensive testing to ensure that they all work OK before
>>>> submitting them.
>>>>
>>>> Hans
>>>>
>>>>
>>>>
>>>>
>>>> On 11/10/08 7:12 AM, "Hans Johnson" <hans-johnson at uiowa.edu> wrote:
>>>>
>>>>> Tom,
>>>>>
>>>>> This code looks very suspicious to me:
>>>>>
>>>>> 149 DirectionType direction;
>>>>> 150 direction.SetIdentity();
>>>>> 151 #ifdef ITK_USE_ORIENTED_IMAGE_DIRECTION
>>>>> 152 direction(1,1)=-1;
>>>>> 153 #endif
>>>>>
>>>>> 162 moving->SetDirection(direction);
>>>>> 163
>>>>>
>>>>>
>>>>> It looks like the directions are being hard coded rather than taken from
>>>>> the
>>>>> input images.
>>>>>
>>>>> On 11/10/08 6:45 AM, "Tom Vercauteren" <tom.vercauteren at m4x.org> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The orientation issue in the ESMDemonsFunction code should now be
>>>>>> fixed. It would however be great if someone could review the change
>>>>>> that I committed. Especially what I did with
>>>>>> #ifdef ITK_USE_ORIENTED_IMAGE_DIRECTION
>>>>>>
>>>>
>>>> http://www.itk.org/cgi-bin/viewcvs.cgi/Code/Review/itkESMDemonsRegistrationFu>>
>>>> n
>>>>>>
>>>>>> ction.txx?root=Insight&r1=1.9&r2=1.10&sortby=date
>>>>>>
>>>>
>>>> http://www.itk.org/cgi-bin/viewcvs.cgi/Testing/Code/Review/itkDiffeomorphicDe>>
>>>> m
>>>>>>
>>>>>> onsRegistrationFilterTest.cxx?root=Insight&r1=1.8&r2=1.9&sortby=date
>>>>>>
>>>>>> I am not yet confident with how orientation should be managed within
>>>>>> ITK depending on what flag is turned on or off...
>>>>>>
>>>>>> Thanks,
>>>>>> Tom
>>>>>>
>>>>>> On Sun, Nov 9, 2008 at 7:07 PM, Bill Lorensen <bill.lorensen at gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hans,
>>>>>>>
>>>>>>> FYI, #warning is GNU specific. Look at my changes to the ESM code. I
>>>>>>> also modified the code to only throw an exception if the Direction is
>>>>>>> non-identity.
>>>>>>>
>>>>>>> Bill
>>>>>>>
>>>>>>> On Fri, Nov 7, 2008 at 11:38 AM, Stephen Aylward
>>>>>>> <Stephen.Aylward at kitware.com> wrote:
>>>>>>>>
>>>>>>>> Not certain if registration with directions will work otherwise.
>>>>>>>>
>>>>>>>> In particular, I think the BSplineInterpolateImageFunction would not
>>>>>>>> work...Heck, I think you also need to make sure you turn on
>>>>>>>> "ITK_USE_ORIENTED_IMAGE_DIRECTIONS" - see line 278 (and others) in
>>>>>>>> ITK/Code/Review/itkOptBSplineInterpoleImageFunction.txx
>>>>>>>>
>>>>>>>> Note that there is no corresponding use of image directions in the
>>>>>>>> ITK/Code/Common/itkBSplineInterpolateImageFunction.txx - as a result,
>>>>>>>> the
>>>>>>>> BSpline grid may not actually overlap the image :)
>>>>>>>>
>>>>>>>> Stephen
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Nov 7, 2008 at 11:18 AM, Hans Johnson
>>>>>>>> <hans-johnson at uiowa.edu>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Stephen,
>>>>>>>>>
>>>>>>>>> USE_OPTIMIZED_REGISTRATION_METHODS is not turned on because it
>>>>>>>>> causes our
>>>>>>>>> local Mutual Information application to fail on some platforms (a
>>>>>>>>> separate
>>>>>>>>> issue that we are working through).
>>>>>>>>>
>>>>>>>>> It is my understanding that USE_OPTIMIZED_REGISTRATION_METHODS
>>>>>>>>> provide
>>>>>>>>> new optimized versions of some algorithms that are a drop in
>>>>>>>>> replacement
>>>>>>>>> (i.e. Provide the same results as) the non optimized versions.
>>>>>>>>>
>>>>>>>>> Hans
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Hans J. Johnson, Ph.D.
>>>>>>>>> Hans-johnson at uiowa.edu
>>>>>>>>>
>>>>>>>>> 278 GH
>>>>>>>>> The University of Iowa
>>>>>>>>> Iowa City, IA 52241
>>>>>>>>> (319) 353 8587
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ________________________________
>>>>>>>>> From: Stephen Aylward <Stephen.Aylward at kitware.com>
>>>>>>>>> Date: Fri, 7 Nov 2008 11:13:36 -0500
>>>>>>>>> To: Johnson Hans <hans-johnson at uiowa.edu>
>>>>>>>>> Cc: Luis Ibanez <luis.ibanez at kitware.com>, ITK
>>>>>>>>> <insight-developers at itk.org>
>>>>>>>>> Subject: Re: [Insight-developers] Bugs with respect to
>>>>>>>>> ITK_IMAGE_BEHAVES_AS_ORIENTED_IMAGE
>>>>>>>>>
>>>>>>>>> Do you also have USE_REVIEW and USE_OPTIMIZED_REGISTRATION_METHODS
>>>>>>>>> turned
>>>>>>>>> on? Those are needed to enable the registration methods that
>>>>>>>>> SHOULD
>>>>>>>>> (may?)
>>>>>>>>> correctly handle directions.
>>>>>>>>>
>>>>>>>>> Stephen
>>>>>>>>>
>>>>>>>>> On Fri, Nov 7, 2008 at 11:07 AM, Hans Johnson
>>>>>>>>> <hans-johnson at uiowa.edu>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Luis,
>>>>>>>>>
>>>>>>>>> I'm sorry to spring this on you just hours after the release, but I
>>>>>>>>> discovered several bugs when ITK_IMAGE_BEHAVES_AS_ORIENTED_IMAGE is
>>>>>>>>> turned
>>>>>>>>> on, and images with different directions are used.
>>>>>>>>>
>>>>>>>>> I'm working on a patch right now, but it does touch many many files.
>>>>>>>>> So
>>>>>>>>> far my tests have shown that regression tests pass both with or
>>>>>>>>> without
>>>>>>>>> setting the output directions. The problem showed up when
>>>>>>>>> attempting to
>>>>>>>>> register images that have different orientations, spacing's, size,
>>>>>>>>> and
>>>>>>>>> origins. I think that our test data is too uniformly defined to
>>>>>>>>> catch
>>>>>>>>> these
>>>>>>>>> problems.
>>>>>>>>>
>>>>>>>>> =======================================================
>>>>>>>>> grep -A 2 -B 2 "Set.*Spacing.*Get.*Spacing" Insight/Code/*/* >
>>>>>>>>> ReviewList
>>>>>>>>>
>>>>>>>>> From this I look for patterns like the following:
>>>>>>>>>
>>>>>>>>> Code/Algorithms/itkBayesianClassifierImageFilter.txx-
>>>>>>>>> this->GetOutput()->SetRegions( membershipImage->GetBufferedRegion()
>>>>>>>>> );
>>>>>>>>> Code/Algorithms/itkBayesianClassifierImageFilter.txx:
>>>>>>>>> this->GetOutput()->SetSpacing( membershipImage->GetSpacing() );
>>>>>>>>> Code/Algorithms/itkBayesianClassifierImageFilter.txx-
>>>>>>>>> this->GetOutput()->SetOrigin( membershipImage->GetOrigin() );
>>>>>>>>> Code/Algorithms/itkBayesianClassifierImageFilter.txx-
>>>>>>>>> this->GetOutput()->Allocate();
>>>>>>>>>
>>>>>>>>> NOTICE: The output of this filter does not set the Direction!!!!
>>>>>>>>> this->GetOutput()->SetDirection( membershipImage->GetDirection() );
>>>>>>>>> =======================================================
>>>>>>>>>
>>>>>>>>> Unfortunately this seems like a very common problem throughout ITK.
>>>>>>>>> It
>>>>>>>>> is my assumption that most filters that: a) take input image, b) do
>>>>>>>>> something to the intensity values, c) generate and output image;
>>>>>>>>> will
>>>>>>>>> behave
>>>>>>>>> in such a way that the output image has the same origin, spacing,
>>>>>>>>> size,
>>>>>>>>> AND
>>>>>>>>> direction as the input image. Filters that: a)take an input image,
>>>>>>>>> b)
>>>>>>>>> take
>>>>>>>>> parameters for desired output physical space defintion, c) generate
>>>>>>>>> the
>>>>>>>>> new
>>>>>>>>> output image; must have options for setting Spacing, Origin, AND
>>>>>>>>> Direction.
>>>>>>>>>
>>>>>>>>> Experimental build:
>>>>>>>>> http://www.cdash.org/CDash/buildSummary.php?buildid=210257
>>>>>>>>>
>>>>>>>>> I hope to have the code committed and bugs reported in about 1 hour.
>>>>>>>>>
>>>>>>>>> Hans
>>>>>>>>> --
>>>>>>>>> Hans J. Johnson, Ph.D.
>>>>>>>>> Hans-johnson at uiowa.edu <http://Hans-johnson@uiowa.edu>
>>>>>>>>>
>>>>>>>>> 278 GH
>>>>>>>>> The University of Iowa
>>>>>>>>> Iowa City, IA 52241
>>>>>>>>> (319) 353 8587
>>>>>>>>>
>>>>>>>>> Notice: This UI Health Care e-mail (including attachments) is
>>>>>>>>> covered by
>>>>>>>>> the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
>>>>>>>>> confidential and may be legally privileged. If you are not the
>>>>>>>>> intended
>>>>>>>>> recipient, you are hereby notified that any retention,
>>>>>>>>> dissemination,
>>>>>>>>> distribution, or copying of this communication is strictly
>>>>>>>>> prohibited.
>>>>>>>>> Please reply to the sender that you have received the message in
>>>>>>>>> error,
>>>>>>>>> then delete it. Thank you.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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. - North Carolina Office
>>>>>>>>> http://www.kitware.com
>>>>>>>>> (518) 371-3971 x300
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Stephen R. Aylward, Ph.D.
>>>>>>>> Chief Medical Scientist
>>>>>>>> Kitware, Inc. - North Carolina Office
>>>>>>>> http://www.kitware.com
>>>>>>>> (518) 371-3971 x300
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>
>>>>
>>> _______________________________________________
>>> Insight-developers mailing list
>>> Insight-developers at itk.org
>>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>> --
>> Gaëtan Lehmann
>> Biologie du Développement et de la Reproduction
>> INRA de Jouy-en-Josas (France)
>> tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
>> http://voxel.jouy.inra.fr http://www.mandriva.org
>> http://www.itk.org http://www.clavier-dvorak.org
>>
>>
> _______________________________________________
> 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