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