Difference between revisions of "Events:2011-08-24-DICOM-ITK-Discussion"

From NAMIC Wiki
Jump to: navigation, search
Line 4: Line 4:
 
*/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.  
 
*/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 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
+
* 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.
> any developer who needs to develop a dicom aware application using itk
+
* 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.
> is going to need to use the ctkDICOM code or build something similar.
+
* 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.
> DCMTK is really the logical choice for that. Certainly that's what we
+
 
> plan for slicer and namic.
+
*Our suggestion would be that the dicom groups in itkv4 focus on interpretation level tasks
>
+
Examples are:
> http://www.commontk.org/index.php/CTK-Hackfest-Feb-2011#ctkDICOM
+
** Dicomrt support  
>
+
**integration of the diffusion work by Hans, Vince, Xioadong et al.
> 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.
 

Revision as of 19:46, 24 August 2011

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