SimpleITK

From KitwarePublic
Revision as of 15:09, 23 August 2010 by Blezek (talk | contribs) (→‎Sandbox)
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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