[Insight-developers] Typeless C++ Layer

[Kent Williams]

I have worked on a version of this problem, namely using ITK to read in 
a file of arbitary pixel format and dimension, and copying it into the 
internal Brains2 image object.

The basic problem is that non-templated code needs to call templated 
code, programmatically.  I've handled this with template functions, 
templated by the image type. Then, a non-templated function uses a 
switch statement to select the proper templated image type to use.

That's all well and good for my particular application, which is 
essentially back-fitting ITK Image IO onto an existing program's 
internal structures.  What you're proposing is more general -- a sort of 
'Easy ITK' that makes programs less template-dependent.

The real problem you will run into is this: If you extend your new 
programmatic interface to cover filters in a general way, your program 
will be expanding templates for many permutations of image types, which 
will invariably lead to significant code bloat.  You end up with 
functions templated over both dimension and pixel type, producing many 
elaborations of each template.  If you build itkWish with all types 
enabled, you end up with a program with a huge memory footprint, that 
takes all day to build on a fast dual Xeon.

I suppose ultimately the code bloat doesn't matter that much -- only the 
pages of code actually touched will get loaded into real memory, but it 
seems like overkill.  But carrying around code that never gets called 
violates my sense of programming aesthetics, if nothing else.

I would suggest a slightly different strategy. Choose a limited number 
of pixel data types for the filter classes: Int and Float, and 3D pixels 
of float. That way, you convert between the image type of your generic 
image object to the most information-preserving datatype for processing 
by filters.

Ultimately, though, I'm not sure that hiding ITK's templated nature is 
really a good thing.  In terms of using the toolkit, the learning curve 
for working with templates is not that high.  Part of ITK's attraction 
after all is that you _don't_ consider every data type --you chose the 
template types that fits your problem best. An ITK program that does 
significant processing using C++ templates directory can be quite small, 
and is subject to quite agressive optimization by a decent C++ compiler.

Also there is already a fairly simple interface to ITK that works quite 
generally over most common datatypes, namely, to use Tcl or Python wrapping.


Seitel Mathias wrote:

>Hi all,
>
>The ITK Roadmap 2005/2006 mentions an interesting upcoming feature of
>ITK:
>
>"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."
>
>We have been thinking about ways to create more adaptive, less
>template-dependent interfaces to ITK in C++. Having a typeless, C++
>based layer would be a major step towards that goal. It would be great
>if an ITK developer could shed some light on the following points:
>
>1. What is the status quo of this feature? Is there already any
>information on how the typeless interface will look like?
>
>2. Will the entire templated ITK code be accessible via this layer, or
>just major classes?
>
>3. Is it possible to contribute to this project?
>
>
>Another interesting feature related to the above would be an interface
>for accessing prominent ITK classes (such as filters and data
>structures) in a unified way. Such an interface would allow the
>application code to set parameters of a filter and control its
>execution, without directly being aware of its class. Generally, this
>could be highly beneficial for unifying application development.
>Implementing this kind of interface manually for each class in question
>would be tedious, but building on the existing ITK wrapping mechanisms
>seems to be a workable alternative. Combining this with the proposed
>typeless layer would yield even more potential applications.
>
>
>Regards,
>Mathias
>
>
>(Sorry for the duplicate post -- I just found out that the developers
>list is accessible as well)
>_______________________________________________
>Insight-developers mailing list
>Insight-developers at itk.org
>http://www.itk.org/mailman/listinfo/insight-developers
>
>  
>