9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Steve Simon" <steve@quintile.net>
To: 9fans@9fans.net
Subject: Re: [9fans] dataflow programming from shell interpreter
Date: Tue, 19 Jan 2010 15:40:49 +0000	[thread overview]
Message-ID: <f274087c6f7a8b40612d7531cc75be71@quintile.net> (raw)
In-Reply-To: <hj2cho$3s7$1@news.bytemine.net>

> 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



  reply	other threads:[~2010-01-19 15:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-18 10:58 Tim Climber
2010-01-18 12:19 ` Steve Simon
2010-01-18 20:04   ` Tim Newsham
2010-01-19  9:59   ` Aharon Robbins
2010-01-19 15:40     ` Steve Simon [this message]
2010-01-20 21:13       ` Eris Discordia
2010-01-20 21:41         ` Patrick Kelly
2010-01-21  8:00           ` roger peppe
2010-01-21 12:45         ` maht
2010-01-21 21:36         ` Skip Tavakkolian
2010-01-22  9:44           ` Eris Discordia
2010-01-19 22:13   ` Andy Spencer
2010-01-18 16:23 ` Eric Van Hensbergen
2010-01-18 19:23 ` Aharon Robbins
2010-01-19 22:33 ` Andy Spencer
2010-01-27 10:44 ` Sam Watkins
     [not found] <c563b2f7-92ac-463a-864c-267721ddb30a@k35g2000yqb.googlegroups.co>
2010-01-18 11:15 ` erik quanstrom
     [not found] <58d8d6b4960925aab27312e0968a3e26@quintile.net>
2010-01-18 19:39 ` Eric Van Hensbergen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f274087c6f7a8b40612d7531cc75be71@quintile.net \
    --to=steve@quintile.net \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).