ITK/Release 4/DICOM/Meeting 2011.09.01 Roadmap: Difference between revisions

From KitwarePublic
< ITK‎ | Release 4‎ | DICOM
Jump to navigationJump to search
No edit summary
 
(5 intermediate revisions by 2 users not shown)
Line 6: Line 6:
= Attendees =
= Attendees =


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


= Notes =
= Notes =
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
 
* Consistent population of MetaData Dictionary between DCMTK and GDCM
* Need ITK ImageFile reader/writer using itk's IO factory mechanism based on DCMTK (  itkDCMTKImageIO a-la itkGdcmImageIO )
* Need way of storing header info from DICOM objects in memory and on disk in an established way
** Focus of Dan's team
** SQL database
** 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
 
* Implementation
** Code could be in a layer/repo that augements DCMTK ("DCMTK::PACSModule")
** Code could be shared by CTK and ITK::DCMTKModule
** http://support.dcmtk.org/wiki/dcmtk/howto/dcmscu-example
 
* Slicer
** Will use cmd line methods from DCMTK for now (RSNA Release)
** Will use DCMTK::PACSModule and ITK::DCMTKModule when they are ready
 
* Testing
** DCM4CHEE as main test
** dicom.co.uk as an alternative test
** 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?

Latest revision as of 16:00, 9 December 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?
Retrieved from "https://public.kitware.com/Wiki/index.php?title=ITK/Release_4/DICOM/Meeting_2011.09.01_Roadmap&oldid=44275"