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

• 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 > yesterday's call we 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, we're making very good progress in ctk > with dcmtk and Qt. It's not ready for prime time, and there are no > assurances about how future development will go, but I would say 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. > DCMTK is really the logical choice for that. Certainly that's what we > plan for slicer and namic. > > http://www.commontk.org/index.php/CTK-Hackfest-Feb-2011#ctkDICOM > > If you have this flexibility, I suggest you direct the dicom groups in > itkv4 to focus on interpretation level tasks - the dicomrt support and > on integrating the diffusion work from Hans, Vince, Xioadong et al would > be good examples.