ITK/Release 4/DICOM/Minutes 2010 10 11: Difference between revisions
From KitwarePublic
Jump to navigationJump to search
(→Topics) |
Daviddoria (talk | contribs) |
||
(3 intermediate revisions by one other user not shown) | |||
Line 14: | Line 14: | ||
* Should we support streaming (in memory, to disk ) ? | * Should we support streaming (in memory, to disk ) ? | ||
** Support for direct in memory import *should* be possible. | ** Support for direct in memory import *should* be possible. | ||
** Support for writing to disk is required | ** Support for writing to disk is required : | ||
**# When OverlayData is stored in unused Pixel Data | **# 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 an image (RTSTRUCT...) | ||
**# When storing something that is not handled by the implementation (eg. C-MOVE sending J2K to a dcmtk implementation) | **# When storing something that is not handled by the implementation (eg. C-MOVE sending J2K to a dcmtk implementation) | ||
Line 25: | Line 26: | ||
*** Patient Name query will be case insensitive when possible. | *** Patient Name query will be case insensitive when possible. | ||
** interface for characterset: | ** interface for characterset: | ||
*** DICOM | *** 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 an ASCII (char*). Question: UTF-8 implicit ? | ||
*** Will provide a wchar interface (different function names) | *** Will provide a wchar interface (different function names) | ||
*** Other Character Set will not be implemented at first. | |||
* Implementation details: | * Implementation details: | ||
Line 40: | Line 42: | ||
* Relation: itk::Image / itk::DICOMDataSet | * 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. | ** 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. | |||
* http://github.com/pieper/CTK/commit/304990558a522b391da7aaa31e1642f8deb37e09 | |||
I would think you want to have this in addition to any other testing options. |
Latest revision as of 16:00, 9 December 2011
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.