Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • M MSOT_Analysis_Pipeline
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 22
    • Issues 22
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • PIRL
  • MSOT_Analysis_Pipeline
  • Wiki
  • Pipeline
  • Features

Last edited by Devin OKelly Sep 19, 2019
Page history

Features

The pipeline is intended to be structured so that the input/output of each block is consistent as a matter of type for that block. This helps to preserve the so-called 'functional programming' paradigm we seek to maintain.

Input-Output Sets

Prefilter

  • Input: Raw MSOT data panel (for us, 2030 x 256)
  • Output: Filtered MSOT data panel of the same size as input

Reconstruction

  • Input: Raw or filtered MSOT data panel (for us, 2030 x 256)
  • Output: Reconstructed MSOT image object, diagnostic information, metadata.

Collating

  • Input: Image objects in arbitrary order
  • Output: Properly ordered MSOT reconstructions.

Spectral Unmixing

  • Input:
  • Output:

Photoacoustic Simulations

  • Input:
  • Output:

Modules should be able to handle cases where they are supposed to 'carry forward' the metadata from a previous step.

The pipeline object itself is composed of several modules, and should be able to provide an estimate of how much space the processing will take up.

MSOT datasets are collected in a tree-like manner, cycling over various levels according to the following: Scan-Run-Z-Repetition-Wavelength-Shot. The number of branches at each level of the tree is predetermined before the scan is acquired, and is recorded in the metadata. Shots may be averaged as they are acquired, in which case the shot level has just one leaf. This case may be detected by checking the metadata.

A few specific data formats are currently planned, in order to improve reproducibility.

Reconstruction Datasets

  • Reflect all of the raw data that made them, including the metadata. This should ordinarily be done by reference, but for smaller datasets it may be desirable to be able to compare the reconstructions against the raw data. Because each reconstruction might be pooled from several shots, this case should be taken with special care. Each reconstruction should inherit the acquisition timestamp of its parent, as well as including a timestamp of when it was reconstructed.
  • The overall reconstruction should have metadata affixed to it. This might include a dump of the code which processed it.

MSP Datasets

  • Should behave similarly to the reconstruction datasets, but each MSP should directly list the indices of the reconstructions that led to it. The MSP should additionally be able to, by reference, determine which raw scans led to it.

Inheritance Hierarchy

All pipeline modules should inherit from their respective superclasses, which should all in turn inherit from Module. Module is intended to be the second-coarsest level of pipeline organization

Clone repository
  • *The Big Picture
  • API
    • ReconSystem
  • Imaging Theory
  • MSOT
    • Data Organization
    • Engineering
    • Image Processing
  • Photoacoustics
    • Physics
  • Pipeline MATLAB
    • Getting Started
  • Pipeline
    • Features
    • Spectral Unmixing
  • Home
  • physics lite
  • post processing
  • scan processing
  • testing