Difference between revisions of "2015 Winter Project Week Segmentations Breakout"

From NAMIC Wiki
Jump to: navigation, search
 
(2 intermediate revisions by 2 users not shown)
Line 10: Line 10:
 
** Background, objectives
 
** Background, objectives
 
** Design, issues, and future work
 
** Design, issues, and future work
−
** GUI and features
 
 
* Labelmap node class - integration to Slicer core
 
* Labelmap node class - integration to Slicer core
 
* Discussion on the features and implementation details
 
* Discussion on the features and implementation details
Line 20: Line 19:
 
=Links=
 
=Links=
 
* [[2015_Winter_Project_Week:Segmentations|Segmentations project page]]
 
* [[2015_Winter_Project_Week:Segmentations|Segmentations project page]]
 +
* Main page for Segmentations project: https://www.assembla.com/spaces/slicerrt/wiki/Segmentation
 +
 +
=Notes=
 +
* Important use cases
 +
** Huge number of segments (Bill, Brad, etc.)
 +
*** Issue: efficient storage and processing
 +
*** Fire segment-specific events from segmentation node (with segment ID)
 +
*** Load subsets of data based on spatial constraints in an on-demand fashion
 +
**** Need to support geometrical decision functions by default (contain, overlap, etc.), maybe even on the CLI level
 +
*** Storage of at the moment non-displayed segments in a compressed way?
 +
** Tractography (Nicole): ask Alex or Lauren
 +
** SceneViews
 +
*** They are defined by display node on/off states basically
 +
* Relevant existing implementations / interfaces
 +
** Similar notions in ITK as the proposed labelmap types: LabelImage ~ LabelMap, LabelMap ~ RLE (ImageStencil)
 +
** VTK6 color table additions
 +
** vtkCompositeDataset, vtkMultiBlockDataset: both composite objects already defined in VTK
 +
* Design alternatives
 +
** vtkSegment subclass of vtkDataObject or vtkCompositeDataset or vtkMultiBlockDataset
 +
** Explicit ID for segments: need to uniquely identify segments
 +
*** Segmentation vector index not good because of its non-unique nature (remove, etc.) (Jim)
 +
*** Tags are one option but not too explicit
 +
*** Need to unambiguosly link segment to color table
 +
** Color, opacity stored elsewhere than the segment
 +
*** Color information is needed to be stored at at least two locations (segment, color table of merged labelmap, ?)
 +
*** Display node? Segment could still store a "default" color (Andras)
 +
** Volume reference in segmentation could be FrameOfReferenceUID (transforms would need to support that anyway; ensuring equality is the most important so UID is just as good for this as matrices or something else)
 +
** Extending CLI to be able to tell the desired representation will be necessary (Jim)
 +
*** Similar to existing ContourSelectorWidget?
 +
* Encoding antology (hierarchies, colors, groupings) is important (Nicole, Andrey)
 +
** Tags can be used, or something more explicit, need ideas
 +
* Other ideas
 +
** Compute/show estimated data loss of conversion

Latest revision as of 01:43, 7 January 2015

Home < 2015 Winter Project Week Segmentations Breakout

Back to Winter project week 2015 Agenda

Introduction

  • Purpose: Discuss present and future of Segmentation object support
  • Time: Tuesday 3:15 - 4:00
  • Participants: Csaba Pinter, Andriy Fedorov, Steve Pieper, Jc, Andras Lasso (via skype) and everybody who is interested

Agenda

  • Present latest plans and progress regarding Segmentation object support (Csaba) slides
    • Background, objectives
    • Design, issues, and future work
  • Labelmap node class - integration to Slicer core
  • Discussion on the features and implementation details
  • Come to an agreement
    • Features and architecture
    • Integration
    • Tentative roadmap

Links

Notes

  • Important use cases
    • Huge number of segments (Bill, Brad, etc.)
      • Issue: efficient storage and processing
      • Fire segment-specific events from segmentation node (with segment ID)
      • Load subsets of data based on spatial constraints in an on-demand fashion
        • Need to support geometrical decision functions by default (contain, overlap, etc.), maybe even on the CLI level
      • Storage of at the moment non-displayed segments in a compressed way?
    • Tractography (Nicole): ask Alex or Lauren
    • SceneViews
      • They are defined by display node on/off states basically
  • Relevant existing implementations / interfaces
    • Similar notions in ITK as the proposed labelmap types: LabelImage ~ LabelMap, LabelMap ~ RLE (ImageStencil)
    • VTK6 color table additions
    • vtkCompositeDataset, vtkMultiBlockDataset: both composite objects already defined in VTK
  • Design alternatives
    • vtkSegment subclass of vtkDataObject or vtkCompositeDataset or vtkMultiBlockDataset
    • Explicit ID for segments: need to uniquely identify segments
      • Segmentation vector index not good because of its non-unique nature (remove, etc.) (Jim)
      • Tags are one option but not too explicit
      • Need to unambiguosly link segment to color table
    • Color, opacity stored elsewhere than the segment
      • Color information is needed to be stored at at least two locations (segment, color table of merged labelmap, ?)
      • Display node? Segment could still store a "default" color (Andras)
    • Volume reference in segmentation could be FrameOfReferenceUID (transforms would need to support that anyway; ensuring equality is the most important so UID is just as good for this as matrices or something else)
    • Extending CLI to be able to tell the desired representation will be necessary (Jim)
      • Similar to existing ContourSelectorWidget?
  • Encoding antology (hierarchies, colors, groupings) is important (Nicole, Andrey)
    • Tags can be used, or something more explicit, need ideas
  • Other ideas
    • Compute/show estimated data loss of conversion
Retrieved from "https://www.na-mic.org/w/index.php?title=2015_Winter_Project_Week_Segmentations_Breakout&oldid=88421"