1. Forum
  2. Usenet
  3. COMP.PROTOCOLS.DICOM

  • WADO-RS: 8.7.3.3 DICOM Bulkdata Media Types

    From Mathieu Malaterre@21:1/5 to All on Fri Feb 19 02:11:16 2021
    Hi there,

    I am trying to understand how a WADO-RS client can retrieve compressed Frames from a server without the server doing any transcoding (1).

    Let's assume the server only stores instances using either JPEG-LS lossless or JPEG Lossy transfer syntaxes (8bits for simplicity).

    I can retrieve the frame #1 without server-side transcoding using either:

    (lossless transfer):

    $ curl -H 'Accept: multipart/related; type=image/dicom+jpeg-ls' -o frame1.part "http://acme.corp:8042/dicom-web/studies/1.2.3/series/4.5.6/instances/7.8.9/frames/1"

    or (lossy transfer):

    $ curl -H 'Accept: multipart/related; type=image/dicom+jpeg; transfer-syntax=1.2.840.10008.1.2.4.50' -o frame1.part "http://acme.corp:8042/dicom-web/studies/2.3.4/series/5.6.7/instances/8.9.0/frames/1"

    It seems that 'transfer-syntax' parameter can be set to '*' precisely for this scenario (2), but that would still leave an open question for the 'type' parameter.

    Since I can only query the DataSet (3) but not the Meta Data Header, how do I know which compression is used on the server-side to avoid the server doing transcoding ?

    Thanks,

    References:
    (1) http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_8.7.3.3.2.html#table_8.7.3-5
    (2) http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_8.7.3.5.2.html
    (3) http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_10.4.html#table_10.4.1-2

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gunter zeilinger@21:1/5 to gunter zeilinger on Wed Feb 24 06:54:32 2021
    Realized a typo in my previous reply: meant "image/jls" not "image/jpeg-ls".

    On Wednesday, February 24, 2021 at 3:46:54 PM UTC+1, gunter zeilinger wrote:
    Guess you meant "image/jpeg" and "image/jpeg-ls", not "image/dicom+jpeg" and "image/dicom+jpeg-ls"!

    According my understanding, parameter "transfer-syntax=1.2.840.10008.1.2.4.50" is only specified for "application/dicom", not for "image/jpeg" and "image/jpeg-ls".

    You may specify to accept multiple content types ; either comma separated in one Accept header field or using multiple Accept header. E.g.

    $ curl -v -H 'Accept: multipart/related;type="image/jls",multipart/related;type="image/jpeg"' -o frame1.part http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.12.2.1107.5.4.3.123456789012345.19950922.121803.6/series/1.3.12.2.1107.5.4.3.
    123456789012345.19950922.121803.8/instances/1.3.12.2.1107.5.4.3.321890.19960124.162922.29/frames/1
    * TCP_NODELAY set
    * Connected to localhost (127.0.0.1) port 8080 (#0)
    GET /dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.12.2.1107.5.4.3.123456789012345.19950922.121803.6/series/1.3.12.2.1107.5.4.3.123456789012345.19950922.121803.8/instances/1.3.12.2.1107.5.4.3.321890.19960124.162922.29/frames/1 HTTP/1.1
    Host: localhost:8080
    User-Agent: curl/7.68.0
    Accept: multipart/related;type="image/jls",multipart/related;type="image/jpeg"

    * Mark bundle as not supporting multiuse
    < HTTP/1.1 200 OK
    < Access-Control-Allow-Headers: origin, content-type, accept, authorization < Date: Wed, 24 Feb 2021 14:35:50 GMT
    < Connection: keep-alive
    < Access-Control-Allow-Origin: *
    < ETag: "-733195899"
    < Last-Modified: Wed, 24 Feb 2021 13:48:27 GMT
    < Access-Control-Allow-Credentials: true
    < Transfer-Encoding: chunked
    < Content-Type: multipart/related;start="<89754e5f-be81-4160-b5e2-ed53b98fa6f9@resteasy-multipart>";type="image/jpeg"; boundary=2846ced2-ac69-478e-b5f3-d48e34f3c3e0
    < Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
    <
    { [16392 bytes data]
    * Connection #0 to host localhost left intact

    or

    $ curl -v -H 'Accept: multipart/related;type="image/jls"' -H 'Accept: multipart/related;type="image/jpeg"' -o frame1.part http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.6.1.4.1.5962.1.2.1.20040826185059.5457/series/1.3.6.1.4.1.5962.1.3.
    1.1.20040826185059.5457/instances/1.3.6.1.4.1.5962.1.1.1.1.6.20040826185059.5457/frames/1
    * TCP_NODELAY set
    * Connected to localhost (127.0.0.1) port 8080 (#0)
    GET /dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.6.1.4.1.5962.1.2.1.20040826185059.5457/series/1.3.6.1.4.1.5962.1.3.1.1.20040826185059.5457/instances/1.3.6.1.4.1.5962.1.1.1.1.6.20040826185059.5457/frames/1 HTTP/1.1
    Host: localhost:8080
    User-Agent: curl/7.68.0
    Accept: multipart/related;type="image/jls"
    Accept: multipart/related;type="image/jpeg"

    * Mark bundle as not supporting multiuse
    < HTTP/1.1 200 OK
    < Access-Control-Allow-Headers: origin, content-type, accept, authorization < Date: Wed, 24 Feb 2021 14:40:40 GMT
    < Connection: keep-alive
    < Access-Control-Allow-Origin: *
    < ETag: "-733226512"
    < Last-Modified: Wed, 24 Feb 2021 13:47:56 GMT
    < Access-Control-Allow-Credentials: true
    < Transfer-Encoding: chunked
    < Content-Type: multipart/related;start="<fa33e404-0b17-43c3-a7b9-c6bb9fd42b17@resteasy-multipart>";type="image/jls"; boundary=566a98d1-ef0f-41a8-afc3-c050ed13539f
    < Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
    <
    { [16778 bytes data]
    * Connection #0 to host localhost left intact

    Be aware, that the received object is wrapped in a multipart/related mime message. E.g.:

    $ head -n6 frame1.part
    --566a98d1-ef0f-41a8-afc3-c050ed13539f
    Content-Location: http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.6.1.4.1.5962.1.2.1.20040826185059.5457/series/1.3.6.1.4.1.5962.1.3.1.1.20040826185059.5457/instances/1.3.6.1.4.1.5962.1.1.1.1.6.20040826185059.5457/frames/1
    Content-ID: <fa33e404-0b17-43c3-a7b9-c6bb9fd42b17@resteasy-multipart> Content-Type: image/jls

    ����
    ��C@�=�@ @ @ B�B�B�B�""""""""""""""""$�I$�I$�I$�I*����������4$���9�H��yY�zHH����<{T��a�Ϣ���$@�6("�
    On Friday, February 19, 2021 at 11:11:18 AM UTC+1, Mathieu Malaterre wrote:
    Hi there,

    I am trying to understand how a WADO-RS client can retrieve compressed Frames from a server without the server doing any transcoding (1).

    Let's assume the server only stores instances using either JPEG-LS lossless or JPEG Lossy transfer syntaxes (8bits for simplicity).

    I can retrieve the frame #1 without server-side transcoding using either:

    (lossless transfer):

    $ curl -H 'Accept: multipart/related; type=image/dicom+jpeg-ls' -o frame1.part "http://acme.corp:8042/dicom-web/studies/1.2.3/series/4.5.6/instances/7.8.9/frames/1"

    or (lossy transfer):

    $ curl -H 'Accept: multipart/related; type=image/dicom+jpeg; transfer-syntax=1.2.840.10008.1.2.4.50' -o frame1.part "http://acme.corp:8042/dicom-web/studies/2.3.4/series/5.6.7/instances/8.9.0/frames/1"

    It seems that 'transfer-syntax' parameter can be set to '*' precisely for this scenario (2), but that would still leave an open question for the 'type' parameter.

    Since I can only query the DataSet (3) but not the Meta Data Header, how do I know which compression is used on the server-side to avoid the server doing transcoding ?

    Thanks,

    References:
    (1) http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_8.7.3.3.2.html#table_8.7.3-5
    (2) http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_8.7.3.5.2.html
    (3) http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_10.4.html#table_10.4.1-2

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gunter zeilinger@21:1/5 to Mathieu Malaterre on Wed Feb 24 06:46:52 2021
    Guess you meant "image/jpeg" and "image/jpeg-ls", not "image/dicom+jpeg" and "image/dicom+jpeg-ls"!

    According my understanding, parameter "transfer-syntax=1.2.840.10008.1.2.4.50" is only specified for "application/dicom", not for "image/jpeg" and "image/jpeg-ls".

    You may specify to accept multiple content types ; either comma separated in one Accept header field or using multiple Accept header. E.g.

    $ curl -v -H 'Accept: multipart/related;type="image/jls",multipart/related;type="image/jpeg"' -o frame1.part http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.12.2.1107.5.4.3.123456789012345.19950922.121803.6/series/1.3.12.2.1107.5.4.3.
    123456789012345.19950922.121803.8/instances/1.3.12.2.1107.5.4.3.321890.19960124.162922.29/frames/1
    * TCP_NODELAY set
    * Connected to localhost (127.0.0.1) port 8080 (#0)
    GET /dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.12.2.1107.5.4.3.123456789012345.19950922.121803.6/series/1.3.12.2.1107.5.4.3.123456789012345.19950922.121803.8/instances/1.3.12.2.1107.5.4.3.321890.19960124.162922.29/frames/1 HTTP/1.1
    Host: localhost:8080
    User-Agent: curl/7.68.0
    Accept: multipart/related;type="image/jls",multipart/related;type="image/jpeg"

    * Mark bundle as not supporting multiuse
    < HTTP/1.1 200 OK
    < Access-Control-Allow-Headers: origin, content-type, accept, authorization
    < Date: Wed, 24 Feb 2021 14:35:50 GMT
    < Connection: keep-alive
    < Access-Control-Allow-Origin: *
    < ETag: "-733195899"
    < Last-Modified: Wed, 24 Feb 2021 13:48:27 GMT
    < Access-Control-Allow-Credentials: true
    < Transfer-Encoding: chunked
    < Content-Type: multipart/related;start="<89754e5f-be81-4160-b5e2-ed53b98fa6f9@resteasy-multipart>";type="image/jpeg"; boundary=2846ced2-ac69-478e-b5f3-d48e34f3c3e0
    < Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
    <
    { [16392 bytes data]
    * Connection #0 to host localhost left intact

    or

    $ curl -v -H 'Accept: multipart/related;type="image/jls"' -H 'Accept: multipart/related;type="image/jpeg"' -o frame1.part http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.6.1.4.1.5962.1.2.1.20040826185059.5457/series/1.3.6.1.4.1.5962.1.3.
    1.1.20040826185059.5457/instances/1.3.6.1.4.1.5962.1.1.1.1.6.20040826185059.5457/frames/1
    * TCP_NODELAY set
    * Connected to localhost (127.0.0.1) port 8080 (#0)
    GET /dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.6.1.4.1.5962.1.2.1.20040826185059.5457/series/1.3.6.1.4.1.5962.1.3.1.1.20040826185059.5457/instances/1.3.6.1.4.1.5962.1.1.1.1.6.20040826185059.5457/frames/1 HTTP/1.1
    Host: localhost:8080
    User-Agent: curl/7.68.0
    Accept: multipart/related;type="image/jls"
    Accept: multipart/related;type="image/jpeg"

    * Mark bundle as not supporting multiuse
    < HTTP/1.1 200 OK
    < Access-Control-Allow-Headers: origin, content-type, accept, authorization
    < Date: Wed, 24 Feb 2021 14:40:40 GMT
    < Connection: keep-alive
    < Access-Control-Allow-Origin: *
    < ETag: "-733226512"
    < Last-Modified: Wed, 24 Feb 2021 13:47:56 GMT
    < Access-Control-Allow-Credentials: true
    < Transfer-Encoding: chunked
    < Content-Type: multipart/related;start="<fa33e404-0b17-43c3-a7b9-c6bb9fd42b17@resteasy-multipart>";type="image/jls"; boundary=566a98d1-ef0f-41a8-afc3-c050ed13539f
    < Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
    <
    { [16778 bytes data]
    * Connection #0 to host localhost left intact

    Be aware, that the received object is wrapped in a multipart/related mime message. E.g.:

    $ head -n6 frame1.part
    --566a98d1-ef0f-41a8-afc3-c050ed13539f
    Content-Location: http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.6.1.4.1.5962.1.2.1.20040826185059.5457/series/1.3.6.1.4.1.5962.1.3.1.1.20040826185059.5457/instances/1.3.6.1.4.1.5962.1.1.1.1.6.20040826185059.5457/frames/1
    Content-ID: <fa33e404-0b17-43c3-a7b9-c6bb9fd42b17@resteasy-multipart> Content-Type: image/jls

    ����
    ��C@�=�@ @ @ B�B�B�B�""""""""""""""""$�I$�I$�I$�I*����������4$���9�H��yY�zHH����<{T��a�Ϣ���$@�6("�




    On Friday, February 19, 2021 at 11:11:18 AM UTC+1, Mathieu Malaterre wrote:
    Hi there,

    I am trying to understand how a WADO-RS client can retrieve compressed Frames from a server without the server doing any transcoding (1).

    Let's assume the server only stores instances using either JPEG-LS lossless or JPEG Lossy transfer syntaxes (8bits for simplicity).

    I can retrieve the frame #1 without server-side transcoding using either:

    (lossless transfer):

    $ curl -H 'Accept: multipart/related; type=image/dicom+jpeg-ls' -o frame1.part "http://acme.corp:8042/dicom-web/studies/1.2.3/series/4.5.6/instances/7.8.9/frames/1"

    or (lossy transfer):

    $ curl -H 'Accept: multipart/related; type=image/dicom+jpeg; transfer-syntax=1.2.840.10008.1.2.4.50' -o frame1.part "http://acme.corp:8042/dicom-web/studies/2.3.4/series/5.6.7/instances/8.9.0/frames/1"

    It seems that 'transfer-syntax' parameter can be set to '*' precisely for this scenario (2), but that would still leave an open question for the 'type' parameter.

    Since I can only query the DataSet (3) but not the Meta Data Header, how do I know which compression is used on the server-side to avoid the server doing transcoding ?

    Thanks,

    References:
    (1) http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_8.7.3.3.2.html#table_8.7.3-5
    (2) http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_8.7.3.5.2.html
    (3) http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_10.4.html#table_10.4.1-2

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mathieu Malaterre@21:1/5 to gunter zeilinger on Wed Feb 24 07:24:06 2021
    Thanks Gunter !

    On Wednesday, February 24, 2021 at 3:54:34 PM UTC+1, gunter zeilinger wrote:
    Realized a typo in my previous reply: meant "image/jls" not "image/jpeg-ls". On Wednesday, February 24, 2021 at 3:46:54 PM UTC+1, gunter zeilinger wrote:
    Guess you meant "image/jpeg" and "image/jpeg-ls", not "image/dicom+jpeg" and "image/dicom+jpeg-ls"!

    According my understanding, parameter "transfer-syntax=1.2.840.10008.1.2.4.50" is only specified for "application/dicom", not for "image/jpeg" and "image/jpeg-ls".

    You are right! The patch has been submitted upstream:

    https://github.com/cornerstonejs/cornerstoneWADOImageLoader/pull/359

    So the request to explicitly state you don't want server side decoding is:

    curl -H 'Accept: multipart/related; type="application/octet-stream"; transfer-syntax=*' -o frame1.part "http://acme.corp:8042/dicom-web/studies/2.3.4/series/5.6.7/instances/8.9.0/frames/1"



    You may specify to accept multiple content types ; either comma separated in one Accept header field or using multiple Accept header. E.g.

    $ curl -v -H 'Accept: multipart/related;type="image/jls",multipart/related;type="image/jpeg"' -o frame1.part http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.12.2.1107.5.4.3.123456789012345.19950922.121803.6/series/1.3.12.2.1107.5.4.3.
    123456789012345.19950922.121803.8/instances/1.3.12.2.1107.5.4.3.321890.19960124.162922.29/frames/1
    * TCP_NODELAY set
    * Connected to localhost (127.0.0.1) port 8080 (#0)
    GET /dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.12.2.1107.5.4.3.123456789012345.19950922.121803.6/series/1.3.12.2.1107.5.4.3.123456789012345.19950922.121803.8/instances/1.3.12.2.1107.5.4.3.321890.19960124.162922.29/frames/1 HTTP/1.1
    Host: localhost:8080
    User-Agent: curl/7.68.0
    Accept: multipart/related;type="image/jls",multipart/related;type="image/jpeg"

    * Mark bundle as not supporting multiuse
    < HTTP/1.1 200 OK
    < Access-Control-Allow-Headers: origin, content-type, accept, authorization
    < Date: Wed, 24 Feb 2021 14:35:50 GMT
    < Connection: keep-alive
    < Access-Control-Allow-Origin: *
    < ETag: "-733195899"
    < Last-Modified: Wed, 24 Feb 2021 13:48:27 GMT
    < Access-Control-Allow-Credentials: true
    < Transfer-Encoding: chunked
    < Content-Type: multipart/related;start="<89754e5f-be81-4160-b5e2-ed53b98fa6f9@resteasy-multipart>";type="image/jpeg"; boundary=2846ced2-ac69-478e-b5f3-d48e34f3c3e0
    < Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
    <
    { [16392 bytes data]
    * Connection #0 to host localhost left intact

    or

    $ curl -v -H 'Accept: multipart/related;type="image/jls"' -H 'Accept: multipart/related;type="image/jpeg"' -o frame1.part http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.6.1.4.1.5962.1.2.1.20040826185059.5457/series/1.3.6.1.4.1.5962.1.
    3.1.1.20040826185059.5457/instances/1.3.6.1.4.1.5962.1.1.1.1.6.20040826185059.5457/frames/1
    * TCP_NODELAY set
    * Connected to localhost (127.0.0.1) port 8080 (#0)
    GET /dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.6.1.4.1.5962.1.2.1.20040826185059.5457/series/1.3.6.1.4.1.5962.1.3.1.1.20040826185059.5457/instances/1.3.6.1.4.1.5962.1.1.1.1.6.20040826185059.5457/frames/1 HTTP/1.1
    Host: localhost:8080
    User-Agent: curl/7.68.0
    Accept: multipart/related;type="image/jls"
    Accept: multipart/related;type="image/jpeg"

    * Mark bundle as not supporting multiuse
    < HTTP/1.1 200 OK
    < Access-Control-Allow-Headers: origin, content-type, accept, authorization
    < Date: Wed, 24 Feb 2021 14:40:40 GMT
    < Connection: keep-alive
    < Access-Control-Allow-Origin: *
    < ETag: "-733226512"
    < Last-Modified: Wed, 24 Feb 2021 13:47:56 GMT
    < Access-Control-Allow-Credentials: true
    < Transfer-Encoding: chunked
    < Content-Type: multipart/related;start="<fa33e404-0b17-43c3-a7b9-c6bb9fd42b17@resteasy-multipart>";type="image/jls"; boundary=566a98d1-ef0f-41a8-afc3-c050ed13539f
    < Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
    <
    { [16778 bytes data]
    * Connection #0 to host localhost left intact

    Be aware, that the received object is wrapped in a multipart/related mime message. E.g.:


    Thanks, that really helped !

    $ head -n6 frame1.part
    --566a98d1-ef0f-41a8-afc3-c050ed13539f
    Content-Location: http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.6.1.4.1.5962.1.2.1.20040826185059.5457/series/1.3.6.1.4.1.5962.1.3.1.1.20040826185059.5457/instances/1.3.6.1.4.1.5962.1.1.1.1.6.20040826185059.5457/frames/1
    Content-ID: <fa33e404-0b17-43c3-a7b9-c6bb9fd42b17@resteasy-multipart> Content-Type: image/jls

    ����
    ��C@�=�@ @ @ B�B�B�B�""""""""""""""""$�I$�I$�I$�I*����������4$���9�H��yY�zHH����<{T��a�Ϣ���$@�6("�
    On Friday, February 19, 2021 at 11:11:18 AM UTC+1, Mathieu Malaterre wrote:
    Hi there,

    I am trying to understand how a WADO-RS client can retrieve compressed Frames from a server without the server doing any transcoding (1).

    Let's assume the server only stores instances using either JPEG-LS lossless or JPEG Lossy transfer syntaxes (8bits for simplicity).

    I can retrieve the frame #1 without server-side transcoding using either:

    (lossless transfer):

    $ curl -H 'Accept: multipart/related; type=image/dicom+jpeg-ls' -o frame1.part "http://acme.corp:8042/dicom-web/studies/1.2.3/series/4.5.6/instances/7.8.9/frames/1"

    or (lossy transfer):

    $ curl -H 'Accept: multipart/related; type=image/dicom+jpeg; transfer-syntax=1.2.840.10008.1.2.4.50' -o frame1.part "http://acme.corp:8042/dicom-web/studies/2.3.4/series/5.6.7/instances/8.9.0/frames/1"

    It seems that 'transfer-syntax' parameter can be set to '*' precisely for this scenario (2), but that would still leave an open question for the 'type' parameter.

    Since I can only query the DataSet (3) but not the Meta Data Header, how do I know which compression is used on the server-side to avoid the server doing transcoding ?

    Thanks,

    References:
    (1) http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_8.7.3.3.2.html#table_8.7.3-5
    (2) http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_8.7.3.5.2.html
    (3) http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_10.4.html#table_10.4.1-2

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gunter zeilinger@21:1/5 to Mathieu Malaterre on Wed Feb 24 08:08:35 2021
    curl -H 'Accept: multipart/related; type="application/octet-stream"; transfer-syntax=*' -o frame1.part "http://acme.corp:8042/dicom-web/studies/2.3.4/series/5.6.7/instances/8.9.0/frames/1"

    would actually force the server to decompress the frame - if it is stored compressed - ( transfer-syntax=* does also not apply to application/octet-stream, as it does not for image/*).

    To enable to return frames JPEG Baseline , JPEG LS Lossless or uncompressed, you may specify
    - all three content types in (the) Accept header field(s)
    - multipart/related; type="application/octet-stream" and multipart/related; type="image/*"
    - or just "*/*"
    as Accept Header(s).

    The last option is possible, because the URL pattern SERVICE/studies/{study}/series/{series}/instances/{instance}/frames/{frame-list} only defines a Bulkdata response, in opposite to

    SERVICE/studies/{study}
    SERVICE/studies/{study}/series/{series} SERVICE/studies/{study}/series/{series}/instances/{instance}

    which are used to retrieve DICOM Part 10 **or** Bulkdata dependent on the Accept Header, better described in versions of PS 3.18 previous to 2019b:
    http://dicom.nema.org/medical/dicom/2019a/output/html/part18.html#sect_6.5.1.2.2

    CP 2049 (Ballot) will restore the part lost in 2019b: : ftp://medical.nema.org/medical/dicom/cp/cp2040_lb_Fix_DicomWeb_DICOM_Media_Types.pdf



    On Wednesday, February 24, 2021 at 4:24:08 PM UTC+1, Mathieu Malaterre wrote:
    Thanks Gunter !
    On Wednesday, February 24, 2021 at 3:54:34 PM UTC+1, gunter zeilinger wrote:
    Realized a typo in my previous reply: meant "image/jls" not "image/jpeg-ls".
    On Wednesday, February 24, 2021 at 3:46:54 PM UTC+1, gunter zeilinger wrote:
    Guess you meant "image/jpeg" and "image/jpeg-ls", not "image/dicom+jpeg" and "image/dicom+jpeg-ls"!

    According my understanding, parameter "transfer-syntax=1.2.840.10008.1.2.4.50" is only specified for "application/dicom", not for "image/jpeg" and "image/jpeg-ls".
    You are right! The patch has been submitted upstream:

    https://github.com/cornerstonejs/cornerstoneWADOImageLoader/pull/359

    So the request to explicitly state you don't want server side decoding is:

    curl -H 'Accept: multipart/related; type="application/octet-stream"; transfer-syntax=*' -o frame1.part "http://acme.corp:8042/dicom-web/studies/2.3.4/series/5.6.7/instances/8.9.0/frames/1"
    You may specify to accept multiple content types ; either comma separated in one Accept header field or using multiple Accept header. E.g.

    $ curl -v -H 'Accept: multipart/related;type="image/jls",multipart/related;type="image/jpeg"' -o frame1.part http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.12.2.1107.5.4.3.123456789012345.19950922.121803.6/series/1.3.12.2.1107.5.4.
    3.123456789012345.19950922.121803.8/instances/1.3.12.2.1107.5.4.3.321890.19960124.162922.29/frames/1
    * TCP_NODELAY set
    * Connected to localhost (127.0.0.1) port 8080 (#0)
    GET /dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.12.2.1107.5.4.3.123456789012345.19950922.121803.6/series/1.3.12.2.1107.5.4.3.123456789012345.19950922.121803.8/instances/1.3.12.2.1107.5.4.3.321890.19960124.162922.29/frames/1 HTTP/1.1
    Host: localhost:8080
    User-Agent: curl/7.68.0
    Accept: multipart/related;type="image/jls",multipart/related;type="image/jpeg"

    * Mark bundle as not supporting multiuse
    < HTTP/1.1 200 OK
    < Access-Control-Allow-Headers: origin, content-type, accept, authorization
    < Date: Wed, 24 Feb 2021 14:35:50 GMT
    < Connection: keep-alive
    < Access-Control-Allow-Origin: *
    < ETag: "-733195899"
    < Last-Modified: Wed, 24 Feb 2021 13:48:27 GMT
    < Access-Control-Allow-Credentials: true
    < Transfer-Encoding: chunked
    < Content-Type: multipart/related;start="<89754e5f-be81-4160-b5e2-ed53b98fa6f9@resteasy-multipart>";type="image/jpeg"; boundary=2846ced2-ac69-478e-b5f3-d48e34f3c3e0
    < Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
    <
    { [16392 bytes data]
    * Connection #0 to host localhost left intact

    or

    $ curl -v -H 'Accept: multipart/related;type="image/jls"' -H 'Accept: multipart/related;type="image/jpeg"' -o frame1.part http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.6.1.4.1.5962.1.2.1.20040826185059.5457/series/1.3.6.1.4.1.5962.
    1.3.1.1.20040826185059.5457/instances/1.3.6.1.4.1.5962.1.1.1.1.6.20040826185059.5457/frames/1
    * TCP_NODELAY set
    * Connected to localhost (127.0.0.1) port 8080 (#0)
    GET /dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.6.1.4.1.5962.1.2.1.20040826185059.5457/series/1.3.6.1.4.1.5962.1.3.1.1.20040826185059.5457/instances/1.3.6.1.4.1.5962.1.1.1.1.6.20040826185059.5457/frames/1 HTTP/1.1
    Host: localhost:8080
    User-Agent: curl/7.68.0
    Accept: multipart/related;type="image/jls"
    Accept: multipart/related;type="image/jpeg"

    * Mark bundle as not supporting multiuse
    < HTTP/1.1 200 OK
    < Access-Control-Allow-Headers: origin, content-type, accept, authorization
    < Date: Wed, 24 Feb 2021 14:40:40 GMT
    < Connection: keep-alive
    < Access-Control-Allow-Origin: *
    < ETag: "-733226512"
    < Last-Modified: Wed, 24 Feb 2021 13:47:56 GMT
    < Access-Control-Allow-Credentials: true
    < Transfer-Encoding: chunked
    < Content-Type: multipart/related;start="<fa33e404-0b17-43c3-a7b9-c6bb9fd42b17@resteasy-multipart>";type="image/jls"; boundary=566a98d1-ef0f-41a8-afc3-c050ed13539f
    < Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
    <
    { [16778 bytes data]
    * Connection #0 to host localhost left intact

    Be aware, that the received object is wrapped in a multipart/related mime message. E.g.:

    Thanks, that really helped !
    $ head -n6 frame1.part
    --566a98d1-ef0f-41a8-afc3-c050ed13539f
    Content-Location: http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.6.1.4.1.5962.1.2.1.20040826185059.5457/series/1.3.6.1.4.1.5962.1.3.1.1.20040826185059.5457/instances/1.3.6.1.4.1.5962.1.1.1.1.6.20040826185059.5457/frames/1
    Content-ID: <fa33e404-0b17-43c3-a7b9-c6bb9fd42b17@resteasy-multipart> Content-Type: image/jls

    ����
    ��C@�=�@ @ @ B�B�B�B�""""""""""""""""$�I$�I$�I$�I*����������4$���9�H��yY�zHH����<{T��a�Ϣ���$@�6("�
    On Friday, February 19, 2021 at 11:11:18 AM UTC+1, Mathieu Malaterre wrote:
    Hi there,

    I am trying to understand how a WADO-RS client can retrieve compressed Frames from a server without the server doing any transcoding (1).

    Let's assume the server only stores instances using either JPEG-LS lossless or JPEG Lossy transfer syntaxes (8bits for simplicity).

    I can retrieve the frame #1 without server-side transcoding using either:

    (lossless transfer):

    $ curl -H 'Accept: multipart/related; type=image/dicom+jpeg-ls' -o frame1.part "http://acme.corp:8042/dicom-web/studies/1.2.3/series/4.5.6/instances/7.8.9/frames/1"

    or (lossy transfer):

    $ curl -H 'Accept: multipart/related; type=image/dicom+jpeg; transfer-syntax=1.2.840.10008.1.2.4.50' -o frame1.part "http://acme.corp:8042/dicom-web/studies/2.3.4/series/5.6.7/instances/8.9.0/frames/1"

    It seems that 'transfer-syntax' parameter can be set to '*' precisely for this scenario (2), but that would still leave an open question for the 'type' parameter.

    Since I can only query the DataSet (3) but not the Meta Data Header, how do I know which compression is used on the server-side to avoid the server doing transcoding ?

    Thanks,

    References:
    (1) http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_8.7.3.3.2.html#table_8.7.3-5
    (2) http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_8.7.3.5.2.html
    (3) http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_10.4.html#table_10.4.1-2

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)