delmic / odemis

Open Delmic Microscope Software

Odemis

Odemis (Open Delmic Microscope Software) is the open-source microscopy software of Delmic B.V.. Odemis is used for controlling microscopes of Delmic and the Odemis viewer allows to load previous experimental data for visualization, analysis and export. Delmic’s mission is to empower companies and researchers by helping them achieve results that can be trusted implicitly with powerful and user-friendly solutions.

Requirements

• Linux (tested on Ubuntu 18.04, 20.04, and 22.04 x86)
• Python (v3.6+)
• Special (forked) version of Pyro4 from Delmic

Note: the viewer part is also tested to run on Windows (10+).

For the complete list of dependencies, see the file requirements.txt.

Installation

See the doc/INSTALL.txt document for the complete installation procedure.

Basic usage

Launch the "Odemis" program, or type on a terminal: odemis-start Eventually the GUI (Graphical User Interface) will appear. As an argument it can take the name of the microscope file corresponding to the back-end.

It is not usually necessary, but if you want, to fully stop odemis (GUI and back-end), type: odemis-stop

To run just the viewer, you can type: odemis-gui --standalone

Advanced usage

odemisd is the command line interface to start and manage the Odemis backend. It should be started first.

Run as odemisd ..., with ... replaced by the correct arguments. For all the possible commands see: odemisd --help

For example: odemisd --daemonize --log-level=2 src/odemis/odemisd/test/optical-sim.odm.yaml

To use the command line interface use: odemis-cli --help

To see the list of components: odemis-cli --list

For example, to turn on the forth source of the "light" component, type: odemis-cli --set-attr light power "0.0, 0.0, 0.0, 0.2"

For example, to move the Y axis of the "stage" component by 100µm, type: odemis-cli --move stage y 100

License

GPLv2, see the LICENSE.txt file for the complete license.

Extending

For information on how to extend the software, see the developer documentation. It must be first compiled, with:

cd doc/develop/
make html
# or
make latexpdf

Then it can be opened with: firefox _build/html/index.html or evince _build/latex/odemis-develop.pdf

Testing

To test the software, there are several unit-test classes in each directory (in their test/ sub-directory). There are also a few example microscope configuration file in the install/linux/usr/share/odemis/.

To run all the tests, you can call util/runtests.sh.

odemis's Issues

Possible to change the resolution during spot mode

On the SECOM, in lens alignment tab, when the spot mode is active, the SEM settings can still be modified.

This means that in spot mode, reducing the scale will increase the resolution, and causing the spot mode to not be correct. Even worse, after spot mode is over, the resolution will be reset to the old one, which causes a cropped acquisition.

The minimum fix is to prevent changes to the SEM settings during spot mode.

Problem of positioning of the image with the acquire dialog

I am noticing a small bug in Odemis during use - I'll try to describe!

With optical on, I am viewing at half resolution and binning 2 to speed up image refresh during focus. If I then acquire an image using the 'Acquire' dialog, when I close the acquire dialog and return to the windowed view, the image very often moves up to the top left quadrant of the camera chip rather than staying in the center. Selecting binning 2>1>2 returns the image to the center.

This is happening with Odemis v1.7 on a SECOM v1

Impossible to cancel an acquisition

The SEM will always finish the current acquisition. For example, accidentally selecting a large dwell time can start an acquisition that takes more than 60 s. Even if the user immediately sets the dwell time back to a normal setting, an already started acquisition will first be completed.

Improve responsiveness of SEM focusing

Focusing of the SEM stream in Odemis is slow compared to the native Phenom GUI. Probable cause could be that the current acquisition is first finish before new focus setting is applied and new acquisition started.

History trail not reset

When unloading and then reloading a sample, the history trail is not reset. Instead, the trail of the previous measurement session is shown.

semcomedi blocks sometimes when (re)starting an analog scan

From a user point of view, the GUI freezes when changing the dwell time. Looking at the logs, there is something like this:

