DICOM @ OFFIS

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

I don't think that it is possible to determine the reason for the segmentation fault from the stack trace alone. As Jörg Riesmeier wrote, you really need to get this running in a debugger to determine the precise function call that causes the segfault. Possible reasons could be either an identical s...

Any comments from your side on why when we pass planar as 1 to above function, we can render it correctly and when we pass planar as 0, we cannot render it properly? Well, apparently you are correctly interpreting the output data in the case of planar configuration 1 (color-by-plane), but not in th...

What you are seeing there is indeed the query (C-FIND request). You are basically querying for everything, so you get all worklist items as response. My understanding of class DcmFindSCU is that the syntax for the override keys is the same as the one used in the findscu command line tool, i.e. "...

The attributes you are looking for are called Scheduled Procedure Step Start Date (0040,0002) and Scheduled Procedure Step Start Time (0040,0003). However, these attributes are not present in the main dataset, but encapsulated in the Scheduled Procedure Step Sequence (0040,0100). Try adding an empty...

I have looked at the anonymized sample file, and it seems to be perfectly OK. dcm2pnm and other tools based on dcmimage can correctly process the image. This means that there must be some bug in the code that uses DicomImage. Are you taking into account that DicomImage::getOutputData() delivers a di...

If you can get access to an anonymized sample file, we'd be interested in a copy to bugs/at/dcmtk/dot/org. I have never seen Hebrew used in an ISO 2022 multi-character set setting, so even if, as Jörg points out, the file violates the DICOM standard, I'd still be interested in checking whether we wo...

JPEG baseline is a lossy (irreversible) compression. That means that the compressed image may not be "identical" from a medical point of view to the original one - the difference being the image quality.
In such cases DICOM requires the SOP Instance UID to be changed.