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.
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 have been typically presented in conferences related to Medical Imaging
The tutorials so far have been focused on Introductory material. The typical introductory tutorial is presented in 8 hours and does not allow for hands-on experience with the segmentation and registration methods. Now that the toolkit has a considerable user-base it seems appropriate to develop tutorials in more advanced topics and present those tutorials at conferences. Advanced tutorial could cover topics such as
Workshops allow for a more interactive experience than tutorials. In the context of a workshop, attendants are expected to contribute material and share it with colleagues. The framework of a workshop could provide a more effective atmosphere for discussing the addition of new classes to the toolkit and for improving the implementation of existing ones.
Documentation for ITK is provided at several levels. It includes the user's manual level provided by the ITK Software Guide, the reference manual level as provided by Doxygen and the community forum as provided by the Wiki.
The Insight Journal will come up online very soon.
We anticipate it to be the standard mechanism for
In particular, the Insight Journal will become a repository on specific recipies on how to process specific types of data sets. This will bring ITK a layer above of the plain image processing and into the more domain specific area of Medical Image Analysis.
Filters should be classified according to the pixel types that they can manage
The functionalities of the pixels should include, for example, being "additive", supporting "product by scalar", and so on.
This categorization should encompass two aspects
Most of ITK is provided as class templates. User code must instantiate these templates in order to use them. As a result very little of ITK is actually compiled when ITK itself is built. Only when testing, wrapping, or application code is compiled do the ITK class templates actually get instantiated and compiled. This leads to excessive compilation times for this code because every source that is compiled includes the implementation code of ITK for every class template it uses and everything those templates need to compile. It also leads to translation units that are too large to compile on certain compilers.
The motivation for using templates in the original design was to allow users to work with any kind of data. This functionality has been successfully provided, but most users' needs can be met by a few common instantiations of ITK's class templates. We plan to provide common instantiations in the ITK libraries themselves. It will then be possible for user code to use these instantiations by including only the interface (.h) files and not the implementation (.txx) files.
If we provide an explicit instantiation for every template currently instantiated by testing, wrapping, and common application code the following benefits will be reaped:
and the following drawbacks will be met:
A C++ typeless layer will provide users with a toolkit where the pixel type and dimension of the image do not have to be decided in advance. This layer will look very close to what VTK uses for representing images and imaging filters.
Code coverage is low for a significan number of files. It is usually correlated with the less used classes in the toolkit
CTest could provide coverage of classes per test in order to determine if a particular class is being covered in multiple tests. From this analysis, developers could remove redundant testing in the toolkit.
Currently we use gcov but this tool have some limitations. It will be desirable to have an alternative way of measuring code coverage.
CTest will have to parse the output of these alternative tools and format it according to what Dart/Dart2 expects as input.
Potential Candidates
Valgrind is a good candidate since it has so many different tools/skin. It allow profile on memory usage, do profiling of code.. (see addrcheck, cachegrind, corecheck, lackey, massif, memcheck )
Testing for run-time problems has received reduced attention. As ITK move more and more into applications, we should pay closer attention to the run-time correctness of the code. We should setup more machines for running Valgrind/Purify testing
Since these builds take longer, we could take advantage here of Dart2 new alternative periodicity. For example, run these tests on a weekly or montly basis and then enter in sessions for cleaning up the code.
Improving run-timeperformance of ITK algorithem requires to analyze the amount of time that each piece of code take for execution.
Potential candidate tools
This will make possible to launch multiple test simultaneously from CTest. In this way, users with multiprocessor machines will be able to reduce the time needed for running the test suite.
This functionality will make possible to analyze the results of the tests suite in a local machine, before it is submitted to the Dart/Dart2 server.
Dart2 will bring a large number of interesting features that will improve the quality control system for ITK. We should plan the transition from Dart to Dart2 in a progressive and organized way.
A committee has been named for designing and enforcing the implementation of a compassionate and user-friendly deprecation policy.
Technical solutions to allow compile time deprecation warnings is to use vendor specifc flags:
For more info see VTK_LEGACY in vtkSetGet.h
The ITK IO classes in ITK are very similar to the VTK ones. In many cases they were simply copy/pasted from VTK
Package a release of ITK that contains
Along with a common CMakeLists.txt file that will allow to configure the entire package with consistent options and minimal effort.
Subversion is an alternative to CVS and provides functionalites that are superior to CVS. Since this is quite a significant change, what we probably want to do is to start maintaining a parallel Subversion repository in order to gain experience with it for a project of the size of ITK.
A variety of image modalities are now well supported in ITK at this point. New image modalities may become important for the medical research community and later on for the clinical users. This section list the upcoming image modalities, their relevance and what would it take to support them in ITK. Note that the categories are not independent and that some of them will overlap.
Basic support exists now in ITK for dealing with RGB images. A reduced number of filters and segmenation techniques are ready-to-use in the toolkit. No support for registration of color images is currently available. Although several users have explored this domains, have written ITK classes for it and are willing to contribute their code to the toolkit.
The challenges are
Multi-spectral images are used for modalities such as Microscopy, MRI and optical tomograpy. Not to mention that ITK has been used for astronomy and for satellite imagery. The issues here are very similar to the ones of color images, with the distinction that here we are not subject to the particularities of the human visual system.
The challenges are
Time series are becoming more and more commong in clinical and medical research applications. ITK has the advantage of providing support for N-D images and algorithms. However few of it has been exercised in real cases, and few 4D specific studies have been performed. This issue is relevant for
Diffusion tensor images are probably the best known variant of tensor images. However, a large number of other physical properties of tissue are represented with Tensors, for example
It is conceivable that images measuring such parameters will become availabe in the near future.
ITK currently has expanded its support for DTI (Diffusion Tensor Images), but much remains to be done in order to provide all the functionalities needed for helping users to develop medical applications.
The challenges are
The specific features of microscopy images are
The specific features of Confocal Microscopy images are
The specific features of Transmission Electron Microscopy images are
The specific features of TEM Tomography images are
The specific features of X-Ray microscopy images are
The specific features of Endoscopic Microscopy images are
Endoscopic images are more on the domain of computer vision but they are quite important in clinical applications.
Fluoroscopic images are very important for image guided surgery, and for computer assisted diagnosis. Since fluoroscopy images are 2D projections of a 3D structure, they have specific challenges.
Very few is availble in ITK in order to support Mamograms. This is an area of significant public health relevance and deserves more attention.
Particular issues are
Perfusion images are quite important for evaluating the vascularization of tissue and for diagnosis and treatement of cardiovascular disorders.
The challenges with this images are
ITK uses a contiguous image memory model. All the pixels in an image/volume are in a single contiguous memory block. Many existing medical image analysis systems use a slice contiguous memory model. Here, all the pixels in a slice are in a contiguous memory block but the slices may not be contiguous in memory. A slice contiguous memory model has benefits over a volume contiguous memory model in memory management and cache coherency. ITK should consider adding an ability to operate on slice contiguous volumes. This will require modification to the image iterators and anywhere Image::GetBufferPointer() is called.
Spatial objects are being used by a variety of projects in foreseen and unforeseen ways, and their API must be reviewed/expanded to support the unforeseen applications. Additionally, SpatialObjects remain relatively unconnected to the rest of ITK - they are easy to use as a product of ITK processing, but there is limited support for having them drive ITK processing. Specifically,
Neural network methods will be added to ITK. These include multilayered neural networks with linear, sigmoid, and radial basis transfer functions. Training strategies such as backpropagation and quickprop. Also Kohonen self-organizing feature maps will be added. Helper-classes will simplify the implementation and use of traditional 3-layer backprop, non-linear component analysis, radial basis function, and feature map networks.
A file-dialog-style FLTK-based tool will be provided for dicom query and retrieve. This tool will be require the use of DCMTK. Using this tool, studies on a remote dicom server can be searched, retrieved, and loaded by an ITK application with minimal programming.
This file format is mostly used in Astronomy, but has the among others, the following interesting features
This file format seems to be suitable for managing Tensor images, Microscopy images, and very large datasets.
Logging classes are useful for debugging purposes and for facilitating to track the behaviour of applications at run time. Classes have been already developed by the ISIS center at Georgtown University and are planned to be integrated into ITK.