[GEM-dev] pix_buffer

[IOhannes m zmoelnig]

B. Bogart wrote:
> hey all,
> 
>
> Obviously it would be inefficient to copy the buffers but if we would
> just remap the indexes, clear the oldest image from memory then we
> should be good. Of course i have no idea how to actually do this in C...
> 
> Basically I'm capturing a number of frames over time, and I'd like index
> 9 of the pix_buffer to always refer to the newest image once the buffer
> is full... We could call this "append" mode [append 0/1<
 >
 > If there is a patch-level way to deal with this fifo type buffer for
 > images outside of writing it myself in C then please let me know...

i think you could resolv this just with a simple patch.
nothing is happening automatically, so you can easily keep your 
patch-logic in synch with the internal logic.

i cannot remember clearly why the "circular buffer" thing went into 
[pix_buffer_read/write] in the first place, it really seems like a 
feature overhead. (but somebody sent me a patch and...)


> 
> Also it would be great if we could also have pix_buffer_open and
> pix_buffer_save which would load and save TIF and JPG files into the
> pix_buffer. This could probably use most of the code from pix_multiimage.

you can already load single images into the [pix_buffer] via the [open( 
message; the arguments are filename and slot.

writing images from the buffer to a file would be a very nice feature.

i don't think that special objects would be apropriate for such things.
(consider [pix_buffer] as a [table] for images)

> 
> Also it would be useful to be able to test if a slot in the buffer is
> empty, so I could always refer to the most recent image no matter how
> full the buffer may be.

i think the test for empty slots is a great idea. (although i don't 
fully understand how this will help you with your most-recent image problem)

> 
> I'd be interested in talking about a bounty for these features... any
> interest?

wow. do you need it soon?

mfg.a.r
IOhannes