[Insight-developers] Bugs with respect to ITK_IMAGE_BEHAVES_AS_ORIENTED_IMAGE
Gaëtan Lehmann
gaetan.lehmann at jouy.inra.fr
Wed Nov 12 06:08:21 EST 2008
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20081112/d1d4fd0e/attachment.pgp>
More information about the Insight-developers
mailing list