mesospim/mesospim-control

Image acquisition software for mesoSPIM light-sheet microscopes.

mesospim-control's Issues

Feature requests and ideas

Discussed in #54

Hi,

In the tiling wizard, would it be possible to add a focussing option for left and right separately rather than have one focus for both? We're often swapping out the large immersion cuvette for different clearing methods and keeping the lasers aligned for a single focal plane isn't always possible/is time consuming to perfect.

Peter

software has a tendency to lock up and become unresponsive

This can manifest on events such as stopping a live scan (rare) or changing camera parameters. On on occasion it was very bad and I found restarting the PC fixed things. I have not had the software fail during an acquisition or a series of acquisitions. So the problem seems to be brought about by user interaction.

Problem with the font size

We have some issues with the font size of all increment numbers in the GUI. They are very small. We use a 4 K monitor at full resolution.

Rotation handling should be implemented

Settings files in repo don't contain new "subsampling" parameters

Using these settings files as a template will not work because the control software is looking for settings that are missing.

X stage becomes unreferenced after software start and can not be moved

I am on the latest version of the master branch (88de162) and v5 stages. I start PI MikroMove and reference all stages. All servos are on and I confirm they move. I close MikroMove and then start mesoSPIM-control. The X stage no longer moves. In the console I see the error message :

Unallowable move attempted on unreferenced axis, or attempted to move with servo off

It references line 145 of mesoSPIM_Serial and 387 of mesoSPIM_Stages.

When I close the control software and re-reopen MikroMove I see that the X stage has become un-referenced.

My x/min/max values are broad enough:

    'x_max' : 30000,
    'x_min' : 8500,

and I have:

pi_parameters = {'controllername' : 'C-884',
                 'stages' : ('L-509.20DG10','L-509.40DG10','L-509.20DG10','M-060.DG','M-406.4PD','NOSTAGE'),
                 'refmode' : ('FRF',),
                 'serialnum' : ('118045956'),
                 }

