[Insight-developers] Renaming frenzy

[Will Schroeder]

Thanks Luis, for some feedback. I've sprinkled some comments throughout. 
Some of these questions are probably better answered in person.

At 05:30 PM 1/26/2001 -0500, Luis Ibanez wrote:
>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).

Does it make sense to break this up into separate pieces?



> >
> > FileIO - -(removal) or ImageReader
> >
> > FileIOCommon - -(removal)
> >
> > FilterFileIOToImage - -(removal)
> >
>
>Are these FileIO classes going to the Interfaces directory ?

Maybe...there are obviously very important classes. I'm not sure where they 
belong without talking to the originator(s).



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

Ok, maybe FirstDerivativeRecursiveSmoothingImageFilter 
SecondDerivativeRecursiveSmoothingImageFilter are better.


> >
> > 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.

The comment refactor is there because of the thinking that the classes, 
which do several steps, could be broken into pieces/classes. The rational 
behind this is to create building blocks that can be combined in various 
combinations. The art of the design is to find the right shape for the 
blocks, too small and you're overwhelmed with bits and pieces and too big 
then you lose flexibility.



> > 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.

I think a general transformation hierarchy is essential. Specific 
subclasses can be
created for registration.


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

I think this is in general, bad. It's hard to find things, since many 
classes can
exist in one file.


>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"

I think this is a topic for discussion at the meeting in SLC. The reason 
that "Registration" is proposed to be removed from many class names is to 
try to think beyond just its use for registration. Isn't it possible that 
these classes could be generalized and/or used in other areas besides just 
registration?

Will