[Insight-developers] Bugs with respect to ITK_IMAGE_BEHAVES_AS_ORIENTED_IMAGE
Hans Johnson
hans-johnson at uiowa.edu
Mon Nov 10 08:12:34 EST 2008
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/itkESMDemonsRegistrationFun
> ction.txx?root=Insight&r1=1.9&r2=1.10&sortby=date
> http://www.itk.org/cgi-bin/viewcvs.cgi/Testing/Code/Review/itkDiffeomorphicDem
> 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
>>
More information about the Insight-developers
mailing list