Transcoding to Deflated Transfer Syntax fails

General
1

I configured Orthanc to store incoming DICOM objects using Deflated transfer syntax.

// If this option is set, Orthanc will transparently transcode any
// incoming DICOM instance to the given transfer syntax before
// storing it into its database. Beware that this might result in
// high CPU usage (if transcoding to some compressed transfer
// syntax), or in higher disk consumption (if transcoding to an
// uncompressed syntax). Also, beware that transcoding to a transfer
// syntax with lossy compression (notably JPEG) will change the
// “SOPInstanceUID” DICOM tag, and thus the Orthanc identifier at
// the instance level, which might break external workflow.
“IngestTranscoding” : “1.2.840.10008.1.2.1.99”,

Orthanc Storage SCP responds to C-STORE RQ with the following error: Refused: OutOfResources

Log:
E0131 20:29:32.140199 DICOM-1 OrthancException.cpp:62] Bad file format: Cannot parse an invalid DICOM file (size: 220381 bytes)
E0131 20:29:32.141192 DICOM-1 StoreScp.cpp:199] Exception while storing DICOM: Bad file format

I tried several different SOP Classes (e.g. CT Image, RT Image), same error.

Any ideas?

2

Hi,

Maybe you could share this offending DICOM file? (possibly after anonymizing it and checking that it still exhibits this behavior after anonymization)

3

Hi, somehow I’m not allowed to upload any attachments. For me, the issue shows up for any CT image (most examples I tried are originally encoded with Implicit VR Little Endian). Does this work for you?

4

Hi,

I have the exact same error, it seems.

======================= END A-ASSOCIATE-AC ======================
T0212 18:24:56.157624 CommandDispatcher.cpp:760] (dicom) Received Command:
===================== INCOMING DIMSE MESSAGE ====================
Message Type                  : C-STORE RQ
Presentation Context ID       : 1
Message ID                    : 1
Affected SOP Class UID        : SecondaryCaptureImageStorage
Affected SOP Instance UID     : 1.2.276.0.7230010.3.1.4.296485376.1.1665793212.499800
Data Set                      : present
Priority                      : medium
======================= END DIMSE MESSAGE =======================
I0212 18:24:56.157624 main.cpp:353] Incoming Store request from AET Local2 on IP 127.0.0.1, calling AET Local1
E0212 18:24:56.234285 OrthancException.cpp:61] Bad file format: Cannot parse an invalid DICOM file (size: 470377 bytes)
E0212 18:24:56.234285 StoreScp.cpp:198] Exception while storing DICOM: Bad file format
I0212 18:24:56.235285 CommandDispatcher.cpp:931] (dicom) Finishing association with AET Local2 on IP 127.0.0.1: DUL Peer Requested Release
I0212 18:24:56.235285 CommandDispatcher.cpp:939] (dicom) Association Release with AET Local2 on IP 127.0.0.1

The Cannot parse an invalid DICOM file message appears even though the file has been correctly C-Stored without IngestTranscoding seconds before (DeflatedTransferSyntaxAccepted was set to `true)

5

I am not a core developer, and my attempts at finding out what’s wrong haven’t lead to anything valuable.

What I can suggest, if you need to compress instances, is to turn on StorageCompression in the Orthanc configuration.

The space that you will save through this setting should be comparable with the deflated syntax one.

HTH

6

Using StorageCompression does not help as in this example Orthanc is used as an intermediate store only. The idea would be that Orthanc not only temporarily stores an instance but also applies the transcoding to Deflated transfer syntax before sending to the remote final store.

Let me know if I should create an issue for this (Deflated does not work for IngestTranscoding).

Does Orthanc’s REST API support the transcoding when being sent to the remote SCP?

7

OK, I understand your issue.

Transcoding to a remote SCP is only supported for decompression.

Full transcoding, is available when sending on http(s) to another Orthanc peer:

$ curl -X POST http://localhost:8042/peers/sample/store -d '{"Transcode":"1.2.840.10008.1.2.4.70","Resources":["66c8e41e-ac3a9029-0b85e42a-8195ee0a-92c2e62e"]}'

(excerpt from Orthanc Book)

However, I just tested it with 1.2.840.10008.1.2.1.99 and it does not work either.

As a last resort, you might rely on an external transcoding tool. You can integrate this with Orthanc rather smoothly, for instance by implementing the solution described in this Lua example where you would use:

os.execute('gdcmconv -t 1.2.840.10008.1.2.1.99 ' .. uncompressed .. ' ' .. compressed)

To make gdcm available, you would need to install it.

If you are using a container based workflow, on the Orthanc Team container, you would use apt update and apt install libgdcm-tools

The Dockerfile would look like this:

FROM orthancteam/orthanc:24.11.0

USER root
RUN apt update && apt install -y libgdcm-tools

USER orthanc

(please replace with the actual version you want to use)

If you want to go down that route and do not feel comfortable with some (or all) of the steps, feel free to ask and we’ll try to help!

Regarding the creation of a ticket, I don’t know. Let’s see if a core dev chimes in with some advice.

HTH

8

Well, it seems we do not build DCMTK with ZLib support which explain why Orthanc is not able to compress it:

image
image516Ă—433 16.6 KB

It seems GDCM is able to compress it but, later, we still use DCMTK to parse the compressed file (at least the DICOM header) and therefore, it fails later.

So, it seems that, right now, Orthanc does not really support 1.2.840.10008.1.2.1.99.

I have added it to our TODO but I’m afraid that’s something only @jodogne can handle since he is our compilation guru :wink:

1 Like
9

Hello,

This is done by the following changeset.

Regards,
SĂ©bastien-

2 Likes
10

Hello,
I still see the same problem with latest Orthanc 25.2.0 release. I now also tried to send (DIMSE) a general CT image encoded in Deflated transfer syntax to Orthanc Storage SCP. It still fails. It also fails when uploading the same Deflated file through the Orthanc Explorer web UI:

E0310 11:50:50.348978           HTTP-5 OrthancException.cpp:62] Bad file format: Cannot parse an invalid DICOM file (size: 6431275 bytes)

Is the changeset you mentioned above included in 25.2.0 release and is it supposed to fix the handling of Deflated objects?
Thanks for looking into this.

11

Hi Thomas,

No, this is not yet included. 25.2.0 still packages Orthanc 1.12.6.

This is how you can get access to mainline binaries.

HTH,

Alain

12

Hi Alain,

I now used Orthanc.exe from mainline 2025-03-10. With that version Orthanc Storage SCP does not fail anymore when sending a deflated CT image. However, the size of the stored file in the Orthanc folder equals the size of the inflated/uncompressed CT image. The transfer syntax in the stored file is still Deflated, the dataset is indeed deflated as well and the space after the Deflated byte stream is filled with 00’s. It looks as Orthanc wrongly allocates the file size of the inflated/uncompressed object.
Uploading the same deflated CT image through the Orthanc Explorer works without any issue, i.e. the size of the file equals the deflated size of the CT image.
Can you please look into this?

Thanks!

Thomas

13

Hi @thomas.schwere

I have now fixed it in this commit.

Validated with this new test.

This change shall soon be available in the mainline binaries.

Best regards,

Alain.