2014 Winter Project Week:IntegrationOfContourObject
From NAMIC Wiki
Home < 2014 Winter Project Week:IntegrationOfContourObject
Contour representations stored in the Contour object
Key Investigators
- Queen's: Csaba Pinter, Andras Lasso
- Isomics: Steve Pieper
- ???
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?
