[Insight-users] Re: Remark on MultiResolutionImageRegistrationMethod
Luc Bracoud
lbracoud@theralys.com
Thu, 14 Nov 2002 11:50:09 +0100
Hi,
I am well aware of the fact that adding "short-cuts" to the
MultiResolutionRegistrationMethod has its drawbacks and would introduce
many code redundancy, which is indeed to be avoided.
It was just a way to limit the potential risks of discrepancy between
RegMethod and PyramidFilters settings. Another way would be to remove
the SetNumberOfLevels method from the RegMethod class so that the user
has to set it at the PyramidFilters level only. The RegMethod would then
get the NumberOfLevels from its PyramidFilters members when really
necessary. (In PreparePyramid method, the RegMethod sets the number of
levels for both PyramidFilters, but the filters must have already been
set with the right number of levels and shrinking schedule)
This may be a better and sounder way. (but the class as it is now is
already very convenient and functional! :-))
Luc.
Lydia Ng wrote:
>Hi All,
>
>This is in response to Luc's request for change to the
>MultiResolutionRegistrationMethod class below.
>
>I have two reservations.
>
>1) Once you expose the SetStartingShrinkFactors to the
>MultiResolutionImageRegistrationMethod you would have to, for
>consistency, expose all the possible schedule methods for
>both the fixed and moving image. This means a lot of duplication
>in the interface, error checking and worst of all documentation.
>
>This duplication can also be a potential source of error in
>maintenance - as one change to the pyramid interface could
>mean many changes in the registration method interface.
>
>2) The shrink factor schedule construct was something that
>I came up with - others may want to do things differently
>(e.g. set the actual image size instead of shrink factors) -
>so if we expose some of the schedule setting methods to
>the registration method interface - we will need in the future
>to have different registration method for the different pryamids.
>
>I am very keen to reduce as much duplication as possible
>- but I am happy to open this up for discussion.
>
>Lydia
>