Difference between revisions of "Documentation/Nightly/Modules/SubjectHierarchy"
(Updated general module information) |
|||
Line 24: | Line 24: | ||
<!-- ---------------------------- --> | <!-- ---------------------------- --> | ||
{{documentation/{{documentation/version}}/module-section|Module Description}} | {{documentation/{{documentation/version}}/module-section|Module Description}} | ||
− | The {{documentation/modulename}} module acts as a central data-organizing point in Slicer. All DICOM data is automatically added | + | The {{documentation/modulename}} module acts as a central data-organizing point in Slicer.<br><br> |
+ | It is deactivated by default, so when the user enters it the first time, it asks whether subject hierarchy should be created for the data loaded in Slicer. Clicking No leaves subject hierarchy unused, clicking Yes adds the nodes only once to subject hierarchy, and clicking Yes to All enables automtic creation of subject hierarchy nodes from all loaded data objects.<br><br> | ||
+ | DICOM data is automatically added as patient-study-series hierarchy. Non-DICOM data can be parsed if loaded from a local directory structure, or can be manually organized in tree structure by creating DICOM-like hierarchy or Folder nodes.<br><br> | ||
Subject hierarchy nodes provide features for the underlying data nodes, including cloning, bulk transforming, bulk show/hide, type-specific features, and basic node operations such as delete or rename. Additional plugins can provide other type-specific features and general operations, see [[Documentation/Labs/SubjectHierarchy|Subject hierarchy labs page]] | Subject hierarchy nodes provide features for the underlying data nodes, including cloning, bulk transforming, bulk show/hide, type-specific features, and basic node operations such as delete or rename. Additional plugins can provide other type-specific features and general operations, see [[Documentation/Labs/SubjectHierarchy|Subject hierarchy labs page]] | ||
Revision as of 20:21, 8 June 2016
Home < Documentation < Nightly < Modules < SubjectHierarchy
For the latest Slicer documentation, visit the read-the-docs. |
Introduction and Acknowledgements
| |||||||
|
Module Description
The SubjectHierarchy module acts as a central data-organizing point in Slicer.
It is deactivated by default, so when the user enters it the first time, it asks whether subject hierarchy should be created for the data loaded in Slicer. Clicking No leaves subject hierarchy unused, clicking Yes adds the nodes only once to subject hierarchy, and clicking Yes to All enables automtic creation of subject hierarchy nodes from all loaded data objects.
DICOM data is automatically added as patient-study-series hierarchy. Non-DICOM data can be parsed if loaded from a local directory structure, or can be manually organized in tree structure by creating DICOM-like hierarchy or Folder nodes.
Subject hierarchy nodes provide features for the underlying data nodes, including cloning, bulk transforming, bulk show/hide, type-specific features, and basic node operations such as delete or rename. Additional plugins can provide other type-specific features and general operations, see Subject hierarchy labs page
Use Cases
Tutorials
Panels and their use
Contains all the objects in the Subject hierarchy in a tree representation
How to
|
Similar Modules
References
- Additional information on Subject hierarchy labs page
- Manual editing of segmentations can be done in the Segmentations module
Information for Developers
- Important note: Instead of the usual New function, vtkMRMLSubjectHierarchyNode::CreateSubjectHierarchyNode should be used for instantiating an SH node. The reason is that when SH auto creation is turned on, then there is no need to create an SH node, but only to set up its properties (parent, level, name, association), but when it is turned off, then creating an SH node is necessary if the module relies on it. The CreateSubjectHierarchyNode function takes care of this, and only creates a node if it doesn't exist, otherwise just updates its properties.
- Implementing new plugins: Plugins are the real power of subject hierarchy, as they provide support for data node types, and add functionality to the context menu items.
To create a C++ plugin, implement a child class of qSlicerSubjectHierarchyAbstractPlugin, for Python plugin see below. Many examples can be found in Slicer core and in the SlicerRT extension, look for folders named SubjectHierarchyPlugins.- Role plugins: add support for new data node types
- Defines: ownership, icon, tooltip, edit properties, help text (in the yellow question mark popup), visibility icon, set/get display visibility, displayed node name (if different than name of the node object)
- Existing plugins in Slicer core: Markups, Models, SceneViews, Charts, Folder, Tables, Transforms, LabelMaps, Volumes
- Function plugins: add feature in right-click context menu for certain types of nodes
- Defines: list of contect menu actions for nodes and the scene, types of nodes for which the action shows up, functions handling the defined action
- Existing plugins in Slicer core: CloneNode, ParseLocalData, Register, Segment, DICOM
- Writing plugins in Python:
- Child class of AbstractScriptedSubjectHierarchyPlugin which is a Python adaptor of the C++ qSlicerSubjectHierarchyScriptedPlugin class
- Example: https://subversion.assembla.com/svn/slicerrt/trunk/VolumeClip/src/SubjectHierarchyPlugins
- Role plugins: add support for new data node types
- Glossary of all the used terms in SlicerRT