ITK/2006 Survey Summary

In December 2006, 102 ITK users and developers took an online survey in order to evaluate the impact of the Insight Toolkit in the community.

Quick Facts

• 50% of the users have been using ITK for less than 2 years
• 73% of the users have cited ITK in at least one publication
• 34% of the users haven't used ITK for publication
• 40% of the users have put ITK in grant proposals
  • 75% of the users have used ITK to generate preliminary data for grant proposal
  • 90% of the users proposed to use ITK in their grant
  • 60% of the grant proposals were funded
• 80% of the users have been helped by ITK in there projects
• 98% of the users have used the Software Guide
• 27% of the users have attended an ITK course
• 75% of the users have made use of ITK Online Tutorials
• 20% of the users have taught a course using ITK
• 22% of the users have used ITK in commercial products
• 75% of the users have integrated ITK into software applications
  • 50% of the users have integrated ITK into preexisting apps
  • 88% of the users have integrated ITK into new applications
• 39% have released applications using ITK
  • 39% have released applications using ITK as only binaries
  • 80% have released applications using ITK as open source
• 72% of the users think the response on the user's list is fast
• 99% of the users would recommend ITK to others :)

Visual Summary

Users Experience

Areas of Use of the Toolkit

Grant Submissions

Contributions to ITK

Areas of Research other than Medical Imaging

• Astronomy
• Paleontology
• Computational geometry
• 3D modeling and animation
• BioMechanics
• Developmental biology Laser scanning microscope images
• Genomics
• Forensic Image Processing
• School projects

What would make ITK more useful?

Learning Curve

Mailing List Response Time

Answered Questions on the Mailing List

Considering ITK as a solution for New Problems

Requested Algorithms

Segmentation

• Live wire segmentation
• Feature detection
• Active Appearance Model
• More support for pattern recognition stuff, like a good framework for classifiers Registration: - support for regularization in image registration. As it is now only a metric can be used - support to do registration based not only on intensity, but also using features - More general support on getting samples from an image, as is done for the MattesMutualInformation metric. This is also useful for other metrics, but currently they simply walk over the entire image domain. A possible implementation can be found at www.isi.uu.nl/Elastix
• Algorithms for tubular structure detection, extraction and analysis (Vessel detection, 3D skeletonization, tubular model based segmentation...) More methods for model-based segmentation.
• DTI-related, e.g., fiber tracking, regularization
• Segmentation using graph cut Progressive Livewire

Registration

• Posibility to use more than one metric for registration, a more generic cost function framework. Vector field analysis.
• Registration algorithms with more complex cost functions (e.g. add a regularization term to a BSpline transform)
• Registration algorithms using "second order" optimizers such as Gauss-Newton/Levenberg Marquardt (Particularly useful for simple metrics such as mean square error)
• Robust and fast iterative closest point algorithm

Filters

• Image projections
• Faster connected components
• Other kind of morphology (integrated algorithms) filters for artifacts
• Graph cuts, More level sets, Skull-stripping, Anatomical segmentation packages (e.g. colon extractor)
• Spline fitting algorithms
• Some "simple" algorithms that can do simple things, for example find the contour of a volume.
• Spatial CFD code
• More shape based techniques
• More simple image operations that seem to be missing

Mesh related

• Better Mesh processing tools
• Better support for algorithms operating on vector images, eg. multi-contrast MRI. Real spatial object fitting.
• Mesh smooth
• Delineation/Mesh manipulation
• Surface mesh processing feature extraction
• More algorithms for meshes and discrete differential geometry.
• Algorithms for dealing with point sets (e.g. Delaunay triangulation, Natural-neighbors interpolation, integration of a graph library such as boost graph)
• 2 and 3-manifold processing
• Nice implementations of Marching Cubes like the vtkContourFilter.

Statistics

• Fuzzy C Means
• Statistical Shape Models
• Wavelet toolbox Image Fusion toolbox
• Machine learning - based algorithms.
• Methods for robust estimation.
• Statistical models, e.g. HMMs - more classification and clustering algorithms, e.g. SVM, Kohonen Maps etc.
• Improved classification framework.
• Wavelets algorithms shape descriptors for labeled images deconvolution algorithms

Validation

