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 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

25. MPI support (I know, non-trivial) 7. 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

Also I find that the linkage to VTK is problematic, since the two systems are very similar but have fundamental differences that the developer needs to manually accomodate.

• 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.