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

[Bradley Lowekamp]

Hrmm this is interesting!!!

I am currently running slice to slice registration on  scanning  
electron microscopy data. This data is very noise compared to most  
medical imaging. This Image spacing parameter could significantly  
change registration! it has been running poorly recently and this may  
in fact be the cause. I will have to run things to determine if this  
is the cause... But a change like this would be very significant to my  
code :(

Also I don't see any way that the user could set a parameter to change  
this too!  If you had an image will large spacing it would in effect  
NOT apply a smoothing filter.

If I am understanding this correctly I would think it is a bug!

Brad

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.
>
> 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/dbf15efc/attachment.htm>