2014 Project Week Breakout Session: Contours - Revision history

Pinter: /* Meeting minutes (Rankin) */

2014-06-26T21:02:54Z

Meeting minutes (Rankin)

Pinter: /* Meeting minutes (Pinter) */

2014-06-26T21:02:13Z

Meeting minutes (Pinter)

Rankin at 17:05, 26 June 2014

2014-06-26T17:05:12Z

Rankin: /* Meeting minutes */

2014-06-26T17:01:13Z

Meeting minutes

Pinter: Minutes added

2014-06-26T13:39:58Z

Minutes added

Rankin at 17:19, 25 June 2014

2014-06-25T17:19:39Z

Rankin: /* Agenda */

2014-06-25T13:54:29Z

Agenda

Pinter at 14:50, 24 June 2014

2014-06-24T14:50:37Z

Rankin: /* Agenda */

2014-06-23T13:12:21Z

Agenda

Naucoin: /* Introduction */

2014-05-29T19:36:27Z

Introduction

@@ Line 88: / Line 88: @@
 **(based on the assumption that multiple labels per contour, as opposed to now)
 **(and segments with fuzzy boundaries)
-*David courney?
+*David Clunie
 **Get more information about DICOM SO and DICOM RT to see which direction DICOM is thinking
 *Is it possible to have an abstraction in slicer that represents both RTSS and DICOMSO

@@ Line 48: / Line 48: @@
 **** Storing image data: multi-component vtkImageData? Do we want to constrain segments to one geometry and dimensions? -> No, DICOM seg. obj. allows segments to be in different frames of reference
 **** Funding purposes: the closer to the DICOM standard in the internals, the better
-** '''Answer''': Both
+** '''Answer''': Both (multiple segment per node and external (subject) hierarchy)
 *** vtkMRMLSegmentationNode will contain a vector of pairs of labelmaps and polydata, indicating the "master" representation (which was loaded; useful to avoid series of lossy conversions). This supports use cases where a huge number of segments have to be handled
 *** At the same time, Subject hierarchy can maintain hierarchy of Segmentations in the way it is currently done in SlicerRT's Contour node. This way a Segmentation contains one segment. Supports use cases where there are not a lot of segments, but relationships are important

← Older revision		Revision as of 17:05, 26 June 2014
Line 56:		Line 56:
	* Other questions		* Other questions
	** QIICR segmentation object to use Contours (Segmentation) on the long run? => ask Andriy		** QIICR segmentation object to use Contours (Segmentation) on the long run? => ask Andriy
		+
		+	=Meeting minutes (Rankin)=
		+	* <strike>Re-try deriving the contour from scalar volume node</strike>
		+	* Contour name does not represent the concept
		+	** ''SegmentationObject decided as new name -- later''
		+	*Instead of contour, improve scalar volume node <Invalid with new design>
		+	**Poly data can be stored in display node
		+	*Contours really are segmentation objects
		+	**DICOM segmentation object
		+	**http://medical.nema.org/dicom/2013/output/chtml/part03/sect_A.51.html
		+	*'''QIICR'''
		+	**Andrey working with segmentation object
		+	**Meet with Andrey to confirm and develop path forward
		+	**Andrey has written read/write for DICOM SO to labelmap
		+	**See structure reporting module
		+	*Integration into Slicer core
		+	**Debate about whether integrating worth it
		+	***Yes, after new design implemented and tested
		+	*Fuzzy boundary could be supported by segmentation object
		+	**Volume rendering segmentation currently ugly, doesn't have to be
		+	**Editor tools could produce fuzzy boundaries aka brush tool
		+	*How to manage CLI
		+	**If a CLI wants labelmap out of contour, we have to determine what it gets
		+	***If a contour contains many vtkImageData or vtkPolyData, how do we let the user know which one got sent in
		+	**CLI that receives it could have to have some logic to pull out information
		+	***This would mean that CLIs would have to become contour aware
		+	**If the segment is a polydata, we can autoconvert to labelmap
		+	**If not told how to get multi label volume, then all segments could be merged into one labelmap
		+	**If specified, could be outputted as multiple segments
		+	**(this is all for when an existing CLI wants a labelmap, and we pass it a contour)
		+	**(based on the assumption that multiple labels per contour, as opposed to now)
		+	**(and segments with fuzzy boundaries)
		+	*David courney?
		+	**Get more information about DICOM SO and DICOM RT to see which direction DICOM is thinking
		+	*Is it possible to have an abstraction in slicer that represents both RTSS and DICOMSO
		+	**Yes, just different import/export
		+	*<strike>In order to represent DICOMSO in image data, have to have 1 component per segmentation</strike>
		+	**<strike>vtkPolyData is possible, one cell per segmentation</strike>
		+	*Should segmentation object represent many segments, or one-to-one?
		+	**What is workflow of segmentation objects? Is it common to operate on a single contour?
		+	***Short answer, both workflows are needed
		+	***Design is to have a segmentation object contain 0..N segments, with splitting/merging of SO
		+	*What is the new naming convention?
		+	**vtkMRMLSegmentationNode
		+	*What is the new design?
		+	**vtkMRMLSegmentationNode
		+	**container< pair<vtkImageData,vtkPolyData*> >
		+	***Split
		+	***Merge
		+	***Depending on DICOM SO master representation, one of each pair will be designated master
		+	****Other representation can be converted on demand
		+	*Discussion on use cases:
		+	**Thresholding might create 10,000+ items, if those are nodes, crash and burn
		+	**in that case, one node holding many items would be best
		+	**use case frequency should determine design choice
		+	**hierarchy of segments important?
		+	**Collect use cases to determine optimum design
		+	*Discussion of design after discussion of use cases:
		+	**split seg object into N seg objects
		+	**merge N seg objects into a seg object
		+	**segmentation node contains N segments