2015-09-28 13:24:06,919 (semcomedi) DEBUG: Reading 5450 lines at a time: 16775100 samples/read every 3 µs
2015-09-28 13:24:06,920 (semcomedi) DEBUG: Going to read 1024 lines
2015-09-28 13:24:06,920 (semcomedi) DEBUG: Generating new write and read commands for 1050624 scans on channels [1, 0]/(0,)
2015-09-28 13:24:06,920 (semcomedi) DEBUG: Going to preload 2097152 bytes
2015-09-28 13:24:06,939 (semcomedi) DEBUG: Waiting 3.56706 s for the acquisition to finish
2015-09-28 13:24:07,880 (semcomedi) DEBUG: Found duplication & over-sampling rates: 800 ns x 1 x 37 = 29600 ns
2015-09-28 13:24:07,883 (_dataflow) DEBUG: Listener '/var/run/odemisd/SEM%20Scan%20Interface.ipc@obj_df85dddea24f401cb4a66811d7325b56' unsubscribed, now 0 subscribers
2015-09-28 13:24:07,883 (semcomedi) DEBUG: cancelling npnotifier
2015-09-28 13:24:07,883 (semcomedi) DEBUG: Cancelling write
2015-09-28 13:24:07,883 (semcomedi) DEBUG: Write cmd cancel sent
2015-09-28 13:24:08,383 (semcomedi) DEBUG: Cancelling read
2015-09-28 13:24:08,384 (semcomedi) DEBUG: read took 1.44568 s
2015-09-28 13:24:08,386 (_dataflow) DEBUG: Listener '/var/run/odemisd/SEM%20Scan%20Interface.ipc@obj_df85dddea24f401cb4a66811d7325b56' subscribed, now 1 subscribers
2015-09-28 13:24:08,404 (semcomedi) DEBUG: Waited for the read thread for actually 1.46577 s
2015-09-28 13:24:08,404 (semcomedi) DEBUG: Acquisition was cancelled
2015-09-28 13:24:08,404 (semcomedi) DEBUG: ranges X = (-3.1722990234374997, 3.1722990234374997)V, Y = (-3.1732017999580076, 3.1732017999580076)V
2015-09-28 13:24:08,410 (semcomedi) DEBUG: Reading 442 lines at a time: 16762850 samples/read every 29.6 µs
2015-09-28 13:24:08,410 (semcomedi) DEBUG: Going to read 442 lines
2015-09-28 13:24:08,410 (semcomedi) DEBUG: Generating new write and read commands for 453050 scans on channels [1, 0]/(0,)
2015-09-28 13:24:08,417 (semcomedi) DEBUG: Going to preload 1812200 bytes

Then it stops. There is no message further, as would be expected. That seems like a AO writer problem. Could also be lock-related.

Position of AR images misplaced (due to drift correction?)

Some AR acquisitions with drift correction activated show the position of the AR spots at different locations than the position of the pixels. See for example angular-part7-40s-ap4spot6-30kv-rotated90deg-shifted.h5 .

The first guess is that the position of the AR image is the raw position, without the drift correction applied.

Cannot "save as" an acquisition opened in the gallery

The menu entry is currently disabled while you'd expect it to allow to save in a (maybe) different format.

Maybe menu should be renamed to "Save as..." instead of "Save snapshot as..." at the same time.

Starting Odemis with Phenom in standby mode

When the Phenom is in standby mode Odemis will not start, reporting "unknown focus position" on the Phenom component.

Be more careful if referencing stage fails

If the referencing of the optical stage failed it might be a sign that the hardware is broken, or at least that it doesn't respond as we expect. Currently, if the referencing fails, a warning is displayed, and Odemis GUI continues (hoping it will work well enough to keep the user happy).

It might damage the hardware more if we keep moving it. So instead, we should warn more about this problem, and maybe even prevent using the optical stage (or eject the sample holder).

Odemis GUI indicates the SEM or Optical part is off if they are activated via CLI

If the GUI is running, and simultaneously the user starts playing a SEM or optical detector, the respective part of the microscope will be technically active, while in the GUI the "OPTICAL" or "SEM" buttons indicate nothing is active.

