Difference between revisions of "Documentation/Labs/ImageStacks"
From Slicer Wiki
Line 60: | Line 60: | ||
* option: put dicom files in database for reuse | * option: put dicom files in database for reuse | ||
* option: use low-res as visualization proxy but use fill res for processing | * option: use low-res as visualization proxy but use fill res for processing | ||
+ | |||
+ | == Work in Progres == | ||
+ | |||
+ | * https://github.com/pieper/SlicerImageStacks |
Revision as of 20:03, 16 October 2019
Home < Documentation < Labs < ImageStacksContents
Background
Image stacks are generated in a lot of scenarios, like microscopes, microCT, and other non-medical sources.
Examples are like:
directoryPath = '/Volumes/SSD2T/data/SlicerMorph/Sample_for_steve/1326_Rec' pathFormat = '%s/1326__rec%04d.png'
Common issues
- Data is really grayscale, but encoded using jpg or other color format
- Data may be large and needs to be cropped or resampled for use
- Data will not have any consistent metadata
- pixel / slice spacing
- orientation (e.g. mapping to anatomical coordinates)
- acquisition time, equipment, operator, etc
- Only a subset of data may actually be wanted (ROI or subsampled volume)
Current reader
Delegates to ITK via vtkITKArchetype mechanism. Lots of hidden logic to guess possible mapping from image files to volumes.
- Guesses filename pattern, which can easily fail
- Creates vector volume for RGB and user must manually convert to scalar
- Reads full volume and then must crop or resample
- Can be slow to read / decompress large files
Available readers
- vtkPNGReader
- itk image IO
- Qt Image
- PIL / PILLOW python packages (not currently bundled in Slicer, but pip installable)
- QWebEngine
Desired properties
- fast, ideally multithreaded
- compatible with multiple file formats (at least jpg, tiff, bmp, png)
- clean slicer integration
- support arbitrary file naming conventions with different ways of mapping names to volumes or other structures
- ability to map anatomical coordinates (e.g. click on nose, right ear, and top of head)
- ability to convert to scalar and/or crop/resample while reading
- store pyramid encoded volumes for later reuse
- use a single-file format for simplicity (avoid creating even more single slice image files)
- store metadata for later reuse
- allow scripted use outside slicer
- use reference volume or ROI to define desired geometry (e.g. reuse crop volume logic)
- handle greater than 8 bits per pixel if the source format supports it
Options
Implementation
- stand-along processing script with command line options -- too difficult for users in general, no interactive feedback
- plugin for Add Data module that exposes some options -- not enough room for gui, not interactive
- Independent importer module -- probably the best option with reusable logic
Features
- store pyramid files in nrrd or some minimal dicom
- option: put dicom files in database for reuse
- option: use low-res as visualization proxy but use fill res for processing