ITK/Release 4/DICOM/Minutes 2010 10 11
From KitwarePublic
< ITK | Release 4 | DICOM
Jump to navigationJump to search
Revision as of 16:00, 9 December 2011 by Daviddoria (talk | contribs) (moved ITK Release 4/DICOM/Minutes 2010 10 11 to ITK/Release 4/DICOM/Minutes 2010 10 11)
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 Abstract Image Model is not sufficiant for representing DICOM Series.
- 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. documentation for wild char, and date range query.
- Patient Name query will be case insensitive when possible.
- interface for characterset:
- DICOM supports almost all possible character set (PS 3.3 - 2009, C.12.1.1.2 Specific Character Set Specific Character). Ref: ftp://medical.nema.org/medical/dicom/2009/09_03pu3.pdf
- Will provide an ASCII (char*). Question: UTF-8 implicit ?
- Will provide a wchar interface (different function names)
- Other Character Set will not be implemented at first.
- 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.
Testing
- Will setup testing for SCU.
- Will need a running server (24/7).
- Will make sure C-ECHO works on it
- Will loop over representative DataSet and C-STORE / C-FIND / C-MOVE it.
- Return from C-MOVE should be identical to C-STORE
Testing - Notes (Steve)
Regarding the testing, it's not clear to me that having an external testing server is the best thing for ctest. I think it's better to have a small, self-contained test. That's why for ctk I have a ctest that sets up both the small server (a mini pacs) and then sends data to it and queries/retrieves from it. This way everything is very deterministic and reproducible.
I would think you want to have this in addition to any other testing options.