2014 Winter Project Week:IntegrationOfContourObject

• 

  Projects List

• 

  Contour representations stored in the Contour object

• 

  Contours module UI (for conversions)

Key Investigators

• Queen's: Csaba Pinter, Andras Lasso
• Isomics: Steve Pieper
• Segmentation object project participants?

Project Description

Objective

Handling of contours is a quite common task, however, the current tools are not optimal in doing it conveniently and correctly. The shortcomings are:

• The representations are not bound together, only the name chosen by the users may indicate that they represent the same contour
• Interaction-heavy conversion from one representation to another
• Difficult conversion of multiple contours
• Ensuring the same color is not trivial

SlicerRT provides a Contour MRML object and module for quite some time, and it proved really useful. As the notion of contours loaded in one representation and being required for processing in another is not an RT-specific thing, we propose integration of this Contour object in the Slicer core to benefit others working with contours. The currently supported contour representations are:

• Ribbon: Directly created from the 2D planar contours found in DICOM
• Labelmap: Common labelmap object with 0 as a background and a unique (in context, such as an RT structure set) foreground index; The color is provided by a color table automatically generated from the colors found in the DICOM context (RTSS)
• Closed surface model: Nice model, mainly for visualization

The features provided by the Contour MRML object:

• Automatic conversion: if the programmer requests a representation and it doesn't exist, it is automatically converted
• Automatic transforming of all representations if one is transformed
• Invalidate other representations when one is changed (e.g. labelmap edited in Editor)

Features of the Contours module:

• Bulk conversion of structure set
• Set conversion options: reference volume (automatically selected if DICOM provides one), oversampling factor, target reduction factor

Approach, Plan

• Explore all possible
  • Input types (DICOM RTSS, Segmentation Object, etc.)
  • Use cases
• Discuss how the new Contour object can co-exist with the current set of tools
  • Possible merging of those?
• Correct way of implementation: storage node, displayable manager etc.
• What would be the right way to do this at the DICOM level? That is, shouldn't we really be defining conversions from contour to segmentation object to surface model object?

Progress

• Presented the idea in meetings (Steve, Alex, Jayashree, Andriy)
• The Contour object looks useful and convenient, integrating in the core is desirable
  • Redundant modules
    • Identify modules that become redundant with this move (ModelToLabelmap, ModelMaker, etc.)
    • Make sure all functions of these are accessible from the Contours module
    • Phase out these modules
  • CLIs theoretically supported (through the Contour selector widget by specifying a representation type and having the CLI load the representation directly)

Reference

• Contours DisplayableManager and StorageNode SlicerRT ticket: #446
  • Related ticket: #407
• Contours CLI integration SlicerRT ticket: #165
• Contours module source code (module UI, Contours MRML, conversion utilities, Subject hierarchy plugin)