Expected behaviour: in such a case the button should light up, (and nothing more should happen in the GUI).
Note: in general, it is not advised to use the CLI without good knowledge of the microscope and its limits, and more generally, when using the CLI it's expected that the GUI doesn't handle every case. Moreover, it's technically very hard for the GUI to "know" that another program is also accessing the backend.

Changing the focus in Combined view always changes the optical focus

The focus actuator of the Combined views is hard linked to the optical focus. So when the SEM stream is active, changing the focus changes the optical focus, which is very confusing/terrible.
Changing the focus should be dependent on the current live stream.

TMCM driver reports IOError sometimes during a move

2015-03-27 14:13:55,624 INFO    __init__:763: Failed to apply focus move
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/odemis/gui/model/__init__.py", line 761, in _moveFocus
    f.result()
  File "/usr/lib/python2.7/dist-packages/Pyro4/futures.py", line 300, in result
    return self.__get_result()
  File "/usr/lib/python2.7/dist-packages/Pyro4/futures.py", line 284, in __get_result
    raise self._exception
IOError: Received only 0 bytes after 1, 6, 8, 2, 0 (17)

That seems corresponding to TMCM._isOnTarget().

Or:

2015-03-27 14:14:15,724 INFO    __init__:763: Failed to apply focus move
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/odemis/gui/model/__init__.py", line 761, in _moveFocus
    f.result()
  File "/usr/lib/python2.7/dist-packages/Pyro4/futures.py", line 300, in result
    return self.__get_result()
  File "/usr/lib/python2.7/dist-packages/Pyro4/futures.py", line 284, in __get_result
    raise self._exception
IOError: Received only 0 bytes after 1, 4, 1, 2, 8642 (235)

That's a relative move request.

Apparently, afterwards, the controller keeps working fine.
=> Need to try harder contacting the controller?

Moving the stage in between FM and SEM acquisitions lead to incorrect overlay

Consider the following use case:

• Acquire an image using the fluorescence microscope
• After the acquisition pause the stream
• Move the stage to a new location
• Acquire an image with the SEM

The resulting image in the combined viewport now combines the FM image of the old stage position with the SEM image at the new stage position.

Last view thumbnails in GUI are hidden if the window is small

Pretty much every widget is resized well when the window is resized to a relatively small size, except for the view thumbnails (in acquisition and analysis tabs). If the window is not high enough, it's quite easy for the last few thumbnails to be completely hidden, which prevents the user to easily switch between views.

Expected behaviour: the whole left panel shrinks as small as needed to fit completely in the space provided.

Note: the reason for this bug is that historically the GUI was designed exclusively for being shown fullscreen on a 1920x1200 display. However, in the case of the Odemis Viewer, such assumption cannot be that easily made (as it should be able to run on any computer).

Changing the center wavelength of the spectrometer with a slider is useless

As noted by Benjamin from AMOLF:

• the slider for the grating position is really not necessary, and actually a pain. You can by accident click on it at positions that will move the grating enormously (such as to several micron) which is completely pointless and nobody is going to use the slider, you always want to move to a specific position, so just typing it in is always going to be easier and faster and more exact (if you click on the slider you might move to 701 nm instead of 700 nm for example I think). So I think it would be better to remove the slider completely. Is there any reason to keep it? Here at Amolf we do not see a reason in any case...
• the units. This is useful for the grating, but also for the pixel size and other places you have to put a length/position. Now it is always in SI, so you have e-9 or something like that, you can easily by accident delete that and have a really strange value. It is not really a problem, but it is not very handy and intuitive. It would probably be better to have everything in nanometers, or to have the units be a little box where you can then choose between nanometers and micrometers (I do not think you would choose something else)... Depending on what you set, now the way the GUI shows the size/position is dependent on what you fill in. So 750 nm will be shown as 750 nm, but 700 nm will be shown as 7e-7m for example...

=> Just provide a number text input, with wavelength in nm.

Contrast/brightness in Delphi

E-mail Matt:

Strange things have been happening with Brightness/Contrast

• Jumps to a setting that's either far too bright or far too dark
• Couldn't use Odemis to adjust this enough to see anything
• Using the Phenom UI, I could adjust it enough to get an image
• Even then it jumps occasionally, and doesn't always correspond to the setting indicated on the sliding scale on the Phenom UI
• The levels graph on Odemis seems suspiciously geometric in its shape so I'm not sure it's accurately representing the actual data

Is the intention to use Odemis alone to adjust SEM Brightness/Contrast? If so, that doesn't seem to work at the moment. As with the SECOM, it seems to adjust the brightness and contrast in the image from the SEM, rather than adjusting the SEM Brightness/Contrast settings directly.

Light can be turned on even with Optical instrument off

By changing the power of the light, it's possible to turn on the light, even if the "Optical instrument" button is off. It should stay off as long as the instrument is off.

Division in python 2 is too tricky

We should always use "from future import division" and either use / or //. Never depend on the number's type.

No error when power lost on Zyla

If the power to the Zyla is lost with Odemis running but no active view, no error is reported to the user in the GUI (it might be in the log file, not checked). The viewport remains black when activating, even when re-applying power to the Zyla.

Viewport opacity slider works incorrectly

When loading a file containing SEM survey/Spectrum data in the Analysis tab for the first time, the opacity slider does not work in the combined view. (The left side gets assigned the SEM stream and the right the Spectrum stream).

After hiding and showing the SEM survey stream, the left and right streams on the slider are swapped and everything seems to work as it should.

GUI crashes if trying to take too large acquisition

Taking an 11x11 AR acquisition with max resolution (=5 Mpixels) will crash the GUI with no warning (and little explanations). That's because currently all the acquired data is stored in memory until the end of the acquisition. In such acquisition, the minimum memory needed is 1.1Gb, and with the rest of the application and the overhead reaches the 2Gb safety limit.

Minimum correct behaviour: warn that such an acquisition will crash Odemis, and so a smaller data size should be selected.

Good behaviour: always work, independent of the total acquisition size.

Chamber loading button stays in waiting state

In certain occasions when loading the sample holder to the SEM in the Delphi the chamber button stays in its waiting state (amber color).

Still possible to move the stage while there is a pause icon (sometimes)

Reported by HT.
On SECOM, in the streams tab, apparently in some cases it's still possible to move the stage even if all the streams of the view as paused.

Acquisition window should allow to directly see the acquired data

In the SECOM, in the acquisition window, at the end of a successful acquisition, the two choices possible are:

• close (the window)
• start (a new acquisition)

Instead of starting a new acquisition, the "START" button should be renamed "SHOW", and do the following:

• Close the window
• Select the gallery tab
• Open the acquisition file which was just saved.

Scale of point spectrum graph always adapt to the current data

(requested by Toon)
When looking at the spectrum of a point, the scale is adapted to the data. That's not always convenient when trying to compare points or to look at a specific intensity level.

So it would be nice to:

• be able to "lock/unlock" the the scale
• be able to select the min/max of the scale
  IOW, that's similar to the brightness/contrast control. The first point might be already a big improvement.

Brightness/Contrast slider lag

When manually adjusting the brightness and/or contrast of a stream using the mouse, the slider freezes in place while the image is updated. Once the update is complete, the slider instantly jumps to the right location.

Marking lines change on different events in different viewports

The MarkingLineOverlay sets a new position on mouse down in the Plot view port, but in the Spatial Spectrum view port only after mouse up.

Improve adjustment of spot size in Delphi

E-mail Matt:
Spot size adjustment is troublesome; after using the slider to set a value, it will adjust the setting to something in that direction, but often still quite different to the set value.

Memory error in GUI

This happened once so far.
Seems to start with problem in cropping the image, then error in writing it in TIFF, and from then on MemoryErrors (maybe due to memory corruption by libtiff?).

2014-11-17 10:31:06,160 INFO    text:696: Received the new value '1.0' to set while in focus
2014-11-17 10:33:52,680 INFO    acquisition:213: Snapshot saved as file '/home/secom/Pictures/141117/InsQD655_Hoechst_1s_100mW.ome.tiff'.
2014-11-17 10:37:31,716 INFO    text:696: Received the new value '1280.0' to set while in focus
2014-11-17 10:43:16,943 ERROR   main:273: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 1344, in on_left_up
    self.update_drawing()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/miccanvas.py", line 394, in update_drawing
    super(DblMicroscopeCanvas, self).update_drawing()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 1535, in update_drawing
    self.draw()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/miccanvas.py", line 758, in draw
    super(DblMicroscopeCanvas, self).draw()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 823, in draw
    self._draw_merged_images(self.ctx)
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 876, in _draw_merged_images
    blend_mode=im.metadata['blend_mode']
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 976, in _draw_image
    im_data, tl = self._get_sub_img(intersection, b_im_rect, im_data, total_scale)
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 1139, in _get_sub_img
    sub_im_x:sub_im_x + sub_im_w].copy()
type

2014-11-17 10:43:16,959 DEBUG   canvas:478: Buffer size changed, redrawing...
2014-11-17 10:43:16,959 DEBUG   canvas:514: Resizing buffer size to (2291, 1922)
2014-11-17 10:43:16,960 ERROR   main:273: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/miccanvas.py", line 530, in on_size
    super(DblMicroscopeCanvas, self).on_size(event)
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 480, in on_size
    self.update_drawing()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/miccanvas.py", line 394, in update_drawing
    super(DblMicroscopeCanvas, self).update_drawing()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 1535, in update_drawing
    self.draw()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/miccanvas.py", line 758, in draw
    super(DblMicroscopeCanvas, self).draw()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 823, in draw
    self._draw_merged_images(self.ctx)
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 876, in _draw_merged_images
    blend_mode=im.metadata['blend_mode']
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 976, in _draw_image
    im_data, tl = self._get_sub_img(intersection, b_im_rect, im_data, total_scale)
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 1139, in _get_sub_img
    sub_im_x:sub_im_x + sub_im_w].copy()
type

2014-11-17 10:43:20,347 ERROR   main:273: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/miccanvas.py", line 530, in on_size
    super(DblMicroscopeCanvas, self).on_size(event)
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 480, in on_size
    self.update_drawing()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/miccanvas.py", line 394, in update_drawing
    super(DblMicroscopeCanvas, self).update_drawing()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 1535, in update_drawing
    self.draw()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/miccanvas.py", line 758, in draw
    super(DblMicroscopeCanvas, self).draw()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 823, in draw
    self._draw_merged_images(self.ctx)
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 876, in _draw_merged_images
    blend_mode=im.metadata['blend_mode']
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 976, in _draw_image
    im_data, tl = self._get_sub_img(intersection, b_im_rect, im_data, total_scale)
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 1139, in _get_sub_img
    sub_im_x:sub_im_x + sub_im_w].copy()
type

2014-11-17 10:43:20,491 DEBUG   canvas:478: Buffer size changed, redrawing...
2014-11-17 10:43:20,491 DEBUG   canvas:514: Resizing buffer size to (2291, 1922)
2014-11-17 10:43:20,492 ERROR   main:273: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/miccanvas.py", line 530, in on_size
    super(DblMicroscopeCanvas, self).on_size(event)
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 480, in on_size
    self.update_drawing()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/miccanvas.py", line 394, in update_drawing
    super(DblMicroscopeCanvas, self).update_drawing()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 1535, in update_drawing
    self.draw()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/miccanvas.py", line 758, in draw
    super(DblMicroscopeCanvas, self).draw()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 823, in draw
    self._draw_merged_images(self.ctx)
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 876, in _draw_merged_images
    blend_mode=im.metadata['blend_mode']
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 976, in _draw_image
    im_data, tl = self._get_sub_img(intersection, b_im_rect, im_data, total_scale)
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 1139, in _get_sub_img
    sub_im_x:sub_im_x + sub_im_w].copy()
type

2014-11-17 10:43:21,736 DEBUG   canvas:1323: Drag started at (315, 1012)
2014-11-17 10:43:21,829 ERROR   main:273: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 1344, in on_left_up
    self.update_drawing()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/miccanvas.py", line 394, in update_drawing
    super(DblMicroscopeCanvas, self).update_drawing()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 1535, in update_drawing
    self.draw()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/miccanvas.py", line 758, in draw
    super(DblMicroscopeCanvas, self).draw()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 823, in draw
    self._draw_merged_images(self.ctx)
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 876, in _draw_merged_images
    blend_mode=im.metadata['blend_mode']
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 976, in _draw_image
    im_data, tl = self._get_sub_img(intersection, b_im_rect, im_data, total_scale)
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/canvas.py", line 1139, in _get_sub_img
    sub_im_x:sub_im_x + sub_im_w].copy()
type

2014-11-17 10:43:22,200 DEBUG   canvas:1323: Drag started at (166, 1120)
2014-11-17 10:43:22,321 DEBUG   canvas:316: Dynamic cursor reset
2014-11-17 10:43:23,511 DEBUG   buttons:795: ViewButton already active
2014-11-17 10:44:34,588 ERROR   log:37: Failed to save snapshot
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/odemis/gui/cont/acquisition.py", line 211, in snapshot_viewport
    exporter.export(filepath, raw_images, thumbnail)
  File "/usr/lib/python2.7/dist-packages/odemis/dataio/tiff.py", line 1427, in export
    _saveAsMultiTiffLT(filename, data, thumbnail)
  File "/usr/lib/python2.7/dist-packages/odemis/dataio/tiff.py", line 1320, in _saveAsMultiTiffLT
    f.write_image(data[i], write_rgb=write_rgb, compression=c)
  File "/usr/lib/python2.7/dist-packages/libtiff/libtiff_ctypes.py", line 555, in write_image
    WriteStrip(0, arr.ctypes.data, size)
  File "/usr/lib/python2.7/dist-packages/libtiff/libtiff_ctypes.py", line 782, in WriteEncodedStrip
    assert r.value==size,`r.value, size`
