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.

Requested Algorithms

• Solve larger problems: MR tumor segmentation, CAD, atlas building
• Statistical Shape Models
• image projections, faster connected components
• Tracking
• other kind of morphology( integrated algorithms) filters for artefacts, more sensible
• focus on performance enhancement of existing algorithms, esp. registration/segmentation
• Feature detection.
• More support for pattern recognition stuff, like a good framework for classifyers Registration: - support for regularisation 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
• live wire segmentation
• Posibility to use more than one metric for registration, a more generic cost function framework. Vector field analysis.
• Graph cuts, More levelsets, Skull-stripping, Anatomical segmentation packages (e.g. colon extractor)
• Active Appearance Model
• Better Mesh processing tools
• Better support for algorithms operating on vector images, eg. multi-contrast MRI. Real spatial object fitting.
• Fuzzy C Means
• More shape based techniques
• DTI-related, e.g., fiber tracking, regularization
• More complete utilities, ie more advanced Regular Expression parsing
• Centerline detection algorithms, fine vessel segmentation algorithms
• More validation / comparision algorithms More simple image operations that seem to be missing
• machine learning - based algorithms.
• Spatial CFD code
• Additional algorithms for non-image data structures
• mesh smooth
• Wavelet toolbox Image Fusion toolbox
• surface mesh processing feature extraction
• More algorithms for meshes and discrete differential geometry.
• Delineation/Mesh manipulation
• Algorithms for tubular structure detection, extraction and analysis (Vessel detection, 3D skeletonization, tubular model based segmentation...) More methods for model-based segmentation.
• Improved classification framework.
• Methods for robust estimation.
• Statistical models, e.g. HMMs - more classification and clustering algorithms, e.g. SVM, Kohonen Maps etc.
• 2 and 3-manifold processing
• Spline fitting algorithms
• Some "simple" algorithms that can do simple things, for example find the contour of a volume.
• Algorithms for evaluation of segmentation algorithms (overlap measurements, etc.)
• 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) -Algorithms for dealing with point sets (e.g. Delaunay triangulation, Natural-neighbors interpolation, integration of a graph library such as boost graph)
• Computational geometry algorithms and signal processing tools
• segmentation using graph cut Progressive Livewire
• Nice implementations of Marching Cubes like the vtkContourFilter.
• Wavelets algorithms shape descriptors for labeled images deconvolution algorithms
• Live Wire semi-automatic segmentation, Robust and fast iterative closest point algorithm

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.