DICOM Standard Browser

10.5 Store Transaction

Table 10.5.1-1 defines the resources used to store Instances.

/studies

/studies/{study}

Table 10.5.1-2. Request Header Fields

• PS3.10 representations of SOP Instances, or

• Metadata and Bulkdata representations of SOP Instances.

• XML representations of Metadata shall be encoded as described in the Native DICOM Model defined in PS3.19 with one representation per XML object.

• JSON representations of Metadata shall be encoded as an array of DICOM JSON Model Objects defined in Annex F in a single representation.

• Representations of Metadata may omit Attributes of the Image Pixel Description Macro for referenced pixel data whose representation is encoded in one of the media types specified in Table 10.5.2-1.

• The Metadata shall include only the DICOM Dataset (without Bulkdata), and in particular shall not include any Group 0002 File Meta Information Data Elements. The origin server shall create appropriate File Meta Information depending on the media type of the supplied compressed pixel data, if it happens to internally store the Dataset in a PS3.10 File.

• Uncompressed Bulkdata (including pixel data but with the exception of the Encapsulated Document (0042,0011) element) shall be encoded as application/octet-stream with one representation per Bulkdata item.

• Compressed pixel data for a Single Frame Image shall be encoded as one compressed Bulkdata representation.

• Compressed pixel data for a Multi-Frame Image shall be encoded as multiple Single Frame Image compressed Bulkdata representations.

• Compressed pixel data for a Video shall be encoded as one compressed Bulkdata representation.

• The Encapsulated Document (0042,0011) Bulkdata element shall be encoded using the media-type from the MIME Type of the Encapsulated Document (0042,0012) Attribute with one representation per document.

1. This allows a user agent to use consumer media types to encode the pixel data even though it may not have:

   • the pixel data in a form that directly corresponds to a lossless (reversible) DICOM Transfer Syntax, or

   • an API to access the information required to populate the Image Pixel Description Macro.

2. If the supplied compressed bit stream is in a lossless (reversible) format, the intent is to allow full fidelity retrieval of the decompressed pixels, not the format in which it happened to be submitted.

1. In the case of pixel data supplied as image/gif or image/png, the origin server may transform the color representation from indexed color to true color (RGB) as necessary to conform to any Photometric Interpretation constraints specified by the IOD (i.e., if PALETTE COLOR is not permitted) ; such a transformation is considered lossless.

2. If the number of bits per channel of an image/png file is not supported by the IOD, a lossless transformation cannot be performed.

3. An animated image/gif will be converted into a multi-frame image by transforming the frame deltas into fully decoded frames; image/png does not support animation, and Multiple-image Network Graphics (MNG) is not included in Table 10.5.2-1.

4. Any transparency information present in an image/gif or image/png file will be discarded, since DICOM does not support the concept of transparency. The actual pixel value used to replace transparent pixels (e.g., black or white) is at the discretion of the implementation, but if the value used does not appear elsewhere in the image, it may be useful to record it in Pixel Padding Value (0028,0120).

5. If an alpha channel is supplied in an image/png file, the alpha channel will be discarded (i.e., considered to consist of all opaque values, consistent with the policy of discarding any transparency information).

6. In the case of pixel data that contains a single channel in the absence of metadata describing the interpretation of the pixel values, the Photometric Interpretation may be assumed by the origin server to be MONOCHROME2 (zero is interpreted as black).

Table 10.5.3-1. Status Code Meaning

Table 10.5.3-2. Response Header Fields