I was hoping to use GDCMImageIO to write large to very large image volumes (~10 -1000GB) as single file, mutiframe DICOM files. I specifically want to avoid writing these images as a set of individual 2D slice files.
However, it seems there is a fundamental limit buried away in the GDCM library that limits the 3D image buffer size (in bytes) to 2^32 due to the general use of uint32_t types to store and handle the multframe buffer.
Interestingly, when the size of a passed ITK image exceeds this limit, no error or warning is produced via the code and a file is produced! Albeit, of a size = buffer size mod 2^32. Which I assume is due to truncated memory copying.
Specifically, the limitation appears to be due to the implementation of the GDCM VL class in gdcmVL.h which wraps DICOM dataset length properties. Here, the max length is constrained by the use of an uint32_t type. There are also various static_cast calls in itkGDCMImageIO.cxx to “unsigned int” and other types, where any larger values are lost.
I was wondering if anyone else has come across this? If so, are there any other options available to produce these large DICOM files (multiframe only) with ITK.
There is Module_ITKIODCMTK which is off by default. Then you can use DCMTK for writing DICOM files instead of GDCM. I am not sure whether it has similar limitations, but it is worth trying.
Yes, I also tried Module_ITKIODCMTK and subsequently discovered writing wasn’t implemented either! It’s also not obvious writing wasn’t available, as it “just works” without any warning or error when used as an “imageio” plugin via a writer. However, nothing is produced.
Sounds like you’re half way to fixing it! Certainly a first pass would be to get rid of those truncating casts. Compiler warnings can help here. gcc/clang have -Wshorten-64-to-32 for example.
Indeed, I’ve already started going down that path, however I also wanted to check that there wasn’t already an existing solution.
A lingering concern I have though is that I may be limited in some way by the current DICOM standard wrt data format of specific fields. I don’t know if extending the size of particular elements may violate the standard.
DICOM value length is max 4 bytes wide. Native data is limited to 0xfffffffe bytes per instance (0xffffffff has the special meaning “undefined length”). Encapsulated data is not limited by the standard, but currently limited by GDCM, AFAIK.
Certainly a first pass would be to get rid of those truncating casts. Compiler warnings can help here. gcc/clang have -Wshorten-64-to-32 for example.