ITK/Release 4/DICOM/Minutes 2010 10 11: Difference between revisions

From KitwarePublic
< ITK‎ | Release 4‎ | DICOM
Jump to navigationJump to search
 
(5 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 22: Line 23:
* C-FIND interface ?
* C-FIND interface ?
** low level DICOM approach: http://www.itk.org/Wiki/DICOM_QueryRetrieve_Explained will be too complex for ITK users
** 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
*** 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:
** 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 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 38: 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 :
      1. When OverlayData is stored in unused Pixel Data
      2. When Abstract Image Model is not sufficiant for representing DICOM Series.
      3. When storing something that is not an image (RTSTRUCT...)
      4. When storing something that is not handled by the implementation (eg. C-MOVE sending J2K to a dcmtk implementation)
      5. 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.
  • 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.