DICOM @ OFFIS

By default, in all operating systems a closed listen socket will be kept in the TIME_WAIT state by the operating system for some time, in order to "catch" packets that were sent to that socket and have not yet arrived. On Posix systems (such as Linux), DCMTK explicitly disables this delay by setting...

If you want DCMTK to convert character sets, then you need to compile it with one of the character set conversion libraries supported, i.e. GNU libiconv or ICU.

This file is defective. It should contain uncompressed pixel data for 17444 frames of 512x512 pixels of 3 bytes per pixel (RGB), i.e. 13,718,519,808 bytes of pixel data (which is not possible in an uncompressed DICOM file). In fact, only 833,617,920 bytes of pixel data are present, less than 10%. Th...

You would have to post a dcmdump output of that file - without that it is difficult to guess what may be the problem. However, based on the warning printed ( computed (4572839936) and stored (277872640) pixel count differ ), the pixel data seems to be incomplete. This is understandable, given that t...

The problem with this image file is that it is compressed with JPEG 2000, and cannot be decompressed. In compressed form, the pixel data already allocates about 3 GBytes of data (17444 frames of 512x512 color pixels). In decompressed form, the image would be 12.8 GBytes large, but uncompressed DICOM...

In general, it is not possible to split a large DICOM multi-frame image into many smaller files without in-depth knowledge of the DICOM standard and the physical parameters of the acquisition device. In brief, I would not recommend this route. Extracting all frames from a (very) large DICOM image is...

I have looked at the test image you provided. Due to the file size, you simply cannot decompress it, because the decompressed pixel data element would be larger than 4 GBytes, the upper limit for (7fe0,0010) Pixel Data in uncompressed format. You can, however, use DcmElement::getUncompressedFrame() ...

I presume that you are working on Linux. The DCMTK build scripts on Linux expect pre-compiled developer versions of the external libraries to be available before CMake is run. For all of these libraries, official development packages exist on most Linux distributions, e.g. on Debian/Ubuntu, you just...

You could use the --exec-on-reception command line option to rename the incoming files after the receive process is complete. As an example, the following command line (for Linux) will cause storescp to append a ".dcm" filename extension only once a file has been completely received and written: sto...

On the other hand, if this is just a single file you are trying to fix, I would use dcmdump +W and dump2dcm to convert the dataset to a text file, and back, while keeping the pixel data in the binary file created by the dcmdump +W option.

I don't think that changing the UID in the metaheader is a function that is foreseen in DCMTK because the transfer syntax value is directly bound to the encoding used, i.e. if you change transfer syntax to MPEG4, then DCMTK will look for an encoder module that would convert uncompressed pixel data t...

It's actually fairly simple. First of all, download the right package from https://dcmtk.org/en/dcmtk/dcmtk-software-development/ . You have apparently downloaded a package with pre-compiled executables, and not the DCMTK source code. Unpack the package ( tar xzf dcmtk-3.6.7.tar.gz ) and carefully r...

Unfortunately, no. iOS and tvOS are not supported platforms for DCMTK (although I would be very exited to see a DICOM-enabled smart TV )
For MacOS, the build process is the same as for other Unix/Posix-like systems, based on CMake.

I would be surprised if the filename had any role in this problem. Please provide more detail: What is the content of the file, what is the output of storescp --debug? Is there a crash does the tool report an error and terminate? Which DCMTK version, which operating system?

The issue report is called "memory_leak_in_3.6.7" which should tell you that this bug is present in 3.6.7. It was fixed with commit c34f4e46e in June 2022. However, the bug only affects one tool (dcmqrscp), which leaks a few bytes of memory with each network connection handled. Feel free to backport...