SimpleITK

Simple ITK

Goals

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

Examples of Other Librarires

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

Sandbox

• http://github.com/dblezek/SimpleITK

Scope

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

Tcon topics 7/15/2010

Toll-Free #:      1-800-704-9804 
International #:  1-404-920-6604
Participant Code: 61466276

Thursday, July 15th, 3:30-5:00pm EDT
(2:30-4:00pm Central).

• General architecture
• Wrapping efficiency
• Should SimpleITK be mixable with normal ITK ?
  • At C++ level ?
  • At WrapITK (Python, Tcl ) level ?
  • Provide access to the underlying ITK image ?
• SimpleImage class
  • Include casting to other image types.
  • Introduce in ITK an itk::ImageBase class that is not templated over Dimension.
• Use Pointer semantics ?
  • image->getDepth() vs image.getDepth()

• What kind of flexibility to provide for Users to add functionalities to SimpleITK
  • It should be easy to write (even if the class is conceptually complex).
  • User says : "I need this data type X..."
    • Then, how hard is for the developer of SimpleITK classes to satisfy the user's request.

• Design a Simple calling convention
  • Procedural-like notation...
  • out = Gaussian().setSigma(2).execute(image)
  • out = Gaussian( image, 2 )
  • Gaussian gaussian( 2 ) // sigma as argument to the constructor
  • gaussian( "Sigma",2, "Width", 2 ); // arguments packed as key,value pair
  • Add introspection to ITK proper
    • All filters provide a list of "Key, Type" pairs
    • SetParameter( "parameterName", parameterValue );

Tcon topics 7/16/2010

• IO class to combine ImageFileReader and ImageSeriesReader into a single class.
  • • Make this class in ITK proper first, then expose it in simple ITK.
• Namespace to use : "sitk" or "stk".
• Const-correctness: (yes)
• Thread-safety:
  • The same instance of the object can't be used from multiple-threads.
  • Multiple-threads can create instances of an object type.
• Testing
  • Based on the same testing framework as ITK.
  • Higher quality bar than ITK proper.
• Exposing basic types:
  • Avoid exposing low level types such as Region, Array...
• Registration
  • Implement pre-fabricated modules that contain a full registration framework
  • Used the Finder (dynamic registration) pattern to reduce compilation time (enable parallel compilation).
    • Finder will locate even internal components (such as interpolators) by name (using a string).
  • Should the output be a
    • Resampled Image ?
    • Transform ? ( <----This one )
    • Transform Parameters ?
  • There will be a simpleResample that takes a simpleTransform as argument
  • There will be simpleTransformReader & simpleTransformWriter
• Segmentation
  • Output should be a LabelMap (plus a naming convention)
    • Make this class in ITK proper first, then expose it in simple ITK.
    • Along with Readers and Writers.
  • "Feature" associated with every label.
  • The Registration resampler should be able to map label images as well (to map a segmentation from an atlas to a subject, for example).
  • Level Sets will be packaged at a modular level (with their preprocessing filters included).

Tcon topics 7/22/2010

• Should SimpleITK be mixable with VTK?
  • SimpleImage class include casting to vtkImage?
  • Concept: interactive programming languages are really cool if they include data visualization. We need to have a way to visualize images as we process them.

Tcon topics 8/12/2010

Notes:

• Gabe Hart reported on experiments with wrapping SimpleITK for Java
  • How to manage classpath ?
  • How to organize ITK classes into jar file.
    • Should they follow the distribution of "modular ITK" ?
• Synergy between WrapITK and SimpleITK
  • Could we use WrapITK infrastructure to generate the instantiations of SimpleITK ?
• Brad L. reported on experiments using template metaprogramming for selecting pixel types
• Discussion about what pixel types to provide
  • Should they be extendable by a user ?
  • How about "unsigned long" ? (or is it Label Maps what we really want ?)
• Label Maps
  • We agree in that they should be a first class citizen object, at the pair of the image
  • How to map LabelObjects from one image grid coordinates to another ?
    • Do we need a "resample label map" filter ?
• Procedural look and feel
  • Should SimpleITK has a procedural look ? (ala Matlab ?)
  • Or the sequence of "create object, set parameter, set parameter.... execute"
  • Can we have both ?
    • Without one diminishing the other ?
• What to do with basic Arrat types ?
  • Point, Vector, CovariantVector
    • How to hide their dimension ?
  • Introduce a generic "Array" class at SimpleITK level ?
    • maybe with an internal enum