Mayor improvements in the documentation. First steps in Dispertech ex…

…periment model
nanoepics · Jul 30, 2019 · 2d26904 · 2d26904
1 parent b03a5a0
commit 2d26904
Show file tree

Hide file tree

Showing 91 changed files with 932 additions and 737 deletions.
diff --git a/.editorconfig b/.editorconfig
@@ -0,0 +1,35 @@
+# http://editorconfig.org
+
+root = true
+
+[*]
+indent_style = space
+indent_size = 4
+insert_final_newline = true
+trim_trailing_whitespace = true
+end_of_line = lf
+charset = utf-8
+
+# Docstrings and comments use max_line_length = 79
+[*.py]
+max_line_length = 119
+
+[*.rst]
+indent_size = 3
+
+# Use 2 spaces for the HTML files
+[*.html]
+indent_size = 2
+
+# The JSON files contain newlines inconsistently
+[*.json]
+indent_size = 2
+insert_final_newline = false
+
+# Makefiles always use tabs for indentation
+[Makefile]
+indent_style = tab
+
+# Batch files use tabs for indentation
+[*.bat]
+indent_style = tab
diff --git a/AUTHORS b/AUTHORS
@@ -1,5 +1,5 @@
 Authors
 -------
 
-Aquiles Carattino <aquiles@aquicarattino.com>
+Aquiles Carattino <aquiles@uetke.com>
 Sanli Faez <[email protected]>
diff --git a/docs/_static/example_config.yml b/docs/_static/example_config.yml
@@ -0,0 +1,72 @@
+%YAML 1.2
+---
+# Default parameters for the Tracking program
+# All parameters can be changed to accommodate user needs.
+# All parameters can be changed at runtime with the appropriate config window
+user:
+  name: Aquiles
+
+saving:
+  auto_save: False
+  auto_save_waterfall: True
+  directory: C:\Users\carat002\Data
+  filename_video: Video # Can be the same filename for video and photo
+  filename_photo: Snap
+  filename_tracks: Tracks
+  filename_waterfall: Waterfall
+  filename_trajectory: Trajectory
+  filename_log: Log
+  max_memory: 200 # In megabytes
+
+GUI:
+  length_waterfall: 20 # Total length of the Waterfall (lines)
+  refresh_time: 50 # Refresh rate of the GUI (in ms)
+
+camera:
+  model: dummy_camera # Should be a python file in model/cameras
+  init: 0 # Initial arguments to pass when creating the camera
+  #extra_args: [extra, arguments] # Extra arguments that can be passed when constructing the model
+  model_camera: Orca Flash # To keep a registry of which camera was used in the experiment
+  exposure_time: 30ms # Initial exposure time (in ms)
+  fps: 30  # Frames per second, should either be defined by the camera or within the model based on timing
+  binning_x: 1 # Binning
+  binning_y: 1
+  roi_x1: 0
+  roi_x2: 599
+  roi_y1: 0
+  roi_y2: 399
+  background: '' # Full path to background file, or empty for none.
+  background_method: [Method1, Method2]
+
+waterfall: # Parameters for calculating the waterfall plot
+  length: 20  # The total length of the waterfall (lines)
+  vertical_bin: 10  # Total number of lines of the CCD to integrate
+
+movie:
+  buffer_length: 1000 # Frames
+
+tracking:
+  locate:
+    diameter: 11  # Diameter of the particles (in pixels) to track, has to be an odd number
+    invert: False
+    minmass: 100
+  link:
+    memory: 3
+    search_range: 4
+  filter:  # Filter spurious trajectories
+    min_length: 25
+  process:
+    compute_drift: False
+    um_pixel: 0.01  # Microns per pixel (calibration of the microscope)
+    min_traj_length: 2
+    min_mass: 0.05
+    max_size: 50.0
+    max_ecc: 1
+    fps: 30
+  param_1: 0.
+  param_2: 0
+
+debug:
+  logging_level: Nothing # One of Nothing, Debug, Info, Warning, Error
+  queue_memory: False
+  to_screen: True
diff --git a/docs/_static/screenshot_01.png b/docs/_static/screenshot_01.png
diff --git a/docs/_static/screenshot_free_run.png b/docs/_static/screenshot_free_run.png
diff --git a/docs/_static/screenshot_particles.png b/docs/_static/screenshot_particles.png
diff --git a/docs/_static/screenshot_save_image.png b/docs/_static/screenshot_save_image.png
diff --git a/docs/_static/screenshot_snap.png b/docs/_static/screenshot_snap.png
diff --git a/docs/_static/screenshot_toolbar.png b/docs/_static/screenshot_toolbar.png
diff --git a/docs/_static/screenshot_tracking.png b/docs/_static/screenshot_tracking.png
diff --git a/docs/conf.py b/docs/conf.py
@@ -177,4 +177,6 @@
 # -- Options for todo extension ----------------------------------------------
 
 # If true, `todo` and `todoList` produce output, else they produce nothing.
