[Insight-developers] Some Thoughts on ITK Functional Instances

[Jisung Kim]

--0-952985126-994788882=:14652
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi.

I wrote a summary of my thoghts on ITK functional
instances. While I am working on computational
routines, I found that there are very limited amount
of information on how to ensure the reusability and
consistency of such routines (or objects). The
attached text file is the summary of my thought on
this matter.

The text file is in dos format, and I formatted it to
fit column size = 75.

=====
Jisung Kim
bahrahm@yahoo.com
106 Mason Farm Rd.
129 Radiology Research Lab., CB# 7515
Univ. of North Carolina at Chapel Hill
Chapel Hill, NC 27599-7515

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
--0-952985126-994788882=:14652
Content-Type: text/plain; name="ITK_Functions.txt"
Content-Description: ITK_Functions.txt
Content-Disposition: inline; filename="ITK_Functions.txt"

Some Thoughts on ITK Functional Instances



PROBLEMS

<More and more computational routines>

    As ITK grows bigger and more complex, it includes not only image
    related functions and algorithms but also more general
    computational routines. For example, people are working on
    statistical pattern recognition & model building
    software. Ideally, computational routines in the software don't
    have to be used only with image. I think ITK eventually will
    include more and more computational routines that are frequently
    used by filters or algorithms and not supported in C++ standard
    libraries or the VNL package.

<Reusability and consistency (Computational routines & Concepts)>

    Already ITK has many computational routines but some of them do
    not seem to be properly exposed so that users and developers can
    reuse them. It might cause redundant effort to implement similar
    or identical routines. There is also possible redundancy in
    definitions and interfaces of concepts. Some concepts that are
    integrated in an object are applicable to other objects. For
    example, InteriorExteriorSpatialFunctions Returns whether or not a
    location is "inside" or "outside" a function. However, a masking
    image might need the same concept and interface.

    A way of guarantee the consistency of concepts and their interface
    (which will result in reducing redundancy) could be a strict class
    hierarchy and use of base classes with virtual functions. However,
    recent discussion on ImageFunction and ContinuousImageFunction
    shows that ITK developers are reluctant to creating base classes
    that do almost nothing; perhaps because of virtual function
    overhead or too much restriction on implementation of derived
    classes. Another possible way to do it is creating atomic concepts
    classes and using them to create practical objects -- forest
    design paradigm comparing to tree paradigm (base classes with
    single inheritance).

    Another issue of consistency arises by the fact that some
    algorithms (or Functions) expect functional objects with specific
    interface. The Optimizer and the CostFunction pair is a good
    example of such case.
 
<How about "low-level" functions>

    There are some functions that are included in more complex
    computational routines but might be useful as low-level functions
    (not classes). For example, the energy function in the MR image
    bias correction example uses a "valley function" that produces
    valley shaped curve. GaussianOperator has several different kinds
    of Bessel functions. I believe such functions should be exposed to
    ITK users and developers as functions belonging to global or
    common "math" namespaces.
 
<OK, we have well-defined concepts and "low-level" functions. How can
I find them?>




SUGGESTIONS

<Concepts Index>

    This index is a list of concepts. Each concept entry consists of a
    definition, common interfaces (member functions and typedefs),
    related concepts, base class, and related classes.

=========== Example entries=========
* Bi-directional Iterator
Definition:
    An Iterator supports backward and forward iterations
Common interfaces:
    Operators
        o --this (default prefix)
        o ++this (default prefix)
Base class:
    None
Related concepts:
    Iterator, Forward Iterator, Backward Iterator, ...
Related classes:
    ImageIteratorWithIndex, SimpleImageRegionIterator, ...

* Cached Results
Definition:
    Pre-evaluation of a function with or without sampled input value
    and saving the result for later use
Common interfaces:
    Member functions
        o OutputType Evaluate(x) - before returning result lookup
        cached values (possibly overrides Function Object's
        Evaluate(x) method)
Base class:
    Planned
Related concepts:
    Function Object, Cost Function
Related classes:
    ValleyCostFunction, ImageMomentsCalculator

* Cost Function
Definition:
    A function object that allows coefficients replacing and
    evaluation using fixed input values and the coefficients.
Common interfaces:
    Types
        o CoefficientsType
        o MeasureType
    Member functions
        o Get/SetCoefficients(CoefficientsType)
        o MeasureType EvaluateCoefficients(CoefficientsType)  
Base class:
    None
Related concepts:
    Function Object, Cacheable Results
Related classes:
    CostFunction, Optimizer, ...

* Energy Function
    See Cost Function

* Function object
Definition: 
    An object evaluates a point in space or value using functional
    computation
Common interfaces:
    Types
        o OutputType - return type of Evaluate(x) function
    Member functions     
        o OutputType Evaluate(x) - evaluates x 
Base class:
    None 
Related concepts:
    Cost Function, Cacheable Results
Related classes:
    ImageFunction, SpatialFunction, ContinuousImageFunction, ...


    This index would help users and developers to easily find relevant
    concepts and their interfaces and use them in their new functional
    object in consistent manner. It will help keep consistency even
    without implementation of base classes. If we want to adopt forest
    design paradigm partially or totally, this index will be a good
    blue print for such adoption.

    We may list them alphabetically in a HTML page or separated HTML
    pages with links to related concepts, classes, and so on.

<Low-level function Index>

    In the case of separate index files, each entry of this index
    would consists of a description, limitations, source-file,
    libraries, and input/output types. Since Doxygen supports "File
    Members" index, we may not need separate index file at all.

=============== Example entry ====================
* double valley (double d)
Description:
    creates a valley shape curve using the functional form 1 - 1 / (1
    + d*d / 3) which hits the lowest point (zero) at d = 0.
namespace:
    global
limitations:

Source:
    Code/Numerics/CurveFunctions.h[cxx]
Libraries:
    ItkMiscFunctions, itkSpecialFunctions



--0-952985126-994788882=:14652--