Who are we?

[campagnola]

.. and what should our name be?

Are we about microscopy in python? Or data acquisition in biosciences? Or data acquisition in general? Something else entirely?

[HazenBabcock]

My suggestion is that we are primarily focused on python for optical microscopy, but deliberately keep the wording of the project goals a bit vague. Most of the hardware we might have python wrappers, at least initially, is going to be for hardware that is typically encountered in bioscience microscopy work. However, if a materials scientist who uses microscopy is interested in using the project or contributing to it we probably don't want to discourage that.

[HazenBabcock]

We also need a cool icon :).

[campagnola]

My personal interest is in electrophysiology techniques, which (for me) is about 2/3 optical microscopy (so I support both an unofficial focus on microscopy and vague wording).

Something along the theme of "data acquisition"? scikit-acquire? It seems like that terminology is almost exclusively used to refer to ADC/DAC/DIO type devices.

Maybe "device control" is closer since it encompasses more than just acquisition.

[HazenBabcock]

My initial thought was that the scikit-X packages were computationally oriented, so this name might not be ideal. However I see now that there are certainly a lot of them, so this could be a good name. Is there someone that administers the scikit namespace that should be asked?

list of scikits

Maybe scikit-hardware? scikit-microscopy?

[berl]

hey folks
late to the game here, but I'm excited about the discussions already.
introduction: my personal interests here are in unifying and/or reducing duplicated work for the usual microscopy automation capabilities plus on-rig chemistry control and image-based "closed loop" experiments.

I agree on the importance of a cool name and icon.
what about scikit-control ? it has the advantage of sounding super important.

[campagnola]

+1 for scikit-control. Also device-control, hardware-control?

[edbarnard]

I have been using to python to control confocal microscopes and automate experiments for solid state physics and materials science applications. To do this I have put together a package called ScopeFoundry (www.scopefoundry.org). I am interested in sharing code and ideas developed for this!

I like scikit-control or scikit-hardware

[VolkerH]

