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

[Bill Lorensen]

Stephen,

As usual I agree, to a degree,

Maybe statisticians should build the library and not image processing
people. Then we should use it.

Bill


On Thu, Apr 9, 2009 at 4:59 PM, Stephen Aylward
<stephen.aylward at kitware.com> wrote:
> There is the philosophy that if you're going to break backward
> compatibility, then you should REALLY break backward compatibility.
>
> In this case it might be best to do what it takes to "get it right"
> this time, rather trying to preserve the old system.
>
> Similarly, regarding making things "consistent with itk", in my
> opinion it is ok to deviate from the ITK ways of doing things if it
> makes more sense in the statistics context - it is not surprising that
> a good statistics library doesn't resemble a good image processing
> library.
>
> So, the consist thread is that neither backward compatibility nor
> consistency should be the driving force in this implementation.   Get
> a statistics library that people use should be.   Heck, I'd be open to
> swapping out the whole things for calls to the R library...
>
> Stephen
>
> On Thu, Apr 9, 2009 at 4:41 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> Ah, but we did release Calculators in Statistics. I'm not suggesting
>> that Calculators be implemented as Filters, rather that Filters be
>> implemented using Calculators.
>>
>> We never released a  MedianImageCalculator, so there is no need to add
>> one now. But we did release Calculators in Statistics and we all
>> agreed to that API.
>>
>> I realize that it is probably not practical to keep the new Statistics
>> 100% backward compatible, but shouldn't we try as best we can?
>>
>> Bill
>>
>> On Thu, Apr 9, 2009 at 4:22 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>>> 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
>>>
>>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>
>
>
> --
> Stephen R. Aylward, Ph.D.
> Director of Medical Imaging
> Kitware, Inc. - North Carolina Office
> http://www.kitware.com
> (518) 371-3971 x300
>