Difference between revisions of "2013 Project Week:DicomRtExport"
From NAMIC Wiki
m |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 22: | Line 22: | ||
<h3>Approach, Plan</h3> | <h3>Approach, Plan</h3> | ||
| − | * Explore the DICOM export code in Plastimatch | + | * Explore the DICOM export code in Plastimatch |
| − | * Decide which objects to export in the first round and identify the obstacles for the other objects | + | * Explore the DICOM export code in DCMTK |
| + | * Implement a plugin mechanism just like the Dicom import plugin framework to determine which plugin is better to export the mrmlnode. Decide which objects to export in the first round and identify the obstacles for the other objects | ||
* Migrate the export code to SlicerRT | * Migrate the export code to SlicerRT | ||
* Have the export function use the Patient Hierarchy to fill the proper DICOM tags | * Have the export function use the Patient Hierarchy to fill the proper DICOM tags | ||
| Line 32: | Line 33: | ||
<h3>Progress</h3> | <h3>Progress</h3> | ||
| − | + | * Discussed the reasonable DICOM export mechanism using Patient Hierarchy model in DICOM breakout session. | |
| + | * Investigated the existing DICOM export mechanism. | ||
| + | |||
| + | '''To do''': | ||
| + | * create a loadable module and corresponding module logic | ||
| + | * organize google hangout with Greg to follow up with how to implement dicom export using the plastimatch lib. | ||
| + | * Implement a save function, and utility functions to construct corresponding plastimatch data structure for saving structure set. | ||
| + | * follow up with Steve and Csaba on how to implement the plugin mechanism | ||
| + | * follow up on patient hierarchy model. | ||
</div> | </div> | ||
Latest revision as of 03:48, 12 January 2013
Home < 2013 Project Week:DicomRtExport
Key Investigators
- PMH, UHN Toronto: Kevin Wang
- MGH: Greg Sharp
- Queen's: Csaba Pinter
Objective
The goal is to migrate the DICOM RT export function in Plastimatch to be able to export the RT objects of SlicerRT, leveraging the Patient Hierarchy tree and the Slicer DICOM Database.
Approach, Plan
- Explore the DICOM export code in Plastimatch
- Explore the DICOM export code in DCMTK
- Implement a plugin mechanism just like the Dicom import plugin framework to determine which plugin is better to export the mrmlnode. Decide which objects to export in the first round and identify the obstacles for the other objects
- Migrate the export code to SlicerRT
- Have the export function use the Patient Hierarchy to fill the proper DICOM tags
Progress
- Discussed the reasonable DICOM export mechanism using Patient Hierarchy model in DICOM breakout session.
- Investigated the existing DICOM export mechanism.
To do:
- create a loadable module and corresponding module logic
- organize google hangout with Greg to follow up with how to implement dicom export using the plastimatch lib.
- Implement a save function, and utility functions to construct corresponding plastimatch data structure for saving structure set.
- follow up with Steve and Csaba on how to implement the plugin mechanism
- follow up on patient hierarchy model.
Delivery Mechanism
This work will be delivered to the NA-MIC Kit as a Slicer module, as part of the SlicerRT extension
