Speed difference between multi_d_acquisition_events in pycro-manager and multi dimensional acquisition in MicroManager

[DominikStich]

Hi,

I noticed that acquiring with multi_d_acquisition_events in pycro-manager is about 2.5 to 3 times slower than the exact same acquisition run from the MDA window in the MicroManager (run with MM nightly build 20230412, pycromanager 0.27.2, no acquisition hooks, no hardware triggering).
Is this speed difference to be expected when using pycromanager or are there ways to run multi-dimensional acquisition just as quickly as with MicroManager?

Thanks,
Dominik

[ieivanov]

pycromanager is able to run just as fast as MicroManager, and maybe a bit faster still. It's likely that something is different between the setup of your two acquisitions. If you post here a picture of your MDA window and your pycromanager code for the equivalent acquisition we should be able to better guide you.

[DominikStich]

Thank you very much for your reply!

I ran a test acquisition from the MDA window in MM, which finished in 30s.

After that I ran the same acquisition from pycromanager using the following code:

import numpy as np
import time
from pycromanager import Acquisition, Studio, multi_d_acquisition_events
studio = Studio()

# pull current MDA window positions
acq_manager = studio.acquisitions()
acq_settings = acq_manager.get_acquisition_settings()
position_list_manager = studio.positions()
position_list = position_list_manager.get_position_list()
number_positions = position_list.get_number_of_positions()
xy_positions = np.empty((number_positions,2))

# iterate through position list to extract XY positions    
for idx in range(number_positions):
    pos = position_list.get_position(idx)
    for ipos in range(pos.size()):
        stage_pos = pos.get(ipos)
        if (stage_pos.get_stage_device_label() == 'XYStage'):
            xy_positions[idx,:] = [stage_pos.x, stage_pos.y]


start = time.time()
with Acquisition(directory='D:/20230417', name='pycromanager_acq') as acq:
    events = multi_d_acquisition_events(
                    channel_group='2. Imaging', 
                    channels=['g) red channel RGB brightfield', 'h) green channel RGB brightfield', 'i) blue channel RGB brightfield'], 
                    channel_exposures_ms=[2.2, 12.5, 22.5], 
                    xy_positions=xy_positions)
    acq.acquire(events)
end = time.time()
print(end - start)

In pycromanger the acquisition took 62s.
It seems like there is always a pause after the stage moves to a new position.
Any suggestions how I can speed up the acquisition pycromanger?

[henrypinkard]

This might be due to differences in the acquisition engine between MM and PM. To test this, if in MM you go to tools options and at the bottom of the list check enable new acquisition engine, then run the same MDA, you should be able to validate it.

If there is a pause after the stage moves I suspect that the issue might be related to the fact that the PM acquisition engine waits after moving the stage for it to report that it is no longer busy. Perhaps the default MM acquisition doesn't do this?

If thats the case, that the stage is waiting to report thats its not busy even after it moved, I would say this is an issue with the stage device adapter

[DominikStich]

@henrypinkard thank you very much for your comments and suggestions!

I tried to run the same acquisition with the new(experimental) acquisition engine as you suggested. The acquisition starts up, moves to the first position, takes the image for the first channel, and then stalls indefinitely.

[henrypinkard]

I just tried similar settings seem to work with the demo configuration. Can you run with the new acquisition and the demo configuration? If so, then something is going on with your hardware probably, and it sounds like its something related to your channel switching hardware. What actual device is changing channels for you?

[ieivanov]

This does look suspicious indeed. Can you also do a speed comparison if acquiring the same 3 channels over 10 time points in a single position, and then acquiring multiple positions for a single channel (say g) red channel RGB brightfield). This way we can decouple if the slowdown is due to the state or the channel switching.