morefigs / pymba

Python wrapper for Allied Vision's Vimba C API
MIT License
105 stars 84 forks source link

[Mako U-130] delayed frame acquisition #81

Closed tabatabai closed 5 years ago

tabatabai commented 5 years ago

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:

frame = camera.getFrame()
frame.announceFrame()
camera.startCapture()
camera.runFeatureCommand('AcquisitionStart')

while True: # this loop actually gets controlled by a hardware switch
    frame.queueFrameCapture()
    frame.waitFrameCapture()
    frame_data = frame.getBufferByteData()
    data_frame = np.ndarray(buffer=frame_data,
                            dtype=np.uint8,
                            shape=(frame.height, frame.width))
    queue.put(np.copy(data_frame)) # putting the data into a queue for further processing

camera.runFeatureCommand('AcquisitionStop')
camera.endCapture()
vimba.shutdown()

Pausing and resuming the loop it becomes clear that the obtained data lags behind. For example:

  1. starting the capture loop
  2. pointing the camera at object A for a few hundred iterations (that's just a few seconds on the Mako),
  3. pausing the capture loop
  4. pointing the camera at object B
  5. resuming the capture loop
  6. the first 50-150 (edit: 102) images will still be of object A

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.

morefigs commented 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.

tabatabai commented 5 years ago

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.

morefigs commented 5 years ago

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.

tabatabai commented 5 years ago

There is no delay in Vimba Viewer. Opening the camera in CONFIG mode does unfortunately not work: VimbaException: API feature is not implemented.

morefigs commented 5 years ago

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?

tabatabai commented 5 years ago

No, unfortunately the log window does not show any changes.

morefigs commented 5 years ago

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.

morefigs commented 5 years ago

Is this still an issue? Or is it due to camera hardware, etc?

tabatabai commented 5 years ago

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

morefigs commented 5 years ago

Great :)

albertoSantana28 commented 3 years ago

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