Can I specify JPEG specific option through *TransferSyntaxAccepted option?

Hi.

I have following option set on Configuration.json for our Orthanc instance

“DeflatedTransferSyntaxAccepted” : true,
“JpegTransferSyntaxAccepted” : true,
“Jpeg2000TransferSyntaxAccepted” : true,
“JpegLosslessTransferSyntaxAccepted” : true,
“JpipTransferSyntaxAccepted” : true,
“Mpeg2TransferSyntaxAccepted” : true,
“RleTransferSyntaxAccepted” : true,

Our orthanc is throwing error messages like following.

E0926 00:54:39.800311 CommandDispatcher.cpp:852] DIMSE failure (aborting association): DIMSE No data available (timeout in non-blocking mode)
E0926 01:00:32.939383 CommandDispatcher.cpp:852] DIMSE failure (aborting association): DIMSE No data available (timeout in non-blocking mode)

My colleague says that he is not having any problem sending our data to his DCMTK’s storescp instance. He then noticed that following storescp options are not currently set in my Configuration.json

+xy: --prefer-jpeg8 (prefer default JPEG lossy TS for 8 bit data)
+xe: --prefer-little (prefer explicit VR little endian TS)
+xx: --prefer-jpeg12 (prefer default JPEG lossy TS for 12 bit data)

Is there an equivalent options that I can set in Orthanc for these options?

Soichi

Hello,

The “TransferSyntaxAccepted” options configure the DICOM C-Store SCP (server). They are not related to the C-Store SCU (client) part, that is used to send DICOM files from Orthanc to another modality as in your question.

In Orthanc, contrarily to the command-line tool “storescu”, the preferred transfer syntax is automatically set by Orthanc depending on the DICOM files that are to be sent. So, there is no possibility, nor need, to set the preferred transfer syntax as is storescu.

As your colleague can send DICOM files to storescp, this means that the problem is most probably in the configuration of the remote modality that sends a timeout error.

Please check the FAQ entry about troubleshooting DICOM communications:
https://orthanc.chu.ulg.ac.be/book/faq/dicom.html

Sébastien-

Sébastien,

Thanks for the reply.

We are still receiving these error messages, but so far we are receiving all images that are sent from my collaborator. I believe the error message can be ignored, but I still don’t know what it means exactly. I think you are right that “the problem is most probably in the configuration of the remote modality that sends a timeout error.”

If someone sees this problem and how to resolve it, I am very interested, but right now this doesn’t seem to be a show-stopper issue.

Soichi