-todo_include_todos = True
+todo_include_todos = True
+
+autodoc_mock_imports = ["pydaqmx", "lantz"]
diff --git a/docs/developers/controller/devices/hamamatsu.rst b/docs/developers/controller/devices/hamamatsu.rst
@@ -0,0 +1,4 @@
+.. automodule:: pynta.controller.devices.hamamatsu.hamamatsu_camera
+    :members:
+    :undoc-members:
+    :show-inheritance:
diff --git a/docs/developers/controller/devices/index.rst b/docs/developers/controller/devices/index.rst
@@ -0,0 +1,13 @@
+.. automodule:: pynta.controller.devices
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+
+.. toctree::
+   :maxdepth: 2
+   :caption: List of available devices
+
+   hamamatsu
+   keysight
+   photonicscience
diff --git a/docs/developers/controller/devices/keysight.rst b/docs/developers/controller/devices/keysight.rst
@@ -0,0 +1,7 @@
+Keysight
+========
+
+.. automodule:: pynta.controller.devices.keysight.infiniivision
+    :members:
+    :undoc-members:
+    :show-inheritance:
diff --git a/docs/developers/controller/devices/photonicscience.rst b/docs/developers/controller/devices/photonicscience.rst
@@ -0,0 +1,4 @@
+.. automodule:: pynta.controller.devices.photonicscience.scmoscam
+    :members:
+    :undoc-members:
+    :show-inheritance:
diff --git a/docs/developers/controller/index.rst b/docs/developers/controller/index.rst
@@ -0,0 +1,13 @@
+Pynta Controllers
+=================
+
+.. automodule:: pynta.controller
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+.. toctree::
+   :maxdepth: 1
+   :caption: Contents
+
+   devices/index
diff --git a/docs/developers/index.rst b/docs/developers/index.rst
@@ -16,19 +16,23 @@ Below you will find an introduction to the code architecture. Read through to un
 
 Controller
 ----------
