ITK/Release 4/DICOM/Minutes 2010 10 11

From KitwarePublic
< ITK‎ | Release 4‎ | DICOM
Revision as of 22:09, 12 October 2010 by Mathieu (talk | contribs) (Created page with "= Attendees = * Mathieu Malaterre (CoSMo) * Mark Roden (CoSMo) * Dan Blezek + Bill Ryan (Mayo) = Topics = * DICOM Query/Retrieve API (C-ECHO, C-STORE, C-MOVE, C-FIND): ** C-EC...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Attendees

  • Mathieu Malaterre (CoSMo)
  • Mark Roden (CoSMo)
  • Dan Blezek + Bill Ryan (Mayo)

Topics

  • DICOM Query/Retrieve API (C-ECHO, C-STORE, C-MOVE, C-FIND):
    • C-ECHO, C-STORE, C-FIND all agree
    • C-GET is not always implemented
    • C-MOVE is always to be found (Mayo exp).
  • Should we support streaming (in memory, to disk ) ?
    • Support for direct in memory import *should* be possible.
    • Support for writing to disk is required !
      1. When OverlayData is stored in unused Pixel Data
      2. When storing something that is not an image (RTSTRUCT...)
      3. When storing something that is not handled by the implementation (eg. C-MOVE sending J2K to a dcmtk implementation)
      4. Low level DICOM protocol does not easily allow streaming. In which case we always need to retrieve the whole DataSet (eg. Large MultiFrame image in Enhanced CT/MR).
  • C-FIND interface ?
  • Implementation details:
    • Support GDCM + DCMTK
    • CTN is difficult to use (Mayo exp).
    • Interface should be flexible to allow Third party implementation (Merge Toolkit).
  • Extensions : kerberos or TLS will not be supported in the short term.

SubTopics

  • Relation: itk::Image / itk::DICOMDataSet
    • itk::Filter should only update Group 0028. Any other operation should be done at application level. ITK pipeline will not be responsible to update the DICOM DataSet.