[Insight-developers] Registration classes

[Luis Ibanez]

"Asad A. Abu-Tarif" wrote:
> Why not have registration estimators also derive from
> the same class?
>

By "estimators" do you mean the objects that evaluate
the similaty between images ?

> Most registration algorithms don't care what estimator
> you use as long as they do the same thing.
> This way, if someone implements a new optimization algorithm
> (say a new robust estimator or a new way of maximizing the MI),
> he/she doesn't need to also write a new registration algorithm
> specially for it. He/she can just pass it to an existing registration
> algorithm that uses the same 'kind' of estimator.
> 

Totally agree,
In fact is what we have tried to setup, maybe the current problem 
is that we are laking some documentation. 

Basically the registration methods have been decomposed in the
following generic elements:

- Reference object (usually an image but don't have to be so)
- Target object (usually an image but don't have to be so)
- Transformation (Translation,Rigid, Affine,Kernel based Splines) 
- Interpolator (will evaluate values for pixels at non-integer
positions)
- Mapper (put together interpolator,transformation and reference)
- Metric (measure of matching: MeanSquares, Correlation,
MutualInformation)
- Optimizers
(GradientDescent,ConjugateGradient,Amoeba,Levenberg-Marquardt)


itk registration methods are templated directly or indirectly over all
these
types.  We can, generate any mix just by adding a .h and a .txx file
with
the appropriate selection of elements. Given that the templates gives
the
framework for combining the elements, derivation is of secondary
importance,
because the polymorphisms is not obtained by using virtual funtions, but
just by instantiating the template with different types.

It is however interesting to factorize as much as possible using
derivation
from base classes, in order to organize the code and to reuse as much
code
as possible.



Thanks



Luis