DICOM PS3.18 2024d - Web Services |
---|
Bulkdata representations are only supported by RESTful services. There are two categories of Bulkdata: uncompressed and compressed.
The Selected Media Type will be the default media type for the Resource Category when the origin server supports none of the Acceptable Media Types, as described in Section 8.7.8, unless the origin server has only access to the pixel data in lossy compressed form or the pixel data in a lossless compressed or encapsulated uncompressed form that is of such length that it cannot be encoded in the Explicit VR Little Endian Transfer Syntax.
The origin server may support additional Transfer Syntaxes.
If no media type Transfer Syntax parameter is specified, then the Explicit VR Little Endian Transfer Syntax "1.2.840.10008.1.2.1" shall be used, unless the origin server has only access to the pixel data in lossy compressed form or the pixel data in a lossless compressed or encapsulated uncompressed form that is of such length that it cannot be encoded in the Explicit VR Little Endian Transfer Syntax.
The tables in this section have no entries for the URI service, since they do not support separate retrieval of Bulkdata.
Depending on the Selected Media Type, the pixel data of a resource in the Single Frame Image Resource Category is encoded in:
Depending on the Selected Media Type, the pixel data of a resource in the Multi-Frame Image Resource Category is encoded in:
Depending on the Selected Media Type, the pixel data of a resource in the Video Resource Category is encoded in:
Table 8.7.3-4 specifies the default media type and Transfer Syntax UIDs, by Resource Category (see Table 8.7.2-1) that can be used with uncompressed Bulkdata for the RESTful services. Uncompressed Bulkdata is encoded as a stream of uncompressed bytes (octets) in Little Endian byte order.
This is the same encoding defined in PS3.19 for the returned value of the getData() call for uncompressed Bulkdata.
In a Multi-Frame Image with a Bits Allocated (0028,0100) of 1 that is uncompressed, the individual frames are not padded, therefore successive bits are packed into bytes or words in Native format as described in Section 8.2 “Native or Encapsulated Format Encoding” in PS3.5. This means that if only selected frames of a Multi-Frame Image are to be encoded in the response, each frame needs to be extracted from the Multi-Frame Image pixel data and successively concatenated in the response, with no padding at the start of first byte in the response, and with no padding between successive encoded frames in the response. I.e., all the frame-specific bitstreams are successively encoded with no padding at the beginning or in between.
DICOM PS3.18 2024d - Web Services |
---|