-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JPEG Lossless incompatible response #4393
Comments
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 |
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! |
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) |
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 notransfer-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.
The text was updated successfully, but these errors were encountered: