[Insight-developers] Bugs with respect to ITK_IMAGE_BEHAVES_AS_ORIENTED_IMAGE

Tom Vercauteren tom.vercauteren at m4x.org
Wed Nov 12 05:24:14 EST 2008


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

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
>
>


More information about the Insight-developers mailing list