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

Wed Mar 25 14:31:27 EDT 2009

This was changed was for no apparent reason in ITK 3.12.

http://www.itk.org/cgi-bin/viewcvs.cgi/Code/Algorithms/itkMultiResolutionPyramidImageFilter.txx?root=Insight&r1=1.26&r2=1.27&sortby=date

The previous behavior (which is how they had been working since 2004)  
is the correct behavior!

For me this is VERY significant I have already waisted a significant  
amount of time trying to getting better results in my registration.

I would even suggest that this should be a patch to 3.12!

Brad :(

On Mar 25, 2009, at 2:19 PM, kent williams wrote:

> So you’re saying smoother->SetUseImageSpacing(true) may be causing  
> your problem?
>
> At a minimum, in order to A) support what many people consider  
> ‘correct’ behavior and B) maintain backwards compatibility, it would  
> be good to add a SetUseImageSpacingForSmoothing method.  That way,  
> if you know you don’t want Image Spacing to affect smoothing, you  
> can turn it off. As it stands now you’re stuck with it.
>
>
>
> On 3/25/09 1:14 PM, "Bradley Lowekamp" <blowekamp at mail.nih.gov> wrote:
>
>> 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 <http://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
>>
>>
>>
>>

========================================================
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/a21b6a2b/attachment-0001.htm>