Closed tabatabai closed 5 years ago
Strange. I would've thought that by only announcing (frame.announce()
) a limited number of frames then that would limit the buffer size that the camera uses. By default Pymba's arm
method only announces 10 frames.
If your camera is indeed buffering more data internally then there may be a camera feature that you can change to prevent that. Running https://github.com/morefigs/pymba/blob/master/examples/camera/list_feature_values_and_ranges.py may help identify any relevant features.
Thank you for your response.
I suspect that setting StreamBufferHandlingMode to 'NewestOnly' would fix the issue. While this option appears in the GenICam GenTL SFNC 1.1.1, in the Mako's Features Reference the only valid value is 'Default' and I can't change StreamBufferHandlingMode in either VimbaViewer or via pymba because it appears to be locked.
Do you get the same behaviour in Vimba Viewer?
When you open()
a camera it's opened with the default access mode of VMB_ACCESS_MODE_FULL
. You could try other values e.g. VMB_ACCESS_MODE_CONFIG
. I've not tried that before so not sure how safe it is.
There is no delay in Vimba Viewer. Opening the camera in CONFIG mode does unfortunately not work: VimbaException: API feature is not implemented.
That error means that the Vimba C API itself doesn't support that feature.
Just guessing now, but Vimba Viewer has a log window (on the right side). Does this list any settings that are being changed when you open/run the camera?
No, unfortunately the log window does not show any changes.
Unfortunately I don't have a USB camera to test on. Vimba Viewer uses the C++ API I believe, so it may be setting something not possible in Vimba C. The Vimba docs might prove useful.
Is this still an issue? Or is it due to camera hardware, etc?
Apologies for the late reply. I solved the issue by lowering the acquisition frame rate from 168 to 144. I think the problem was that the python loop was running with less than 168 iterations per second, which led to images being buffered.
Thank you for your time and help! Paul
Great :)
Apologies for the late reply. I solved the issue by lowering the acquisition frame rate from 168 to 144. I think the problem was that the python loop was running with less than 168 iterations per second, which led to images being buffered.
Thank you for your time and help! Paul
Paul, I have the same problem as you, when you say you fixed the problem by lowering the acquisition frame, do you mean that this setting is in the camera? did you change it with the vimba software?
Regards
Thank you for the work you put into pymba, it has been really helpful.
On the current version of pymba, trying the example opencv_acquire_streaming_images.py I noticed that the live view is delayed by roughly a second.
Using an older version of pymba the same thing happens. The code looks roughly as follows:
Pausing and resuming the loop it becomes clear that the obtained data lags behind. For example:
This behaviour is the same as when running the live view from opencv_acquire_streaming_images.py.
I would be grateful for any pointers to fix this.
Thank you for your work and time, Paul
EDIT: I did some additional testing, Using a different (GigE) AVT camera, both the above code and opencv_acquire_streaming_images.py work flawlessly. On the Mako, the delay seems to be exactly 102 frames, independently from the set exposure time.
EDIT2: It seems the number 102 is exactly the number of frames that the internal memory on the Mako U-130 holds. According to the Technical Manual, the memory operates FIFO, so that explains the unfortunate behavior.