I’m using the vision routines to capture frames (“grab”) from a 300fps GigE camera. The camera can deliver frames a little faster than the HD can write them, so I’m capturing in one loop and sticking them in a queue which is read out in a second (adjacent/parallel) loop. Everything goes fine until the first loop finishes (as far as I can tell), meaning that the data has all been acquired, most has been written, and the remainder just needs to be written out. Unfortunately, all of the images left in the queue magically retroactively all end up with the same data, so the last part of the data set contains hundreds of static frames.
How do I avoid this behavior? I assume that there’s some resource I need to hold on to so that image buffer memory isn’t reclaimed, but it’s obviously not the images themselves. (I do not do any explicit camera cleanup stuff there.)
Here’s an ASCII-art depiction of what I’m doing (at least I hope this is the relevant part):
+===============+ +==========+
-queue----@-------Insert--@---@-Empty?---@---Release queue
| # GrabImg-^ # # | #
| # # # Y->Stop #
| # i-(>n?)->Stop # +==========+
| +===============+
|
| +==============+
\--@-Deleted?--Y #
# | | #
# N->Get | #
# | v #
# Write Stop#
+==============+
I’m using queue deletion to signal the end of the loop. It’s a bit sloppy, granted, so I could understand an off by one error, but not an off-by-2200 error, which is the worst that I’ve seen. (And again, it does write all the images, they’re just all the same at the end.)
In a producer-consumer loop the producer needs to copy the image so that it’s not overwritten at the next iteration if consumer hasn’t processed it. GrabImg does not do this step, so you need to create a new one before each grab, and have the consumer take care of releasing each buffer it has processed.
Beware of memory issues though!