ITK/Roadmap 2005 2006: Difference between revisions

From KitwarePublic
< ITK
Jump to navigationJump to search
No edit summary
Line 31: Line 31:




=== Adopting Dart2 ===
=== Explicit Template Instantiations ===


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.
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:
<ul>
<li> Reduced compilation times for sources outside ITK libraries
<li> Reduced wrapper module sizes
<li> Reduced executable sizes when using shared libraries
<li> Increased testing of compilation of ITK templates
</ul>
and the following drawbacks will be met:
<ul>
  <li> Increased compilation time of ITK libraries themselves (though total time for ITK+application code will still be reduced)
  <li> Increased complexity in ITK sources to specify instantiations (similar to current wrapping specification)
</ul>


=== Increasing Code Coverage ===
=== Increasing Code Coverage ===

Revision as of 17:51, 11 May 2005

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

Tutorials

Workshops

Documentation

Doxygen

Software Guide

WIKI

Features and Functionalities

Software Engineering

Explicit Instantiations

This will improve compile time and will reduce the size of libraries and binaries


Typeless layer

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.


Explicit Template Instantiations

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:

  • Reduced compilation times for sources outside ITK libraries
  • Reduced wrapper module sizes
  • Reduced executable sizes when using shared libraries
  • Increased testing of compilation of ITK templates

and the following drawbacks will be met:

  • Increased compilation time of ITK libraries themselves (though total time for ITK+application code will still be reduced)
  • Increased complexity in ITK sources to specify instantiations (similar to current wrapping specification)

Increasing Code Coverage

Code coverage is low for a significan number of files. It is usually correlated with the less used classes in the toolkit

Add support to CTest for reducing redundant tests

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.

Explore other tools for code coverage in CTest

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

Increasing Valgrind/Purify Testing

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.

Add support to CTest for runtime profiling

Improving run-timeperformance of ITK algorithem requires to analyze the amount of time that each piece of code take for execution.

Potential candidate tools

  • Visual Studio
  • gprof
  • Valgrind/Calltree


Add Support for parallel testing in CTest

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.


Add Support to CTest for generating reports locally

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.


Deprecation Policy

Factorizing IO Classes with VTK

The ITK IO classes in ITK are very similar to the VTK ones. In many cases they were simply copy/pasted from VTK

  • A particular attention should be done for jpeg since ITK and VTK does not use exactly the same one.
  • Question: Does this mean that VTK/ITK should be synchronized on let say the exact same png library ?

ITK Complete

Package a release of ITK that contains

  • Insight
  • InsightApplications
  • VTK
  • FLTK

Along with a commong CMakeLists.txt file that will allow to configure the entire package with consistent options and minimal effort.

  • These distribution will factorize common resources such as KWSYS/PNG/JPEG/TIFF/expat/gdcm/

Experimental repository with Subversion (SVN)

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.

Image Modalities

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.

Color Images

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

  • Color model conversion (HSV, RGB)
  • Image IO
  • Segmentation
    • Statistical classifications
    • Region growing
    • Levelsets

Multi-Spectral Images

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

  • Enhancement and Noise reduction
  • Principla components analysis
  • Registration for multiple-component images
  • Callibration
  • Segmentation
    • Statistical classification
    • Region growing
    • Multicomponents level sets
  • Pattern recognition
  • Image registration
  • File formats


4D Images (time series)

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

  • Functional MRI
  • Perfusion images
  • Cardiac 4D
    • MRI
    • CT
  • 3D Ultrasound + time
  • PET


Tensor Images

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

  • Electrical conductivity
  • Refraction index
  • Mechanical resistance

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

  • File formats
  • Image size
  • Tensor operations
  • Tractography
  • Tensor based Segmentation
  • Tensor based Registration
    • Tensor to Tensor images
    • Tensor to Vector images
    • Tensor to Scalar images
  • Feature detection


Microscopy Images

The specific features of microscopy images are

  • 2D images
  • Large images (1K x 1K) up to (4K to 4K)
  • Mosaics
  • Need for annotations
  • Movement and tracking of particles
  • Multi-spectral images
  • Polarization
  • File formats (the microscopy community uses a large set of fileformats)


Confocal Microscopy Images

The specific features of Confocal Microscopy images are

  • 3D images
  • Strong anisotropy (Z spacing >> X,Y spacing)
  • Attenuation in Z
  • Large images
  • Multi-spectral images
  • Need for registration
  • 3D Mosaics
  • File formats (the microscopy community uses a large set of fileformats)


Transmision Electron Microscopy (TEM)

The specific features of Transmission Electron Microscopy images are

  • 2D images
  • Small signal to noise ratio
  • Large images
  • Need for model based segmentation techniques
  • Image features are close to the image resolution


Tomography from Transmision Electron Microscopy (TEM)

The specific features of TEM Tomography images are

  • 3D images
  • Small signal to noise ratio
  • Large images
  • Need for model based segmentation techniques
  • Image features are close to the image resolution


Endoscopic Images

The specific features of Endoscopic Microscopy images are

  • Video images
  • Color
  • Reflections in tissue
  • Continues movement
  • Shape from shading

Endoscopic images are more on the domain of computer vision but they are quite important in clinical applications.


Fluoroscopy Images

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.

  • Time varying images (video)
  • Geometric distorsion
  • Need for detection and tracking of instruments
  • 3D / 2D registration with 3D preoperative images


Mamography Images

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

  • Large images
  • 12 bits / 16 bits
  • Contrast enhancement
  • Calcification detection
  • Significance for Biopsies (assist localization)


Perfusion Images

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

  • Intensity normalization
  • Time series
  • Vascular modeling


What to include in ITK 2.2 (Scheduled for September 2005)

What to include in ITK 2.4 (Scheduled for February 2006)

What to include in ITK 2.6 (Scheduled for September 2006)