Continous acquisition slow on Ximea in free running

jacopoabramo commented 2 years ago

Greetings,

After rewriting the _fetch_loop implementation for the Ximea (in this commit), I tested the performance in free running and made a comparison with my napari-live-recording plugin. Unfortunately, the python-microscope implementation of the Ximea handle is quite slower: at the same exposure time and at full frame the maximum framerate I achieved was 545 FPS on microscope, while with my plugin I reached up to 1500 FPS. Of course, I understand that it's a limitation of microscope and it was already mentioned before (microscope was not intended in its origin to be used in free running with cameras), but I was hoping that maybe there could be a solution on how to gain some speed. It may very well be that my implementation of the fetch loop is not efficient.

iandobbie commented 2 years ago

How did you interface your code to microscope? Did you use the device server and a Pyro connection? If so then you are going to pay a high price for serialization/deserialization, might be better to just access the microscope device directly, although you then have to deal with GIL issues etc as you loose the process spawning of the deviceserver.

jacopoabramo commented 2 years ago

Hi @iandobbie , I'm not sure I understand your questions. I'll post the code snippet I used for testing; I apologize I should have done this from the start:

from time import sleep
from queue import Queue
from microscope.cameras.ximea import XimeaCamera
from microscope import TriggerType, TriggerMode

buffer = Queue()

camera = XimeaCamera()
camera.set_trigger(TriggerType.SOFTWARE, TriggerMode.STROBE)
camera.set_exposure_time(100.0*1e-6)
camera.set_client(buffer)

camera.enable()
sleep(0.10)
framerate = camera.get_setting("framerate")
camera.disable()

print(f"Final framerate: {1.0 / framerate}")

camera.shutdown()

print(f"Current queue size: {buffer.qsize()}")
print(f"First image of buffer: {buffer.queue[0]}")

This is the produced output:

Final framerate: 545.0
Current queue size: 169
First image of buffer: [[1 4 1 ... 1 1 1]
 [1 1 4 ... 4 1 4]
 [5 3 5 ... 6 6 6]
 ...
 [5 5 5 ... 5 5 5]
 [4 4 5 ... 5 4 5]
 [5 5 5 ... 5 5 5]]

As you can see it's a pretty straightforward example which uses my fork of python microscope. If you instead refer to my plugin it's actually a straightforward implementation of the python bindings of XiAPI. As I said, I expected as much since microscope is a more complex wrapper around the python APIs so a loss in performance is due. Still, I was hoping to achieve at least a 1000 FPS rate with this settings.

iandobbie commented 2 years ago

So you aren't using the device server so not suffering from the serialization slowdown. However you have just arbitrarily created a queue object which you are adding unknown sized objects to. I think a large chunk of your issue could be the need to create and manage the memory for this. Do you get better results if you pre-create a buffer and use that for the data?

LeonZ77 commented 1 year ago

Hello @jacopoabramo, I tried your commit but it doesen't work for me as I would expect. For some reason, I only get 2 images in the queue. Did you change other code sections in order to make it work? The camera I'm using is the xiC MC124MG-SY which uses the UBS3 Vision Protocol. It seems like that the trigger configuration XI_TRG_OFF is not working correctly for me.