Transfer JPEG2000 Lossless image fails from Conquest to Orthanc

  • 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.

  • 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

  • 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.

  • 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

    Files

    • dgatea.zip

      (843.34 kB, downloaded 41 times, last: )

    Marcel van Herk is developer of the Conquest DICOM server together with Lambert Zijp.

  • 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

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!