ITK/Release 4/DICOM/Meeting 2011.09.01 Roadmap
From KitwarePublicJump to navigationJump to search
- Alex, Steve, Stephen, terry, dan and William
- 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
- Code could be in a layer/repo that augements DCMTK ("DCMTK::PACSModule")
- Code could be shared by CTK and ITK::DCMTKModule
- Will use cmd line methods from DCMTK for now (RSNA Release)
- Will use DCMTK::PACSModule and ITK::DCMTKModule when they are ready
- 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
- 1 FTE until 15 of december
- 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?