View source for 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

= Infrastructure =

== Maintaining Existing Infrastructure ==

* Dealing with new compilers
** e.g., [http://msdn2.microsoft.com/en-us/express/default.aspx 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 

# making the collections publicly available
# or by the authors making their source code publicly available
# or combinations of both.

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

* [http://www.insight-journal.org/nlm 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 ==

* 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).
* 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.

== Keeping up with the Field ==

* 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
* 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. 
* Data provenance
** Next step after image databases is data providence, i.e., tracking images after they leave the database.
** Providence refers to tracking the acquired data and subsequent processings that lead to a particular image.
** Two components are essential
*** Tracking the processings while image is in memory
*** Tracking the processings 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.)
*** 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) 
** First step towards maintaining providence: modify ITK's filters and extend ITK's metaDataDictionary to generate, store, and maintain data providence information.