Common API: Mirror micro-manager API

[HazenBabcock]

Thoughts on trying to follow the micro-manager (MM) API as much as possible?

The context is that there has been some discussion of separating the device driver layer in MM (written in C++) from the layers above so that one can use the devices from any language (that can bind to C++) without being forced to use the rest of MM core, such as the acquisition engine if you want to use a camera device driver.

The current API is documented here. This may also change if MM is refactored.

Another possibility is to provide a compatibility layer.

Why do this?

• It would further reduce duplication of effort.
• It could be easier to switch back and forth between the Python and MM versions of the device driver in the event that one turned out to work better than the other one.

And then I was going to provide an example of how this might work, but because in MM as it is now all the hardware is accessible by calling methods on a single core object it doesn't really map very well.. So this is maybe something to keep in mind for the future if/when MM becomes less monolithic.

[berl]

I propose that we consolidate our high-level model (something like resolving the existing issues in this repo) and then circulate it among similar python projects/devs and see what people think. At that point we can do an assessment of the overlap between our model and the MM api.

If we want to take consider the MM model for now, I think we can skip matching the top-layer MM interface (i.e. the single core object) and focus on the model/interface for the individual devices. For example, what do we think of the XY stage control interface in the MMCore documentation?

@HazenBabcock re: the single core object, Luke and I have dealt with this by having a single global mmCorepy object- something that makes the most sense inside a further framework like acq4 but it (the single mmCorePy object) sort of breaks the modularity of our proposal here.

[campagnola]

I agree we should at the very least be looking at the µM API to make sure what we do is compatible, and ideally to learn from the huge amount of experience that is encoded there.

[HazenBabcock]

If you haven't seen it, there are also active discussions about what might come next for micro-manager, uScopeControl. Announcement on image.sc here.

[campagnola]

Their whitepaper does a great job of summarizing the situation and explaining µManager's relationship to it. In general, I like the idea of having device drivers written in C++ if that means they will get a larger audience (and by extension, more industry support / funding).

.. but that raises the question: if µManager gets the resources it needs and covers most of our devices, does this project have any extra value to offer? Would it make more sense just to converge on µM as the standard? I could see this going a few different ways..

[berl]

at the Janelia workshop and in the whitepaper it's pretty clear the there is room for discussion on what the µManager core/not-core looks like and there is support for ongoing maintenance of the python wrapper. Maybe one way this could go would be to

1. Python microscopy folks work with µManager folks to converge on the device model and API- that discussion could happen here, as the authors suggest
2. Identify devices or use-cases where a python driver is preferred and build those here to the same API as in 1.

we originally had these swapped, figuring that between @campagnola @David-Baddeley and @HazenBabcock we had so many great drivers that this thing would write itself 😄

I can think of a few reasons it might be nice to have pure python drivers, but most of those reasons would be obviated by a perfect non-python driver + wrapper.

I have a feeling others might have stronger opinions about when/why pure python drivers would be preferable to a wrapped µManager driver.

[David-Baddeley]

I think some level of interoperability with the c++ level micromanager drivers is a must (as long as we don't have to go near the java code), whether it be through a shim or a more substantial alignment.

My concerns:

• I also dislike the top-level single core object
• It's much faster/easier to add support for new hardware in python (particularly for, e.g. devices which attach to a serial port)
• ditto for fixing broken drivers
• I'm not convinced that MMs camera interfaces are high performance / high quality (this might be a common problem in trying to force all cameras through a common interface, so might bite us too).
• thread safety (I'm not sure how much of an issue this actually is, but it's something we should look into in depth)
• potential for installation pain

Part of my feelings might be coloured by some poor past experiences with micromanager (and in particular the Photometrics drivers).

[berl]

@David-Baddeley the dislike of the top-level core object was heard loud and clear at the workshop and based on the white paper there is at least the possibility of a driver layer that would be accessible without the core.

Also the quick turnaround for driver development in python was acknowledged as a big plus. One idea was to have python drivers (here perhaps) graduate to supported C++ drivers in µManager if it made sense, but ideally in such a way that the interface for the device wouldn't have to change.