[Insight-users] Roadblocks of using ITK in practice

[Jarek Sacha]

ITK is has a very good potential of being a great image analysis package.
* Multi-platform support
* Large number of already available imaging algorithms
* Parametric algorithms and data representation 
* Pipeline architecture
* Potential for streaming and multi-threading support
* Last but not least, great community of users and developers

However, in the current stage, ITK is very difficult to be used for many
practical application. There are number of issues a developer stumbles
upon. To keep discussion focused, I want to single out one that is the
most critical: difficulty, or stating it more directly, practical
inability to handle image types at runtime.

Many data representation objects in ITK, an image in particular, are
parametric (template classes) without a related non-parametric base class.
Consider image representation, purely parametric representation means that
exact image type has to be known at compile time. Fixing image type at
compile time drastically limits  application's usability to handle images
with different pixel types (or dimension). In medical application, forcing
type conversion, in praticulat automatic type conversion, is undesirable.
Conversions that involve shifting and scaling distort data. Converting to
a 'larger' type to avoid scaling, e.g. 'short' to 'int' increases memory
requirement that is unacceptable for processing of large images. ITK is
missing a base non-parametric image class. This class should allow
querying information about an image like its pixel type, dimension, size,
etc. This information could be used to execute a version of a pipeline
that matches image typew without need of conversion. The solution to this
problem is relatively simple: add a base non-parametric image class for
ImageBase<> (or even better make ImageBase non-parametric by dropping
dimension as a template parameter). I do not suggest removing templates
all together, there are important for creation of generic and robust code.
I do suggest extending ITK architecture by adding non-parametric base
classes for existing data representation classes. This extension would
facilitate run-time type handling that enable writing code that can
directly handle various image types (without) need for conversion.

I would strongly advocate addition of non-parametric base classes to ITK.
This would help in creation of practical medical image analysis
applications. It would also help to resolve some of other ITKs issues like
wrapping in other languages or creation of more robust image I/O module.

Jarek


P.S.: Note that, in a limited sense, writing run-time type independent
code using ITK is possible. It is possible only in the case when input to
a pipeline is an image file. One can query image pixel type and dimension
before declaring and initializing processing pipeline. Here is a sample
code, for simplicity image dimension is ignored:

  MetaImageIO::Pointer io = MetaImageIO::New();
  io->SetFileName(inputFileName);
  io->ReadImageInformation();
  if(io->GetPixelType() == std::typeid(unsigned char) ) {
    MyPipeline<unsigned char> myPipeline;
    myPipeline.SetFileName(inputFileName);
    myPipeline.Update();
  }
  else if(io->GetPixelType() == std::typeid(unsigned short) ) {
    MyPipeline<unsigned short> myPipeline;
    myPipeline.SetFileName(inputFileName);
    myPipeline.Update();
  }
  ... // and so on


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com