DICOM @ OFFIS

You can ignore the warnings, but "Information Object Not found" indicates some fundamental problem. SOP Class UID missing?

I agree that this is a bug in DICOMscope. The overlay seems to be offset by about two pixels horizontally and vertically. Even worse, when you rotate the image, the offset seems to change between 0 and 2 pixels. Unfortunately, this rendering of graphical overlays is part of DICOMscope's Java layer a...

Try running the compressed file through "dciodvfy" from dicom3tools - in most cases you will get a meaningful error message.

My guess is that this is indeed some out-of-memory condition. dcmodify calls DcmItem::loadAllDataIntoMemory() to load the entire DICOM file into main memory before starting to modify it, but apparently does not check the return code of this call. Are you perhaps using a 32-bit binary? That would exp...

That quote only means that applications are not supposed to read meaning into the structure of the UIDs (e.g. they must not assume that UID 1.2.3.4 is in any way related to UID 1.2.3). That does not prevent an application to check whether or not a UID is syntactically valid, i.e. contains no leading...

On Windows, DCMTK uses a different mechanism (defined in CMake/3rdparty.cmake) to locate the external support libraries such as OpenSSL. This makes use of the CMake find_path() command, which apparently always returns an absolute path. It should not be overly difficult to add some code in that file ...

I don't think this is related to the "well-known" Cornell bug, which is an overflow in the Huffman table values that only occurs when the Cornell encoder is used for image data with more than 8 bits/sample.

As a brief follow-up, the current development version of DCMTK available from our git repository compiles and runs on MacOS ARM "out of the box", without any modifications.
We have meanwhile integrated an M1 MacMini into our nightly build infrastructure to make sure it stays that way

Sorry for the late reply. The attack vector was indeed that a malicious attacker could send a DICOM image with an invalid SOP Instance UID, which would be used as part of a filename. Under certain conditions (including something like "../../../../" in the UID) storescp can be manipulated t...

This is entirely possible with DCMTK, there is just no command line tool to do it.

With regard to using the various classes for compressed images, see Image2Dcm::insertEncapsulatedPixelDataFirstFrame() (file dcmdata/libi2d/i2d.cc) as an example.

Three issues in your example: DICOM tags contain a comma, not a period character: 0008,0052 You need to specify the port under which movescu will accept incoming images using the --port option In your PACS server(!), you need to configure PACSAET as an application entity that can receive images, spe...

The call to chooseRepresentation() causes DCMTK to decompress the image and to then discard the JPEG compressed original. This explains why sending in JPEG lossless fails after decompression. The problem is that in some cases decompression requires changes in the main dataset (e.g. Photometric Inter...

You might have noticed that with DCMTK 3.6.7 we have introduced "DCMTK_PORTABLE_LINUX_BINARIES" as another build option. This tries to link all libraries except glibc statically and should result in fairly portable binaries.

Also, what does the DCMTK_LINK_STATIC do? DCMTK_LINK_STATIC tries to create truly static DCMTK command line tool binaries, i.e. it calls gcc -static . Such binaries are not ELF binaries anymore and depend on no shared object (i.e. just require a compatible kernel), but unfortunately under Linux the...

You don't need to register an encoder, since you are not using that.
Use new DcmPixelSequence(DCM_PixelSequenceTag) and new DcmPixelItem(DCM_PixelItemTag).
Don't forget the call to DcmPixelData::putOriginalRepresentation().