2014 Project Week Breakout Session: Contours

Back to Summer Project Week 2014 Agenda

Introduction

• Purpose: Present purpose and current state of Contours data type in the SlicerRt extension with the hope of integrating them into the core, come to agreement in technical details and action plan
• Time: Wednesday 1:00-2:30
• Participants: Adam Rankin, Csaba Pinter, Andras Lasso, Steve Pieper, JC, Nicole, and everybody who is interested

Agenda

• Present current state of contours (Adam) slides
• Discussion on the features and implementation details
  • Change propagation - what happens when a repr. is changed?
    • Delete other repr. if nothing references them (ref. count)
    • Re-convert those that are used
  • Issue of the original ROI contour points
    • Should we try to update it if we change some other repr?
    • Is it just another repr or it's the "ground truth"?
  • 2D display of contour
    • Add contour object to the slice view control drop-down combobox
    • Filled (labelmap), outline (model slice intersection)
  • CLI contour support
    • Contour selection widget
    • Representations
  • Storage
    • Only save source representation or all?
    • Representations in one file or more?
    • In what format? Concealed standard files (different extension) or standard files with attributes specifying contour as target object?

Discussion

• See contours project page
• See winter discussion page

Meeting minutes (Pinter)

• Supporting information
  • Treatment planning systems and other workstations work with labelmaps, but display contours
  • Segmentation object is the new standard for storing this kind of data, it is versatile, supporting it is desirable and necessary
  • Is RTSS (structure set) going to be improved? Yes, according to David Clunie, a major overhaul is on its way
    • The reason for this question is that RTSS is very basic (stores list of list of points) and does not accommodate lot of use cases (partial coverage, structures with holes, etc.)
  • One displayable MRML node can have multiple display nodes (e.g. tensors)
• Main question #1: Naming
  • Contour -> No, it implies 2D outlines
  • Segmentation -> Yes, but only if the node contains multiple "segments" (VOIs, organs)
  • Structure -> No, means this concept only in RT
• Main question #2: Representation
  • Improved labelmap: RLE, multiple structures, have the polydatas in display nodes -> No, we need poly datas as core representation, not just for display
  • SegmentationNode contains one segment, or multiple segments?
    • More
      • CLI support? Creates multiple labelmaps? New CLI type
      • Storing image data: multi-component vtkImageData? Do we want to constrain segments to one geometry and dimensions? -> No, DICOM seg. obj. allows segments to be in different frames of reference
      • Funding purposes: the closer to the DICOM standard in the internals, the better
  • Answer: Both
    • vtkMRMLSegmentationNode will contain a vector of pairs of labelmaps and polydata, indicating the "master" representation (which was loaded; useful to avoid series of lossy conversions). This supports use cases where a huge number of segments have to be handled
    • At the same time, Subject hierarchy can maintain hierarchy of Segmentations in the way it is currently done in SlicerRT's Contour node. This way a Segmentation contains one segment. Supports use cases where there are not a lot of segments, but relationships are important
    • Split and merge of Segmentations (conversion between the first and second case above) is needed
    • Color table supports both use cases
  • Partial coverage will be needed (float labelmap image data)
• Other questions
  • QIICR segmentation object to use Contours (Segmentation) on the long run? => ask Andriy