Thanks for trying this out.
Is this something that can be configured in Orthanc?
Marcel
Thanks for trying this out.
Is this something that can be configured in Orthanc?
Marcel
The only configuration as per their docs is this:
// The transfer syntaxes that are accepted by Orthanc C-Store SCP
"DeflatedTransferSyntaxAccepted" : true,
"JpegTransferSyntaxAccepted" : true,
"Jpeg2000TransferSyntaxAccepted" : true,
"JpegLosslessTransferSyntaxAccepted" : true,
"JpipTransferSyntaxAccepted" : true,
"Mpeg2TransferSyntaxAccepted" : true,
"RleTransferSyntaxAccepted" : true,
// Whether Orthanc accepts to act as C-Store SCP for unknown storage
// SOP classes (aka. "promiscuous mode")
"UnknownSopClassAccepted" : true,
We have to keep all of it as true to accept all listed transfer syntaxes. That's it.
I tried to do a Orthanc To Orthanc transfer of JpegLossless image and it was successful (no transcoding involved).
Captured packets here, may be this can shed some light on what is happening. There is difference in Association request sent out by Conquest and Orthanc.
Sorry don't have pcap instelled at the moment, can you explain or post screendump?
Marcel
Orthanc to Orthanc Request:
A-ASSOCIATE request ROUTER --> ORTHANC
Protocol Version: 1
Called AE Title: ORTHANC
Calling AE Title: ROUTER
Application Context: DICOM Application Context Name (1.2.840.10008.3.1.1.1)
Presentation Context: CT Image Storage (1.2.840.10008.5.1.4.1.1.2)
Item Type: Presentation Context (0x20)
Item Length: 59
Context ID: 0x01
Abstract Syntax: CT Image Storage (1.2.840.10008.5.1.4.1.1.2)
Transfer Syntax: JPEG Lossless, Non-Hierarchical (Process 14) (1.2.840.10008.1.2.4.57)
Presentation Context: CT Image Storage (1.2.840.10008.5.1.4.1.1.2)
Item Type: Presentation Context (0x20)
Item Length: 54
Context ID: 0x03
Abstract Syntax: CT Image Storage (1.2.840.10008.5.1.4.1.1.2)
Transfer Syntax: Implicit VR Little Endian: Default Transfer Syntax for DICOM (1.2.840.10008.1.2)
Presentation Context: CT Image Storage (1.2.840.10008.5.1.4.1.1.2)
Item Type: Presentation Context (0x20)
Item Length: 56
Context ID: 0x05
Abstract Syntax: CT Image Storage (1.2.840.10008.5.1.4.1.1.2)
Transfer Syntax: Explicit VR Little Endian (1.2.840.10008.1.2.1)
.
.
.
User Info: Max PDU Length 16384, Implementation UID 1.2.276.0.7230010.3.0.3.6.5, Version OFFIS_DCMTK_365
Orthanc to Orthanc Response:
A-ASSOCIATE accept ROUTER <-- ORTHANC
Protocol Version: 1
Called AE Title: ORTHANC
Calling AE Title: ROUTER
Application Context: DICOM Application Context Name (1.2.840.10008.3.1.1.1)
Presentation Context: ID 0x01, Accept, JPEG Lossless, Non-Hierarchical (Process 14), CT Image Storage
Item Type: Presentation Context Reply (0x21)
Item Length: 30
Context ID: 0x01
Result: Accept (0x0)
Transfer Syntax: JPEG Lossless, Non-Hierarchical (Process 14) (1.2.840.10008.1.2.4.57)
Presentation Context: ID 0x03, Accept, Implicit VR Little Endian: Default Transfer Syntax for DICOM, CT Image Storage
Item Type: Presentation Context Reply (0x21)
Item Length: 25
Context ID: 0x03
Result: Accept (0x0)
Transfer Syntax: Implicit VR Little Endian: Default Transfer Syntax for DICOM (1.2.840.10008.1.2)
Presentation Context: ID 0x05, Accept, Explicit VR Little Endian, CT Image Storage
Item Type: Presentation Context Reply (0x21)
Item Length: 27
Context ID: 0x05
Result: Accept (0x0)
Transfer Syntax: Explicit VR Little Endian (1.2.840.10008.1.2.1)
.
.
.
User Info: Max PDU Length 16384, Implementation UID 1.2.276.0.7230010.3.0.3.6.6, Version OFFIS_DCMTK_366
Conquest to Orthanc Request:
A-ASSOCIATE request CONQUESTSRV2 --> ORTHANC
Protocol Version: 1
Called AE Title: ORTHANC
Calling AE Title: CONQUESTSRV2
Application Context: DICOM Application Context Name (1.2.840.10008.3.1.1.1)
Presentation Context: CT Image Storage (1.2.840.10008.5.1.4.1.1.2)
Item Type: Presentation Context (0x20)
Item Length: 106
Context ID: 0xeb
Abstract Syntax: CT Image Storage (1.2.840.10008.5.1.4.1.1.2)
Transfer Syntax: JPEG Lossless, Non-Hierarchical (Process 14) (1.2.840.10008.1.2.4.57)
Transfer Syntax: JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1]): Default Transfer Syntax for Lossless JPEG Image Compression (1.2.840.10008.1.2.4.70)
Transfer Syntax: Implicit VR Little Endian: Default Transfer Syntax for DICOM (1.2.840.10008.1.2)
User Info: Max PDU Length 32768, Implementation UID 1.2.826.0.1.3680043.2.135.1066.101, Version 1.5.0/WIN32
Orthanc to Conquest Response:
A-ASSOCIATE accept CONQUESTSRV2 <-- ORTHANC
Protocol Version: 1
Called AE Title: ORTHANC
Calling AE Title: CONQUESTSRV2
Application Context: DICOM Application Context Name (1.2.840.10008.3.1.1.1)
Presentation Context: ID 0xeb, Accept, Implicit VR Little Endian: Default Transfer Syntax for DICOM, CT Image Storage
Item Type: Presentation Context Reply (0x21)
Item Length: 25
Context ID: 0xeb
Result: Accept (0x0)
Transfer Syntax: Implicit VR Little Endian: Default Transfer Syntax for DICOM (1.2.840.10008.1.2)
User Info: Max PDU Length 16384, Implementation UID 1.2.276.0.7230010.3.0.3.6.6, Version OFFIS_DCMTK_366
Interesting,
conquest lists CT once with two syntaxes, orthanc lists CT twice with different syntaxes.
If I look at the DICOM standard conquest seems to do it right?
http://dicom.nema.org/dicom/20…html/part07/sect_D.3.html
Marcel
I guess there is an issue during negotiation of association. Orthanc is sending the wrong transfer syntax?
Also, I couldnt find much on this issue except this post from years ago.
Re: JPEG encoded image transfert problem
Let me know if your have any ideas, I am unable to find a solution to this problem and its a critical aspect of my ongoing work.
Or maybe not, some documentation lists that the same abstract sytnax may be proposed more than once (saw in in pydicomnet somewhere). In any case when such a request is proposed to conquest it would accept the first it encounters in the response, which is the highest priority.
Your problem, however, occurs going the other way. I think conquest is talking valid DICOM, and the response of orthanc is allowed, conquest then does as it is told, send uncompressed. Orthanc should not fail on that.
regards,
Marcel
I dont think there is any decompression after orthanc tells to send uncompressed as there are no logs about it in Conquest. Also, in the acrnema.map I have declared orthanc as j2.
I think the image is going as j2 only.
How are the data stored?
conquest would use the accepted compression (I assume).
Marcel
Yes, conquest is storing the images as j2.
If i send uncompressed images to conquest, it compresses it to j2.
If i send j2 images, it stores it as is.
I'll check the code.
Marcel
Hi Marcel
Did you get any insight on how to fix this?
Hi,
the code suggests it recompresses to the accepted compression, i.e. decompresses. Had you tried with debug logging on?
Marcel
Hi,
I just installed Orthanc. Can you talk me through how I reproduce the issue?
Marcel
On my orthanc, setting conquest to j2, and sending from conquest I get:
[CONQUESTSRV2] Accepted compression: ui
[CONQUESTSRV2] Sending file : c:\dicom150beta\data\ATP2019Lung\1.2.826.0.1.3680043.2.135.737059.58899160.7.1563455369.937.87\1.2.826.0.1.3680043.2.135.737059.58899160.7.1563455374.140.1\1.2.826.0.1.3680043.2.135.737059.58899160.7.1563455374.234.3.dcm
[CONQUESTSRV2] C-Move (StudyRoot)
seems to work, although not compressed!
Marcel
Hi,
this is a 32 bits dgate.exe with the the transfer syntax acceptance reversed. On my latest orthanc it was able to receive an image with jpegls encoding. It also lists all proposed syntaxes for debugging.
Can you give it a try?
I would install a test server using all files in install32 and this one renamed to dgate.exe, without dgate64 in the folder.
Marcel
Hi,
I have now spend spend several evenings on this - this code is very complex, and depends greatly on how you transfer. For a C-MOVE initiated by conquest from conquest to orthanc (see #26) you see conquest proposes:
j2
ui
in that order, which is valid dicom. Orthanc chooses to accept ui.
I have tried reversing it.
ui
j2
Orthanc still accepts ui.
On the latest orthanc, ui is then used and the image transferred correctly. Do I need to configure orthanc differently?
The orthanc request style can be programmed but I am afraid that may breaks other systems.
In any case it is in: pdu.cxx, PDU_Service::Connect where it calls PresContext.SetAbstractSyntax, which is overriden in nkiqrsop.cxx, line 4898.
Only if I only propose j2 (I tested jk), orthanc will accept j2 (jk), and then images are sent compressed. Tested by adding
if (RequestedCompressionType[1]!='k') around lines 5050-5053 in nkiqrsop.cxx. But this change may break other operations as well.
Marcel
Hi,
I could allow something like J2! compression, which would then only propose the relevant jpeg compressions without fallback. Would that work?
Marcel
Don’t have an account yet? Register yourself now and be a part of our community!