EDIT: This bug also blocks the z-stage motion at the start of an Acquisition. This causes the stack to begin from the current z-position (Issue #45)

Close & reopen camera and acquisition manager windows

Add dynamixel source code to zoom directory?

Is there a reason for not adding the Dynamixel source code to the zoom directory? It would simplify the install. It took me a while to get it importing because initially I was using a different version that is not compatible (hence #19). Then I of course one has to modify the library location, which is an additional step.

Joystick start/stop button does nothing after an acquisition is complete

After an acquisition is complete, pressing the joystick start/stop button causes the console to report Current state: run_selected_acquisition but nothing else happens. To get a live acquisition again one must press the "Live" button on the main GUI. After this the joystick start/stop button works again as normal.

Are 'galvo_l_amplitude' and 'galvo_r_amplitude' in config file obsolete?

What do these two galvo amplitude settings do? The GUI has only one amplitude setting on the Parameters tab: in ours it starts at 5V. Where does this number come from and are the r and l amplitudes now obsolete?

Last frame in stack blank

For a while I thought this was a read bug in Fiji, but I'm not so sure any more. I believe the last frame from each stack is empty (black).

Add pause button to be able to transiently stop acquisitions / acquisition lists

Produce downsampled BigStitcher stacks during acquisition

I wonder if it possible to generate downsampled stacks for bigstitcher during acquisition? e.g. the user asks to downsample by a factor of 8 by 8 by 4. Then every 4th Z plane is downsampled 8 by 8. Nearest neighbour would be fine for speed reasons. This would save a lot time later during stitching, as the user needs then needs initiate the stitching command manually then wait for it to complete.

Demo cannot run

I want to run the demo,no matter which demo config i choose , there is always different errors.
such as
nidaqmx.errors.DaqError: Device identifier is invalid.
Device Specified: PXI6259
Suggested Device(s): PXI2Slot5, PXI2Slot4, PXI2Slot3

Task Name: _unnamedTask<0>

Status Code: -200220

how should those problem can be solved?
thanks.

Entering text into boxes is a bit buggy

It looks like there is a loop that constantly updates edit box text (e.g. for the ETL parameters). When editing these boxes if you don't type fast enough the entered text is not registered. I'm not sure what is happening here.

"stop movement" does not stop focus

On DRI mesoSPIM we have found that the focus continues to move long after the joystick is released. Pressing stop did nothing. Had to quit the software.

Disconnecting the joystick/side panel leads to crashes

This could be improved by having a gentle way to disconnect the joystick.

Acquisitions Manager: Cells with a Mark button don't support value changes without hitting Enter

For cells with a "Mark"-Button in the TableView of the Acquistion Manager, editing a value and then clicking in another cell does not lead to changed data in the model.

This probably has to do with the way mouse events are handled by custom delegates and that some method needs to be reimplemented when subclassing QItemDelegate or QStyledItemDelegate. For default delegates such as QSpinBox or QDoubleSpinBox, this works fine.

mesoSPIM-control GUI should resize properly if a scaling factor is used

Assigning a different ETL config file in the microscope config does not work

If only one acquisition in list, this should always be selected

Currently if only one acquisition is present in the acquisition manager it is not selected by default. Thus a user might click one of the "mark" buttons but nothing is actually updated on the acquisition line. This slightly violates expected behavior.

Power bar with no indication of the actual power used

It would be great either to replace the bar that was below the power slider or even better indicate as a number the % of power actually used. This would be very useful.

a problem with NI chassis

a problem with NI cards appeared, the error code that you wrote says that NI chassis are not registered.

The error:
Traceback (most recent call last):
File "C:\soft\mesoSPIM-control-master\mesoSPIM\src\mesoSPIM_Core.py", line 177, in state_request_handler
exec('self.set_'+key+'(value)')
File "", line 1, in
File "C:\soft\mesoSPIM-control-master\mesoSPIM\src\mesoSPIM_Core.py", line 216, in set_state
self.live()
File "C:\soft\mesoSPIM-control-master\mesoSPIM\src\mesoSPIM_Core.py", line 399, in live
self.snap_image()
File "C:\soft\mesoSPIM-control-master\mesoSPIM\src\mesoSPIM_Core.py", line 367, in snap_image
self.waveformer.write_waveforms_to_tasks()
File "C:\soft\mesoSPIM-control-master\mesoSPIM\src\mesoSPIM_WaveFormGenerator.py", line 389, in write_waveforms_to_tasks
self.laser_task.write(self.laser_waveforms)
File "C:\ProgramData\Anaconda3\lib\site-packages\nidaqmx\task.py", line 1235, in write
timeout)
File "C:\ProgramData\Anaconda3\lib\site-packages\nidaqmx_task_modules\write_functions.py", line 32, in _write_analog_f_64
check_for_error(error_code)
File "C:\ProgramData\Anaconda3\lib\site-packages\nidaqmx\errors.py", line 127, in check_for_error
raise DaqError(error_buffer.value.decode("utf-8"), error_code)
nidaqmx.errors.DaqError: No registered trigger lines could be found between the devices in the route.

If you have a PXI chassis, identify the chassis correctly in MAX, and make sure it has been configured properly. If you are using PCI devices, make sure they are connected with a RTSI cable and that the RTSI cable is registered in MAX. Otherwise, make sure there is an available trigger line on the trigger bus shared between the devices.
Source Device: PXI6259
Destination Device: PXI6733

Task Name: _unnamedTask

Status Code: -89125

It is possible for motions to just exceed the max/min ranges

Joystick motions can cause the sample position to exceed the motion range by a few microns (e.g. 50 microns). The axis is then out of range and it is no longer possible to move it with the joystick. It can only be returned using the on-screen buttons.

I'm on the master branch.

Automatically save reslices and max-projections

This is intended both to streamline quality control checks and to debug acquisitions.

Users should be able to select one of the following options for each row in the Acquisition Manager:

• save xy max projection of the stack (most important)
• save full xz / yz reslices of the stack (xz has priority)
• save maximum projections of full and partial reslices (e.g. select to split the resliced volume in 1 to 10 subvolumes and do a partial reslice there)

This way, for a single stack, multiple datasets can be created on the fly:

This will require touching the following parts of the code:

• in the camera thread (mesoSPIM_Camera.py), the computations should be executed
• add a corresponding row to acquisitions.py (e.g. a dictionary that allows specifying which online-processing steps should be taken and with which parameters)
• add a delegate in delegates.py to have a button that opens a GUI (e.g. a wizard) to specify which processing steps should be executed

Here is some code from my experiments with this in the camera thread:

In prepare_stack():

self.xz_stack = np.memmap(self.path[:-4]+'xz.raw', mode = "write", dtype = np.uint16, shape = 2048 * self.max_frame * 2048)
self.yz_stack = np.memmap(self.path[:-4]+'yz.raw', mode = "write", dtype = np.uint16, shape = 2048 * self.max_frame * 2048)

In add_images_to_stack():

''' Write YZ (coronal) image '''
for j in range(2048):
    line =  data[j*2048:(j+1)*2048]
     self.yz_stack[2048*j*self.max_frame+2048*self.cur_frame:2048*j*self.max_frame+2048*self.cur_frame+2048] = line

In end_stack(), one should make sure to delete the self.yz_stack object as it might need a lot of memory.

Zooming drop down menu often fails to update after a zoom

Just noticed this with latest version. Not tried restarting software to see if it goes away. The system zooms correctly.

If directory does not exist the software crashes when trying to run an acquisition

I have noticed that if a non-existent directory is defined in the acquisition list, starting the acquisition causes the software to crash. An error message indicating that this was the source of the crash appears in the console.

If Filter '515LP' is not in the filterdict in the config, the software crashes

Add DemoCamera

This will involve:

• create a mesoSPIM_Camera facade class that contains all the methods of the current mesoSPIM_HamamatsuCamera
• inherit it in a mesoSPIM_DemoCamera class
• generate some noise demo data to be sent to the mesoSPIM_CameraWindow, for example some noisy stripes via:

def create_demo_image(n, size):
  n = (n % 64) - 32 # the range -32 to 32 produces decent images

  size = 1024 # or 2048
  line = np.linspace(0,6*np.pi,size)
  line = 4*np.sin(line)+4

  data = np.array([np.roll(line, n*i) for i in range(0, size)])
  data = data + np.random.normal(size=(1024, 1024))

• one could wire this up to the NI WaveFormGenerator or a Demo variant of it - currently the camera is triggered by a wired digital signal in hardware
• but as a test, one could simply use the sig_add_images_to_image_series signal by the mesoSPIM_Core to trigger the generation of images in a simulated stack and sig_get_live_image for live mode

hdf5 / image processing

We just installed the last stable version and found out that the automatic image processing is not working when .h5 is choosen as an outpout format.

Write image size to raw data text file

In order read the raw file we need to know the number of pixel rows and columns in a frame. Right now I think all rigs have cameras that are 2048 x 2048 but in future people might use different cameras. It's useful to have this parameter logged so future raw file readers (like the one I'm writing now!) will definitely open the images correctly.

