i had some ideas along these sorts of lines which i put into a tool in inferno that i called "alphabet". it works (with a few rough edges). http://www.vitanuova.com/inferno/man/1/sh-alphabet.html
for an example of something it can do that's not possible with a conventional shell pipeline, see http://www.vitanuova.com/inferno/man/1/alphabet-fs.html one of these days i intend to dust it off and take it to the next level - i've had a few ideas in the meantime. don't hold your breath though. 2010/1/20 Patrick Kelly <kameo76...@gmail.com>: > > > 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 >>> >> >> >> >> >> > >
