SimpleITK

From KitwarePublic
Jump to navigationJump to search

Simple ITK

Goals

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

Examples of Other Librarires

Sandbox

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 from discussions held during the tcon:

  • 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 indicating that it is a Point, Vector or CovariantVector ?
      • Manage Dimension dynamically (or hide it internally), just like the simple Image class.
  • SimpleITK making it look natural in Wrapped languages
    • Provide functionalities for converting ITK classes into classes of the target language
  • SimpleITK & Visualization
    • Should we provide some simple visualization capabilities ?
    • Easy conversion from ITK simpleImage to vtkImageData
    • Basic Viewer example (maybe based on Qt+VTK: or CTK for that matter) that takes origin, spacing and orientation into account.
  • What pixel types to include ?
    • Suggested for Microscopy
      • unsigned char (int8)
      • signed short (int16)
      • unsigned short (uint16)
      • signed int (int32)
      • unsigned int (uint32)
      • float (float32)
      • double

Tcon topics 8/13/2010

  • How many classes to expose ?
    • Start with the classes exposed in v3d plugins (~80)
    • Grow to about ~200 ~300 classes
    • From there, listen to community feedback regarding new classes to add.
  • Support for Large Data
    • SimpleITK must be usable for building real applications.
    • It must support image larger than the available RAM.
  • Identify Target Customers for SimpleITK
    • Groups that are not using ITK at this point, because this consider it too complicated
    • Invite them to be early evaluators of the SimpleITK prototypes.
  • Reviewing the MetaProgramming layer used by Brad L. to instantiate types
  • How to manage multiple component images ?
    • Have an array of simpleITK images ?
  • How to manage time ?
    • ND+t ?


Tcon topics 8/17/2010

  • Next ITKv4 Meeting - Potentially October 4-6
  • Additional Conference Calls held last week
    • SimpleITK
    • Microscopy
      • Summary: What changes to the ITK fundamentals required for large image sizes. There may be issues for video processing as well
        • How to deal with time as a dimension
        • Memory management (Streaming)
      • Possible changes to the image structure - Luis will make proposal to handle these issues and present to the group
        • Video processing may require a ring buffer structure
        • Iterators may need to be updated to avoid access to the buffer pointer
        • Possibility of using image adapters
      • Multi-resolution Images
        • Possibility of support for this at the level of the image reader (JPEG2000: support for 2D images in files)
        • Query image reader for different resolution images
      • Non-regular image spacing
        • Potential different time point for top and bottom of image
        • VTK Rectilinear grid handles this
        • What filters are required to handle non-uniform spacing. Can convolution be applied and then resample to regular spacing
        • Does this cause a data explosion
      • File formats
        • Desire for more file format support: probably would benefit from just 2-3 formats
        • 64 bit TIFF reader, Vendor specific private tags
        • Update to libTiff is required
        • Streaming support exists for Meta, VTK, MRC. ImageSeriesReader will stream slice-by-slice
    • WrapITK
  • Sequestered reference applications
  • Clean-up Releases
    • Currently running behind
    • Limited coverage for Windows machines on the Dashboard - Need to turn on BUILD_EXAMPLES for these machines
    • Need to updated OpenJPEG (version 2) and libTiff
  • DICOM
    • Design for QR of PACS without writing to disk
      • Currently requires to locally save a copy of the file(s) before reading as an ITK image
      • How do you know what you are going to get (e.g. multi-planar scout images)
      • Create a database or data structure to present to the programmer and then create an image from the bulk data
      • What API is required to support this functionality
      • Data structure to hold information (DOM specification - Larry Tarbox from XIP - Stephen Alyward)
      • Potential to pass Metadata Dictionary