-In our definition of the MVC pattern, :mod:`controllers <pynta.controller>` are the drivers of the devices. Controllers for cameras, for example, rely on library files (.dll files on Windows, .so in Linux) that can be more or less documented. For example :mod:`~pynta.controller.devices.hamamatsu` uses the *DCAM-API*, while :mod:`~pynta.controller.devices.photonicscience` uses *scmoscam.dll*. Controllers should follow the specifications of each device as closely as possible. For instance, the units each devices uses for setting exposure times or framerates, etc. Moreover, they shouldn't implement anything that the device is not capable of doing. A clear example would be to set a region of interest. Some cameras support it but some don't. You could be tempted to apply a ROI in the software directly, but you shouldn't do it in the Controller, there is a better place as we will see later.
+In our definition of the MVC pattern, :mod:`~pynta.controller` are the drivers of the devices. Controllers for cameras, for example, rely on library files (.dll files on Windows, .so in Linux) that can be more or less documented. For example :mod:`~pynta.controller.devices.hamamatsu` uses the *DCAM-API*, while :mod:`~pynta.controller.devices.photonicscience` uses *scmoscam.dll*. Controllers should follow the specifications of each device as closely as possible. For instance, the units each devices uses for setting exposure times or framerates, etc. Moreover, they shouldn't implement anything that the device is not capable of doing. A clear example would be to set a region of interest. Some cameras support it but some don't. You could be tempted to apply a ROI in the software directly, but you shouldn't do it in the Controller, there is a better place as we will see later.
 
 Controllers are not always plain python files, sometimes are entire packages on themselves. For instance, the controller for Basler cameras (PyPylons) or National Instruments cards (pyDAQmx) are packages on their own. Sometimes the controllers where developed by other people, like the case of the Hamamatsu code, which was borrowed from Zhuang's lab. If you explore the controllers folder, you will notice that there are some available, like the :mod:`~pynta.controller.devices.keysight` ,that holds the drivers for an oscilloscope and function generator. Those controllers are remnants of a different incarnation of PyNTA, but that may still be valuable for the future.
 
 Model
 -----
+In the MVC pattern that we have defined earlier, :mod:`~pynta.model` is the place to define all the logic on how to use the devices is located. The core principle of splitting Controllers and Models is to separate what the device can do by design and what the user imposes to the devices. For example, imagine a camera which can acquire frames one by one. The controller would provide a way to snap a single-frame. However, a user may want to acquire a movie by developing a for-loop that acquires a series of frames. The controller should reflect the capacities of the device, while the model will include all the user-imposed logic.
+
+A clear advantage of having models is that in the case where controllers are not part of the package, for example if the driver is provided by the manufacturer itself, a model will make explicit how the driver is used. For example, NI-cards are very complex devices, and if one wants to monitor a signal, there are several required steps, which can be written down as a method of a class and re-used as much as wanted. Models can make use of explicit units (through Pint), for example.
+
+Models are not limited to devices, but they also make explicit how an experiment is performed. In PyNTA, there are available at least two different experimental models, one for performing nanoparticle tracking analysis in 2D images (the classical NTA) and one to perform tracking analysis in hollow optical fibers, i.e., 1-D nanoparticle tracking. In these experiment models, you can find all the steps and how they relate to each other. For example, you can't subtract background if you haven't acquired the background first, etc.
 
 Models for the Cameras
 ^^^^^^^^^^^^^^^^^^^^^^
+Imagine you have a camera that doesn't support setting a region of interest (ROI), you can still crop the resulting images in the software, giving the same result as what a camera that does support ROI does. By having an intermediate layer between the controllers and the users, it is possible to detach the specific logic of an experiment and the specifications of the devices. Moreover, it makes very straightforward to add new devices to the experiment, exchanging cameras, etc.
 
-Models define the way the users will interact with the devices. Imagine you have a camera that doesn't support setting a region of interest (ROI), you can still crop the resulting images in the software, giving the same result as what a camera that does support ROI does. By having an intermediate layer between the controllers and the users, it is possible to detach the specific logic of an experiment and the specifications of the devices. Moreover, it makes very straightforward to add new devices to the experiment, exchanging cameras, etc.
-
-Therefore in :doc:`pynta.model.cameras` is where we will develop classes that have always the same methods and outputs defined, but that behave completely different when communicating with the devices. The starting point is the :mod:`skeleton <pynta.model.cameras.skeleton>`, where the ``cameraBase`` class is defined. In this class all the methods and variables needed by the rest of the program are defined. This strategy not only allows to keep track of the functions, it also enables the subclassing, which will be discussed later.
+Therefore in :mod:`~pynta.model.cameras` is where we will develop classes that have always the same methods and outputs defined, but that behave completely different when communicating with the devices. The starting point is the :mod:`skeleton <pynta.model.cameras.skeleton>`, where the ``cameraBase`` class is defined. In this class all the methods and variables needed by the rest of the program are defined. This strategy not only allows to keep track of the functions, it also enables the subclassing, which will be discussed later.
 
 Having models also allow to quickly change from one camera to another. For example, if one desires to switch from a :mod:`Hamamatsu <pynta.model.cameras.hamamatsu>` to a :mod:`PSI <pynta.model.cameras.psi>`, the only needed thing to do is to replace::
 
