David Baddeley

After a lot of hard work, our paper on super-resolved membrane estimation is out! Congratulations Zach! doi.org/10.1016/j.bpj.… @zachsimile, @bewersdorflab

An integrated platform for high-throughput nanoscopy go.nature.com/3T8ZsrT

@zacsimile @bewersdorflab @YaleCellBio We'll have the install simplified by the time it appears in a journal.

Our latest work is a #bioRxiv double feature: Endoplasmic reticulum tubules are ellipsoidal thanks to the nanoscale organization of Rtn4 oligomers (biorxiv.org/content/10.110……)! Lukas Fuentes @zacsimile @jtysonphd @DavidBaddeley5 @YaleCellBio #er #ellipsoidaler and...

@geofftnz @geonet complete amateur here, but maybe a en.wikipedia.org/wiki/Seiche - the lowest frequency would pretty much spot on for the crater lake.

What do you think is going on with the recent highly periodic signals on the Far West drum? @geonet

@christlet @ZachMarin__ @aesbarentine @SoellerLab That box is not well named - should be changed to, e.g. "localization units [nm]" or similar (think we have an open issue on it). The purpose of the box is to correct things if your localisations are in units of pixels rather than nm (in which case you do enter the pixel size).

@christlet @ZachMarin__ @aesbarentine @SoellerLab super odd - I'm wondering if it's a string encoding / character set / unicode issue. On py3 at least they u'x' should be equal to 'x' but it's the only thing I can think of

@Maurice_Y_Lee @kD3AN Biased view: Initial setup of PYME for hardware control arguably has the steepest learning curve due to the current state of the documentation, but then the lowest incremental cost of adding new features. Once set up, I think the end user experience compares very favourably.

@Maurice_Y_Lee @kD3AN It's a hard choice, and is going to depend on what your priorities are - for me the rationale for writing PYME was that I enjoy programming in python much more than the other options. The numpy-scipy ecosystem also helped.

@HohlbeinLab @Maurice_Y_Lee @kD3AN Currently "alpha" status on python 3 - we're using it in production on our high-throughput system, but still run into occasional issues. Dependency availability as conda packages mixed, but best for python 3.6.x.

@mueller_physics @Maurice_Y_Lee @kD3AN @MicronOxford They use an adapted form of our camera driver :). Ian Dobbie and I have talked about co-ordinating efforts a few times, but the py2 vs 3 thing has always got in the way. This should no-longer be an issue.

@Maurice_Y_Lee @kD3AN python-microscope.org Almost the same URL, different project (but also python). Run by @MicronOxford and others, quite flexible, and with reliable timing (based on a DSP, Red Pitaya, etc.) baked into the concept.

@DrBrianPatton @kD3AN @Maurice_Y_Lee Sounds like a really good option. PYME doesn't even attempt deterministic timing at present (arguably impossible without a hardware solution) but interfacing with an FPGA has been on our wishlist for a while (with any luck we'll be able to copy/use the group at microns efforts)

@marcelonollmann @cmci_ @CapitanioLab We've managed to run acquisition on Linux twice in our ~10 yr history, both for small projects - even with camera support (e.g. Andor, IDS) something always keeps you on windows :( (e.g. activex/COM [ugh] driver for microscope stand). Routinely do analysis on *nix.

@cmci_ @CapitanioLab Awesome! I ve been waiting so long for an alternative to labview that runs in Linux!!!

"The PYthon Microscopy Environment" ... looks great. Browsing briefly through the documentation, there are many attractive features such as graphic scripting. python-microscopy.org

@marcelonollmann @cmci_ @CapitanioLab Love the enthusiasm, but don't want to oversell. Graphical scripting is data analysis only, not microscope control - we're closer to Micro-manager or NIS elements than labview on the the acquisition side.

@kschink @HohlbeinLab We've got an alternative for Pyro almost ready to go, using HTTP REST calls which should remove the last major bottleneck and will also allow you to more easily interface from other software - e.g. custom acquisition software.

@kschink @HohlbeinLab Python3 is indeed a work in progress, around 80%. Roadblock is Pyro3 (used for IPC within real time analysis, no Py3k port and Pyro4 not API compatible). The init code for some c extension modules might also need changing and it still needs lots of testing.