@@ Line 30: / Line 30: @@
 * See [[2014_Winter_Project_Week:IntegrationOfContourObject|winter discussion page]]
-=Meeting minutes=
+=Meeting minutes (Pinter)=
 * Supporting information
 ** Treatment planning systems and other workstations work with labelmaps, but display contours

← Older revision		Revision as of 13:39, 26 June 2014
Line 29:		Line 29:
	* See [[2014_Summer_Project_Week:Contours\|contours project page]]		* See [[2014_Summer_Project_Week:Contours\|contours project page]]
	* See [[2014_Winter_Project_Week:IntegrationOfContourObject\|winter discussion page]]		* See [[2014_Winter_Project_Week:IntegrationOfContourObject\|winter discussion page]]
		+
		+	=Meeting minutes=
		+	* Supporting information
		+	** Treatment planning systems and other workstations work with labelmaps, but display contours
		+	** Segmentation object is the new standard for storing this kind of data, it is versatile, supporting it is desirable and necessary
		+	** Is RTSS (structure set) going to be improved? Yes, according to David Clunie, a major overhaul is on its way
		+	*** The reason for this question is that RTSS is very basic (stores list of list of points) and does not accommodate lot of use cases (partial coverage, structures with holes, etc.)
		+	** One displayable MRML node can have multiple display nodes (e.g. tensors)
		+	* Main question #1: Naming
		+	** Contour -> No, it implies 2D outlines
		+	** '''Segmentation''' -> Yes, but only if the node contains multiple "segments" (VOIs, organs)
		+	** Structure -> No, means this concept only in RT
		+	* Main question #2: Representation
		+	** Improved labelmap: RLE, multiple structures, have the polydatas in display nodes -> No, we need poly datas as core representation, not just for display
		+	** SegmentationNode contains one segment, or multiple segments?
		+	*** More
		+	**** CLI support? Creates multiple labelmaps? New CLI type
		+	**** Storing image data: multi-component vtkImageData? Do we want to constrain segments to one geometry and dimensions? -> No, DICOM seg. obj. allows segments to be in different frames of reference
		+	**** Funding purposes: the closer to the DICOM standard in the internals, the better
		+	** '''Answer''': Both
		+	*** vtkMRMLSegmentationNode will contain a vector of pairs of labelmaps and polydata, indicating the "master" representation (which was loaded; useful to avoid series of lossy conversions). This supports use cases where a huge number of segments have to be handled
		+	*** At the same time, Subject hierarchy can maintain hierarchy of Segmentations in the way it is currently done in SlicerRT's Contour node. This way a Segmentation contains one segment. Supports use cases where there are not a lot of segments, but relationships are important
		+	*** Split and merge of Segmentations (conversion between the first and second case above) is needed
		+	*** Color table supports both use cases
		+	** Partial coverage will be needed (float labelmap image data)
		+	* Other questions
		+	** QIICR segmentation object to use Contours (Segmentation) on the long run? => ask Andriy

← Older revision		Revision as of 17:19, 25 June 2014
Line 28:		Line 28:
	=Discussion=		=Discussion=
	* See [[2014_Summer_Project_Week:Contours\|contours project page]]		* See [[2014_Summer_Project_Week:Contours\|contours project page]]
		+	* See [[2014_Winter_Project_Week:IntegrationOfContourObject\|winter discussion page]]

@@ Line 7: / Line 7: @@
 =Agenda=
-* Present current state of contours (Adam) (slides in progress)
+* Present current state of contours (Adam) [[Media:2014-06-23-NAMIC Summer Contours.pptx | slides]]
 * Discussion on the features and implementation details
 ** Change propagation - what happens when a repr. is changed?

← Older revision		Revision as of 14:50, 24 June 2014
Line 27:		Line 27:

	=Discussion=		=Discussion=
−	* See contours project page ~~(TODO)~~	+	* See [[2014_Summer_Project_Week:Contours\|contours project page]]

@@ Line 7: / Line 7: @@
 =Agenda=
-* Present current state of contours (Adam) (slides here)
+* Present current state of contours (Adam) (slides in progress)
 * Discussion on the features and implementation details
 ** Change propagation - what happens when a repr. is changed?
@@ Line 25: / Line 25: @@
 *** Representations in one file or more?
 *** In what format? Concealed standard files (different extension) or standard files with attributes specifying contour as target object?
 =Discussion=
 * See contours project page (TODO)

@@ Line 4: / Line 4: @@
 * Purpose: Present purpose and current state of Contours data type in the SlicerRt extension with the hope of integrating them into the core, come to agreement in technical details and action plan
 * Time: Wednesday 1:00-2:30
-* Participants: Adam Rankin, Csaba Pinter, Andras Lasso, Steve Pieper, JC, and everybody who is interested
+* Participants: Adam Rankin, Csaba Pinter, Andras Lasso, Steve Pieper, JC, Nicole, and everybody who is interested
 =Agenda=