Skip to content

Segmentation plans archive

Jump to bottom
Sunderlandkyl edited this page Sep 21, 2017 · 1 revision

Design (before implementation started)

  • New Segmentation node type

    • defines some common properties, such as a common raster (position, orientation, size, resolution) in Slicer RAS; colormap(s), dictionaries
    • defines some common methods, such as provide a merged representation containing all segments
    • manages storage (many segments may be stored more efficiently in a centralized way, e.g., in a single 4D volume instead of many separate 3D volumes)

  • One Segmentation node can store multiple Segment objects

    • maybe allow attaching tags ("segment tag") for easy grouping: hierarchy nodes only support node-level operation and they are also quite complicated and inefficient; tags could be organized in multiple hierarchies, sophisticated filtering rules could be created quite simply

  • Conversion and caching logic could be implemented in pure VTK, as it is done similarly for forward/inverse transform computation and caching in vtkGeneralTransform.

  • Representations: one master (editable) representation, all the others would be generated automatically; all segments in a segmentation object have the same master representation type!

    • Segmentation:

      • merged binary non-overlapping segments stored in a single volume with indexed colormap (current labelmap volume) - drop this (keep only as an export/import format)?
      • merged RGBA volume with all the per-segment volumes composited with their color
      • master representation type

    • For each segment:

      • continuous (non-binary) per-segment volume
        • may be compressed and/or multi-resolution but then: the complete display pipeline has to be implemented to work directly on this special representationand additional compression/decompression would be needed for editing
        • VTK stencil is an example for compressed data storage and processing, but it's only binary data and only a few operations are implemented
      • set of 2D contours: from RT structure sets or from other user-defined contours on slices - contours may be open
      • closed 3D surface: needed for nice 3D rendering
      • allow adding more representations for additional storage as compressed, lower-resolution, etc. (e.g., for real-time update of 3D rendering of the segmentation results)

Options:

A: Keeping compatibility of Segmentation node (parent is vtkMRMLScalarVolumeNode) just add new features, do many minor, mostly backward-compatible steps (phases below). Pro: no duplication of infrastructure, no big, breaking changes. Con: frequent changes in core needed, design may be more complex due to backward compatibility and some non-backward-compatible changes may be needed sometimes anyway; the core will keep changing (may be instable or not always fully functional) for a long period of time. -> This will be implemented

B: Completely new Segmentation node (parent is vtkMRMLDisplayableNode), new mechanisms are developed in parallel with existing ones: new Editor module ("Segmenter", effects can be made compatible with both the Editor and Segmenter), new display managers, etc. Once the new Segmentation infrastructure is fully functional, the old labelmap-based infrastructure will be made deprecated. Pro: old infrastructure fully functional while the development is in progress. Con: one big (risky) switch, duplicate maintenance/development of modules until the old infrastructure is not removed from the core.

C: In between B/C: Completely new Segmentation node, convert existing modules one-by-one to use the new segmentation node instead of the old labelmap. Pro: no duplication of modules. Con: temporary interoperability problems between modules that support labelmap vs. segmentation.

Short-term questions:

  • Is frequent integration (changes in the core) acceptable? (option A vs B)
  • Can we create a new class for storing segmentation? (vtkMRMLLabelmapVolume: parent is vtkMRMLScalarVolume, no methods are overriden, just a new type to allow filtering in node selectors; SegmentationVolume: parent is vtkMRMLLabelmapVolume, extends it internally with new features) - for options A, C -> Yes
  • How to handle structure names, colors, and grouping; currently there are colormaps and model hierarchy in Slicer and SNOMED dictionary (supported by DICOM) - we may need to come up with something that combines all these

Option A:

Phase 1:

  • vtkMRMLLabelmapVolume subclasses vtkMRMLScalarVolume, vtkMRMLSegmentation subclasses vtkMRMLLabelmapVolume (for backward compatibility reasons), get rid of LabelMap flag
  • Decide if labelmap or not by class type check and not labelmap attribute (node selectors, CLI, ...)
  • Generate merged labelmap from segments on every Modified event, needs mechanism to resolve overlaps
  • Segmentations module: edit properties (similar to volumes module), import/export, conversions, etc.
  • Displayable manager for 2D and 3D views
  • Segmentation logic class: conversion algorithms
  • Volumes module: remove labelmap related features/widgets
  • SlicerRT: Contour subclasses Segmentation

Phase 2:

  • Editor

    • Writes on segments
    • Editor plugins "Paint over"mechanism needs to be updated (existing labels are not stored in the output volume)
    • Per-structure volumes box (HelperBox.py) becomes main widget (Merge volume -> Segmentation, Per-structure volumes -> Segments)

  • Surface models category

    • Model to labelmap -> Model to segmentation
    • Model maker -> Segmentation to model?
      • Conversion parameters moved to Segmentations
      • Smoothing etc. implicitly fixed by non-binary volumes
    • ...

Phase 3:

  • Editor

  • CLI

    • Allow specification of required representation (merged labelmap, per-segment volumes - pass as a 4D nrrd image), or an extra flag in xml: 'OverlapEnabled'
    • In other cases create merged volume (compatibility)

  • SlicerRT

    • ContourSet -> Segmentation, Contour -> Segment
    • ...
Clone this wiki locally