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

Thu Mar 5 11:58:17 EST 2009

Before we settle for a decision, I'd like to document the inconsistent behavior.

Unless I get a better proposal, here's what I am planning to add:

For MultiResolutionPyramidImageFilter;

 * Note that even if the shrink factors are all equal to one, a smoothing
 * will still be applied. The output at the finest level of the pyramid
 * will thus typically be a smoothed version of the input.

For RecursiveMultiResolutionPyramidImageFilter;

 * Note that unlike the MultiResolutionPyramidImageFilter,
 * RecursiveMultiResolutionPyramidImageFilter will not smooth the output at
 * the finest level if the shrink factors are all one and the schedule
 * is downward divisible.

Cheers,
Tom

On Thu, Mar 5, 2009 at 17:50, Hans Johnson <hans-johnson at uiowa.edu> wrote:
> 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
>
>