# Writing large multiframe DICOM files via GDCM in ITK
**URL:** https://discourse.itk.org/t/writing-large-multiframe-dicom-files-via-gdcm-in-itk/7426
**Category:** Algorithms
**Tags:** dicom, gdcm
**Created:** [February 11, 2025, 4:39am UTC](https://discourse.itk.org/t/writing-large-multiframe-dicom-files-via-gdcm-in-itk/7426 "2025-02-11T04:39:20Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@darrent1974](https://discourse.itk.org/u/darrent1974)
#### Post date: [February 11, 2025, 4:39am UTC](https://discourse.itk.org/t/writing-large-multiframe-dicom-files-via-gdcm-in-itk/7426/1 "2025-02-11T04:39:20Z")
Hi,
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.
Regards,
Darren
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [February 11, 2025, 8:37pm UTC](https://discourse.itk.org/t/writing-large-multiframe-dicom-files-via-gdcm-in-itk/7426/2 "2025-02-11T20:37:30Z")
Discovery of these limitations might be interesting to @mathieu.malaterre. @mihail.isakov might also want to comment.
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.
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [February 11, 2025, 8:41pm UTC](https://discourse.itk.org/t/writing-large-multiframe-dicom-files-via-gdcm-in-itk/7426/3 "2025-02-11T20:41:12Z")
Writing is not implemented with ITK’s DCMTK.
>
---
### Author:  [@darrent1974](https://discourse.itk.org/u/darrent1974)
#### Post date: [February 11, 2025, 8:52pm UTC](https://discourse.itk.org/t/writing-large-multiframe-dicom-files-via-gdcm-in-itk/7426/4 "2025-02-11T20:52:55Z")
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.
---
### Author:  [@seanm](https://discourse.itk.org/u/seanm)
#### Post date: [February 12, 2025, 2:35am UTC](https://discourse.itk.org/t/writing-large-multiframe-dicom-files-via-gdcm-in-itk/7426/5 "2025-02-12T02:35:31Z")
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.
All that is needed is someone to do it. 🙂
Sean
---
### Author:  [@darrent1974](https://discourse.itk.org/u/darrent1974)
#### Post date: [February 12, 2025, 2:54am UTC](https://discourse.itk.org/t/writing-large-multiframe-dicom-files-via-gdcm-in-itk/7426/6 "2025-02-12T02:54:20Z")
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.
---
### Author:  [@mihail.isakov](https://discourse.itk.org/u/mihail.isakov)
#### Post date: [February 12, 2025, 3:59am UTC](https://discourse.itk.org/t/writing-large-multiframe-dicom-files-via-gdcm-in-itk/7426/7 "2025-02-12T03:59:33Z")
> [@darrent1974](#):
>
> 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.
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.
Also s. [GDCMImageIO bug, DICOM file cannot be decompressed unencapsulated representation · Issue #2681 · InsightSoftwareConsortium/ITK · GitHub](https://github.com/InsightSoftwareConsortium/ITK/issues/2681), the example file is still available, BTW.
Edit:
for completeness, s. [7 The Data Set](https://dicom.nema.org/medical/dicom/current/output/chtml/part05/chapter_7.html#sect_7.1)
---
### Author:  [@mathieu.malaterre](https://discourse.itk.org/u/mathieu.malaterre)
#### Post date: [February 12, 2025, 7:23am UTC](https://discourse.itk.org/t/writing-large-multiframe-dicom-files-via-gdcm-in-itk/7426/8 "2025-02-12T07:23:05Z")
> [@darrent1974](#):
>
> 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.
[The 32-bit Value Length Field limits the maximum size of large data Value Fields such as Pixel Data sent in a Native Format.](https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_8.2.html#para_a7e1bfa6-d021-48eb-bbe7-4bbe16f873a4)
---
### Author:  [@John\_Drescher](https://discourse.itk.org/u/John_Drescher)
#### Post date: [September 4, 2026, 3:30am UTC](https://discourse.itk.org/t/writing-large-multiframe-dicom-files-via-gdcm-in-itk/7426/9 "2026-09-04T03:30:30Z")
I have just run into a similar problem on the reading side. I am trying to read some ultrasound cine loop images that are multiframe and have over a thousand frames making the image larger than 2GB in size. When trying to read such an image I get an “Impossible” gdcm::Exception.