JPEG Lossless incompatible response

[liamcarter111]

JPEG Lossless (1.2.840.10008.1.2.4.70) encoded data is not decodable by most web browsers (Chrome, Firefox). Transcoding works as expected when defining the Accept header as multipart/related; type="application/octet-stream";. The issue is that this clashes with supported encodings (1.2.840.10008.1.2.4.50) that are supported by web browsers. Always transcoding is not a solution since the JPEG compression (where is is supported at least) brings massive performance benefits when streaming over the web.
Thus it should be possible to define the transfer syntax for image/jpeg types. Such as

• multipart/related; type="image/jpeg"; transfer-syntax=1.2.840.10008.1.2.4.50, multipart/related; type="application/octet-stream"; transfer-syntax=*
• multipart/related; type="image/jpeg"; transfer-syntax=1.2.840.10008.1.2.4.50, multipart/related; type="application/octet-stream"; transfer-syntax=1.2.840.10008.1.2.4.70.
• multipart/related; type="image/jpeg"; transfer-syntax=1.2.840.10008.1.2.4.50, multipart/related; type="application/octet-stream".

Google Heathcare API supports this behaviour
https://cloud.google.com/healthcare-api/docs/dicom#dicom_frames

Another question, when requesting a JPEG Lossless (1.2.840.10008.1.2.4.70) frame as a image/jpeg why is no transfer-syntax returned in the multipart response as it does for JPEG Baseline (1.2.840.10008.1.2.4.50)? This seems very odd, as there should be no transcoding happening.

If this value was available I could at least determine that the response is not compatible with the browser and re-request it specifically.

[gunterze]

DICOM PS 3.18, Table 8.7.3-5 specifies JPEG Lossless (1.2.840.10008.1.2.4.70) as default Transfer Syntax for Media Type image/jpeg, so appending parameter ; tansfer-syntax=1.2.840.10008.1.2.4.70 to Media Type image/jpeg is redundant - but it also would not harm -> #4399 .

[gunterze]

If you want to get frames for display by the browser, you should rather retrieve them as rendered resource. Just displaying a JPEG Baseline compressed frame disregards possible VOI information from the Metadata!

[liamcarter111]

We handle VOI and Window/Level transformations client side so that we can optimise and cache the download...And since it seems impossible to know the transfer syntax prior to the download request we should be able to at lease define our expected response type per transfer-syntax (either transcoded or original where the client decides)