Difference between revisions of "Events:2011-08-24-DICOM-ITK-Discussion"
From NAMIC Wiki
| Line 1: | Line 1: | ||
| + | =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). | *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. | *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, but I would say that | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
> any developer who needs to develop a dicom aware application using itk | > 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. | > is going to need to use the ctkDICOM code or build something similar. | ||
Revision as of 19:29, 24 August 2011
Home < Events:2011-08-24-DICOM-ITK-DiscussionSlicer 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, 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.
