| DICOM PS3.18 2019e - Web Services |
|---|
Compressed Bulkdata contains only the compressed octet stream without the fragment delimiters.
Table 8.7.3-5 specifies the default and optional media types and Transfer Syntax UID combinations for each Resource Category (see Table 8.7.2-1) of compressed Bulkdata for the RESTful services.
Some of the Transfer Syntax Names include text about Default Transfer Syntax, however this applies to its role in DIMSE transactions, rather than the default for RESTful services (which is specified in the RESTful column of the table).
These media types can be used to retrieve Bulkdata, such as images or video, encoded in a specific Transfer Syntax.
Table 8.7.3-5. Media Types and Transfer Syntax UIDs for Compressed Data in Bulkdata
The origin server may support additional Transfer Syntaxes.
For the media type image/jpeg Transfer Syntaxes, the image may or may not include the JFIF marker segment. The image may or may not include APP2 marker segments with an identifier of "ICC_PROFILE". There is no requirement for the origin server to add a JFIF marker segment nor to copy the value of the ICC Profile (0028,2000) Attribute, if present, into APP2 marker segments in the compressed data stream. See Section 8.2.1 “JPEG Image Compression” in PS3.5.
For the media type image/jp2 and image/jpx Transfer Syntaxes, the image does not include the jp2 marker segment. See Section 8.2.4 “JPEG 2000 Image Compression” in PS3.5 and Section A.4.4 “JPEG 2000 Image Compression” in PS3.5
The resource on the origin server may have been encoded in the Deflated Explicit VR Little Endian (1.2.840.10008.1.2.1.99) Transfer Syntax. If so, the origin server may inflate it, and then convert it into an Acceptable Transfer Syntax. Alternatively, if the user agent allowed a Content-Encoding header field of 'deflate', then the deflated bytes may be transferred unaltered, but the Transfer Syntax parameter in the response should be the Explicit VR Little Endian Transfer Syntax.
Compressed multi-frame image Bulkdata is encoded as one frame per part. E.g., each frame of a JPEG 2000 multi-frame image will be encoded as a separate part with an image/jp2 media type, rather than as a single part with a video/mj2 ([RFC3745]) or uncompressed application/octet-stream media type.
Video Bulkdata is encoded as a single part containing all frames. E.g., all frames of an MPEG-4 video will be encoded as a single part with a video/mp4 ([RFC_4337]) media type.
Many of the media types used for compressed Pixel Data transferred as Bulkdata values are also used for consumer format media types. A web browser may not be able to display the encoded data directly, even though some of the same media types are also used for encoding rendered Pixel Data. See Section 8.7.4.
For example, the media type for Bulkdata values of lossless 16-bit JPEG [ISO/IEC 10918-1] encoded Pixel Data is "image/jpeg", the same media type as might be used for 8-bit JPEG [ISO/IEC 10918-1] encoded Pixel Data, whether extracted as Bulkdata, or rendered. The Transfer Syntax parameter of the Content-Type header field is useful to signal the difference.
Each part of a multipart response is distinguished by the Content-Type and Content-Location header fields of the part.
Previously, experimental Media Types "image/x-dicom-rle" and "image/x-jls" were defined, so origin servers and user agents may want to account for these when communicating with older implementations. These have been replaced with the standard Media Types "image/dicom-rle" and "image/jls", respectively.
| DICOM PS3.18 2019e - Web Services |
|---|