Difference between revisions of "Proposals:Calculators Architecture"

From KitwarePublic
Jump to navigationJump to search
Line 36: Line 36:
= Proposed changes =
= Proposed changes =


A decision should be made on which framework should be chosen going forward.  Then the current calculators should be refactored to all have the same inheritance tree and consistent methods.
A decision should be made on which framework should be chosen going forward.  Then the current calculators should be refactored to all have the same inheritance tree and consistent methods. Here are some suggestions, none of which is great.
* Change the name of the calculators that inherit from
* Are there other better suggestions?


If the original framework is chosen, methods like Compute() should be moved to a layer between Object and the calculator so that all calculators inherit them automatically to yield a consistent API.  Such a layer could consist of classes that have consistent methods for inputs and outputs.  For example:
If the original framework is chosen, methods like Compute() should be moved to a layer between Object and the calculator so that all calculators inherit them automatically to yield a consistent API.  Such a layer could consist of classes that have consistent methods for inputs and outputs.  For example:
* HistogramThresholdCalculator class with methods: Compute, SetInputHistogram, GetOutputThreshold
* HistogramThresholdCalculator class with methods: Compute, SetInputHistogram, GetOutputThreshold
* ImageCalculator class with methods: Compute, SetInputImage
* ImageCalculator class with methods: Compute, SetInputImage
Rename these new 10?
Change name to have HistogramFilter in the name?
Take guts out and put them in real calculators that are called from the calculators?
Having layer above calculators to make the inputs and outputs more consistent


= Current Status =  
= Current Status =  


{{ITK/Template/Footer}}
{{ITK/Template/Footer}}

Revision as of 16:23, 26 July 2013

Proposal

Decide on the best architecture for how to implement ITK Calculators. Should they inherit from Object and be separate from the pipeline, or should they inherit from ProcessObject and be part of the pipeline?

Current situation

There are currently two different types of Calculators implemented in ITK, one that inherits from Object and is not part of the pipeline, and one that inherits from ProcessObject and is part of the pipeline.

  • Originally, all calculators had the following properties:
  • Inherit from Object
  • Are not part of the pipeline
  • Must include the following methods: Compute
  • Must include context specific Set/Get methods such as SetImage and GetThreshold
    • Examples: All calculators except those that inherit from itkHistogramThresholdCalculator, which inherits from ProcessObject. This includes, for example, OtsuMultipleThresholdsCalculator.
  • A new group of calculators having the following properties:
    • Inherit from ProcessObject
    • Are part of the pipeline
    • Must include the following methods: Update, SetInput, GetOutput
    • Provide a Compute() method that simply calls Update()
    • Examples: All calculators that inherit from itkHistogramThresholdCalculator. This includes, for example, OtsuThresholdCalculator.

Existing limitations

  • How should a developer write a new calculator? Should it inherit from Object or ProcessObject?
  • Having two separate implementations, both with the name "Calculator", that inherit from entirely different trees and with different methods is inconsistent and confusing.
  • Another drawback of having two different inheritance trees is that the calculators can't be hot-swapped since they have different methods.

Drawbacks: Can't hot-swap calculators, pipeline overhead Calculators were designed to be fast and separate from pipeline structure


Here is a very troublesome example: Example: Otsu. The only option is to call one from the other. Cannot take advantage of inheritance. Method need to be explicitly called on the one being instantiated.

Proposed changes

A decision should be made on which framework should be chosen going forward. Then the current calculators should be refactored to all have the same inheritance tree and consistent methods. Here are some suggestions, none of which is great.

  • Change the name of the calculators that inherit from
  • Are there other better suggestions?

If the original framework is chosen, methods like Compute() should be moved to a layer between Object and the calculator so that all calculators inherit them automatically to yield a consistent API. Such a layer could consist of classes that have consistent methods for inputs and outputs. For example:

  • HistogramThresholdCalculator class with methods: Compute, SetInputHistogram, GetOutputThreshold
  • ImageCalculator class with methods: Compute, SetInputImage

Rename these new 10? Change name to have HistogramFilter in the name? Take guts out and put them in real calculators that are called from the calculators? Having layer above calculators to make the inputs and outputs more consistent

Current Status



ITK: [Welcome | Site Map]