I have been using generally GDCMImageIO for the ImageFileReader for reading dicom files from disk, but I recently discovered another ImageIO called DCMTKImageIO which seems to use the dcmtk toolkit instead of the gdcm to read in data. There isn’t really a lot of information on the DCMTKImageIO specifically especially in comparing it to the GDCMImageIO.
What is the reason for having two different IOs to process and read dicom data in ITK? Aren’t they doing the same thing, i.e. aren’t they going to end up with the same ITKImage if reading the same dicom files? Is there any benefit or disadvantages to using one or the other?
The ITK IO infrastructure is primarily based on third party back ends, the heavy lifting associated with reading and writing complex file formats is offloaded to those external libraries.
The DICOM file format is very complex and constantly expanding (it is sufficiently complex that you can make a living just developing and customizing software to deal with DICOM). Because of this complexity, many libraries only support parts of the standard. By supporting multiple back ends ITK enables us to choose which one to use, the one that is able to read all of the information found in your specific DICOM images .
To quote the slicer DICOM documentation: “You can choose what back-end library to use (currently GDCM, DCMTK, or GDCM with DCMTK fallback with the last option being the default. This is provided in case some data is unsupported by one library or the other.”
.