[Insight-users] Roadblocks of using ITK in practice

[Jarek Sacha]

--- Will Schroeder <will.schroeder@kitware.com> wrote:
> If a non-parametric image class is added, how do you see modifying the 
> templated filters to process such a base class? I have some ideas but 
> rather than taint yours, I'd like to hear what you have to say first.

Will:

I would see it as a two phase change. Initially only non-parametric
classes for data representation objects are added. This already would help
solve some issues. In the second phase data processing API is extended to
actually support non-parametric data representation objects. 

The parametric filters should not need to handle non-parametric images.
Rather there should be a non-parametric "selector" that would instantiate
proper parametric filter based on information queried from a
non-parametric image base class. How this is going to be actually done is
a very good point for discussion. 

One possibility is to add a non-parametric base for each parametric
filter. This class will act as a filter handle and as a dispatch for
instantiating proper parametric filter. The point here would be to make
life easy for the user. A sample program using this approach could look
something like this:
 
// Setup image file reader
ImageFileReaderS::Pointer reader = ImageFileReaderS::New();
reader->SetImageIO(MyImageIO::New());
reader->SetFileName(inputFileName);

// Setup median filter
MedianImageFilterS::Pointer filter = MedianImageFilterS::New();
filter->SetInput(reader->GetOutput());

// Setup image file writer
ImageFileWriterS::Pointer writer = ImageFileWriterS::New();
writer->SetImageIO(MyImageIO::New());
writer->SetFileName(outputFileName);
writer->SetInput(filter->GetOutput());

// Execute pipeline
writer->Write();

Selectors would support some known set of data types. That is, only a
fixed number of parametric filters could be instantiated by a selector
since each type must be known at compile time. To aid a library developer
a right set of preprocessor macros could simplify writing instantiation
code for selector classes. Possibly, filter selector classes could be
automatically generated from filter templates.

>From the library development and maintenance point of view, creating a
"selector" for each filter may not be most desirable solution. A different
approach could be to provide a mechanism for assembling parametric
pipeline fragments, say using a parametric StaticPipelineChunk<> class and
then generating a "selector" for each such chunk. A StaticPipelineChunk
correspons to pipeline fragments where image type could not randomly
change. As before, the selector would handle instantiating
StaticPipelineChunk with proper data representation types at runtime. This
could be a solution simpler to implement and maintain but may be more
difficult to handle on the user side. 

In general, there should always be a possibility of directly using
parametric filter. With same care parametric and non parametric code could
be mixed. 

There may be a need to modify existing parametric filters and the pipeline
in general. For instance, many filters take output image type as a
parameter. In non-parametric pipeline, as in example above, the output
image type is decided by the filter based on the input image type and type
of processing. Another example, efficient streaming support may require
addition of messages that would indicate beginning (before first piece is
in) and end of streaming (after last piece is out) to prevent unneeded
re-instantiations of template-filters. 

Just some thoughts, hope that you will find them helpful. 

I wonder what you were thinking about.

Jarek


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