Difference between revisions of "Proposals:Calculators Architecture"

From KitwarePublic
Jump to navigationJump to search
Line 36: Line 36:




* Having two separate implementation, both with the name "Calculator", that inherit from entirely different trees and with different methods is inconsistent and confusing.   
* Having two separate implementations, both with the name "Calculator", that inherit from entirely different trees and with different methods is inconsistent and confusing.   
* It also makes it difficult to for developers to know which framework to use for implementing new calculators.
* It also makes it difficult to for developers to know which framework to use for implementing new calculators.


Here is a very troublesome example:
Here is a very troublesome example:


= Proposed changes =
= Proposed changes =

Revision as of 16:02, 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 derived from Object and were not part of the pipeline.
  • A new group of calculators inherit from ProcessObject and are part of the pipeline with the following properties:
    • Inherits from ProcessObject
    • Are part of the pipeline
    • Must include the following methods: Update, SetInput, GetOutput
    • Provide a Compute() method that simply calls Update()
    • Examples:

Calculators: Based on Object() Must have a Compute() Context specific Set/Get methods Give examples:

New code:

How to write a new calculator? Drawbacks: Can't hot-swap calculators, pipeline overhead Calculators were designed to be fast and separate from pipeline structure 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. 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


Existing limitations

  • Having two separate implementations, both with the name "Calculator", that inherit from entirely different trees and with different methods is inconsistent and confusing.
  • It also makes it difficult to for developers to know which framework to use for implementing new calculators.

Here is a very troublesome example:

Proposed changes

Current Status



ITK: [Welcome | Site Map]