Hi,
I am interested in following this. I have done some work on automating Leica microscopes (see for example https://github.com/VolkerH/MatrixScreenerCellprofiler , but this is starting to become outdated). Currently mainly working in image analysis but still interested in automating microscopes.

Shout out to @tischi @MartinHjelmare @ssgpers @manerotoni

[nvladimus]

Hi,
+1 for scikit-hardware. Poke @mesoSPIM.

[barentine]

Is there someone that administers the scikit namespace that should be asked?
list of scikits

Looks like only (formal) steps are that we list on pypy and have an OSI license. Would probably be good to message the SciPy-dev mailing list and point people here if they're interested.

[MartinHjelmare]

Hi!

Emma Lundberg's team at KTH (Cell Profiling) is also interested in following this initiative. Thanks for the shout out @VolkerH!

We've also worked with Leica microscopes and the CAM interface and have a Python 3 app that connects to that:
https://github.com/CellProfiling/cam_acq

CC @haoxusci

[sofroniewn]

Hi all!

Nick Sofroniew here, one of the maintainers of napari here and member of the Imaging Team at CZI.

Really exciting to see this come together and happy to help. I'm not sure how this group is thinking about connecting to visualization, but if there is any interest in leveraging napari and it's plugin infrastructure in that context we'd be excited to work to make that possible and high performance.

CC @jni @royerloic @tlambert03 @AhmetCanSolak @AndrewGYork @henrypinkard

[tlambert03]

just dropping by to say this looks awesome! watching with great interest.

[sofroniewn]

Based on this twitter thread from yesterday https://twitter.com/aquicarattino/status/1255366351381827587 and work here https://www.pythonforthelab.com/about/ @aquilesC might be interested in this thread too. I hope no one minds the ping and me making the connection - I'm just a guest here :-)

[aquilesC]

Thanks for the ping!

I am indeed interested, but skeptical... Now that more seasoned people are in here, perhaps there is enough pull to get things done. See this discussion which started back in 2018, for example. Should we ping everyone on that thread? Also, don't forget Python Microscopy, which I believe is actively maintained.

First, the name, I like the sciki- approach, but control reminisces me of industrial control, hardware perhaps gives the idea of limiting to drivers and wrappers, while I guess there's going to be a component of data analysis, visualization, etc. Since the focus is working in labs, something like scikit-lab, scikit-experiments? In any case, it is just fun to think about names.

I have been advocating and teaching people how to use Python for data acquisition (mostly involving microscopes because of my own background, but not always). At the beginning, my assumption was that I was going to compete with LabView, that I had to advocate for the use of Python. In reality, most of the people interested in learning had no experience with LabView, it was people who wanted to learn to control experiments from scratch. Some had even little programming experience.

I have been toying with the idea of having a framework (it is in a shameful state, but I am making it grow based on need), learning from what the Django community achieved. Django has a very low entry-barrier for anyone who wants to develop a website, you can find many 'recipes' online, tutorials, etc. and you can make it grow to very complex projects.

Perhaps the Open Canvas is a good tool to sparkle the organization of thoughts.

In my mind, I always thought about having an intermediate between uManager (which, by the way, is an experience we can learn from) and starting from scratch, hence the idea of the framework.

[campagnola]

It's good to be skeptical; there are a lot of reasons a project like this can fail and we need to have some plan for managing those. But on the other hand, a success here would be invaluable to this community, and there are plenty of examples of successful defragmentation in the past. For further discussion on that topic, though, let's move to #14

[berl]

@iandobbie if you have a minute, take a look around- this issue catalogs some of goals and interests and we'd love it if you can add your work to the existing_packages.md file in this repo.
Thanks!

[henrypinkard]

Thanks for the tag @sofroniewn .

I think consolidation and maintenance of python-based hardware control is a fantastic goal!

I also want to add a plug for a project that may be of interest to people this thread that @nicost and I have just released called Pycro-Manager. As the name suggests, this package enables Python access to Micro-Manager. The access works through a behind-the-scenes high-speed bridge that dynamically "translates" between the Java and c++ parts of Micro-Manager and Python. This allows for Python users to use any of the existing Java/c++ APIs and plugins of micro-manager as if they had been written in pure Python. The translation between languages occurs dynamically at runtime, so any future development on the Java/c++ side will be available through Python as well. Most relevantly to those here, it also provides Python-based control of the hundreds of devices that already work with micro-manager.

Pycro-manager also has a flexible, high-level API to enable complex, customized data acquisition without having write all the boilerplate automation yourself. This can be used, for example, to synchronize external hardware with the acquisition process, modify acquired images on-the-fly before saving/visualization, implement your own customized data saving/visualization, and easily adapt acquisition in response to data.

If you'd like to learn more, please check out the documentation (https://pycro-manager.readthedocs.io/en/latest/). For any questions/suggestions/discussions, the best place is the Pycro-manager issues page (https://github.com/micro-manager/pycro-manager/issues).

[aquilesC]

Tomorrow, the Chan Zuckerberg Initiative opens its call for proposals for open-source software. I've opened a separated issue #17 but I guess not everyone will be notified. That's why this message.

Perhaps collectively (and openly) working on an application would help defragment the community, as discussed on #14, regardless of the outcome of the application.

[pskeshu]

Hi everyone! It's very exciting to see efforts in this direction.

I have been trying to write a closed-loop acquisition application that uses online image processing to identify region of interest in the sample, after which I aim to run multiposition non linear timelapses.

It'll be great to see how this project evolves, and I look forward to learning from the community, and contribute in anyway I can.

[sofroniewn]

This project https://python.yaq.fyi/scipy-2020/#/ - https://gitlab.com/yaq - I saw at SciPy2020 seems relevant, but I do not know the authors. They might be interested in this project too

[ksunden]

I am the author of yaq, yaq is already on the list of projects, I've been referencing this repo regularly in the scipy2020 slack #hardware-bof channel