Difference between revisions of "Documentation/Nightly/Modules/SubjectHierarchy"
(Added info about implementing new plugins) |
Hillarylia (talk | contribs) m (Fixed minor typos) |
||
Line 66: | Line 66: | ||
** '''Volumes''': icon, Edit properties and additional information in tooltip | ** '''Volumes''': icon, Edit properties and additional information in tooltip | ||
*** ''''Register this...'''' action to select fixed image for registration. Right-click the moving image to initiate registration | *** ''''Register this...'''' action to select fixed image for registration. Right-click the moving image to initiate registration | ||
− | *** ''''Segment this using...'''' action allows segmenting the volume | + | *** ''''Segment this using...'''' action allows segmenting the volume, for example, in the Editor module |
*** ''''Toggle labelmap outline display'''' for labelmaps | *** ''''Toggle labelmap outline display'''' for labelmaps | ||
** '''Models''': icon, Edit properties and additional information in tooltip | ** '''Models''': icon, Edit properties and additional information in tooltip | ||
Line 110: | Line 110: | ||
{{documentation/{{documentation/version}}/module-section|Information for Developers}} | {{documentation/{{documentation/version}}/module-section|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. | * '''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.<br>To create a C++ plugin, implement a child class of qSlicerSubjectHierarchyAbstractPlugin, for | + | * '''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.<br>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 | ** 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) | *** 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) | ||
Line 117: | Line 117: | ||
*** 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 | *** 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 | *** Existing plugins in Slicer core: CloneNode, ParseLocalData, Register, Segment, DICOM | ||
− | ** Writing plugins in | + | ** Writing plugins in Python: |
− | *** Child class of AbstractScriptedSubjectHierarchyPlugin which is a | + | *** 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 | *** Example: https://subversion.assembla.com/svn/slicerrt/trunk/VolumeClip/src/SubjectHierarchyPlugins | ||
* [https://www.assembla.com/spaces/slicerrt/wiki/SlicerRt_naming_conventions Glossary of all the used terms in SlicerRT] | * [https://www.assembla.com/spaces/slicerrt/wiki/SlicerRt_naming_conventions Glossary of all the used terms in SlicerRT] |
Revision as of 13:33, 12 May 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. All DICOM data is automatically added to the tree. Non-DICOM data can be parsed if loaded from a local directory structure, or has to be manually added (non-SH nodes are the ones on the bottom with no icons). 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