2023-01-10.md

2023/01/10 - Microscope development meeting

Attendees

Attending:

• Danail Stoychev
• David Miguel Susano Pinto
• Ian Dobbie
• Julio Mateos-Langerak

Notes

• incorrect use of WinDLL (python-microscope/microscope#261)

  We seem to be using WinDLL when we should be using CDLL. We think we're doing it wrong in Alpao and BMC mirrors, Linkam stage, and Hamamatsu cameras. Danny will test in the Alpao mirrors and David will ask Tom to test on the Linkam stage. If we're right about those we will also fix on the Hamamatsu cameras and BMC mirrors since we no longer have access to them.

• testing Hamamatsu in Windows

  Microscope now supports Hamamatsu cameras but we never tested on Windows, we only tested on Linux. Julio will try to test on Windows.

• Cockpit camera readout and gain (microscope-cockpit/cockpit#810)

  David has proposed fix that removes the gain and readout mode for all cameras. This is ok to push but we'd like to have them for some cameras. Actually, for other cameras we would like even some more easy access to settings. So what makes sense is to have this configurable per camera. A new issue was open for that (microscope-cockpit/cockpit#838).

• Rename picam to picamera module

  Support for the RaspberryPi camera is on a module named picam but that name is not used anywhere. We will rename it to picamera before the first release where it is included.

• camera transform on settings (python-microscope/microscope#260)

  Both David and Danny found that Cockpit does not use the settings dict to set the camera transform so it should be fine to remove it on Microscope.

  The main thing lost with the change is the ability to quickly try different transforms when setting up a system. David will document on cockpit how to do it via the Python Shell in Cockpit.

  While the transform is supposed to be a tuple of bools, the cockpit configuration file expects ints. David will fix this. Also, Microscope set_transform will handle ints for Cockpit. We will have Microscope raise a warning about deprecation with the goal of only accepting bools in the future.

• TOML instead of INI files in cockpit config files

  Julio mentioned that TOML is nicer for configuration instead of INI. For example, supports different types such as int or bools or lists of them instead of only strings which we then need to parse. It was not considered much because there is no one to do the work anyway.

• camera roi on settings (python-microscope/microscope#260)

  This is only way that Cockpit has to set ROIs so we can't remove them yet. Danny has some work that adds a UI to Cockpit to draw a ROI. Danny will prepare it as a separate brancg to be merged and then we can remove it from Microscope.

• release of resources on device shutdown (python-microscope/microscope#256)

  When we shutdown devices we don't actually close any connections and we don't always release resources. It's a bit more work but we agreed that we should do it.

• behaviour of trigger() when camera is busy acquiring (python-microscope/microscope#224)

  When a camera is busy acquiring an image in software trigger mode and Camera.trigger is called it's not defined what happens. In most cases, the trigger is just silently discarded. One proposal is to keep delaying the trigger until is accepted (effectively making trigger block) or raise an error. We agreed that we would raise an error.

  The reason to not do the sleep until a trigger is accepted is that it is tricky to get it when multiple threads may be sending triggers and deciding on a timeout value. With an error, the user can still do the delay on their side. And we can still implement the block as an option with a timeout value later.

• remove the microscope.clients module

  Microscope has a Client and DataClient classes in microscope.clients. The first is a very thin wrapper around Pyro4.Proxy and it's not clear what it is for. The later adds a trigger_and_wait method which is nice. However, this doesn't seem to be used anywhere and maybe trigger_and_wait could be implemented as function elsewhere.

  We will open an issue bout it, deprecate the module with a message pointing to it, and wait for someone to complain that they use and find out why. If no one complains we will remove it.

  There's a case of someone using it on python-microscope/microscope#210 but it is not clear there why.

• use of setter/getter methods instead of properties

  We have a mix of setter/getter methods and properties. For consistency, some time ago we settled on properties and started making the change but have not done it for all yet. David says this has been a bad choice because it makes the logic when passing callbacks to GUI much more complicated. Danny also pointed out that setter/getter are potentially more powerful as can pass extra options and specify units. Danny asked what is more Pythonic but there doesn't seem really be one but we can at leats be uniform within our project. getter and setter also have more a signal that setting it actually does something that may take time which is true for hardware. We agreed to use setter/getter instead.

• Danny is helping Veronika with 16 lines RedPitaya

• rolling shutter in Microsocpe and Cockpit (microscope-cockpit/cockpit#651)

  There's a few issues open about this and Julio has just cleaned up some branches for it and on microscope-cockpit/cockpit#651 . It adds a setter and getter for rolling shutter to all cameras. The idea is that camera is either on global exposure or rolling shutter but seems that some Ximea cameras have multiple rolling shutter modes so it's not clear how it will behave there. Also, the whole point of it is to plan experiments in Cockpit better but the different rolling shutter modes may affect that timing. Ian will take a look.

• Thorlabs multi position sliders (python-microscope/microscope#252)

  Julio has a branch that adds support it but it's not clear whether it does the right thing. His code does the same as MicroManager and what the vendor says he should do (hardcodes the unit size) but it is not not what Thorlabs own software does (read the step size from the hardware - which is wrong - instruct to move that physically incorrect distance but the device then moves the correct distance).