[Insight-developers] RecursiveMultiResolutionPyramidImageFilter -- questions about fixing bug 8482

Bradley Lowekamp blowekamp at mail.nih.gov
Wed Mar 25 15:18:54 EDT 2009


On Mar 25, 2009, at 1:31 PM, kent williams wrote:

> I don't have an opinion about whether ImageSpacing should be used in  
> these
> filters.  I didn't even know what a  
> MultiResolutionPyramidImageFilter was
> used for until this morning, when I read the comments in the header.


It is unfortunate, but a fact of ITK that the comments and the tests  
don't cover all of the expected behavior. I think the fact that this  
bug got through is an clear indication that we need another  
registration test which is noisy and has non-one spacing.

Kent, thank you for uncovering this bug. Making the change to not use  
image spacing to my local copy restored the quality of my registration.

Brad


>
>
> So to summarize, Tom thinks neither filter should use ImageSpacing for
> smoothing. Currently the RecursiveMulti... filter does not, but the
> MultiResolution... filter does.
>
> So the choices are
>
> 1. Maintain the status quo (which is inconsistent).
> 2. Make the two consistently use image spacing (which Tom thinks is  
> wrong in
> both cases).
> 3. Make the two both NOT use image spacing for smoothing (which  
> 'breaks
> backward compatibility' w.r.t. the MultiRes...Filter).
>
> I think in the long run choice 3 is the best, if in fact using image  
> spacing
> when smoothing is the Wrong Thing To Do.  Failing that, we need to  
> add a
> flag on the filter so that the behavior can be turned off for users  
> like
> Tom, who don't want it.
>
> On 3/25/09 12:00 PM, "Tom Vercauteren" <tom.vercauteren at gmail.com>  
> wrote:
>
>> Hi Kent,
>>
>>> In making RecursiveMultiResolutionPyramidFilter consisitent with
>>> MultiResolutionPyramidFilter, I made the smoother use  
>>> ImageSpacing.  This is
>>> consistent; is it desirable?
>>
>> Both multi-resolution pyramids define their sigmas in terms of pixel
>> sizes, not physical space. Therefore, they should use a smoother with
>> UseImageSpacingOff. This is what
>> http://public.kitware.com/Bug/view.php?id=503 says.
>>
>> I really don't understand why ITK 3.12 introduced UseImageSpacingOn
>> instead of UseImageSpacingOff in the smoother of
>> MultiResolutionPyramidFilter. This makes no sense to me and broke
>> bachwards compatibility.
>>
>> A patch should really not introduce this bug also in
>> RecursiveMultiResolutionPyramidFilter. I would definitely vote for
>> patching MultiResolutionPyramidFilter w.r.t. smoother spacing. This
>> will make both pyramids a little more consistent and would fix the  
>> bug
>> introduced in 3.12. It would not be strictly backwards compatible  
>> with
>> 3.12 but should be with 3.10 and earlier.
>>
>> Let me know if I am missing something.
>>
>> Regards,
>> Tom
>
>
>
> 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/20090325/589acfef/attachment.htm>


More information about the Insight-developers mailing list