• Algorithms for evaluation of segmentation algorithms (overlap measurements, etc.)
• More validation / comparison algorithms

Others

• Tracking
• Focus on performance enhancement of existing algorithms, esp. registration/segmentation
• Additional algorithms for non-image data structures
• More complete utilities, i.e. more advanced Regular Expression parsing
• Computational geometry algorithms and signal processing tools

Requested Features

Wrapping

• Swig wrapping as vtk, more easy. WrapITK's very good, but it needs to be include into ITK.
• Improved Wrapping
• Wrapping for Perl
• Usable wrapping for Python. Judging by the remarks on the mailing list, it is possible to use Python, but only through near-heroic effort. It would be nice it it "just worked" in the same way that C++ does.

Documentation

• Better documentation, for example, some examples with class documentation.
• More documentation online
• Better way of finding things/features, as API is quite large and have often written things that already exist(and only found later hidden somewhere).
• More binary distributions
• Clear documentation of allowed input image types for algorithms
• More reactivity to bug reports
• The online Doxygen-generated documentation is not always great. I think at this point I would be happier to see people spend time on adding better online documentation (NOT the software guide, but the specific function documentation)
• ITK would benefit from a more solution-based index to all of its features. Finding solutions for specific problems is very hard with the existing documentation and mostly based on asking for help at the mailing lists.

GPU

• Support for implementing filters on the GPU. Feature descriptors.

Parallelization

• MPI support (I know, non-trivial)
• Parallel processing for clusters Parallel IO suitable for clusters
• Batch processing

GUI

• More integrated GUI support.
• Simple class with a simple GUI to provide the files an command line parameters interactively.
• A graphical application to design ITK pipelines could be nice. Workflow manager
• It would be nice if some of the better generalized front ends were released into the public domain.

I know that the decision not to support a specific GUI was a a basic design decision. However, for many (including me), it means that the learning curve for ITK includes the learning curve for writing a GUI.

Misc.

• Make it simple and fast :)
• More efficient - either in memory or processing.
• Many more tests

IO

• Faster DICOM reader better volume management
• A reader/writer for meshes (preferably to VTK's unstructured grid file format *.vtu, maybe also to UCD-AVS).
• Additional support is needed for transform I/O
• Probably an improved treatment of VRML format (textures)
• Support for microscopy I/O formats
• Add video-stream format support for Ultrasound or microscope.
• DICOM network support. I realize that ITK is more about image formats and image I/O. However, the fact of the matter is that I/O is I/O whether it comes from a binary data set on the local hard drive or from a DICOM network server (i.e., PACS). DICOM plays such an important role in the medical setting and this feature would make ITK much more useful out of the box. However, I realize this is probably feature creep.
• Support for conversion between other imaging platforms (e.g. JAI).

VTK

• Adapter classes for easy integration with VTK (again, I was surprised I had to write a converter from itk::Mesh to VTK myself)
• Easier transform between ITK and VTK formats
• Linkage to VTK is problematic, since the two systems are very similar but have fundamental differences that the developer needs to manually accommodate.
• I dream to have the equivalent of VTK's mesh processing in ITK, to avoid complex itk-vtk-itk pipelines.

Template related

• It would be nice if there was an "untemplated" image class as an abstract parent class of ImageBase or Image, such that it could be used to store images in a generic way (much like vtkImageData does in VTK) with no explicit info on type/dimensions.
• I would love to see ITK be more dynamic in it's support for data types. I often find it too restrictive for the work I need to do.
• Better basic support for vector images.
• The templating nature of ITK seriously limits the ability to write generic code w/o implicit workaround. I'm not sure how this could be addressed, but its definitely a pain.
• Performance enhancement using template specialization for the most common types (e.g. 2D and 3D floating point images) and simple code optimization

Algorithms

• Improved ANN support
• Graph analysis (for example to create graphs of vessel branches).
• Easier data handling, e.g. extraction of slices from a volume etc. (as long as that does not decrease flexibility)
• Shape analysis statistical analysis
• Animation concepts and tools (e.g. tracks, key-frame interpolation, etc.)
• Giving some architectural thought to things like transforms so that everything interoperates properly and one truly can mix and match metrics, optimizers, etc.
• Extended options for modeling parametric curves / splines

Build

• More straightforward build with less dependencies on other packages.