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

Slicer ITK Dicom

• 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.