Difference between revisions of "2014 Project Week:DICOM enhanced multiframe"
From NAMIC Wiki
(Created page with '__NOTOC__ <gallery> Image:PW-SLC2014.png|Projects List </gallery> ==Key Investigators== * BWH: Andrey Fedorov, Alireza Mehrtash * David Clu…') |
|||
| (4 intermediate revisions by the same user not shown) | |||
| Line 11: | Line 11: | ||
* Iowa: Reinhard Beichel | * Iowa: Reinhard Beichel | ||
* GE: Jim Miller | * GE: Jim Miller | ||
| + | * Kitware: Jean-Christophe Fillion-Robin | ||
==Project Description== | ==Project Description== | ||
| Line 18: | Line 19: | ||
<h3>Objective</h3> | <h3>Objective</h3> | ||
* Most commonly, DICOM images are stored such that each frame (slice) is stored as a separate file. Enhanced multiframe objects allow to reduce storage requirements and simplify interaction with the DICOM data. These objects are also versatile to support various use cases such as storing perfusion or multi-echo data in a single object. | * Most commonly, DICOM images are stored such that each frame (slice) is stored as a separate file. Enhanced multiframe objects allow to reduce storage requirements and simplify interaction with the DICOM data. These objects are also versatile to support various use cases such as storing perfusion or multi-echo data in a single object. | ||
| − | * Our goal is to investigate current level of DICOM enhanced multiframe support in Slicer and related tools, and improve it to support communication of perfusion data (potential replacement for NRRD used by MultiVolume) | + | * Citing Suppl 157: "The enhanced family of modality-specific multi-frame IODs as currently defined does not permit a simple mapping of the legacy single-frame IOD attributes to the enhanced multi-frame IOD attributes, due to the requirement for much more mandatory information, and the requirement to use standard codes and pre-defined strings for many features that are unspecified or unsupported in the older IODs." To address this limitation, Legacy Converted modality-specific OIDs have been introduced. |
| + | * Our goal is to investigate current level of DICOM enhanced (and legacy converted enhanced) multiframe support in Slicer and related tools, and improve it; we will also investigate the use of miltiframe DICOM to support communication of perfusion data (potential replacement for NRRD used by MultiVolume) | ||
</div> | </div> | ||
| Line 30: | Line 32: | ||
<div style="width: 27%; float: left; padding-right: 3%;"> | <div style="width: 27%; float: left; padding-right: 3%;"> | ||
<h3>Progress</h3> | <h3>Progress</h3> | ||
| − | * | + | * Among the evaluated tools (dicom3tools, gdcm, Pixelmed, dcmulti from dicom3tools of David Clunie is most functional (support for dimensions and stacks initialization, sorting, initialization of functional groups) |
| + | * dicom3tools is open source, but not open contribution tool, and is a part of a big legacy toolkit, improvement/upgrades are problematic. 2.25 UID approach is not supported. | ||
| + | * none of the existing tools supports generation of legacy converted enhanced storage objects (there are differences in handling tags not assigned to a specific functional group). Implementation of separate standalone conversion tool (pydicom-based?) was decided as most practical. | ||
| + | * example converted objects are available in the MIDAS QIICR community (multi-slice T2w and DCE series). Note the legacy converted objects provided in the examples are not | ||
| + | * enhanced 3d objects can be read with ITK GDCM reader, but not time-resolved DCE. Legacy converted objects are not recognized (introduced June 2013, supported by DCMTK current trunk). | ||
| + | * Infrastructure sub-projects: pydicom external project integration with Slicer completed ([https://github.com/Slicer/Slicer/pull/93 Slicer pull request]), use of CMake-configured DCMTK from an external project tested (see [http://forum.dcmtk.org/viewtopic.php?f=1&t=3906 DCMTK forum post]) | ||
</div> | </div> | ||
| + | |||
| + | <h3>References</h3> | ||
| + | * [https://github.com/QIICR/ProjectIssuesAndWiki/wiki/Multiframe-DICOM-for-data-exchange Project page on QIICR wiki] | ||
</div> | </div> | ||
Latest revision as of 05:41, 10 January 2014
Home < 2014 Project Week:DICOM enhanced multiframe
Key Investigators
- BWH: Andrey Fedorov, Alireza Mehrtash
- David Clunie
- Isomics: Steve Pieper
- MGH: Jayashree Kalpathy-Cramer
- Iowa: Reinhard Beichel
- GE: Jim Miller
- Kitware: Jean-Christophe Fillion-Robin
Project Description
Objective
- Most commonly, DICOM images are stored such that each frame (slice) is stored as a separate file. Enhanced multiframe objects allow to reduce storage requirements and simplify interaction with the DICOM data. These objects are also versatile to support various use cases such as storing perfusion or multi-echo data in a single object.
- Citing Suppl 157: "The enhanced family of modality-specific multi-frame IODs as currently defined does not permit a simple mapping of the legacy single-frame IOD attributes to the enhanced multi-frame IOD attributes, due to the requirement for much more mandatory information, and the requirement to use standard codes and pre-defined strings for many features that are unspecified or unsupported in the older IODs." To address this limitation, Legacy Converted modality-specific OIDs have been introduced.
- Our goal is to investigate current level of DICOM enhanced (and legacy converted enhanced) multiframe support in Slicer and related tools, and improve it; we will also investigate the use of miltiframe DICOM to support communication of perfusion data (potential replacement for NRRD used by MultiVolume)
Approach, Plan
- Use Pixelmed tools to convert sample datasets (3D volumes and perfusion) into enhanced multi-frame representation
- test if the generated objects can be read by Slicer, debug the unsupported use cases
- discuss experience of using multi-frame data with the interested project attendees and collect sample datasets that can be shared
- discuss with Jim integration of multiframe for DCE communication in PkModeling CLI
Progress
- Among the evaluated tools (dicom3tools, gdcm, Pixelmed, dcmulti from dicom3tools of David Clunie is most functional (support for dimensions and stacks initialization, sorting, initialization of functional groups)
- dicom3tools is open source, but not open contribution tool, and is a part of a big legacy toolkit, improvement/upgrades are problematic. 2.25 UID approach is not supported.
- none of the existing tools supports generation of legacy converted enhanced storage objects (there are differences in handling tags not assigned to a specific functional group). Implementation of separate standalone conversion tool (pydicom-based?) was decided as most practical.
- example converted objects are available in the MIDAS QIICR community (multi-slice T2w and DCE series). Note the legacy converted objects provided in the examples are not
- enhanced 3d objects can be read with ITK GDCM reader, but not time-resolved DCE. Legacy converted objects are not recognized (introduced June 2013, supported by DCMTK current trunk).
- Infrastructure sub-projects: pydicom external project integration with Slicer completed (Slicer pull request), use of CMake-configured DCMTK from an external project tested (see DCMTK forum post)
