[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