Difference between revisions of "2017 Winter Project Week/SubjectHierarchyRefactoring"

From NAMIC Wiki
Jump to: navigation, search
(Created page with "__NOTOC__ <gallery> Image:PW-Winter2017.png|link=2017_Winter_Project_Week#Projects|Projects List <!-- Use the "Upload file" link on the l...")
 
 
(4 intermediate revisions by the same user not shown)
Line 2: Line 2:
 
<gallery>
 
<gallery>
 
Image:PW-Winter2017.png|link=2017_Winter_Project_Week#Projects|[[2017_Winter_Project_Week#Projects|Projects List]]
 
Image:PW-Winter2017.png|link=2017_Winter_Project_Week#Projects|[[2017_Winter_Project_Week#Projects|Projects List]]
 +
Image:20170109_SubjectHierarchy.png|Subject hierarchy tree
 
<!-- Use the "Upload file" link on the left and then add a line to this list like "File:MyAlgorithmScreenshot.png" -->
 
<!-- Use the "Upload file" link on the left and then add a line to this list like "File:MyAlgorithmScreenshot.png" -->
 
</gallery>
 
</gallery>
Line 8: Line 9:
 
* Csaba Pinter (Queen's)
 
* Csaba Pinter (Queen's)
 
* ? (JC, Steve, Andras)
 
* ? (JC, Steve, Andras)
 +
* Jorge Onieva
  
 
==Project Description==
 
==Project Description==
Line 26: Line 28:
 
* Node selector based on subject hierarchy (e.g. where it's possible to start selecting by patient in some way) cannot be implemented without major changes
 
* Node selector based on subject hierarchy (e.g. where it's possible to start selecting by patient in some way) cannot be implemented without major changes
 
These issues are due to
 
These issues are due to
* The extremely complex Qt MRML scene model infrastructure, which is quite rigid in various ways, and has unstable features
+
* The overly complex Qt MRML scene model infrastructure, which is rigid in some ways, and bloated in others
* Unstable workarounds implemented in the current subject hierarchy infrastructure to accommodate certain use cases, e.g.
+
** Can only show nodes, so if an item is needed to be shown, a new node needs to be created (thus the lot of SH nodes and the virtual branches, see below). Also pointer tracking of nodes complicates things.
 +
** Index calculation is very complex and gets even more complex in the sub classes.
 +
** The features that are needed for specific models but are implemented in the base model overcomplicate the implementation (e.g. pre- and post items)
 +
* Unstable workarounds implemented in the current subject hierarchy infrastructure to accommodate certain use cases
 
** Nested associations that use the MRML hierarchy associations in a nested way so that the same nodes can be added both to model and subject hierarchies
 
** Nested associations that use the MRML hierarchy associations in a nested way so that the same nodes can be added both to model and subject hierarchies
 
** Virtual branches to accommodate data that do not correspond to MRML nodes one-on-one (segments contained by segmentations, fiducials contained by markups)
 
** Virtual branches to accommodate data that do not correspond to MRML nodes one-on-one (segments contained by segmentations, fiducials contained by markups)
 
** Postfixes of the SH nodes to differentiate them from the associated data nodes
 
** Postfixes of the SH nodes to differentiate them from the associated data nodes
This necessitates a re-design of the subject hierarchy mechanism. The proposed solution is to store the whole subject hierarchy tree in one node, the internals of which are synchronized with the data nodes of the scene. A new Qt item model needs to be implemented for this node that supplies the information to the tree view and the future node selectors to show the information.
+
This necessitates a re-design of the subject hierarchy mechanism. The proposed solution is to store the whole subject hierarchy tree in one node, the internals of which are synchronized with the data nodes of the scene. A new Qt item model needs to be implemented for this node that supplies the information to the tree view and the future node selectors.
 
|
 
|
 
<!-- Approach and Plan bullet points -->
 
<!-- Approach and Plan bullet points -->
Line 43: Line 48:
 
|
 
|
 
<!-- Progress and Next steps bullet points (fill out at the end of project week) -->
 
<!-- Progress and Next steps bullet points (fill out at the end of project week) -->
*
+
* Rewrote all subject hierarchy classes (node, logic, model, tree view, plugin handler, plugin logic, abstract plugin) and updating classes using subject hierarchy
 +
* It compiles, but need to work on making it really work
 +
* Need to make sure all components, all plugins work well. Also need to check all extensions and update them if they use subject hierarchy directly
 
|}
 
|}
  
 
==Background and References==
 
==Background and References==
 
<!-- Use this space for information that may help people better understand your project, like links to papers, source code, or data -->
 
<!-- Use this space for information that may help people better understand your project, like links to papers, source code, or data -->

Latest revision as of 14:54, 13 January 2017

Home < 2017 Winter Project Week < SubjectHierarchyRefactoring

Key Investigators

  • Csaba Pinter (Queen's)
  •  ? (JC, Steve, Andras)
  • Jorge Onieva

Project Description

Objective Approach and Plan Progress and Next Steps

Although the subject hierarchy mechanism is in place and is already used, there are several issues and limitations that cannot be addressed in its current form:

  • Subject hierarchy needs to be disabled by default, because
    • A second node is created for each data node and the scene can grow very large in case of many data nodes
    • Model hierarchies and subject hierarchies are not fully compatible, so problems may arise in case of complex model hierarchies (such as atlases)
    • Because of this, a popup is shown to the user, which is confusing for users. It prevents some from using SH, and is annoying for the others
  • Expanded state is reset to all extended when switching to another module and back. This can be very frustrating when there are many subjects or folders, because the user sees it very differently after returning to SH
  • Manual re-ordering of nodes is not possible
  • Node selector based on subject hierarchy (e.g. where it's possible to start selecting by patient in some way) cannot be implemented without major changes

These issues are due to

  • The overly complex Qt MRML scene model infrastructure, which is rigid in some ways, and bloated in others
    • Can only show nodes, so if an item is needed to be shown, a new node needs to be created (thus the lot of SH nodes and the virtual branches, see below). Also pointer tracking of nodes complicates things.
    • Index calculation is very complex and gets even more complex in the sub classes.
    • The features that are needed for specific models but are implemented in the base model overcomplicate the implementation (e.g. pre- and post items)
  • Unstable workarounds implemented in the current subject hierarchy infrastructure to accommodate certain use cases
    • Nested associations that use the MRML hierarchy associations in a nested way so that the same nodes can be added both to model and subject hierarchies
    • Virtual branches to accommodate data that do not correspond to MRML nodes one-on-one (segments contained by segmentations, fiducials contained by markups)
    • Postfixes of the SH nodes to differentiate them from the associated data nodes

This necessitates a re-design of the subject hierarchy mechanism. The proposed solution is to store the whole subject hierarchy tree in one node, the internals of which are synchronized with the data nodes of the scene. A new Qt item model needs to be implemented for this node that supplies the information to the tree view and the future node selectors.

  • Store the whole tree in one vtkMRMLSubjectHierarchy node
    • Items have unique identifier numbers that is strictly incremental
    • Item information can be accessed using accessors, the item class itself is private
  • Automatically populate from added nodes (as before), observe modified and removed events
  • Implement new Qt item model that is synchronized with the subject hierarchy node instead of the scene
  • Import model hierarchies to SH node on entering SH module if new detected (thus model hierarchies can be fully used from
  • Subject hierarchy logic makes sure there is only one SH node and it is valid (at import, deletion, potential undo, etc.)
  • Rewrote all subject hierarchy classes (node, logic, model, tree view, plugin handler, plugin logic, abstract plugin) and updating classes using subject hierarchy
  • It compiles, but need to work on making it really work
  • Need to make sure all components, all plugins work well. Also need to check all extensions and update them if they use subject hierarchy directly

Background and References