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

From NAMIC Wiki
Jump to: navigation, search
m (Text replacement - "[http://www.na-mic.org/Wiki/images/" to "[https://na-mic.org/w/images/")
 
(3 intermediate revisions by one other user not shown)
Line 3: Line 3:
 
Image:PW-SLC2014.png|[[2014_Winter_Project_Week#Projects|Projects List]]
 
Image:PW-SLC2014.png|[[2014_Winter_Project_Week#Projects|Projects List]]
 
Image:SlicerRT 0.13 SubjectHierarchy ProstateEclipseLoaded.png|Screenshot of Subject Hierachy module
 
Image:SlicerRT 0.13 SubjectHierarchy ProstateEclipseLoaded.png|Screenshot of Subject Hierachy module
 +
Image:Screenshot HuntingtonsLongitudinalInSubjectHierarchy.png|Huntington's longitudinal data in Sibject Hierarchy
 
</gallery>
 
</gallery>
  
Line 24: Line 25:
 
<h3>Approach, Plan</h3>
 
<h3>Approach, Plan</h3>
 
* [http://www.na-mic.org/Wiki/index.php/AHM2014-SubjectHierarchy Breakout session]
 
* [http://www.na-mic.org/Wiki/index.php/AHM2014-SubjectHierarchy Breakout session]
−
** [http://www.na-mic.org/Wiki/images/5/5e/SubjectHierarchy_NAMIC2014Jan.pptx Slides]
+
** [https://na-mic.org/w/images/5/5e/SubjectHierarchy_NAMIC2014Jan.pptx Slides]
−
** [http://www.na-mic.org/Wiki/images/6/6d/Subject_Hierarchy_-_Class_Diagram.png Detailed class diagram]
+
** [https://na-mic.org/w/images/6/6d/Subject_Hierarchy_-_Class_Diagram.png Detailed class diagram]
  
 
</div>
 
</div>
 
<div style="width: 27%; float: left; padding-right: 3%;">
 
<div style="width: 27%; float: left; padding-right: 3%;">
 
<h3>Progress</h3>
 
<h3>Progress</h3>
−
*
+
* Subject hierarchy enhanced to better support handling Huntington's longitudinal data, [http://screencast.com/t/bIsTSFxkj video]
 +
** Volumes subject hierarchy plugin handles labelmap and proper show/hide of volumes in the slice viewers
 +
* Subject hierarchy module and mechanism presented in the breakot session, a lot of valuable feedback was given (see below)
 +
 
 
</div>
 
</div>
 +
 +
== Received feedback ==
 +
* DICOM back into SH? Derived vtkMRMLDICOMSubjectHierarchyNode class? For tags, UID, maybe levels?
 +
* DICOM connections
 +
** "All DICOM all the time" (@QIICR) means for import/export on disc, not in memory
 +
** Tree vs DAG: Support DAGs? How to display them? "Infinite trees"?
 +
** Update referenced UIDs and references when reparenting and the connections are known (plugins reparent method)
 +
** Look at BioImageSuite (by Xenios) - User manual chapter 15 (page 193)
 +
*** Connector lines in the tree are colored (indicate status of registration?)
 +
* Export
 +
** Override the selection made by the user to the most sensible one (if they select a contour, the RTSS is also selected)
 +
** Determine mandatory tags for export
 +
*** Stored in the plugins?
 +
**** Maybe in XML or JSON templates that are read by the plugins?
 +
**** Collect tags from plugin dependencies
 +
** Use DICOM header widget with some changes (ctkDICOMObjectModel + ListWidget)
 +
** Similar modalities to export (legacy, multiframe, enhanced) - separate plugins?
 +
** Explicit representation of DICOM tags in Slicer in separate class?
 +
** Ask for mandatory DICOM tags and connections (e.g. after conversion, resample, manual plugin selection)
 +
* Use cases
 +
** Neuro
 +
*** Multiple modalities (different MR types)
 +
*** Display tractography
 +
*** Register volumes and indicate the registration status in the tree (in the icons)
 +
** Data probe custom readout (e.g. dose)
 +
** DICOM slice offset into the slice views
 +
** Displayable manager customizable behavior
 +
*** Scalar volume types e.g. multi-component vector volumes
 +
*** Volume rendering transfer functions
 +
* UIDs
 +
** "2.25.hash" DICOM UIDs will be generated as new UIDs (perhaps even instead of MRML IDs in the future)
 +
** What happens to the UIDs if we modify a node?
 +
*** Create new SH node and move the data there?
 +
** MIDAS url should be a SH storage node property? (Julien)
 +
* Plugins
 +
** Give confidence value of -1 if the node cannot be handled for sure?
 +
** Per-structure labelmaps
 +
** More abstraction: Qt, JavaScript etc. -> presentation managers
 +
** Icon could be in the MRML node as a resource (string)
 +
** Move core plugins into their corresponding modules after integration (Volumes, Transforms, Markups, etc.)
 +
* Create dummy parents for loaded node if there is no parent (Study, Patient too)
 +
* 'Unclaimed' section on the bottom of the tree instead of potential list? (Jim)
 +
*Drag&drop would be difficult if there is a lot of nodes in the tree already
 +
* Generate thumbnails as icons for volumes
 +
* vtkSubjectHierarchyConstants -> vtkMRMLSubjectHierarchyConstants?
 +
* qMRMLSortFilterPotentialSubjectHierarchyProxyModel be merged into qMRMLSortFilterSubjectHierarhcyProxyModel?
 +
*Maybe a Q_PROPERTY controls their different behavior?
 +
* Propagating / Overwriting attributes
 +
*In the model, for example for "height" of an item
 +
* Select and drag&drop multiple nodes from the potential list
 +
 
== Reference ==
 
== Reference ==
 
* [[2013_Summer_Project_Week:Patient_hierarchy|Summer Project Week page]]
 
* [[2013_Summer_Project_Week:Patient_hierarchy|Summer Project Week page]]

Latest revision as of 18:27, 10 July 2017

Home < 2014 Winter Project Week:SubjectHierarchy

  • Screenshot of Subject Hierachy module

  • Huntington's longitudinal data in Sibject Hierarchy

Key Investigators

  • Queen's: Csaba Pinter, Andras Lasso
  • Isomics: Steve Pieper
  • Kitware: Jean-Cristophe Fillion-Robin

Project Description

Objective

  • Review the current state of Subject Hierarchy
  • Discuss features to develop and things to change
  • Create roadmap for the integration


Progress

  • Subject hierarchy enhanced to better support handling Huntington's longitudinal data, video
    • Volumes subject hierarchy plugin handles labelmap and proper show/hide of volumes in the slice viewers
  • Subject hierarchy module and mechanism presented in the breakot session, a lot of valuable feedback was given (see below)

Received feedback

  • DICOM back into SH? Derived vtkMRMLDICOMSubjectHierarchyNode class? For tags, UID, maybe levels?
  • DICOM connections
    • "All DICOM all the time" (@QIICR) means for import/export on disc, not in memory
    • Tree vs DAG: Support DAGs? How to display them? "Infinite trees"?
    • Update referenced UIDs and references when reparenting and the connections are known (plugins reparent method)
    • Look at BioImageSuite (by Xenios) - User manual chapter 15 (page 193)
      • Connector lines in the tree are colored (indicate status of registration?)
  • Export
    • Override the selection made by the user to the most sensible one (if they select a contour, the RTSS is also selected)
    • Determine mandatory tags for export
      • Stored in the plugins?
        • Maybe in XML or JSON templates that are read by the plugins?
        • Collect tags from plugin dependencies
    • Use DICOM header widget with some changes (ctkDICOMObjectModel + ListWidget)
    • Similar modalities to export (legacy, multiframe, enhanced) - separate plugins?
    • Explicit representation of DICOM tags in Slicer in separate class?
    • Ask for mandatory DICOM tags and connections (e.g. after conversion, resample, manual plugin selection)
  • Use cases
    • Neuro
      • Multiple modalities (different MR types)
      • Display tractography
      • Register volumes and indicate the registration status in the tree (in the icons)
    • Data probe custom readout (e.g. dose)
    • DICOM slice offset into the slice views
    • Displayable manager customizable behavior
      • Scalar volume types e.g. multi-component vector volumes
      • Volume rendering transfer functions
  • UIDs
    • "2.25.hash" DICOM UIDs will be generated as new UIDs (perhaps even instead of MRML IDs in the future)
    • What happens to the UIDs if we modify a node?
      • Create new SH node and move the data there?
    • MIDAS url should be a SH storage node property? (Julien)
  • Plugins
    • Give confidence value of -1 if the node cannot be handled for sure?
    • Per-structure labelmaps
    • More abstraction: Qt, JavaScript etc. -> presentation managers
    • Icon could be in the MRML node as a resource (string)
    • Move core plugins into their corresponding modules after integration (Volumes, Transforms, Markups, etc.)
  • Create dummy parents for loaded node if there is no parent (Study, Patient too)
  • 'Unclaimed' section on the bottom of the tree instead of potential list? (Jim)
  • Drag&drop would be difficult if there is a lot of nodes in the tree already
  • Generate thumbnails as icons for volumes
  • vtkSubjectHierarchyConstants -> vtkMRMLSubjectHierarchyConstants?
  • qMRMLSortFilterPotentialSubjectHierarchyProxyModel be merged into qMRMLSortFilterSubjectHierarhcyProxyModel?
  • Maybe a Q_PROPERTY controls their different behavior?
  • Propagating / Overwriting attributes
  • In the model, for example for "height" of an item
  • Select and drag&drop multiple nodes from the potential list

Reference

Retrieved from "https://www.na-mic.org/w/index.php?title=2014_Winter_Project_Week:SubjectHierarchy&oldid=97809"