On Jan 20, 2010, at 4:13 PM, Eris Discordia <eris.discor...@gmail.com>
wrote:
Aren't DirectShow filter graphs and programs like GraphStudio/
GraphEdit one possible answer to the video processing question?
Filter graphs can be generated by any program, GUI or CLI, and fed
to DirectShow provided one learns the in and out of generating them.
The OP's question, too, finds one answer in MS PowerShell where
instead of byte streams .NET objects are passed between various
tools and a C#-like shell language is used for manipulating
them. .NET objects can at any point be serialized/deserialized to/
from XML using stock classes and routines in
System.Xml.Serialization namespace.
Why XML? Surely there are better options.
Just a note that at least some implementations of both ideas exist
in production settings.
--On Tuesday, January 19, 2010 15:40 +0000 Steve Simon <st...@quintile.net
> wrote:
The PBM utilities (now net pbm) did something similar for bitmaps.
I think V10 also had some pipeline utils for manipulating images.
Indeed, however I make a firsm distinction between image
proccessing (2d)
and video processing (3d).
In Video processing the image sequences can be of arbitary length,
the
processing is often across several fields, and, because we want our
results ASAP tools should present the minimum delay possible (e.g. a
gain control only needs a one pixel buffer).
Aditionally image processing pipelines often have nasty things like
feedback loops and mixing different paths with differing delays
which all
need special care.
We have a package of good old unix tools developed jointly by us
and the
BBC which works as you might expect
cat video-stream | interpolate -x 0.7 -y 0.3 | rpnc - 0.5 '*' |
display
however this can get quite ugly when the algorithm gets complex.
We need to cache intermediate results - processing HD (let alone 2k
3d)
can get time consuming so we want an environment which tee's off
intermediate results automagicially and uses them if possible -
sort of
mk(1) combined with rc(1).
It is also a pain that its not easy to work at different scales i.e.
writing expressions to operate at the pixel level and using large
blocks
like interpolate, the rpnc is an attempt to do this but its
interpreted
(slow).
a restricted rc(1)-like language which supports pipelines,
and scalar (configuration) variables combined with a JIT compiler
(in the vein of popi) looks like a solution but I have never go
further
than wishful thinking.
-Steve
