DICOM @ OFFIS

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 wr...

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 t...

Unfortunately, the answer is no. The DICOM C-STORE network protocol does not provide this information. The client (SCU) sends image after image, but there is no information about how many images should be present and whether they should arrive in one or in multiple network connections. For this reas...

This may sound trivial, but have you checked the content of android-emulator.log which should hopefully contain a meaningful error message?
If it doesn't, try removing the OUTPUT_QUIET and ERROR_QUIET flags in the execute_process() call in CMake/dcmtkUseAndroidSDK.cmake.

Unfortunately DCMTK currently does not allow to have different values for this setting in different threads. The encoders and decoders in DCMTK have access to two parameter sets: the "codec parameters" and the "representation parameters". The representation parameters can be expl...

I have registered this in our issue tracker, see https://support.dcmtk.org/redmine/issues/1082.

I would suggest that you use Valgrind to find out where exactly that leak happens.

That could mean that the Wireshark capture is incomplete, or that the network connection was dropped by the PACS before the image transmission was complete, e.g. because the sending process crashed. That would also explain the error message on your side. Unfortunately that will be difficult to debug...