Documentation/Labs/Segmentations

Motivation

• See File:20160526 Segmentations.pptx for motivation, features, and details of the infrastructure.
• For further details see original project page, 2014 NA-MIC week contours breakout session page, 2015 NA-MIC week segmentations breakout session page
• Main issues to solve
  • Automatic conversion is preferred because of user interaction (and knowledge) need
  • Relationships between the converted objects need to be preserved to be able to determine their origin and identity
  • When a segment representation changes, the others must follow so that no outdated data is used
  • The structures (referred to as segments) that belong together must be converted together to preserve coherence

Features

• New Segmentation MRML node that can contain multiple segments and multiple representations for segments
• Automatic conversion between representations
• Visualization of lablemap and model representations simultaneously in 2D or 3D views
• Copy/move segments between segmentations
• Import/export representations into labelmap ormodel nodes
• Drastic improvement in memory usage compared to labelmaps and conversion speed compared to Contours (the previous SlicerRT mechanism for the same purpose, predecessor of Segmentations) due to only allocating the effective extent
• Segment Editor module that can edit segmentation labelmap representations the same way as Editor module currently can Assembla ticket #757

Design and implementation

• New Segmentation MRML node that can contain multiple segments and multiple representations for all segments
  • Each segment has the same set of representations. This means that if segments are copied/moved between segmentations, then conversion will take place if possible (if not then copy will fail)
  • Supported representations (initially) are
    • Binary lablemap (vtkOrientedImageData)
    • Closed surface (vtkPolyData)
    • Planar contour (vtkPolyData)
  • Additional representations can be added, such as Ribbon model or Fractional labelmap that can be found in SlicerRT
• Conversion between representations are driven by a conversion graph in which the nodes are the representations and the edges are conversion rules
  • When converting with the default method (Create: 'Default' button), then the path with the lowest cost is used (rules have a cost field that gives a ballpark value for the conversion cost)
  • Representation types can be defined by registering conversion algorithms (rules) that specify their source and target representations, and an estimated cost metric
• Master representation
  • Privileged representation type. Can be any of the available representations, but usually it's the original representation of the data (binary labelmap for editing, planar contour for RT)
  • Properties: (a) all conversions use it as source, (b) when changed all other representations are invalidated, and (c) it is the representation that is saved to disk
  • Using the proper master representation ensures that no information is lost, which is crucial to avoid discrepancies that can never be solved when data is permanently lost in conversion

Segmentations module, Visualizing model in 2D and 3D, also showing merged labelmap in 2D

Class diagram

Code

Segmentation modules is part of the SlicerRT extension during development and will be moved to Slicer core when the developments are complete:

• SlicerRT trunk modules:
  • SegmentationCore containing the base VTK container and conversion classes: https://subversion.assembla.com/svn/slicerrt/trunk/SlicerRt/src/SegmentationCore/
  • Segmentations module: https://subversion.assembla.com/svn/slicerrt/trunk/SlicerRt/src/Segmentations/
• Original topic branch in SlicerRT: https://subversion.assembla.com/svn/slicerrt/branches/SegmentationObject/

Slicer core changes

https://github.com/SlicerRT/Slicer/tree/segmentation-node

Future features

• CLI support for vtkMRMLSegmentationNode

Issues

• Opacity spinbox does not update until done

Topics to discuss

• Ability to support potential use cases
  • Huge number of segments vs memory (compressed representation and/or on-demand loading)
  • SceneViews (states are defined basically by display node visibility on/off)
  • FiberTract support
• Partial SH visibility for segmentation that tracks segment visibility? What happens when the segmentation visibility is set? All show/hide?

Notes

• Module page

vtkMRMLLabelMapVolumeNode integration

Slicer core updated, see this commit: https://github.com/Slicer/Slicer/commit/e4ffa1f6dcfafc1ca8f0015ecf02a0c23a8bd503

Module update instructions

Module selectors that expect a labelmap volume should be changed

From:

   self.outputSelector.nodeTypes = ( ("vtkMRMLScalarVolumeNode"), "" )
   self.outputSelector.addAttribute( "vtkMRMLScalarVolumeNode", "LabelMap", 1)

to

   self.outputSelector.nodeTypes = ["vtkMRMLLabelMapVolumeNode"]

From:

   self.outputSelector.nodeTypes = ( ("vtkMRMLScalarVolumeNode"), "" )
   self.outputSelector.addAttribute( "vtkMRMLScalarVolumeNode", "LabelMap", 0)

to

   self.outputSelector.nodeTypes = ["vtkMRMLScalarVolumeNode"]

• Note: This changes the value assigned to nodeTypes from a Tuple with 2 elements to a List with only one element. Additional information on the Tuple syntax can be found here: https://wiki.python.org/moin/TupleSyntax

CLI modules

CLI modules are not impacted. No change is needed in interface definition XML files or in the module implementation.

Switch between scalar/labelmap volume

See Documentation/Nightly/FAQ#How_to_switch_between_scalar.2Flabelmap_volume_.3F