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

Thu Mar 5 10:08:32 EST 2009

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/itkMultiResolutionPyramidImageFilter.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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090305/fe840470/attachment-0001.htm>