[FFmpeg-devel] [PATCH] life: add slow_death, life_color and death_color options.

[Stefano Sabatini]

On date Thursday 2011-12-08 01:32:50 +0100, Clément Bœsch encoded:
> On Thu, Dec 08, 2011 at 12:29:52AM +0100, Stefano Sabatini wrote:
> > On date Wednesday 2011-12-07 07:51:55 +0100, Clément Bœsch encoded:
> > > On Tue, Dec 06, 2011 at 03:18:37PM +0100, Stefano Sabatini wrote:
> > > > On date Monday 2011-12-05 00:48:47 +0100, Clément Bœsch encoded:
> > > > > ---
> > > > > Additionally to the example, here is a more organic one:
> > > > >   ffplay -f lavfi life=f=CREDITS:s=400x400:slow_death=1:r=120:death_color=#113366:life_color=#ff0000,boxblur=2:2
> > > > > ---
> > > > >  doc/filters.texi        |   17 ++++++++++
> > > > >  libavfilter/vsrc_life.c |   82 +++++++++++++++++++++++++++++++---------------
> > > > >  2 files changed, 72 insertions(+), 27 deletions(-)
> > > > > 
> > > > > diff --git a/doc/filters.texi b/doc/filters.texi
> > > > > index eb1a4df..5e38b08 100644
> > > > > --- a/doc/filters.texi
> > > > > +++ b/doc/filters.texi
> > > > > @@ -2863,6 +2863,17 @@ If a filename is not specified, the size value defaults to "320x240"
> > > > >  @item stitch
> > > > >  If set to 1, stitch the left and right grid edges together, and the
> > > > >  top and bottom edges also. Defaults to 1.
> > > > > +
> > > > > + at item slow_death
> > > > > +If set to 1, the progressive death effect will be effective: the dead cells
> > > > > +will slightly go from @option{death_color} to black.
> > > > > +
> > > > > + at item life_color
> > > > > +Color of a living cell.
> > > > > +
> > > > > + at item death_color
> > > > > +Color of a dead cell. If @option{slow_death} is set, this is the first color
> > > > > +used to represent a dead cell.
> > > > >  @end table
> > > > 
> > > > nit: sort items
> > > > 
> > > 
> > 
> > > I'm not sure about that; life_color and death_color won't be together. I
> > > could rename them to something like color0 and color1, but then they will
> > > be the first option user will see (while they are less important than the
> > > options we can see in the current list).
> > 
> > I'm still slightly in favor of sorted items so that I know where to
> > put options if I add them, but that's bikeshed so as you prefer.
> > 
> 
> How would you avoid the separation of life & death color options?

There is no way indeed, a possibility would be to adopt a hierarchical
scheme (color_death/color_life) *or* to keep separated the options,
but again I don't think this is very important so the committer has
the last choice.

> [...]
> > > From c0e0355682330844f78d560f287721a1cb9ffa57 Mon Sep 17 00:00:00 2001
> > > From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?= <ubitux at gmail.com>
> > > Date: Mon, 5 Dec 2011 00:38:39 +0100
> > > Subject: [PATCH] life: add slow_death, life_color and death_color options.
> > > 
> > > ---
> > >  doc/filters.texi        |   16 ++++++++
> > >  libavfilter/vsrc_life.c |   98 +++++++++++++++++++++++++++++++++++++---------
> > >  2 files changed, 95 insertions(+), 19 deletions(-)
> > > 
> > > diff --git a/doc/filters.texi b/doc/filters.texi
> > > index eb1a4df..0e5bda7 100644
> > > --- a/doc/filters.texi
> > > +++ b/doc/filters.texi
> > > @@ -2863,6 +2863,17 @@ If a filename is not specified, the size value defaults to "320x240"
> > >  @item stitch
> > >  If set to 1, stitch the left and right grid edges together, and the
> > >  top and bottom edges also. Defaults to 1.
> > > +
> > > + at item slow_death
> > 
> > > +If set to 1, the progressive death effect will be effective: the dead cells
> >                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > not very clear, I suggest "enable slow death effect:"
> > 
> 
> Changed.
> 
> [...]
> > > @@ -135,7 +144,7 @@ static void show_life_grid(AVFilterContext *ctx)
> > >          return;
> > >      for (i = 0; i < life->h; i++) {
> > >          for (j = 0; j < life->w; j++)
> > > -            line[j] = life->buf[life->buf_idx][i*life->w + j] ? '@' : ' ';
> > > +            line[j] = life->buf[life->buf_idx][i*life->w + j] ? ' ' : '@';
> > >          line[j] = 0;
> > >          av_log(ctx, AV_LOG_DEBUG, "%3d: %s\n", i, line);
> > >      }
> > > @@ -186,13 +195,14 @@ static int init_pattern_from_file(AVFilterContext *ctx)
> > >  
> > >      /* fill buf[0] */
> > >      p = life->file_buf;
> > > +    memset(life->buf[0], 0xff, life->w * life->h);
> > 
> > why the inverted logic? My more natural interpretation is that alive
> > cells should have non-zero values, decreasing to zero as they die.
> > 
> 
> To allow a wider range? I added a doxycomment to buf to explain this:
> 
>     A zero value means the cell is alive (or new born), while the values
>     from 1 to 0xFF means the cell is dead; the range of values is used for
>     the slow death effect (1 means dead, 2 means very dead, 3 means very
>     very dead... and 0xFF means definitely dead).
> 
> We could use 0 → 0xFE for dead cell, and 0xFF for alive cell, but it's a bit
> weird to deal with the value sometimes (you can't just "not" the value for
> instance). I also don't like the solution of 0 and 2 → 0xFF for dead. And using
> signed value make use of half of the buffer (BTW, I changed the char to uint8_t
> in the struct).

What I mean is:
alive = 255
...
dead  = 0

so you can interpret the values in the grid like "energy", which seems
the most natural interpretation, and so should lead to the most
readable implementation.
-- 
FFmpeg = Fostering & Foolish Muttering Programmable Elastic Gorilla