WADO-RS: 8.7.3.3 DICOM Bulkdata Media Types

[Mathieu Malaterre]

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

[gunter zeilinger]

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("�

[gunter zeilinger]

Realized a typo in my previous reply: meant "image/jls" not "image/jpeg-ls".

[Mathieu Malaterre]

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"

Thanks, that really helped !

[gunter zeilinger]

> 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