Difference between revisions of "2014 Winter Project Week:IntegrationOfContourObject"

From NAMIC Wiki
Jump to: navigation, search
(Page created)
 
Line 43: Line 43:
 
** Possible merging of those?
 
** Possible merging of those?
 
* Correct way of implementation: storage node, displayable manager etc.
 
* 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?
  
 
</div>
 
</div>
Line 49: Line 50:
 
*
 
*
 
</div>
 
</div>
 +
 
== Reference ==
 
== Reference ==
 
* [[2013_Summer_Project_Week:Patient_hierarchy|Summer Project Week page]]
 
* [[2013_Summer_Project_Week:Patient_hierarchy|Summer Project Week page]]

Revision as of 16:05, 20 December 2013

Home < 2014 Winter Project Week:IntegrationOfContourObject

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?

Progress

Reference