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

Thu Mar 5 12:03:29 EST 2009

Very good idea!

Got my vote!

s

On Thu, Mar 5, 2009 at 11:58 AM, Tom Vercauteren
<tom.vercauteren at m4x.org> wrote:
> 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
>>
>>
>

-- 
Stephen R. Aylward, Ph.D.
Chief Medical Scientist
Kitware, Inc. - North Carolina Office
http://www.kitware.com
(518) 371-3971 x300