2017 Winter Project Week/SubjectHierarchyRefactoring

• 

  Projects List

• 

  Subject hierarchy tree

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