ITK Roadmap 2007 2008

Introduction

The future developement of ITK relies heavily on feedback from the community of users and developers as well as guidelines from the clinical and medical research community.

This page is intended to gather feedback regarding the future direction of ITK and in particular to list specific features and functionalities that would make the toolkit more useful for the medical imaging community.

Users/Developers Support

This section relates to the services that will help beginners to start with ITK as well as material that will help experienced users to take better advantage of the functionalities available in the Insight toolkit.

• Tutorials
• Mailing List Support
• Bug Tracking / Triage / Fixing
• Weekly telephone conferences
• Updated printed guide

Infrastructure

Maintaining Existing Infrastructure

Supporting Tools

• GCC-XML: Upgrade internal parser to use the one from GCC 4.X.
  • Gcc 4.2 has been released and its headers break current GCC-XML parsing.
  • This may require about 1-month-person.

Toolkit Itself

• Dealing with new compilers
  • e.g., Microsoft Visual Studio Express 2008 is in Beta2
• Using Bullseye code coverage tool in addition to gcov
  • Bullseye works in Windows and Linux

Improving Infrastructure

Nightly Testing

• CMake
  • Allow tests to run in parallel (i.e. make Experimental -j8 should complete more quickly than make Experimental)
• Dart v3
  • Includes integration of BatchMake with CMake/Dart.
    • BatchBoards that plot results from multiple datasets and machines, and over time will be integrated with Dartboards.

Grand Challenges

In this section we would like to address the need for comparing different algorithms by running them using common collections of images.

This can be done by

1. making the collections publicly available
2. or by the authors making their source code publicly available
3. or combinations of both.

The goal is to provide an infrastructure where algorithms can effectively be compared in a fair and reproducible context.

• RIRE (and other automated test tools)
  • Complete integration of BatchMake and the Insight Journal
    • Provides automated scoring of IJ-submitted segmentation and registration algorithms.
    • Scoring is accomplished using BatchMake and sequestered testing data
  • Gather additional data with truth for testing.
    • Data must have already been acquired by others and must have already been made available for public use.
    • Funding will go towards manipulating the data and defining scoring metrics to work in the RIRE testing environment

Improving ITK

Improving Existing Code Base

1. Completing Statistics Refactoring
   • Classifiers refactoring (hardly backward compatible / will use deprecation policy)
   • Multi-threading Expectation Maximization (EM).
     • method by Dempster, Laird, and Rubin, John Wiley and Sons, 1973 - that method is used by STAPLE, classifiers, and reconstruction methods).
2. Multi-Processors
   • Work with Dan Blezek to integrate new threading library (that uses a thread-pool and other advanced threading features) as an alternative to ITK's threading existing library
   • Thread pools, in particular, will reduce the overhead (programmer and CPU) of using threads.
3. Technical points
   • Remove support for VS6, and finally allow template member function which are not template parameter of class,
   • Convert single threaded filter to be multi threaded one,
   • allow multi threading ImageIO (reading different file can be done in different threads),
   • Add more support for 4D dataset (see IJ with unary retract filter for instance)

Keeping up with the Field

1. Adopting new methods from the literature
   • Process the backlog of current contributions in the Insight Journal
     • Move methods to the Review directory
     • Perform code reviews and subsequent fixes (coding style / refactoring)
   • Transition methods from MICCAI 2007 Open Source Workshop
2. GPU framework
   • Implement a portion of a pipeline (perhaps a simplified one with no branching allowed and no prior state saved) on the GPU.
   • This goes beyond using someone else's library to implement one algorithm, but instead would build a framework on which GPU algorithms could be developed.
3. Data provenance
   • The follow-on to image databases is data providence, i.e., tracking images after they leave the database.
     • Providence refers to tracking the acquired data and subsequent processing that lead to a particular image.
     • The providence of non-image data could also be stored (e.g., the file could record the pipeline that was used to generate a surface model)
   • Two components are essential
     • Tracking the processing while image is in memory
     • Tracking the processing while image is on disk
   • Regarding tracking images in memory
     • ITK's metaDataDictionary is ideal
   • Regarding tracking images on disk
     • While this could be done within some image formats, providence information can be lost when an image is converted between formats.
     • To preserve providence information, independent of the image format, we propose to use an adjunct file to store an image's providence. That is, the providence file will be an extra file that parallels (refers to) the actual data that is stored in an arbitrary image format. (Perhaps an implementation of the BIRN XCEDE 2.0 xml format could be used.)
   • First step towards maintaining providence: modify ITK's filters and extend ITK's metaDataDictionary to generate, store, and maintain data providence information.
4. Tomographic reconstruction library
   • Perhaps outside of the initial focus of ITK, but eventually a compatible open-source effort needs to be developed.

Improving external languages support

With WrapITK, ITK is now really usable from python, but there is still a lot to do to have a really good support of external languages.

New classes policy

Every new class added in the Review directory should be wrapped before being moved to its definitive place, to be sure that its API will not be a problem to wrap the class.

Using the native swig instead of cable swig

Cableswig is a good tool, which has allowed to create the current wrapping system. However, cableswig uses a now old version of swig. We are not getting the bug fixes from the newer version. Also, cableswig do not expose all the nice feature of swig which would allow a better integration with the target languages.

Switching to swig is possible (an effort has began, but is now stuck by lack of ressources http://voxel.jouy.inra.fr/darcsweb/darcsweb.cgi?r=WrapITK-unstable;a=summary), and would solve the problems cited above.

Using explicit instantiation to reduce the binary size, and the compilation time

The ITK binaries for the 3 languages supported by ITK are really big. The explicit instantiation of the classes wrapped seems to be a promising way to reduce both the build time and the binary size.

Merging the different efforts into a single one

WrapITK as been modified by Dan Mueller to create ManagedITK, a new project to wrap the .Net languages, by Julien Jomier to create ExplicitITK, a subpart of ITK in charge of the explicit instantiations, and recently by Sebastian Seifert to create csharp bindings. All those projects are sharing a lot with WrapITK, but can't benefit of the new classes added in one project or the other.

They likely result from a too small flexibility of WrapITK code. However, instead of forking, the developers should try to enhance the WrapITK base code to make it fit their need, and make all those projects benefit of the changes made in the others.

Providing binaries

One of the biggest problem, while working with external languages, is to build ITK. The binaries with the default settings should be provided for windows and mac os x with the ITK releases. CPack has already been successfully used with WrapITK to build a python-itk installer for mac os x, and the size of the provided binary may highly benefit of the explicit instantiation cited above.

A binary distribution is already kindly proposed by Charl P. Botha.