Events:2011-08-24-DICOM-ITK-Discussion

Slicer ITK Dicom

The following are talking points for a phone call on 8-25-2011

• Dicom query-retrieve networking without a UI isn't much help (there is almost always a human-in-the-loop to decide which study or series to select).
• Since ITK isn't in the UI business so there is no need for ITK dicom networking support.
• /Interpreting dicom/ on the other hand, is right in the ITK sweet spot. That is, converting dicom datasets into itk images (or meshes, etc) is a big unsolved problem where applications need a lot of help.
• On one of the ITK calls it was discussed that the application might point itk to a directory tree and ask, essentially, for a list of possible interpretations of that data. For example, by looking at a directory you might get back a data structure that says that there are two DWI volumes that could be loaded or you could load them as 60 individual volumes, or you could load them as several thousand 2D slices.
• On the GUI and networking side, very good progress has been made in the combination of ctk with dcmtk and Qt. It's not ready for prime time, and there are no assurances about how future development will go.
• Nevertheless, we believe that any developer who needs to develop a dicom aware application using itk is going to need to use the ctkDICOM code or build something similar duplicating the ctkDICOM functionality.
• At this point, Slicer and NA-MIC are committed to DCMTK. See http://www.commontk.org/index.php/CTK-Hackfest-Feb-2011#ctkDICOM for more information.

• Our suggestion would be that the dicom groups in itkv4 focus on interpretation level tasks. Examples are:
  • Dicomrt support
  • integration of the diffusion work by Hans, Vince, Xioadong et al.

ITKv4 / NA-MIC Meeting

• August 25, 10:30am
• Attendees
  • Ron, Steve P, Will, Jim, Terry, Alex, Dan, Gaetan, Bill Ryan

Meeting notes

• Agenda
  1. Update from Mayo on DICOM effort
  2. Slicer4 Point of View
  3. Future of DICOM and Wrapping in ITKv4

Slicer4 Point of View

• See notes above
• Consistent plan for quite some time
• Design: DCMTK -> CTK -> Slicer
• Use case:
  • access objects and PACS
  • embed MRML scene as a binary blob in a DICOM object for upload/download from PACS and general sharing
• Request:
  • DCMTK supported in ITKv4
• Response from Terry
  • GDCM chosen because of licensing concerns on DCMTK, appearance of inactivity on DCMTK, DCMTK size
  • ITK isn't GUI - so networking support might be weak fit
  • Situation is changing since original awards wrt DCMTK and GDCM and CTK
  • Needs:
    • DCMTK parse into meta-data dictionary on read
    • DCMTK needs to write meta-data dictionary on write/save
  • Issues:
    • Testing: NA-MIC using AMIGO suite for networking
    • Size, licensing, and software-revision-control of DCMTK: NA-MIC reviewed and has helped them come up to speed
    • NA-MIC: Not trying for DCMTK and GDCM to co-exist - concern is inconsistent interpretation of data

Update from Mayo

• Process
  1. Create programmatic query
  2. Send to series
  3. Creates a volume
  • No GUI
  • Tool for an application developer
  • Similar to CTK
  • Filters don't know DICOM - just ITK meta-data
  • Application is responsible for DICOM management

DICOM/Wrapping in ITKv4

Proposed

• Moving forward (Alex)
  • Don't do DICOM networking (PACS) in GDCM
  • RT support in GDCM
  • Diffusion MRI support in GDCM
  • Streaming support
  • Redirect PACS support to wrapping
• Moving forward (Dan)
  • DICOM expertise consulting
• Priorities
  • DCMTK (including networking) into ITKv4 via a module
    • Extract things from CTK

Yoo Directive (Actual tasks moving forward)

• DCMTK moving forward
  • Get integrated with ITK
  • Get rapid closure on DICOM RT and Diffusion MRI in GDCM
• Steve, Stephen, and Alex create a committee to solve
  • Roadmap, Define deliverables, Validation
  • Use wiki and emails to keep Terry and Community informed
  • Dan and Bill can be part of the solution (pending Jim M's "approval")