SimpleITK: Difference between revisions

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


* [[ITK_Release_4/SimpleITK/Tcon 2010 08 26|8/26/2010]]
* [[ITK_Release_4/SimpleITK/Tcon 2010 08 26|8/26/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?

Revision as of 19:30, 1 September 2010

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.

Examples of Other Librarires

Sandbox

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