[Insight-users] Re: Remark on MultiResolutionImageRegistrationMethod

[Luc Bracoud]

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
>