Difference between revisions of "ITK/Release 4/DICOM/Meeting 2011.09.01 Roadmap"

From KitwarePublic
< ITK‎ | Release 4‎ | DICOM
Jump to navigationJump to search
Line 12: Line 12:
 
* DCMTK Module
 
* DCMTK Module
 
** Modularization of ITK has been helpful
 
** Modularization of ITK has been helpful
** DCMTK was forked by CTK, but now uses direct DCMTK repo
+
** Need to patch DCMTK to expose build settings to be used through external_project() / superbuild
** Need to patch DCMTK to expose build settings
+
** Need to create a FindDCMTK.cmake
** Need to fix findpackage commands
+
*** Need to fix findpackage commands
 
*** Need a UseDCMTK.cmake file
 
*** Need a UseDCMTK.cmake file
* Need ITK ImageFile reader/writer based on DCMTK
+
 
 +
* Need ITK ImageFile reader/writer using itk's IO factory mechanism based on DCMTK (  itkDCMTKImageIO a-la itkGdcmImageIO )
 
** Focus of Dan's team
 
** Focus of Dan's team
* Consistent population of MetaData Dictionary between DCMTK and GDCM
+
** this is enough on the image processing point of view. One could/should decorrelate the PACS, Dicom Metadata handling, and image processing.
** Work in progress
+
 
* Need way of storing header info from DICOM objects in memory and on disk in an established way
+
* Dicom Metadata dictionnary handling
** SQL database
+
** using DCMTK in memory structure (as CTK does)
** Future work - might not happen
+
** currently using gdcm in memory structure, at best
 +
** structures being incompatible, you need to aprse twice today in slicer to go from itk to ctk
 +
** Possible goal: Consistent population of MetaData Dictionary between DCMTK and GDCM, perhaps through DB
 +
*** common in memory structure that could be populated arbitrarily by the user (file list, cosines, spacing, ...)?
 +
*** common DB structure that could be then read into either gdcm or dcmtk ?
 +
*** Work in progress
 +
*** Future work - might not happen
 +
 
 
* Implementation
 
* Implementation
** Code will be in a layer/repo that augements DCMTK ("DCMTK::PACSModule")
+
** Code could be in a layer/repo that augements DCMTK ("DCMTK::PACSModule")
** Code will be shared by CTK and ITK::DCMTKModule
+
** Code could be shared by CTK and ITK::DCMTKModule
 
** http://support.dcmtk.org/wiki/dcmtk/howto/dcmscu-example
 
** http://support.dcmtk.org/wiki/dcmtk/howto/dcmscu-example
 +
 
* Slicer
 
* Slicer
 
** Will use cmd line methods from DCMTK for now (RSNA Release)
 
** Will use cmd line methods from DCMTK for now (RSNA Release)
 
** Will use DCMTK::PACSModule and ITK::DCMTKModule when they are ready
 
** Will use DCMTK::PACSModule and ITK::DCMTKModule when they are ready
 +
 
* Testing
 
* Testing
 
** DCM4CHEE as main test
 
** DCM4CHEE as main test
 
** dicom.co.uk as an alternative test
 
** dicom.co.uk as an alternative test
** Safe sequence of clinical PACS testing - as a "am I compatible with ITK DICOM" executable
+
** Safe sequence of clinical PACS testing (C-ECHO) - as a "am I compatible with ITK DICOM" executable
 +
** http://support.dcmtk.org/wiki/dcmtk/howto/dcmscu-example
 +
 
 
* Funding
 
* Funding
 
** Alex
 
** Alex
*** 1 FTE for 2 weeks
+
*** 1 FTE until 15 of december
 +
*** underspent
 
** Dan/William/Mayo
 
** Dan/William/Mayo
 
*** Underspent
 
*** Underspent
 +
** Terry mentioned that a no cost extension could be possible. The new target could be SPIE as there is an ITK tutorial programmed. That would give an extra one month and a half and could cover NAMIC week. Dan asked if traveling to SLC would then be covered?

Revision as of 00:56, 2 September 2011

Agenda

  1. Review roadmap


Attendees

  • Alex, Steve, Stephen, terry, dan and William

Notes

  • DCMTK Module
    • Modularization of ITK has been helpful
    • Need to patch DCMTK to expose build settings to be used through external_project() / superbuild
    • Need to create a FindDCMTK.cmake
      • Need to fix findpackage commands
      • Need a UseDCMTK.cmake file
  • Need ITK ImageFile reader/writer using itk's IO factory mechanism based on DCMTK ( itkDCMTKImageIO a-la itkGdcmImageIO )
    • Focus of Dan's team
    • this is enough on the image processing point of view. One could/should decorrelate the PACS, Dicom Metadata handling, and image processing.
  • Dicom Metadata dictionnary handling
    • using DCMTK in memory structure (as CTK does)
    • currently using gdcm in memory structure, at best
    • structures being incompatible, you need to aprse twice today in slicer to go from itk to ctk
    • Possible goal: Consistent population of MetaData Dictionary between DCMTK and GDCM, perhaps through DB
      • common in memory structure that could be populated arbitrarily by the user (file list, cosines, spacing, ...)?
      • common DB structure that could be then read into either gdcm or dcmtk ?
      • Work in progress
      • Future work - might not happen
  • Slicer
    • Will use cmd line methods from DCMTK for now (RSNA Release)
    • Will use DCMTK::PACSModule and ITK::DCMTKModule when they are ready
  • Funding
    • Alex
      • 1 FTE until 15 of december
      • underspent
    • Dan/William/Mayo
      • Underspent
    • Terry mentioned that a no cost extension could be possible. The new target could be SPIE as there is an ITK tutorial programmed. That would give an extra one month and a half and could cover NAMIC week. Dan asked if traveling to SLC would then be covered?