[Insight-developers] Renaming frenzy

[Luis Ibanez]

Hi,

Some comments about the new naming:

> AffineMutualInformation - AffineMutualInformationMetric

This class is actually doing more that just the Metric.
It includes the Optimizer and a particular Transform  (affine).


>
> FileIO - -(removal) or ImageReader
>
> FileIOCommon - -(removal)
>
> FilterFileIOToImage - -(removal)
>

Are these FileIO classes going to the Interfaces directory ?


>
> FilterImageRecursiveGaussian - IterativeSmoothingImageFilter
>
> FilterImageRecursiveGaussianFirstDerivative - FirstDerivativeIterativeSmoothingImageFilter
>
> FilterImageRecursiveGaussianSecondDerivative - SecondDerivativeIterativeSmoothingImageFilter
>

The "Recursive" term on these classes standed for the fact
of implementing IIR filters. "Iterative" suggest more that
they use an algorithms that makes several passes.

In any case, what is important is to make the distintion with
filters that apply a convolution with a truncated gaussian.


> MutualInformation - MutualInformationMetric (MutualInformationImageMetric?)
>
> MutualInformationRigidRegistration - MutualInformationRigidTransform

Here there are two concepts together.  Using a Mutual Information Metric
and applying  a Rigid Transform



>
> RegistrationMapper - refactor (transform, sampler, probefilter)
>
> RegistrationMapperImage - refactor (transform, sampler, probefilter)
>
> RegistrationMapperProcrustes - refactor (transform, sampler, probefilter)

I would like to insist in the term "Mapper".
This class is supposed to "map" an object from the reference space
into the target space using a particular spatial transformation.



> RegistrationMethod - RegistrationTransform

Registratoin Method encapsulated the set of :
{   a spatial transform,  a similarity  metric,  an optimization method
},



> RegistrationMetric - SimilarityRegistrationMetric,

> RegistrationMetricProcrustes - ProcrustesRegistrationMetric
>
> RegistrationOptimizer - Optimizer

> RegistrationOptimizerAmoeba - AmoebaOptimizer
>
> RegistrationOptimizerConjugateGradient - ConjugateGradientOptimizer
>
> RegistrationOptimizerLBFGS - LBFGSOptimizer
>
> RegistrationOptimizerLevenbergMarquardt - LevenbergMarquardtOptimizer
>
> RegistrationOptimizerNonLinear - NonLinearOptimizer
>
> RegistrationTransformation - Transform

> RegistrationTransformationAffine - AffineTransform (did we have one above?)
>

About these set of  Registration classes:

They are supposed to be a family of Adaptors working together, rather
than real implementations of any code. For instance, the optimizers just 
call vnl methods, RegistrationTransformAffine uses an AffineTransform 
inside and just add the types that other Registration adaptors expect to 
find and use on the optimization process.

There are some extra things that don't seems to be justified in a
generic "Transform" class.  The idea was to use a family of Transforms 
(by now we only have Affine) and add to them the types and methods that 
facilitate to use it in the particular context of a registration
method.  
In that way we don't have to contaminate the real AffineTransform class 
with concepts that only make sense for  Registration, and we avoid to 
rewrite a second affine transform.

In some way that raises the question of allowing classes inside
classes....

Should we rather have a RegistrationMethod class with classes inside
being  Transform, Metric, Optimizer... ?

and allow code like:

itk::RegistrationMethod::Metric::Pointer   myMetric =...

in a similar way to what is done in itkArray with Reference and
ConstReference, and with itkLightObject and itkObserver...

That has the advantage of organizing concepts together, not just by
their names but by their distribution as a set of types.  The
disadvantage is the maintenance of big files with complex internal 
interactions.


Another alternative is to segment the namespace with sub-namespaces like

namespace itk {

namespace Registration {

.... Classes related with registration strategies

   }  // end namespace "registration"

}  // end namespace "itk"


That could be a good balance that still allows to regroup classes,
without having to couple them too thightly.  They can still be in
separate files and directories.  This is well supported in Doxygen
for the documentation,  at will make that when a user consult one
class of the group he will find the links to the others.



Luis