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

Thu Mar 5 10:33:34 EST 2009

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

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