LabVIEW
IMAQdx Calculate Frames per second
Hello,
I'm using LabVIEW to record with a gigE camera at around ~250fps. It's not a triggered mode right now and hence, it varies between 247 to 252 fps. I'm trying to make sure that none of my frames are dropping and that I extract the entire buffer but I'm having trouble understanding the "Images Left Behind" value from the Calculate Framer per Second vi. I've attached my code and I've also included a photo showing the bit that's confusing me.
Buffer Number and Images Behind are the outputs from the Calculate Frames per Second vi. Acq Loop is the while loop count that I feed in as Buffer number to the Get Image2 vi. When I end the acquisition, why doesn't the Buffer Number go all the way up and Images Behind go down to 0 (basically flushing the buffer)?
Is there something wrong in how I'm thinking about this?
Thanks
NV
Unfortunately I haven't any suitable cam in my hand at the moment, but comment in IMAQdx Calculate Frames per Second.vi stated that the "Images behind" is useful when acquiring every image, so operations can be skipped (i.e. display) to help catch up and avoid missing images if the acquisition gets too far behind.
Technically it is just difference between Buffer Count and Buffer Number
If you "trying to make sure that none of my frames are dropping" then may be LostBufferCount property could be useful:
and also this one — Detecting Packet Losses From a GigE Camera in LabVIEW
Consider uploading a Snippet.png of your code, since I can't have a look into your VI.
With imaqdx you define the local ring buffer size on your PC. The GetImage2.vi reads then from that local buffer. If your camera acquires faster images than your PC can fetch them, you 'Inages Behind' increases. If this delta gets bigger than your local buffer, your camera overwrites in this case local buffers, which weren't read out yet. Since the local buffer size is restricted to max 250, your images behind counter can't go from 6040 to 0.
Check also if you have a IncompleteBufferMode Attribute and to what it is set. I think there is a Get Every Image example in LabView.
Thank you all for your replies. I'm still learning a lot about high speed acquisition and your suggestions definitely helped with that.
The Lost Packet Count shows up as 0 indicating that I'm not dropping any frames. When I started tracking the Processed Frames per Second value from the CalculateFramesPerSecond.vi, it was processing at 90Hz while acquiring at 250Hz. This is what also led to the images behind values being non-zero. This in itself isn't bad but when I stop the acquisition, the frames in the buffer aren't passed through my Channel writer that I'm using to write to an avi file. The vi snippet for this is below.
When I disabled my channel writer and stopped writing to the avi file, the acquisition rate and the processing rate started matching. This snippet is below. So just writing to that channel writer increased lag time. This still doesn't make sense to me seeing as this sort of producer-consumer architecture has worked for a lot of other posts I've seen in this community.
I used Get Image Data to save the data while acquiring it. This showed the same acquisition and processing frame rates.
With this method I have to add converting the data to an image -> demosaic-> write to avi.
The Get Every Image (Optimized Performance) example didn't work with the camera that I have. I suspect that it's due to the output format by the camera which is BayerBG8. Could the conversion between BayerBG8 ->RGB be causing the delay when I try to directly save the image to the avi?
The Ring Text being connected to the codec was a leftover from when I was still learning about my different codec options and then running mini-experiments to check speed and size of the avi file.
I tried the "Next" mode and still the same result. I now get non-zero images missed.
Mode: Buffer Number
Mode: Every
Mode: Next
Just few comments from my side.
First of them, keep in mind, that the IMAQ Images passed by reference, not by value!
The typical error which most engineers doing when starting working with IMAQ is something like that:
Here we have two loops - one is the "fast" acquisition loop and another one is slow "processing" loop.
The problem is that the images in the queue of the Channel referred to the SAME image.
You need to allocate array of images (Ring buffer), then transfer each image.
It seems to be that you found this already, because on the last VI you switched to LabVIEW arrays.
This will eliminate this issue, because arrays transferred by value, but this is very not efficient way to do this like this:
If you need really fast processing, don't use conversion of IMAQ to LabVIEW array, and visa versa.
In additional, conversion 1D array to 2D is also caused penalties.
What I would like to recommend is to use configured Ring Acquisition like this
Actually this based on the standard IMAQdx Example
Now if you still prefer to use Channel Writer (personally I prefer to use old school classical queues), then you have to limit size of the queue to the size of the Ring Buffer (makes no sense to have unlimited, because unprocessed images gets overwritten, because they are references in the fact):
When this queue on the channel writer get full, then you will start to lost images, because they will be overwritten in the Ring Buffer, then Images Missed starts increased.
In this pattern you will not have "Images Behind", because they will be pushed to the queue pretty quickly, but indirect you will get this on the processing loop, because amount of the images in the Queue are the unprocessed behind the acquisition point.
I would like to recommend to read Ring Acquisitions kb article for better understanding.
Here is slightly modified original NI Example, where I added simple logging (queue guaranteed to have race condition free):
And then you will see how the images acquired and processed when acquisition faster than processing:
Ring 0 acquired in buffer 0
Ring 0 processed
Ring 1 acquired in buffer 1
Ring 1 processed
Ring 2 acquired in buffer 2
Ring 3 acquired in buffer 3
Ring 4 acquired in buffer 4
Ring 2 processed
Ring 5 acquired in buffer 5
Ring 6 acquired in buffer 6
Ring 7 acquired in buffer 7
Ring 8 acquired in buffer 8
Ring 9 acquired in buffer 9
Ring 3 processed
Ring 0 acquired in buffer 10
Ring 1 acquired in buffer 11
Ring 2 acquired in buffer 12
Ring 3 acquired in buffer 13
Ring 4 acquired in buffer 14
Ring 4 processed
Ring 5 acquired in buffer 15
Ring 5 processed
Ring 6 acquired in buffer 16
And you can recognize here that in extreme situation 10 images was acquired, but the only 3 processed and the image Ring 4 acquired into 14th buffer was overwritten.
Hope it helps for understanding a little bit. Kind of "double buffering" is also possible in theory, if you don't prefer to touch Ring Acquisition buffer directly, but not like you did with arrays (because in the fact, the queue in channel writer is your second buffer, but very inefficient in such form).
Technically your buffer should be large enough, and how large — it depends from the speed of both loops and overall acquisition time, of course.
Last year I finished project where 10000 FPS acquisition was required without frame loss, and that was done with cams with memory onboard, so the images first was acquired into internal 128GB buffer, then "slowly" unloaded via 10GB network. It was also required to encode frames into video, and I've used OpenCV Video Writer, which is slightly more efficient (but the root cause for taking OpenCV onboard was a codec and ability to save video in *.mp4 container rather than *.avi, and not the performance). In some cases, like Camera Link grabber you might have this Ring Buffer on board of the framegrabber (but this is not your case, I guess).
