[Insight-developers] Multi-resolution pyramid and multi-resolution PDE deformable registration small issues

Hans Johnson hans-johnson at uiowa.edu
Thu Mar 5 11:50:29 EST 2009 

The behavior of this class changed last fall.  There was a 2-3 week period
of discussion on the mailing list, and Bill Lorensen, Luis Ibanez, and I all
worked on developing failing test, and resolving this bug until the tests
passed.  It affected the ShrinkImage filter and the
MultiResolutionImageFilter.



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: Thu, 5 Mar 2009 10:33:34 -0500
> To: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Cc: Tom Vercauteren <tom.vercauteren at m4x.org>, Hans Johnson
> <hans-johnson at uiowa.edu>, ITK <insight-developers at itk.org>
> Subject: Re: [Insight-developers] Multi-resolution pyramid and
> multi-resolution PDE deformable registration small issues
> 
> Has the behavior of this class been changing recently?
> 
> Do we need to take away some CVS write accesses? :)
> 
> s
> 
> On Thu, Mar 5, 2009 at 10:08 AM, Bradley Lowekamp
> <blowekamp at mail.nih.gov> wrote:
>> Please let me know when the default behavior changes, so that I can reverify
>> that my registration programs still work. As I am registering
>> noisy microscopy data, I am likely dependent on this smoothing.
>> I do think these classes need a close look. They are not
>> even consistent with there documentation. MultiResolutionPyramidImageFilter
>> claims it can stream but it clearly can not!!!  And the change in the
>> behavior from using ShrinkImageFilter to linear interpolate
>> ResampleImageFilter was significant too! I just have some gripes :)
>> I am agreeing with Stephen on this one. The subtle changes to this class are
>> causing my registrations to change!
>> I much prefer to get compiler errors when function names change so I know
>> behaviors have changed :)
>> Brad
>> 
>> On Mar 5, 2009, at 9:34 AM, Tom Vercauteren wrote:
>> 
>> Thanks for the feedback.
>> 
>> Stephen: Just like Gaetan, I don't really the option of having a wrong
>> default behavior. I consider the over-smoothing and inconsistency
>> between MultiResolutionPyramidImageFilter and
>> RecursiveMultiResolutionPyramidImageFilter to be a bug. Therefore,
>> correcting it shouldn't be seen as breaking backwards compatibility.
>> But of course that's my point of view.
>> 
>> Also, since it is possible for the user to change the multi-resolution
>> pyramid in MultiResolutionPDEDeformableRegistration, I don't gain much
>> if the default bebahior of MultiResolutionPyramidImageFilter stays the
>> same. I'd rather not modify ITK and tweak the multi-resolution pyramid
>> in MultiResolutionPDEDeformableRegistration from my application.
>> 
>> 
>> Hans: I have looked at the patch you mention:
>> http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/Algorithms/itkMultiResolut
>> ionPyramidImageFilter.txx?root=Insight&r1=1.29&r2=1.25
>> 
>> Is there any reason why the smoother changed from
>>  smoother->SetUseImageSpacing( false );
>> to
>>  smoother->SetUseImageSpacing( true );
>> 
>> It seems like "smoother->SetUseImageSpacing( false );" should be the
>> right version to use as the sigma is computed only from the pyramid
>> schedule.
>> 
>> Apart from that fixing this in
>> RecursiveMultiResolutionPyramidImageFilter shouldn't be a problem.
>> 
>> Tom
>> 
>> On Thu, Mar 5, 2009 at 15:06, Hans Johnson <hans-johnson at uiowa.edu> wrote:
>> 
>> Tom,
>> 
>> In addition to this behavior enhancement, it is also necessary to address a
>> 
>> bug in the Recursive MultiResolutionPyramidImageFilter:
>> 
>> http://public.kitware.com/Bug/view.php?id=8482
>> 
>> I am in favor of changing to this default after this bug is fixed (which
>> 
>> should then preserve backwards compatibility with programs that depend on
>> 
>> the correct behavior implemented in bug fixes for
>> 
>> MultiResolutionPyramidImageFilter in December 2008).
>> 
>> 
>> 
>> 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: Thu, 5 Mar 2009 08:11:35 -0500
>> 
>> To: Tom Vercauteren <tom.vercauteren at m4x.org>
>> 
>> Cc: ITK <insight-developers at itk.org>
>> 
>> Subject: Re: [Insight-developers] Multi-resolution pyramid and
>> 
>> multi-resolution PDE deformable registration small issues
>> 
>> How about making this an option?
>> 
>> The default behavior can be unchanged (heck, could even throw a
>> 
>> deprecated flag and explain why).   If the option is set then the
>> 
>> deprecated flag isn't thrown and you get the behaviour you'd like.
>> 
>> Option should be controlled by a member function (NOT a cmake option).
>> 
>>   Perhaps something like: AlwaysSmoothOutput or OverSmoothOutput or
>> 
>> some such...
>> 
>> s
>> 
>> On Thu, Mar 5, 2009 at 4:12 AM, Tom Vercauteren <tom.vercauteren at m4x.org>
>> 
>> wrote:
>> 
>> Hi all,
>> 
>> I just saw a few weird things in some multi-resolution objects.
>> 
>> First of all, the MultiResolutionPyramidImageFilter will always
>> 
>> produce a blurred image even with an all one schedule. This is because
>> 
>> the input it always smoothed to produce the output. If the schedule at
>> 
>> a given level is all one, the sigma of the Gaussian will be 0.5.
>> 
>> This case is better handled in
>> 
>> RecursiveMultiResolutionPyramidImageFilter. In that class, if the
>> 
>> schedule is all one, the output will only be a casted version of the
>> 
>> input. This makes more sense to me.
>> 
>> Would anyone mind if I changed the behavior of
>> 
>> MultiResolutionPyramidImageFilter to perform the same operation as
>> 
>> RecursiveMultiResolutionPyramidImageFilter in the case of all one
>> 
>> schedule?
>> 
>> 
>> Also it seems that RecursiveMultiResolutionPyramidImageFilter should
>> 
>> be the default image pyramid class for most applications. It is more
>> 
>> efficient than MultiResolutionPyramidImageFilter when the schedule is
>> 
>> downward divisible and falls back to MultiResolutionPyramidImageFilter
>> 
>> when it is not.
>> 
>> Would anyone mind if I changed the default image pyramid filter in
>> 
>> MultiResolutionPDEDeformableRegistration to be
>> 
>> RecursiveMultiResolutionPyramidImageFilter instead of
>> 
>> MultiResolutionPyramidImageFilter?
>> 
>> Regards,
>> 
>> Tom
>> 
>> _______________________________________________
>> 
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at
>> 
>> http://www.kitware.com/opensource/opensource.html
>> 
>> Please keep messages on-topic and check the ITK FAQ at:
>> 
>> http://www.itk.org/Wiki/ITK_FAQ
>> 
>> Follow this link to subscribe/unsubscribe:
>> 
>> 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
>> 
>> _______________________________________________
>> 
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at
>> 
>> http://www.kitware.com/opensource/opensource.html
>> 
>> Please keep messages on-topic and check the ITK FAQ at:
>> 
>> http://www.itk.org/Wiki/ITK_FAQ
>> 
>> Follow this link to subscribe/unsubscribe:
>> 
>> http://www.itk.org/mailman/listinfo/insight-developers
>> 
>> 
>> 
>> 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.
>> 
>> 
>> 
>> _______________________________________________
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> 
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers
>> 
>> ========================================================
>> 
>> Bradley Lowekamp
>> 
>> Lockheed Martin Contractor for
>> 
>> Office of High Performance Computing and Communications
>> 
>> National Library of Medicine
>> 
>> blowekamp at mail.nih.gov
>> 
>> 
> 
> 
> 
> -- 
> Stephen R. Aylward, Ph.D.
> Chief Medical Scientist
> Kitware, Inc. - North Carolina Office
> http://www.kitware.com
> (518) 371-3971 x300

More information about the Insight-developers mailing list