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

From KitwarePublic
< ITK‎ | Release 4‎ | DICOM
Jump to navigationJump to search
Line 50: Line 50:
** Will loop over representative DataSet and C-STORE / C-FIND / C-MOVE it.
** Will loop over representative DataSet and C-STORE / C-FIND / C-MOVE it.
** Return from C-MOVE should be identical to C-STORE
** 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.

Revision as of 08:05, 13 October 2010

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.