ITK/Release 4/DICOM/Minutes 2010 10 11
From KitwarePublic
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 !
- When OverlayData is stored in unused Pixel Data
- When storing something that is not an image (RTSTRUCT...)
- When storing something that is not handled by the implementation (eg. C-MOVE sending J2K to a dcmtk implementation)
- 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)
- low level DICOM approach: http://www.itk.org/Wiki/DICOM_QueryRetrieve_Explained will be too complex for ITK users
- 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.