MantisBT - ITK
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007002ITKpublic2008-05-12 11:212015-12-02 12:48
Reportersajendra 
Assigned ToBill Lorensen 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformWindowsOSXPOS VersionSP2
Product Version 
Target VersionFixed in Version 
Resolution Date
Sprint
Sprint Statusbacklog
Summary0007002: MultiResolutionPyramidImageFilter blurs image when no resizing down
DescriptionFor pyramid level with downsample factor one, the output image should be the same as input. Currently the output is a Gaussian blurred version of the input.
Proposed patch checks for this special case.
Steps To ReproduceCreate multiresolutionpyramidimagefilter with one level and default schedule. Compare output to input.
Additional Information
TagsNo tags attached.
Relationships
related to 0008482closed kentwilliams RecursiveMultiResolutionPyramid needs to center of mass of original image 
Attached Filespatch itkMultiResolutionPyramidImageFilter.patch (925) 2008-05-12 11:21
https://public.kitware.com/Bug/file/1455/itkMultiResolutionPyramidImageFilter.patch
Issue History
Date ModifiedUsernameFieldChange
2008-05-12 11:21sajendraNew Issue
2008-05-12 11:21sajendraFile Added: itkMultiResolutionPyramidImageFilter.patch
2009-03-05 13:43Tom VercauterenNote Added: 0015568
2009-03-05 13:45Tom VercauterenRelationship addedrelated to 0008482
2009-03-05 13:46Tom VercauterenNote Added: 0015569
2009-04-07 23:09Hans JohnsonStatusnew => assigned
2009-04-07 23:09Hans JohnsonAssigned To => kentwilliams
2009-04-09 07:31Hans JohnsonNote Added: 0015982
2010-11-04 15:57Hans JohnsonNote Added: 0022856
2010-11-18 13:19kentwilliamsAssigned Tokentwilliams => Bill Lorensen
2010-11-18 13:20kentwilliamsNote Added: 0023393
2015-12-02 12:48Dzenan ZukicSprint Status => backlog
2015-12-02 12:48Dzenan ZukicNote Added: 0039938
2015-12-02 12:48Dzenan ZukicStatusassigned => closed
2015-12-02 12:48Dzenan ZukicResolutionopen => fixed

Notes
(0015568)
Tom Vercauteren   
2009-03-05 13:43   
A note has been added to the documentation
http://www.itk.org/cgi-bin/viewcvs.cgi/Code/Algorithms/itkRecursiveMultiResolutionPyramidImageFilter.h?root=Insight&r1=1.13&r2=1.14&sortby=date [^]
http://www.itk.org/cgi-bin/viewcvs.cgi/Code/Algorithms/itkMultiResolutionPyramidImageFilter.h?root=Insight&r1=1.20&r2=1.21&sortby=date [^]

Apparently, there is no consensus yet on how exactly to fix this:
http://www.itk.org/mailman/private/insight-developers/2009-March/011874.html [^]
(0015569)
Tom Vercauteren   
2009-03-05 13:46   
I have added a relationshipt to bug 0008482 because they both point out an inconsistent behavior between RecursiveMultiResolutionPyramidImageFilter and MultiResolutionPyramidImageFilter.
(0015982)
Hans Johnson   
2009-04-09 07:31   
On 4/9/09 6:30 AM, "Hans Johnson" <hans-johnson@uiowa.edu> wrote:

> Since this is considered a bug for over a year
> http://www.vtk.org/Bug/view.php?id=7002 [^] we should consider the fact that
> MultiResolutionPyramidImageFilter smooths for unit shrink factors a bug that
> would allow us to fix it (even through numerical sameness/backwards
> compatibility will be lost).
>
> This is not the behavior that I would expect by reading the documentation on
> how an Image Pyramid should be constructed (i.e. The top level should be an
> exact copy of the reference images).
>
> I think that this is a bug that also affects the
> RecursiveMultiResolutionPyramidImageFilter because it would produce different
> results for the unit shrink factor image if I change the shrink schedule from
> being downward divisible to being non-downward divisible. This is
> particularly nasty because given the same "shrink schedule [8,4,2,1]" the unit
> shrink result will be different depending on the size of the input image.
>
> ===============
> If there are no objects today, then the solution that will be implemented will
> be:
>
> 1) Add a test that fails when the unit shrink image is not the same as the
> reference image (and the m_SmoothIfUnitShrinkFactors =false).
> 2) Add the m_SmoothIfUnitShrinkFactors conditional flag to allow explicit
> smoothing of the unit shrink factors.
> 3) Set the default to "false" in all cases.
> ===============
>
>
> Regards,
> Hans
>
>
> On 4/9/09 1:56 AM, "Tom Vercauteren" <tom.vercauteren@gmail.com> wrote:
>
>> Hi Kent,
>>
>> Even if there is no consensus about what the default should be, it
>> could be add a flag that lets the user decide (as Stephen suggested).
>>
>> Maybe something like:
>> m_SmoothIfUnitShrinkFactors
>>
>> For backwards compatibility, the default for this flag would be:
>> - true for MultiResolutionPyramidImageFilter
>> - false for RecursiveMultiResolutionPyramidImageFilter
>>
>> Now, I also would like to propose a NON-backward compatible change to
>> fix something that might be very confusing to the user.
>>
>> Since RecursiveMultiResolutionPyramidImageFilter wil call
>> MultiResolutionPyramidImageFilter if the schedule is not downward
>> divisible, I suggest that RecursiveMultiResolutionPyramidImageFilter
>> sets
>>
>> internalNonRecursivePyramid->SetSmoothIfUnitShrinkFactors(this->m_SmoothIfUni>> t
>> ShrinkFactors)
>> when the schedule is not downward divisible.
>>
>> With this small non-backward compatible change, it would at least make
>> things a bit clearer.
>>
>> Otherwise we might need a three state flag for
>> RecursiveMultiResolutionPyramidImageFilter:
>> - AlwaysSmoothIfUnitShrinkFactors
>> - NeverSmoothIfUnitShrinkFactors
>> - SmoothIfUnitShrinkFactorsAndScheduleDownardDivisible (this being
>> the default for true backwards compatibility)
>>
>> Thoughts anyone?
>>
>> Tom
>>
>> On Wed, Apr 8, 2009 at 23:27, kent williams <norman-k-williams@uiowa.edu>
>> wrote:
>>> It seems Hans assigned me yesterday to fix this 'bug':
>>>
>>> http://www.vtk.org/Bug/view.php?id=7002 [^]
>>>
>>> As is noted there, there still doesn't appear to be a consensus on how to
>>> handle this problem.  So I've taken ownership of a bug with no clear way to
>>> fix it.
>>>
>>> If the issue is truly tabled, does it need to hang around as an open bug?
>>>
>>>
>>>
>>> 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 [^]
>>>
>> _______________________________________________
>> 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 [^]
(0022856)
Hans Johnson   
2010-11-04 15:57   
Kent, This may be fixed already, but you need to double check the behavior.
(0023393)
kentwilliams   
2010-11-18 13:20   
Bill, I don't know what the deal is with this bug -- if it has already been addressed, if it needs fixing, how to fix it.
(0039938)
Dzenan Zukic   
2015-12-02 12:48   
This issue has been solved in ITK v4 by clearly documenting the difference between the two classes.