Skip to content

Requests and feedback

Jump to bottom
gregsharp edited this page May 24, 2018 · 2 revisions

Use cases to pay attention to

(Keep them feasible within the design)

  • Huge number of segments vs memory (compressed representation and/or on-demand loading)
  • SceneViews (states are defined basically by display node visibility on/off)
  • FiberTract support

Feedback

Andrey Fedorov

  • Support codes for segmented organs (~labels, structures). Segmentation structure names are restricted so that they become valid segmentation objects. The user is offered an option: free text / SegObj

Michael Halle

  1. The most general interface to a segmentation object is "am I inside or outside the segment at point (x,y,z), and if so what extra information is available (e.g., probability or fractional volume, gradient/orientation of the underlying structure, etc.)?" It's a little like the VTK implicit surface model.

  2. Another general, but more efficient, interface would be "give me the same information as (1) above, but sampled on a regular grid with bounds (x0,y0,z0, x1,y1,z1)"

  3. The next level of efficiency could include groups of segmentations; conceptually, "do (2) for n segments, but efficiently, and merge the results". This better handles the common case of mutually-exclusive segments, and allows backward compatibility with the existing labelmap representation.

  4. All segmentation representations can respond to these requests,but some might have additional interfaces to allow, say, vector representations to communicate their geometric structure meaningfully.

  5. The representation of a segment should probably be separate from its storage, so that (as now) multiple segments can be represented in a single volume.

  6. Segmentation objects should be able to be grouped inside of Slicer/MRML independent of their origin. It should be possible to load two different groups of segmentation objects created using two different processing steps and mix and match between them.

  7. Individual segmentation object should be able to exist in multiple groups. They would allow multiple representations of the atlas to exist simultaneously (e.g., left side/right side, white matter/gray matter, nervous system/vascular system). Architecturally, that just means groups should exist as separate objects from the segments themselves.

  8. With this kind of structure, it would be much easier to tag segments and segmentation groups with metadata nodes, which could have a parallel structure.

Brad Lowekamp

  • Currently it's a large waste to store multiple full resolution sparse ( 99%) segmentations of individual object in memory. I have had ideas about improving handling of multiple resolutions and ROI label maps. This may be related to some of the issue and designs going on here. --> Multiple representations available, we can have a binary RLE representation for example
  • Use itkLabelmap that supports advanced features: http://www.itk.org/Doxygen320/html/classitk_1_1LabelMap.html
  • Storing huge number of segments can be problematic with current design. Need to use compressed representations and/or on-demand loading into memory

Jim Miller

  • Segment UIDs should be stored, otherwise it would be very hard to keep track of individual segments (index of a segment in the vector in segmentation is not stable)
  • Color should be stored some place else. Although segment is the place where color is stored in DICOM SegObj, it might not be the best place to store it. (it will be necessary to store the color in multiple places, the question is which should be the primary? - Csaba)
  • Extend CLI to tell what representation they want (similar to what we have in ContourSelectorWidget - Csaba)

Bill Lorensen

  • Need to pay special attention to the "many structures" use case. We'll run out of memory very quickly!
  • vtkSegment could be a subclass of vtkDataObject. There are composite objects already in VTK, such as Common/vtkMultiBlockDataset and vtkCompositeDataset
  • Load subsets of data by spatial position/extent (by geometric conditions)

Nicole Aucoin

  • VTK6 new color table features could be used
  • Keep in mind the SceneView use case, where the states are defined basically by display node visibility on/off
  • Geometric decisions/conditions need to be supported on the CLI level

Greg Sharp

  • Greg should make a demo of how he uses Slicer for RT segmentation
  • Greg requests an erase tool for the pen effect
Clone this wiki locally