I think we should deliver a stable release as soon as possible (that’s why I’m slowly chewing through all the open issues in Mantis) and after that we can change the default to DCMTK.
We have to be careful about how to save the user preference for DCMTK/GDCM: we should not save the user preference now to be GDCM, as user preferences are not overwritten when releases are uninstalled/installed. A solution could be to offer Default, DCMTK, and GDCM options to the user. We can then change in the code at any time what toolkit we use if “Default” is selected.
Sure, but the flipside is that we’ll never get regression reports and test data if we never break anything. A hypothetical deprecation schedule might look something like:
2 months, GDCM stays default, DCMTK fallback with pop-up request to report
+4 months, switch to DCMTK, GDCM fallback with strongly-worded pop-up request to report
+6 months, DCMTK default, GDCM annoying pop-up over-ride available with desperate plea to report
+1 year, GDCM importer available as an extension (or perhaps via emscripten)
Every dependency adds build complication and potential failures, maintenance burden, etc. and we are now carrying two JSON libraries, a bunch of Python packages, etc. too.
Given the quality of DCMTK ImageIO code, severely limited availability of DICOM test data and DICOM testing functionality in general, and other issues mentioned by @pieper, I vote against deprecating GDCM IO. It is good to have both options for the situations when one approach does not work.
Yes, but we introduced 0 new dependencies by the new feature introduced. Both GDCM and DCMTK are already build by Slicer/ITK.