Notes
(0015568) Tom Vercauteren (developer) 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 (developer) 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 (developer) 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 (developer) 2010-11-04 15:57	Kent, This may be fixed already, but you need to double check the behavior.

(0023393) kentwilliams (developer) 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 (developer) 2015-12-02 12:48	This issue has been solved in ITK v4 by clearly documenting the difference between the two classes.

Issue History
Date Modified	Username	Field	Change
2008-05-12 11:21	sajendra	New Issue
2008-05-12 11:21	sajendra	File Added: itkMultiResolutionPyramidImageFilter.patch
2009-03-05 13:43	Tom Vercauteren	Note Added: 0015568
2009-03-05 13:45	Tom Vercauteren	Relationship added	related to 0008482
2009-03-05 13:46	Tom Vercauteren	Note Added: 0015569
2009-04-07 23:09	Hans Johnson	Status	new => assigned
2009-04-07 23:09	Hans Johnson	Assigned To	=> kentwilliams
2009-04-09 07:31	Hans Johnson	Note Added: 0015982
2010-11-04 15:57	Hans Johnson	Note Added: 0022856
2010-11-18 13:19	kentwilliams	Assigned To	kentwilliams => Bill Lorensen
2010-11-18 13:20	kentwilliams	Note Added: 0023393
2015-12-02 12:48	Dzenan Zukic	Sprint Status	=> backlog
2015-12-02 12:48	Dzenan Zukic	Note Added: 0039938
2015-12-02 12:48	Dzenan Zukic	Status	assigned => closed
2015-12-02 12:48	Dzenan Zukic	Resolution	open => fixed