Difference between revisions of "2015 Winter Project Week:DICOM References"
From NAMIC Wiki
(Created page with '__NOTOC__ <gallery> Image:PW-2015SLC.png|Projects List </gallery> ==Key Investigators== * Andrey Fedorov, BWH * Csaba Pinter, Queen's * Ste…') |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 17: | Line 17: | ||
<div style="width: 27%; float: left; padding-right: 3%;"> | <div style="width: 27%; float: left; padding-right: 3%;"> | ||
<h3>Approach, Plan</h3> | <h3>Approach, Plan</h3> | ||
| − | * | + | * Notification that a DICOM dataset being loaded is referencing things, and asking the user if they would like to load those too. I think this should be done in DICOM browser at the time of examine/load. |
| − | + | * Marking the hierarchy entries that have resolved or unresolved dependencies in the subject hierarchy (this could be done by highlghting of rows in red/yellow, for example) | |
| − | * | + | * Providing user with the mechanism to pull in unresolved dependencies (this could be done using "Related" pop-up menu in SH). |
| − | * | + | * Extend the ctkDICOMDatabase to cache references during the import process |
| + | * Reconcile the reference graph (which is a DAG) with the "composite context" (patient/study/series) which is a tree. They are handled quite differently in DICOM, but to me they should be very similarly handled and exposed to the user if possible (as it is in the subject hierarchy) | ||
</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> | ||
| − | * | + | * Decisions: |
| + | ** DICOM browser prompts the user to load referenced data | ||
| + | *** Plugins have the option to return referencedInstanceUIDs at the time of examine (plugins, because the reference tags might be in different places depending on modality) | ||
| + | *** These UIDs are collected by the browser, and if not empty, the corresponding files are looked for | ||
| + | *** Group these instances to series for the files that are present (warning maybe if some of them are not?) | ||
| + | *** When user clicks Load, pop up dialog with rows for each referenced series found. Load also those that the user checked (and if clicked Yes) | ||
| + | ** Subject hierarchy highlights referenced series | ||
| + | *** References are stored in MRML sttributes of the subject hierarchy node (just as currently, but always use the same attribute name and the value is a list of UIDs) | ||
| + | *** When a series node is clicked, the referenced UIDs are mapped to nodes and those are highlighted (to indicate to export it along with the selected node, or to indicate what to show along with the just shown series) | ||
| + | *** Idea: If knowing type of reference is important (does not look like that now), and we have a way to store it (then probably reference inspector widget will be also necessary), then force show tooltips for the highlighted nodes containing the type of reference | ||
</div> | </div> | ||
</div> | </div> | ||
Latest revision as of 22:59, 7 January 2015
Home < 2015 Winter Project Week:DICOM References
Key Investigators
- Andrey Fedorov, BWH
- Csaba Pinter, Queen's
- Steve Pieper, Isomics
Project Description
Objective
- Lay down a plan to handle DICOM object references in Slicer
Approach, Plan
- Notification that a DICOM dataset being loaded is referencing things, and asking the user if they would like to load those too. I think this should be done in DICOM browser at the time of examine/load.
- Marking the hierarchy entries that have resolved or unresolved dependencies in the subject hierarchy (this could be done by highlghting of rows in red/yellow, for example)
- Providing user with the mechanism to pull in unresolved dependencies (this could be done using "Related" pop-up menu in SH).
- Extend the ctkDICOMDatabase to cache references during the import process
- Reconcile the reference graph (which is a DAG) with the "composite context" (patient/study/series) which is a tree. They are handled quite differently in DICOM, but to me they should be very similarly handled and exposed to the user if possible (as it is in the subject hierarchy)
Progress
- Decisions:
- DICOM browser prompts the user to load referenced data
- Plugins have the option to return referencedInstanceUIDs at the time of examine (plugins, because the reference tags might be in different places depending on modality)
- These UIDs are collected by the browser, and if not empty, the corresponding files are looked for
- Group these instances to series for the files that are present (warning maybe if some of them are not?)
- When user clicks Load, pop up dialog with rows for each referenced series found. Load also those that the user checked (and if clicked Yes)
- Subject hierarchy highlights referenced series
- References are stored in MRML sttributes of the subject hierarchy node (just as currently, but always use the same attribute name and the value is a list of UIDs)
- When a series node is clicked, the referenced UIDs are mapped to nodes and those are highlighted (to indicate to export it along with the selected node, or to indicate what to show along with the just shown series)
- Idea: If knowing type of reference is important (does not look like that now), and we have a way to store it (then probably reference inspector widget will be also necessary), then force show tooltips for the highlighted nodes containing the type of reference
- DICOM browser prompts the user to load referenced data
