ITK/Release 4/DICOM/Minutes 2010 10 11

From KitwarePublic
< ITK‎ | Release 4‎ | DICOM
Revision as of 22:11, 12 October 2010 by Mathieu (talk | contribs) (→‎Topics)
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 ?
    • low level DICOM approach: http://www.itk.org/Wiki/DICOM_QueryRetrieve_Explained will be too complex for ITK users
      • Will provide a simple structure that limit user to legal element only
    • interface for characterset:
      • Will provide an ASCII (char*). Question: UTF-8 implicit ?
      • Will provide a wchar interface (different function names)
  • 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.