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 (multiple segment per node and external (subject) hierarchy)
    • 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

Meeting minutes (Rankin)

• Re-try deriving the contour from scalar volume node
• Contour name does not represent the concept
  • SegmentationObject decided as new name -- later
• Instead of contour, improve scalar volume node <Invalid with new design>
  • Poly data can be stored in display node
• Contours really are segmentation objects
  • DICOM segmentation object
  • http://medical.nema.org/dicom/2013/output/chtml/part03/sect_A.51.html
• QIICR
  • Andrey working with segmentation object
  • Meet with Andrey to confirm and develop path forward
  • Andrey has written read/write for DICOM SO to labelmap
  • See structure reporting module
• Integration into Slicer core
  • Debate about whether integrating worth it
    • Yes, after new design implemented and tested
• Fuzzy boundary could be supported by segmentation object
  • Volume rendering segmentation currently ugly, doesn't have to be
  • Editor tools could produce fuzzy boundaries aka brush tool
• How to manage CLI
  • If a CLI wants labelmap out of contour, we have to determine what it gets
    • If a contour contains many vtkImageData or vtkPolyData, how do we let the user know which one got sent in
  • CLI that receives it could have to have some logic to pull out information
    • This would mean that CLIs would have to become contour aware
  • If the segment is a polydata, we can autoconvert to labelmap
  • If not told how to get multi label volume, then all segments could be merged into one labelmap
  • If specified, could be outputted as multiple segments
  • (this is all for when an existing CLI wants a labelmap, and we pass it a contour)
  • (based on the assumption that multiple labels per contour, as opposed to now)
  • (and segments with fuzzy boundaries)
• David Clunie
  • Get more information about DICOM SO and DICOM RT to see which direction DICOM is thinking
• Is it possible to have an abstraction in slicer that represents both RTSS and DICOMSO
  • Yes, just different import/export
• In order to represent DICOMSO in image data, have to have 1 component per segmentation
  • vtkPolyData is possible, one cell per segmentation
• Should segmentation object represent many segments, or one-to-one?
  • What is workflow of segmentation objects? Is it common to operate on a single contour?
    • Short answer, both workflows are needed
    • Design is to have a segmentation object contain 0..N segments, with splitting/merging of SO
• What is the new naming convention?
  • vtkMRMLSegmentationNode
• What is the new design?
  • vtkMRMLSegmentationNode
    • container< pair<vtkImageData*,vtkPolyData*> >
    • Split
    • Merge
    • Depending on DICOM SO master representation, one of each pair will be designated master
      • Other representation can be converted on demand
• Discussion on use cases:
  • Thresholding might create 10,000+ items, if those are nodes, crash and burn
  • in that case, one node holding many items would be best
  • use case frequency should determine design choice
  • hierarchy of segments important?
  • Collect use cases to determine optimum design
• Discussion of design after discussion of use cases:
  • split seg object into N seg objects
  • merge N seg objects into a seg object
  • segmentation node contains N segments