Revision as of 19:31, 1 September 2010

Simple ITK

Goals

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.

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)

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?

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

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.

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

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