Skip to content

Requirements

Jump to bottom
Chris Meyer edited this page May 17, 2022 · 3 revisions

Describes the requirements for the Nion Swift project.

Requirements Preamble

Requirements should be necessary, attainable, and verifiable; and written in clear concise sentences.

Requirements should only state what the software is supposed to do in terms of functional and non-functional requirements and use cases.

This is not a design document.

When referring to an item in this requirements document, please specify the Git commit hash and the reference within this document.

Objectives

  1. A tool for data acquisition, processing, analysis, and presentation.
  2. A framework on which to build further domain specific applications.
  3. Open Source. Based on Python. Runs on Linux, Windows, Mac.
  4. Play nicely with Python libraries: numpy, scipy, h5py, hyperspy, matplotlib, jupyter.

Functional Requirements

Model

Data

  1. User should be able to track data organized into a variety of formats, including 1d, 2d, and 3d data, zero or more collection dimensions, and a time/sequence dimension.
  2. User should be able to calibrate all dimensions (including intensity) of the data.
  3. User should be able to organize data on a variety of axes: date, name, site, instrument, session, sample, sample area, acquisition set, etc.
  4. User should be able to track primary/master data and derived/computed data.
  5. User should be able to have data sets comprised of multiple related pieces of data including primary and derived data.

Graphics

  1. User should be able to add graphics overlays to displayed data, based on the coordinate system of the display.
  2. User should be able to make points, lines, rectangles, ellipses, polygons, and curved regions on raster data.
  3. User should be able to make channels and intevals on line plot data.
  4. User should be able to make masks.

Objects

  1. User should be able to track other objects related to data, such as configuration for a specific custom app.

Computations

  1. User should be able to configure computations to maintain live connections between data and objects.

Storage

  1. User should be able to store data and objects on disk organized into a folder structure or as a single file (e.g. HDF5).
  2. User should be able organize storage according to a grouping such as a session.
  3. User should be able to import/export basic data from/into a variety of formats.

User Interface

Data Display

  1. User should be able to display data in basic forms: raster, line plots, x-y plots.
  2. User should be able to display data with specific composition types: composite raster, multiple line plot.
  3. User should be able to reduce multi-dimensional data (e.g. spectrum-image) to basic form (1d, 2d, xy) and display.
  4. User should be able to see live display of data at cursor position.
  5. User should be able to have multiple views of the same data (e.g. spectrum-image).

Raster Images

  1. User should be able to control the mapping of data from raw data to RGB through the use of display limits, color tables, and similar.

Line Plots

  1. User should have option to display linear or logarithmic vertical scale.

Data Browsing

  1. User should be able to browse each piece of data individually, by list and by grid.
  2. User should be able to browse sets of data as single entities.
  3. User should be able to browse computed items inputs and outputs.
  4. User should be able to browse related items from a set.
  5. User should be able to filter data by criteria such as date or title.
  6. User should be able to browse objects and see their relationships to other data and objects.
  7. User should be able to form custom groupings of data and objects.

Data Acquisition

  1. User should be able to configure optimized display of live acquisition data.
  2. User should be able to control acquisition according to device (e.g. play/pause/stop).

Data Recording

  1. User should be able to record acquisition data.

Inspectors

  1. User should be able to edit data slicing and conversion, display options, calibration, and other details via an inspector UI.
  2. User should be able to see basic statistics and histogram via a UI.
  3. User should be able to view and edit metadata via a UI.

Tools

  1. User should be able to use tools to make graphics and adjust displays.

Exporting

  1. User should be able to export data via a dialog and choose the naming scheme for exported files.

Notebook (future)

  1. User should be able to record important events in an ongoing notebook.

Data Reporting (future)

  1. User should be able to generate reports in various formats including PDF, SVG, HTML, PowerPoint.

Scripting

  1. User should have a script console with access to data and objects.
  2. User should have some form of interactive script that can do a question and answer style interaction.

Data Acquisition and Device Control

  1. User should be able to acquire data streams from devices and display the data in real time.
  2. Maximum latency target is 100ms. Throughtput target (2k x 2k minimally processed image) should be 20 fps.

Extensions

  1. User should be able to extend software with additional devices, processing, and UI.
  2. User should be able to run code in a thread and update progress on UI.

Use Cases

User does basic acquisition from multiple devices, exporting data to individual files when finished.

User visits lab and wants to take their entire acquisition session when finished.

User wants to display live EELS spectrum with a ZLP peak width computed and displayed for fine tuning.

User wants to analyze alignment of microscope using an array of five acquired images, update the settings on the microscope, and display the alignment images in a composite display.

User wants to display live EELS with an edge selected and background and subtracted signal also displayed. They want to have multiple edges selectable and overlayable.

User has a spectrum image and wants to align the zero loss peak and then background subtract a specific edge for the entire spectrum image.

User acquires a context image and a few spectrum image sets from different regions consisting of a high resolution sub-scan in multiple channels, a spectrum image, and the sub-scan readout during the spectrum image in multiple channels.

User wants to know which spectrum image sets came from a particular context image.

User finds interesting sample location, acquires context image, then a spectrum image, then another context image to compare damage after the spectrum image.

User wants to track items in a library file by user and data set.

User wants to track items in a library file by sample and data set.

User has a sequence of images and wants to compare (via cross correlation) one image to the others.

Clone this wiki locally