[Insight-developers] Integrating the New Statistics framework into ITK

[Luis Ibanez]

Bill Lorensen wrote:
> 
> Just a few initial comments:
> 
> I see in general that Calculators have been replaced with Filters. It
> is a great idea to have filters. However, I'm suprised that the
> calculators are gone. In other parts of ITK, we have both Calculators
> and Filters. The Filters are implemented using the Calculators.
> 
> I wonder was there any consideration to minimize backward compatibility issues.
> 
---------------

Bill,

The main purpose of the refactoring was to make the Statistics
Framework compatible with the pipeline architecture of the
rest of the toolkit, and to solve for a number of structural
problems in the implementations (e.g. SubSamples of SubSamples).

In that regard the main change was to convert:

      * Samples    ----->  DataObjects
      * Calculator ----->  Filters

In the current statistics framework most operations are done by
Calculators. This was mostly due to the disconnection with the
pipeline architecture of the rest of the toolkit.

We could indeed reimplement the old Calculators based on using
the new Filters, but it will not correspond to the duality that
you refer to in other sections of the toolkit.

To be more concrete:

In ITK we have the ImageStatistics filter and we have the
Calculators that will compute min, max, variance ... etc.

But...
we don't have both a MedianImageFilter and a MedianImageCaculator,
we don't have AnisotropicImagefilter and AnisotropicImageCalculators
... etc... That is, not every filter is duplicated into a calculator.

This latter will be more a duplication of functionality (not to
mention a maintenance nightmare).


Calculators are a functional programming approach and they break away
from the data pipeline architecture of the rest of the toolkit.


If users are going to migrate and to learn a new framework,
we should avoid cluttering it with the same weaknesses that
we are trying to get away from.


Given that we are not going to remove the existing Statistics
Framework anyways, there is not much point into crippling the
new Framework with the burden of being backward compatible with
the structure that we already identified as having a number of
design limitations.


---

The rationale for the DensityFrequencyContainer being renamed as "2"
is detailed in the Migration Guide, at:
http://www.itk.org/Wiki/Proposals:Refactoring_Statistics_Framework_2007_Migration_Users_Guide#Frequency_Containers

It also lists the deperecated API (methods from the old class
that are no longer available in the new class), and the New API
(methods that replace the deprecated methods).



    Luis