Difference between revisions of "2015 Winter Project Week Segmentations Breakout"
From NAMIC Wiki
(→Agenda) |
(→Links) |
||
(3 intermediate revisions by 2 users not shown) | |||
Line 8: | Line 8: | ||
=Agenda= | =Agenda= | ||
* Present latest plans and progress regarding Segmentation object support (Csaba) [[Media:Segmentation_NAMIC2015W_Pinter.pptx | slides]] | * Present latest plans and progress regarding Segmentation object support (Csaba) [[Media:Segmentation_NAMIC2015W_Pinter.pptx | slides]] | ||
− | ** | + | ** Background, objectives |
− | + | ** Design, issues, and future work | |
− | ** Design | ||
* 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 BreakoutBack to Winter project week 2015 Agenda
Contents
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
- 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
- Huge number of segments (Bill, Brad, etc.)
- 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