No subject

"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