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

From NAMIC Wiki
Jump to: navigation, search
 
(14 intermediate revisions by 2 users not shown)
Line 1: Line 1:
*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).   
+
=Slicer ITK Dicom=
*Since ITK isn't in the UI business so there is no need for ITK dicom networking support.
+
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).   
> /Interpreting dicom/ on the other hand, is right in the itk sweet spot.
+
* Since ITK isn't in the UI business so there is no need for ITK dicom networking support.
That is, converting dicom datasets into itk images (or meshes, etc) is
+
* /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.  
> a big unsolved problem where applications need a lot of help. On
+
* 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.
> yesterday's call we discussed that the application might point itk to a
+
* 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.
> directory tree and ask, essentially, for a list of possible
+
* 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.
> interpretations of that data.  For example, by looking at a directory
+
* 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.
> 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
+
*Our suggestion would be that the dicom groups in itkv4 focus on interpretation level tasks. Examples are:
> volumes, or you could load them as several thousand 2D slices.
+
** Dicomrt support  
>
+
**integration of the diffusion work by Hans, Vince, Xioadong et al.
> 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
+
= ITKv4 / NA-MIC Meeting =
> assurances about how future development will go, but I would say that
+
* August 25, 10:30am
> any developer who needs to develop a dicom aware application using itk
+
* Attendees
> is going to need to use the ctkDICOM code or build something similar.
+
** Ron, Steve P, Will, Jim, Terry, Alex, Dan, Gaetan, Bill Ryan
> DCMTK is really the logical choice for that. Certainly that's what we
+
 
> plan for slicer and namic.
+
== Meeting notes ==
>
+
* Agenda
> http://www.commontk.org/index.php/CTK-Hackfest-Feb-2011#ctkDICOM
+
*# Update from Mayo on DICOM effort
>
+
*# Slicer4 Point of View
> If you have this flexibility, I suggest you direct the dicom groups in
+
*# Future of DICOM and Wrapping in ITKv4
> 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.
+
=== 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
 +
*# Create programmatic query
 +
*# Send to series
 +
*# 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")

Latest revision as of 15:43, 25 August 2011

Home < 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")