Issue with CT instance and

[thomb]

Hello,
A customer is sending a CT study with transfer syntax: JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [
Selection Value 1])

There are receiving this error on their ClearCanvas server:
2025-01-10 15:12:20,266 [368] ERROR ClearCanvas.Common.Platform - Unable to
transfer SOP 1.3.12.2.1107.5.1.4.246616.30000024121304414405400000909 in study
1.2.840.114350.2.348.2.798268.2.1479512998.1. Remote device does not accept CT
Image Storage in JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [
Selection Value 1]): Default Transfer Syntax for Lossless JPEG Image Compression
transfer syntax
Note: codec is NOT available for JPEG Lossless, Non-Hierarchical, First-Order
Prediction (Process 14 [Selection Value 1]): Default Transfer Syntax for Lossless JPEG
Image Compression

The receiving application is using DCMTK 3.6.8. The code has called
DJDecoderRegistration::registerCodecs ();
DcmRLEDecoderRegistration::registerCodecs ();
when handling the C-STORE.
The dcmjpeg.lib was statically linked to the service using the DCMTK.
What else should I check to understand why the code using the DCMTK can't accept the CT Image Storage in the specified transfer syntax?

Thank you.

[thomb]

I also tried using dcmj2pnm +oj to see if I could convert the image from dicom file to a jpeg. It worked.
However, that file was not stored using a JPEG transfer syntax. Does that matter?
I was only trying to see if the codec and libraries were used to build dcmj2pnm

[J. Riesmeier]

What else should I check to understand why the code using the DCMTK can't accept the CT Image Storage in the specified transfer syntax?

You should check the list of Presentation Contexts that are accepted by your SCP. Receiving compressed DICOM images over the network has nothing to do with registering compression codecs in DCMTK. The latter is needed if you want to compress/decompress DICOM images.

[thomb]

What else should I check to understand why the code using the DCMTK can't accept the CT Image Storage in the specified transfer syntax?

You should check the list of Presentation Contexts that are accepted by your SCP. Receiving compressed DICOM images over the network has nothing to do with registering compression codecs in DCMTK. The latter is needed if you want to compress/decompress DICOM images.

The error log message I received says both a problem with a missing codec and CT.
My first thought was that the codec isn't being loaded for some reason.
What are the steps to be sure the app using DCMTK can load the codec for JPEG decompression (and possibly compression).

I will check the list of Presentation Contexts. What should I be watching for?

[Marco Eichelberg]

Transmission of a DICOM image in JPEG lossless will only work if during association negotiation a presentation context is proposed and accepted where SOP Class is CT Image Storage and Transfer Syntax is JPEG Lossless, Non-Hierarchical, First-Order Prediction (Selection Value 1). This has nothing to do with the availability of a codec, this is simply how DICOM association negotiation works.

[thomb]

Transmission of a DICOM image in JPEG lossless will only work if during association negotiation a presentation context is proposed and accepted where SOP Class is CT Image Storage and Transfer Syntax is JPEG Lossless, Non-Hierarchical, First-Order Prediction (Selection Value 1). This has nothing to do with the availability of a codec, this is simply how DICOM association negotiation works.

I see that we should be accepting CT Image Storage - 1.2.840.10008.5.1.4.1.1.2 (SOP Class UID).
I also see that we should be accepting 1.2.840.10008.1.2.4.70 JPEG Lossless, Nonhierarchical, First- Order Prediction (Processes 14 [Selection Value 1]): Default Transfer Syntax for Lossless JPEG Image Compression

I will double check both of these to be sure the system is properly loading the SOP Class UIDs into the available SOP Class UID list and the same for available transfer syntaxes.

Why would ClearCanvas log mention the codec issue if it's not part of the transfer/association behavior.
I know our code will receive instance files and transfer them to another server. I don't know why it would need to do anything with the codec for that.

[Marco Eichelberg]

In DICOM, the expected behavior of a storage SCU is to first check if an image can be transmitted in compressed form, and if this is not the case, then to silently decompress the image and transmit in uncompressed form. Apparently the SCU does not have a decoder for JPEG lossless, so this fails (and explains the error message).

In detail, you need to look if you can find an accepted presentation context in the A-ASSOCIATE-RSP message that combines "CT Image Storage" as SOP class and "JPEG lossless SV1" as transfer syntax. Otherwise, the SCU will not be able to send in compressed form.