SimpleITK

Simple ITK

Goals

• Provide an easy-access layer to ITK for non-C++ expert developers

Advisory Review Board (ARB)

• The Advisory Review Board is composed of groups and individual who are potential users of the Simple ITK Layer.
• They provide advice to ITK developers of the simple layer regarding the design and implementation of the SimpleITK API.

• Advisory Review Board

Examples of Other Librarires

• CIMG: http://cimg.sourceforge.net

Sandbox

• Dan's: http://github.com/dblezek/SimpleITK (This is currently the "unofficial" SimpleITK repository)
• Gabe's: http://github.com/gabehart/SimpleITK (Experiments with multi-image filters, e.g. AddImage)
• Brad's: http://github.com/blowekamp/SimpleITK (Meta-programming experiment)

Scope

Current open questions

• Internal execution mechanism
  • switch statement, supported by macros
  • Factory mechanism, new image types could be added at runtime
  • Meta-programming
• Datatypes
  • What to support "out of the box"?
  • How easy/difficult to add new datatypes to a build?
• Compile times
  • Templates radically extend CPU and memory requirements
• Library size / scope
  • Custom SWIG files vs. automatically generated SWIG
  • Automation for SimpleITK facade generation from ITK classes?

Suggested Areas to Cover

• IO
• Basic Filters
• Registration
  • Basic Framework
  • Deformable registration
    • BSplines
    • Demons
• Segmentation
  • Region Growing
  • Level Sets
  • Classifiers
• Meshes ? (Not Yet)

Types

• Image pixel types supported
  • int8_t
  • int16_t
  • int32_t
  • float
• Image dimensions supported
  • 3D
  • Is 2D managed as a 3D image of 1 slice ?
    • Performance penalty for neighborhood filters... ?
    • Could be "2D" versions of 3D filters, i.e. RecursiveGaussianFilter2D. This would work on a slice-by-slice basis.

Languages

Wrapped languages will be any that SWIG supports, if someone is willing to write tests / any needed glue code.

• C++ Layer
• Python
• Lua
• Java
• ?

Implementation Details

• Coding Style
  • Copyright Headers & License
• Const correctness (can we avoid using const's completely?)
• Testing
  • C++ testing (Google Test?)
  • Python tests (PyUnit?)
  • Lua tests (?!?)
  • Java tests (JUnit)
  • ? other languages ?
• Managing basic types
  • Arrays
  • Regions
  • Transforms
• Not so basic types (could these be enums passed as ivars?)
  • Interpolators
  • Optimizers
  • Metrics

Plan

• Image classes
• IO

TCons

• 7/15/2010

• 7/16/2010

• 7/22/2010

• 8/12/2010

• 8/13/2010

• 8/17/2010

Tcon topics 8/26/2010

• Gerrit
  • What sort of work flow should we follow?
  • How do we get this set up correctly with git and github?
• Interoperability with ITK
  • Are we all agreed that this is a top priority?
• Flexibility w.r.t. dimensions
  • Are we all agreed that no more than 2D and 3D is needed?
• Flexibility w.r.t. types
  • Fixed set of types? (Just a thought)
  • Everything cast to doubles? (Again, just a thought)
  • Typing system
    • PixelTypeID
    • Instantiation
    • Runtime choosing of methods
    • Macros
      • Not pretty
      • Fairly intuitive
    • Meta-Programming
      • Hard to understand completely
      • Adds ability for each filter to specify what types it works for
• Dynamic casting
  • Should there be convenience methods to do this?
  • Should the user have to do it themselves?
• User seeing templates
  • Are we all agreed that the user should never see templates?
  • image creation without templates?
• Documentation
  • Doxygen
  • Tutorial?