Seems to be no robust check that the software is at the correct z position before starting a stack

Issue #44 describes the X stage becoming unreferenced when the software starts. As a consequence of this, the z motion to the start position of the stack never happens. I suspect what happens is the software first tries to go to the correct X/Y position, this fails, and it never proceeds to moving to the correct initial Z position. Despite this failure to move to the correct position, the acquisition still begins taking slices from whatever is the current Z position. Therefore there does not seem to be a final check to ensure that the stages are at the correct position before the acquisition of the stack begins.

I confirm that with the X stage referenced and working properly, the Z stage behaves as expected and stacks are taken from the correct position.

After an acquisition list with varying zoom & filter, the microscope does not return to the initial state

TIFFs files saved by meso control do not load into MATLAB

The TIFFs are reported in MATLAB as having just one header -- not one header per frame -- and so only the first frame can be loaded. Re-saving them in Fiji allows all frames to be index and therefore loaded.

edit - it also fails if I try to load the images into Elastix.

Add prediction for the acquisition time

Link better documentation of device pinouts

Suggested by @kD3AN

Improve documentation for the shutter pinout here, in the config file and in the documentation:

• default for the shutter_right is PXI6259/port2/line0, equivalent to: PFI 8/P2.0
• The best way for us to go to MAX, right click on the device, and then go to Device Pinouts.

Different left and right laser power, sheet height and dimming during z-stack acquisition

Hi all,

Issue 1: I'm noticing a difference in laser power between the lasers with the left lasers being dimmer, it's slightly different for different lasers lines too, what's the best way to fix this?

Issue 2: the left and right laser sheets are different heights with the left being audibly quieter (images below)

Issue 3: When using higher magnifications, I notice that the 488 laser power dips for some slices of a stack, the 561 and 647 seem OK though. This seems intermittent and can be repeated at even spacing throughout the sample or sometimes just be one set of slices that are dimmer. Any ideas why this might be?

Any help is much appreciated.

Peter

Joystick inputs should only be taken into account in idle & live states

Possibly in alignment & visual mode as well. However, during stacks, joystick inputs should be disregarded. In a future iteration, the stop button should work, however.

Add a config option so that the software runs without a joystick plugged in

This would help both testing with demo classes and in case a joystick breaks.

Tiling Wizard should be implemented

Add calibration factor for differing laser power between left and right sides

On our rig I have measured laser power after the collimating lens for a range of powers over our three most used lines. Our 488 nm is about 10% stronger on average on the left but the 561 nm is about 15% stronger on the right. The 640 nm is less consistent but seems to be equally bright on both sides at power settings over about 20%. Thus it does not look like the power differences can be ascribed to dirt on the fibre tip on one side.

I think it would be helpful to have one constant in the settings file per laser line to allow the super-user to set a L/R scaling factor for each line.
EDIT -- I notice that for the Toptica lasers I can DIY this in the GUI by reducing the max power of the brighter laser.

I'm also wondering if it would be useful to somehow correct for illumination in the images before fusing. It obvious how to do this for non-tilescan scenarios or for tilescans where each tile imaged twice. Has anyone tried a correction of this sort? I guess BigStitcher does not do it out of the box, but might BigStitcher provide for scaling image intensity according to a pre-calculated value?

Loading an acquisition table from a previous version can crash the application

As the aqcuisition tables are currently saved only via pickle, reading of the serialized table will fail if the software was updated (especially when changes to the acquisition data structure in acquisitions.py were done.) There should be a warning in case loading fails.