@@ -52,14 +56,13 @@ The idea behind the experiment model is that it makes it very clear what the log
 
 View
 ----
-The View is, as the name suggests, where the GUI is defined. Since we defined all the logic of the experiment in a separate class, the View takes care of only triggering specific steps of the experiment and displaying the results. In principle, the only logic present in the view modules is only for aesthetic reasons. For instance, disable a specific button while a measurement is going on, etc. However, it should be the experiment model the one that avoids triggering two measurements if it is not possible, etc. That guarantees a lower-level safety.
+In the MVC patter, :mod:`~pynta.view` is, as the name suggests, where the GUI is defined. Since we defined all the logic of the experiment in a separate class, the View takes care of only triggering specific steps of the experiment and displaying the results. In principle, the only logic present in the view modules is only for aesthetic reasons. For instance, disable a specific button while a measurement is going on, etc. However, it should be the experiment model the one that avoids triggering two measurements if it is not possible, etc. That guarantees a lower-level safety.
 
-:doc:`pynta.view` is where the GUI lives. Within the module, you will also find :doc:`pynta.view.GUI`, in which the different widgets that make up the window are defined and another folder called designer, where the Qt Designer files are located. Adapting the looks of a program should start by looking into the ``.ui`` files, then checking the associated widgets in the ``GUI`` module, in order to connect the proper signals, etc. and finally modifying the main view class.
+:mod:`~pynta.view` is where the GUI lives. Within the module, you will also find :mod:`pynta.view.GUI`, in which the different widgets that make up the window are defined and another folder called designer, where the Qt Designer files are located. Adapting the looks of a program should start by looking into the ``.ui`` files, then checking the associated widgets in the ``GUI`` module, in order to connect the proper signals, etc. and finally modifying the main view class.
 
 
 .. toctree::
-   :maxdepth: 4
-   :caption: Contents:
+   :maxdepth: 1
+   :caption: PyNTA API
 
    pynta
-   modules
diff --git a/docs/developers/model/cameras/base_camera.rst b/docs/developers/model/cameras/base_camera.rst
@@ -0,0 +1,4 @@
+.. automodule:: pynta.model.cameras.base_camera
+    :members:
+    :undoc-members:
+    :show-inheritance:
diff --git a/docs/developers/model/cameras/basler.rst b/docs/developers/model/cameras/basler.rst
@@ -0,0 +1,4 @@
+.. automodule:: pynta.model.cameras.basler
+    :members:
+    :undoc-members:
+    :show-inheritance:
diff --git a/docs/developers/model/cameras/dummy_camera.rst b/docs/developers/model/cameras/dummy_camera.rst
@@ -0,0 +1,4 @@
+.. automodule:: pynta.model.cameras.dummy_camera
+    :members:
+    :undoc-members:
+    :show-inheritance:
diff --git a/docs/developers/model/cameras/hamamatsu.rst b/docs/developers/model/cameras/hamamatsu.rst
@@ -0,0 +1,4 @@
+.. automodule:: pynta.model.cameras.hamamatsu
+    :members:
+    :undoc-members:
+    :show-inheritance:
diff --git a/docs/developers/model/cameras/index.rst b/docs/developers/model/cameras/index.rst
@@ -0,0 +1,16 @@
+Camera Models
+=============
+.. automodule:: pynta.model.cameras
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+.. toctree::
+    :maxdepth: 1
+
+    base_camera
+    simulate_brownian
+    dummy_camera
+    basler
+    hamamatsu
+    psi
diff --git a/docs/developers/model/cameras/psi.rst b/docs/developers/model/cameras/psi.rst
@@ -0,0 +1,4 @@
+.. automodule:: pynta.model.cameras.psi
+    :members:
+    :undoc-members:
+    :show-inheritance:
diff --git a/docs/developers/model/cameras/simulate_brownian.rst b/docs/developers/model/cameras/simulate_brownian.rst
@@ -0,0 +1,4 @@
+.. automodule:: pynta.model.cameras.simulate_brownian
+    :members:
+    :undoc-members:
+    :show-inheritance:
diff --git a/docs/developers/pynta.model.daqs.rst → docs/developers/model/daqs/index.rst b/docs/developers/pynta.model.daqs.rst → docs/developers/model/daqs/index.rst
@@ -1,38 +1,25 @@
-pynta.model.daqs package
-========================
-
-Submodules
-----------
-
-pynta.model.daqs.NI module
---------------------------
-
-.. automodule:: pynta.model.daqs.NI
+Data Acquisition Cards Models
+=============================
+.. automodule:: pynta.model.daqs
     :members:
     :undoc-members:
     :show-inheritance:
 
