DICOM @ OFFIS

Within the Icon Image Sequence, you will find an image that is either monochrome or palette color. In both cases, Samples per Pixel will be one. As far as I remember, the encoder is permitted to either compress the icon image, or to leave it uncompressed. Decoders need to be able to handle both. I ...

The -ppc option allows you to build very large A-ASSOCIATE-RQ packets for debugging purposes, i.e. for checking whether an association acceptor is able to handle such large packets. Other than that, negotiating more than one presentation context and any specific transfer syntax makes no sense for th...

Thank you for the bug report and test program. I have been able to reproduce the bug and have added it to our issue tracker at https://support.dcmtk.org/redmine/issues/1143.

Same procedure as for JPEG-LS. You need a JPEG 2000 encoder, however, which is not included in DCMTK.
The (commercially available) DCMJP2K module, which is an extension to DCMTK, provides this.

You cannot directly convert JPEG to JPEG-LS. These are two entirely different file formats (despite the similar name). If you want to generate a JPEG-LS encoded DICOM file from a JPEG file, you must use class Image2Dcm to convert the JPEG file to a DICOM file in JPEG Baseline transfer syntax decompr...

The symbol is definitely defined in "i2d.lib". Perhaps there is a problem with the order in which libraries are linked?

Ah, that is another error. I tracked this in DCMTK issue #1141 and fixed it right away (the fix is, of course, trivial).
The commit should be visible in the public git in a few days.

I see two possibilities: During association negotiation, the server does not accept a presentation context for the compressed transfer syntax. In this case, the SCU will decompress the object before transmitting it The image is transmitted in compressed form, but the server does some local processin...

Thank you for the bug report. This bug has been reported before and has been fixed with commit #169030f5a in May 2024, which is publicly available via our Git server or the Github mirror.

Please describe your problem more precisely. Who is sending what where? Furthermore, are you certain that the delay is caused by your application, or could this be a problem on the "other side"?

For your information, I have created an issue in our issue tracker: https://support.dcmtk.org/redmine/issues/1140

There are several problems here: The JPEG decoder will decode a 12-bit JPEG bitstream into an image with BitsAllocated=16. However, the getUncompressedFrameSize() method does not know this and returns a calculation based on BitsAllocated=12. BitsAllocated=12 is not permitted in DICOM. This value mus...

You are generating DICOM files using either the Multi-frame Grayscale Byte SC Image Storage or the Multi-frame True Color SC Image Storage SOP Class. Neither of these SOP classes support the Image Plane Module, where the (0020,0037) Image Orientation (Patient) attribute is defined. In brief, you are...

You mean, we should declare some methods in class DcmJsonFormat virtual that are currently not declared so? That would certainly be possible. Perhaps you could propose a patch.

Unfortunately, JSON does not have official keywords for "not a number" and "infinity". DICOM will define official keywords in CP 2275, which is not public yet. These will probably be the same ones as supported by JavaScript, but in any case DCMTK will write JSON compatible with C...