hey all,
I'm playing with pix_buffer and realized the idea of a cyclic buffer as implimented is not what I actually need.
Here is an example:
Say we have a buffer of 3 slots
First we capture a frame at t0 f0.
the buffer contains:
s0: f0 s1: empty s2: empty
Then we capture a second frame at t1 f1
s0: f0 s1: f1 s2: empty
When once we have filled the butter by t2 then I want this to happen:
s0: f1 s1: f2 s2: f3
So we have lost frame f0 because it is the oldest, and shifteverything to clear a new spot at s2 for a new image.
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<
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.
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.
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'd be interested in talking about a bounty for these features... any interest?
Thanks all.
b.
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
-
B. Bogart -
IOhannes m zmoelnig