-pynta.model.daqs.daq\_dummy module
-----------------------------------
+Available DAQS
+---------------
 
-.. automodule:: pynta.model.daqs.daq_dummy
+.. automodule:: pynta.model.daqs.NI
     :members:
     :undoc-members:
     :show-inheritance:
 
-pynta.model.daqs.skeleton module
---------------------------------
-
-.. automodule:: pynta.model.daqs.skeleton
+.. automodule:: pynta.model.daqs.daq_dummy
     :members:
     :undoc-members:
     :show-inheritance:
 
 
-Module contents
----------------
-
-.. automodule:: pynta.model.daqs
+.. automodule:: pynta.model.daqs.skeleton
     :members:
     :undoc-members:
     :show-inheritance:
diff --git a/docs/developers/model/experiments/fiber_tracking.rst b/docs/developers/model/experiments/fiber_tracking.rst
@@ -0,0 +1,4 @@
+.. automodule:: pynta.model.experiment.dispertech.fiber_tracking
+    :members:
+    :undoc-members:
+    :show-inheritance:
diff --git a/docs/developers/pynta.model.experiment.rst → docs/developers/model/experiments/index.rst b/docs/developers/pynta.model.experiment.rst → docs/developers/model/experiments/index.rst
@@ -1,45 +1,38 @@
-pynta.model.experiment package
-==============================
-
-Subpackages
------------
+Model for Experiments
+=====================
 
 .. toctree::
+    :maxdepth: 1
+    :caption: Available Experiments
 
-    pynta.model.experiment.nano_cet
-
-Submodules
-----------
+    fiber_tracking
+    np_tracking
 
-pynta.model.experiment.base\_experiment module
-----------------------------------------------
+.. automodule:: pynta.model.experiment
+    :members:
+    :undoc-members:
+    :show-inheritance:
 
 .. automodule:: pynta.model.experiment.base_experiment
     :members:
     :undoc-members:
     :show-inheritance:
 
-pynta.model.experiment.publisher module
----------------------------------------
-
 .. automodule:: pynta.model.experiment.publisher
     :members:
     :undoc-members:
     :show-inheritance:
 
-pynta.model.experiment.subscriber module
-----------------------------------------
-
 .. automodule:: pynta.model.experiment.subscriber
     :members:
     :undoc-members:
     :show-inheritance:
 
-
-Module contents
----------------
-
-.. automodule:: pynta.model.experiment
+.. automodule:: pynta.model.experiment.config
     :members:
     :undoc-members:
     :show-inheritance:
+
+
+
+
diff --git a/docs/developers/model/experiments/np_tracking.rst b/docs/developers/model/experiments/np_tracking.rst
@@ -0,0 +1,4 @@
+.. automodule:: pynta.model.experiment.nanoparticle_tracking.np_tracking
+    :members:
+    :undoc-members:
+    :show-inheritance: