We thought about this a bit more and discussed the implementation plan further with @pieper.
The following issues related to the initially considered approach of introducing a new C++ CLI that would read a DICOM series using DCMTKImageIO have been identified:
- there will be a need to re-implement the code that determines the scalar type from DICOM - this has to be done before the ITK reader is instantiated!
- since in the general case we cannot assume that the directory containing DICOM files does not include files from other series, and there is a limit on the maximum length of a command line in Windows, we would need to work around this by either copying files into a temp location, or communicating the list of files via a file
Based on this, and further analysis of the archetype reder code, an alternative approach has been developed:
- add a flag to ArchetypeScalarVolumeSeriesReader that would allow at runtime to select between GDCM and DCMTK image IO (done, see this commit in a branch referenced earlier: https://github.com/fedorov/Slicer/commit/505265f8c1c48aea3ae3619e4718b5902170dafb#diff-849c98df12f92abb7d0eb4d31e9f83a5R100)
- propagate the capability of setting the flag to the layer that is used by DICOMScalarVolumePlugin (currently it is using Volumes logic
- keep GDCMImageIO as default to address the concerns expressed earlier about limited experience with DCMTKImageIO in Slicer
- in the case when loading an image series as a scalar volume fails in
load()of the DICOMScalarVolumePlugin (Nonereturned in this line: https://github.com/Slicer/Slicer/blob/master/Modules/Scripted/DICOMPlugins/DICOMScalarVolumePlugin.py#L298) using GDCMImageIO (this is what was happening in the use case reported by the user that motivated this discussion), retry loading of the series using DCMTKImageIO
By using this approach, we will not change any of the behavior in the application or its reliance on GDCM, unless GDCM fails. As such, we will be able to introduce the fix addressing the user need relatively easily, and without waiting for the next release, and without confusing the user by introducing a new type of plugin for scalar volumes.
If you have any concerns or suggestions, please respond. We plan to proceed with the implementation of the proposed approach very soon.