AssertionError: (-1, 8388608)
2014-11-17 10:44:34,615 DEBUG   canvas:478: Buffer size changed, redrawing...
2014-11-17 10:44:34,615 DEBUG   canvas:514: Resizing buffer size to (2295, 1958)
2014-11-17 10:44:34,616 DEBUG   viewport:466: Canvas HFW too small! Setting it to 0.01
2014-11-17 10:44:34,637 DEBUG   canvas:478: Buffer size changed, redrawing...
2014-11-17 10:44:34,638 DEBUG   canvas:514: Resizing buffer size to (2291, 1922)
2014-11-17 10:45:20,084 ERROR   log:37: Subscriber <odemis.model._core.WeakMethodBound object at 0xc19da0c> raised exception when receiving value 1416217520.05
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/odemis/model/_vattributes.py", line 96, in notify
    l(v)
  File "/usr/lib/python2.7/dist-packages/odemis/model/_core.py", line 382, in __call__
    return self.f(ins, *arg, **kwargs)
  File "<string>", line 2, in _onViewImageUpdate
  File "/usr/lib/python2.7/dist-packages/odemis/gui/util/__init__.py", line 118, in ignore_dead
    return f(self, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/miccanvas.py", line 382, in _onViewImageUpdate
    self._convert_streams_to_images()
  File "/usr/lib/python2.7/dist-packages/odemis/gui/comp/miccanvas.py", line 352, in _convert_streams_to_images
    rgba_im = img.format_rgba_darray(rgbim)
  File "/usr/lib/python2.7/dist-packages/odemis/gui/util/img.py", line 45, in format_rgba_darray
    rgba = numpy.empty(rgba_shape, dtype=numpy.uint8)
MemoryError

First SEM acquisition saturated

In the Delphi the first acquisition when turning on the SEM is in general almost completely saturated (white), whereas the second has the right contrast/brightness

Binning/resolution incorrectly set when changing presets causing cropping

When closing acquisition window, the resolution might end up smaller than before when binning is changed. This is very likely due to presets not being set back in the right order.

Potential fix: ensure binning is always set before resolution.

Automatically disable the camera fan when needed

Description: (as proposed by Dr. L.)

The fan of the camera (e.g. Zyla) induces vibrations in the SEM, which severly limits the resolution of the SEM image. Therefore the fan should be turned off during SEM imaging. This allows the user to turn the fan off (also when imaging with the SEMvendor software) by playing the SEM stream.

Details:

The following is only applicable if the driver of the camera has the features fanSpeed & targetTemperature

The fanSpeed is always 1 & targetTemperature 0, except when:

• SEM stream is live
  fanSpeed is set to 0 and targetTemperature 25
• during the 'optical' part of an acquisition sequence of the 'acquire image' window
  fanSpeed is set to 0 and targetTemperature 0
• during the SEM part of an acquisition sequence of the 'acquire image' window
  fanSpeed is set to 0 and targetTemperature 25
• during the 'fine-alignment' part of an acquisition sequence of the 'acquire image' window
  fanSpeed is set to 0 and targetTemperature 0

When starting with the 'optical' & 'fine-alignment' part of the 'acquire image' window, there should be an additional check to make sure that the camera sensor is cooled sufficiently.

• If the temperature of the sensor is not close (<1C?) to 0, set fanSpeed 1 targetTemperature 0.
• Wait untill targetTemperature is reached.
• Continue to the 'optical' or 'fine-alignment' part with the appropriate settings.

Reason is that the fine-alignment fails when the temperature of the sensor is too high. This might happen after a long SEM exposure.

Auto brightness/contrast is late

Auto BC is actually computed with the histogram of the previous image. So for long exposure times, it can be quite annoying when changing some settings (e.g., binning).

We need to either have a faster histogram computation that can be done immediately, or at least, redisplay the image as soon as the new histogram is available (and the outliers are quite different from the previous one).

View in acquisition window has a very large field of view

The SECOM/DELPHI acquisition window view shows the data of all streams. However, in some cases, this doesn't work well for the user. For instance, if the SEM stream hasn't been updated (contains data from on old location far away), and the optical stream has data from the new location, the acquisition view will be very zoomed out.

=> Center the view on the current stage location, and compute the zoom based on the theoritical FoV from each stream.

Histogram fails when using the Zyla in 11-bit mode

When using the Zyla in low noise / 11-bit read out mode, the histogram widget is displayed incorrectly

On Windows, images scaled down are not drawn

When zooming out in a spatial view, the images are more and more scaled down.
On Windows, when an image is about 6x times scaled down, it's not drawn anymore. That's relatively easy to hit with SECOM acquisition with an SEM image with a small HFW.

Most likely a Cairo bug/limitation.

Overview of the sample in the Delphi is out of focus

Currently the focus of the navcam is hard coded. If you're lucky, the focus is correct, but in most of the time you're not lucky.

So instead of using a hard coded position, we should either:

• Run the autofocus (starting from this hard coded position)
• Run the autofocus at calibration and reuse this value (= one value per Phenom/sample holder)

Check if error codes of the Phenom can be made available to Odemis

If the Phenom reports an error condition (for example, vacuum error, stage error, ...) it would be nice Odemis could report this to the user.

Andorcam3 driver should raise HwError if the USB camera is not connected over USB3

Strangely, the Andor SDK is fine with connecting to the camera over USB2, but it just crashes when starting to acquire image.
So it'd be better to just fail to initialise and raise a HwError in such a case.

cf: cat /sys/bus/usb/devices/*/version

Anchor region metadata take too much space

On acquisition with long exposure time, the anchor region is acquire (almost) for every pixel. That means the anchor region data is much bigger than the actual data.

It's not really nice to save that much metadata. Because of this, Odemis can easily run out of memory, and the acquisition is huge. In addition, anchor region for every pixel is not very useful.

=> Always save the 1st, 2nd and last image, plus some more to have at max 10 images.

Contrast/Brightness of streams not adjustable using keyboard

When entering a value manually into a contrast/brightness slider, or when adjusting this value using the arrow keys, the associated stream image will not be updated to reflect this new value.

Changing HFW not possible

Changing the HFW from the SEM settings menu is not possible

semcomedi.find_best_oversampling_rate() sometimes return wrong period

In semcomedi, find_best_oversampling_rate() sometimes return a wrong period.
That's not directly obvious, but eventually that causes such error to be reported:
Failed to create the precise command period = 2300300 ns (should be 2300321 ns)

Here are two logs causing the same issue, but potentially caused by different cases:

(semcomedi) DEBUG: Found duplication & over-sampling rates: 2.30032e+06 ns x 1 x 1 = 2.30032e+06 ns
(semcomedi) DEBUG: read took 0.00142694 s
(semcomedi) DEBUG: Waited for the read thread for actually 0.00340796 s
(semcomedi) DEBUG: Write finished after 0.00349689 s, while expected  0.00137471 s
(semcomedi) DEBUG: Counter sync read after 0.00354695 s
(semcomedi) WARNING: Simultaneous acquisition from analog and counting detector not supported. Only going to acquire from counting detector!
(semcomedi) DEBUG: Reading 1 lines at a time: 1 samples/counter every 2300.32 µs
(semcomedi) DEBUG: Going to read 1 lines
(semcomedi) DEBUG: Generating new write and count commands for 2 scans on [1, 0]/8
(semcomedi) ERROR: Failed to create the precise command period = 2300300 ns (should be 2300321 ns)

=> This is with a long dwell time, and with the counting detector. It seems to have returned period not even multiple of 50 ns (which is a hardware limitation).

(semcomedi) DEBUG: Found duplication & over-sampling rates: 1650 ns x 1 x 17 = 28050 ns
(semcomedi) DEBUG: ranges X = (-2.7486572265625, 2.7486572265625)V, Y = (-2.7486572265625, 2.7486572265625)V
(semcomedi) DEBUG: Reading 240 lines at a time: 16719840 samples/read every 28.05 µs
(semcomedi) DEBUG: Going to read 240 lines
(semcomedi) DEBUG: Generating new write and read commands for 491760 scans on channels [1, 0]/(0, 1)
(semcomedi) ERROR: Failed to create the precise command period = 1700 ns (should be 1650 ns)

=> Dwell time was set at 28.05µs, and two analog detectors are running simultaneously. The result of the method seems coherent, but likely for 2 read channels, the hardware limitation is a period multiple of 100 ns (ie, 2x50ns).

The SpatialSpectrumViewport disappears when the line tool is deselected, but does not come back on the next selection

As long as there's a line defined, the SpatialSpectrumViewport should be shown if the line tool is selected in the menu.

User feel of the sensitivity of focus in SEM and FM

Sensitivity of the focus is much lower in SEM than in FM due to the much larger depth of focus, especially when using high-NA objective lens. When setting the focus by dragging the mouse while holding the right mouse button the user has to be 'delicate' when focusing the FM and can be 'rough' when focusing the SEM. While physically accurate, it might improve the user feel if we apply a variable gain to the focus operation dependent on the depth of focus.

Hard to select a line on a sprectrum with just one line

In the analysis tab, when the spectrum region is a thin data set, eg 200x1, it's difficult to draw a line over it.

In such a case, there is pretty much only one possibility that the user wants when selecting the line: the whole data set. So we should detect such a case (ie, on of the dimensions of the data set is 1), and then automatically create a line that goes over the whole data set.

Font size of the exported AR "Print-ready" image is too small

When exporting as "print-ready" an AR projection, the font used to display the angles is tiny. It should be bigger.

Also, the lines of the "spider-web" are a bit too thin as well.

Configure stallguard in TMCM driver

The TMCM 3110 supports stallguard to detect that the motor doesn't move (and avoid breaking stuff).
However the default values are apparently too large to ever detect any stall in the microscope.

We need to find the right configuration, and set them at init in the TMCM driver.

Potential for (unexpected) strong signal received by PMTs when changing axes

On the SPARC, when doing live view of a PMT (eg, CL intensity or Monochromator), if the user changes filter or center wavelength, there is a potential that during the move a strong signal is received. That's because while the move happen, on the filter wheel other filters (such as pass-through) can be temporarily active, and allow more signal to go through, or on the spectrograph, a peak could be situated between the initial and target position of the center wavelength move.

Possible solutions:

• Stop acquisition during the moves
• Activate the protection during the moves