zhuanglab / storm-control Goto Github PK

There is some unnecessary duplication between the various CameraControl classes. This could be reduced by touching up andorcontroller.py so that it better matched the Andor SDK3 and Hamamamatsu camera control classes, then adding a sub-class of CameraControl with much of the redundant code.

A copy of the current settings should be saved as XML for each movie. This should include the stage position. It should also include the actual camera settings, not just the requested camera settings.

1. use c_void_p for pointers and not c_int or c_long as these are the wrong size (4 bytes, not 8 bytes) on 64 bit platforms.

2. use "import ctypes" and not "from ctypes import *" to reduce name space pollution.

Files to fix:
andor/andorcontroller.py
crystalTechnologies/AOTF.py
halLib/imagewriters.py
madCityLabs/mclController.py
marzhauser/marzhauser.py
nationalInstruments/nicontrol.py
objectFinder/lmmObjectFinder.py

Files to remove:
andor/andorSDK3_v0.py
andor/formatconverters.py
objectFinder/fastObjectFinder.py

Each setting in the parameter object should be a setting object with attributes like "added", "unused" and "type". This way we wouldn't have to keep track of the properties of each setting in separate dictionaries and/or infer them from the type() of the settings. This change will definitely break the dot notation but since we aren't supposed to be using it anyway that is probably ok.

Use os.path.join() instead of simple string concatenation to combine directory and filenames.

Why not use the range slider from HAL instead of two horizontal sliders?

If the user changes some aspect of the parameters in the main window then perhaps (as with the parameters editor) (1) There should some visual indication that the parameters have been changed (2) They should be able to save the changed parameters into a possibly different file.

Due to the recent changes to the parameters we are limited to having exactly 3 objectives. If the setup has fewer objectives there is no way to specify that. If the setup has more objectives again there is no way to specify that.

I would really like to have HAL4000 to drive our STORM imaging. From what I heard, it is much easier to use the exact hardware that your lab currently is using. Is it possible to add a hardware list that HAL4000 current drives? Or, a published protocol? Thanks!

These used to be configurable but they are not anymore after the changes that were made to parameters.

To reduce name space pollution all the currently existing directories will be moved to sub-directories of a directory call storm-control.

Current layout:
storm-control/hal4000/

New layout:
storm-control/storm-control/hal4000/

In kilroy.py line 42:
if not hasattr(parameters, "num_simulated_valves"):

hasattr(parameters, "num_simulated_valves") will always return false even if
parameters.get("num_simulated_valves") will not error and return the value in the xml loaded by the paramaters.

Suggested change:
Replace:
if not hasattr(parameters, "num_simulated_valves"):
self.num_simulated_valves = 0
else:
self.num_simulated_valves = parameters.get("num_simulated_valves")
with:
self.num_simulated_valves = parameters.get("num_simulated_valves", 0)

To get variables with defaults use: self. = get(,<default_value>)

Need an option to allow exposure only during the time when the camera is not actually reading anything out.

The removal of the "int-array" parameter type has broken the interval feed, which used this parameter type to specify which frames to capture.

Each feedviewer should remember it's own value for the sync parameter based on the parameters and feed controller so that they are not all set to the value when the parameters file is switched.

This class needs some work, among other issues it probably has too many member variables.

The acquisition of images in automated mode (i.e. under Dave or Steve control) could be faster.

The initial parameters should be obtained by querying the camera not hard coded.
We also need to support parameters that are key/value pairs, otherwise for a parameter like defect_correct_mode the user has to know that "1" is OFF and "2" is ON.

Enable re-ordering of parameters by dragging. This might be most easily done by using a Qt list view instead of the current custom solution?

When you select an ROI in the camera this is not adjusted for the current camera orientation (i.e. flip_horizontal, flip_vertical and transpose).

The
initCamera(self, pci_card = 0)
function in class
ACameraControl(cameraControl.HWCameraControl)
in file
storm-control/hal4000/camera/andorCameraControl.py
has hardcoded in the paths to the Andor dll drivers.
The new: "C:\Program Files\Andor Driver Pack 2" path is missing from the list.
I recommend adding this as a camera parameter.

Should we make the effort to improve PEP8 compliance using flake8?

You cannot view a mosaic that you created on a PC on a linux machine.

Add meta-data such as pixel size and stage position to .tif files in a form that can be understood by ImageJ.

Since Hazen added a set path file in python I would suggest using it otherwise I experienced trouble with the "serial" module.

Suggested fix:
In kilroy.py suggest adding:
import imp
imp.load_source("setPath", "../sc_library/setPath.py")

The calibrate.py script(s) needs to be fixed so that the output is 2D array that is the captured frame size, not a 1D array.

Consider adding a tooltip to the parameters display. This could include the parameters file name with the full path as well as information about how to activate the editor, e.g. "path/to/params.xml - right click and select edit to edit".

1. Code cleanup.
2. User adjustable offset.
3. Faster fitting.
4. Single spot lock is optional, might want this to be a focus lock failure.
5. Image convolution for camera based approaches.

If we don't save the camera feed, just one of the derived feeds, then the parameters are not saved.

Add the storm-control directory to the python path at start. This would enable the use of multiple repositories on a single computer without mass confusion about what version is actually being run.

The ability to specify an initial value for the illumination sliders in the parameters file has been lost. Now they always start at the maximum when the parameters file is first loaded and then you have to (re)adjust them.

Dave crashes for sequences that contain only one item.

If the log file directory can't be accessed on startup logging should be disabled with a warning instead of just crashing.

You should also be able to specify the channel in the shutters file by channel name, not just it's index.

Parameters should be accesses using get() and set() not the dot notation.

It should zoom into the spot under the mouse pointer when you turn the scroll wheel, but this only works correctly if the image from the camera is square and fills that view its lowest magnification. Any thing else and you can end up at a very different place from where you intended.

Use Gohlke's tifffile for saving tiffs and add support for writing bigtiffs.

Both the focuslock and the joystick modules require the parameter lockt_step, which is currently in the joystick parameters.

The standard camera display (as opposed to a feed display) should be able to open and close the shutter even if it is displaying a feed and not the image from the camera. It would open and close the shutter that corresponds to the camera that the feed is generated from.

Is this ever going to happen?

A possibly stand-alone parameters file editor could be useful.

At some point in the coming months, probably this summer (2016), convert the project to PyQt5.

Steve should be able to load and correctly position any movie. This depends on issue #6 .

Add a layer between the camera and HAL that would handle things like averaging frames, saving only certain frames, and possibly processing different sub-regions in different ways.

The library location should be a parameter. Also an error should be thrown if the library is not found.

Each parameter file should have it's own progression file, not all of them using the same progression file.

Some sort of testing framework would be useful. As things are now all the testing is done manually so regressions are not always getting caught.