10.5.2 Behavior

10.5.2 Behavior (Current)
Prev	10.5 Store Transaction	Next

The origin server stores Instances from the representations contained in the request payload.

The stored Instance(s) shall fully conform to the IOD and encoding requirements of PS3.3 and PS3.5, respectively.

This Transaction stores one or more new Instances, and adds them to new or existing Series and Studies.

While creating resources from the representations, the origin server may coerce or replace the values of data elements. For example, Patient Name, Patient ID, and Accession Number might be coerced when importing media from an external institution, reconciling the Instances against a master patient index, or reconciling them against an imaging procedure order. The origin server may also fix incorrect values, such as Patient Name or Patient ID; for example, because an incorrect work list item was chosen, or an operator input error has occurred.

If any Attribute is coerced or corrected, the Original Attribute Sequence (0400,0561) shall be included in the DICOM Object that is stored and may be included in the Store Instances Response Module (see Annex I) in the response.

Note

For more information on populating the Original Attribute Sequence see Section C.12.1 “SOP Common Module” in PS3.3.

The origin server shall encapsulate or convert any compressed pixel data received as Bulkdata into an appropriate DICOM Transfer Syntax, as defined in Table 10.5.2-1.

If the request message contains compressed Bulkdata with a Content Type that is one of the media types specified in Table 10.5.2-1, the request may omit the Image Pixel Description Macro Attributes and the origin server will derive them from the compressed octet stream. Some media types do not directly correspond to a DICOM Transfer Syntax and the origin server will transform the received bit stream into an uncompressed or lossless (reversibly) compressed Transfer Syntax.

Note

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.
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.

The origin server shall encapsulate or convert any compressed pixel data received as bulk data into an appropriate DICOM Transfer Syntax, as defined in Table 10.5.2-1.

If the supplied compressed octet stream is in a lossy (irreversible) format, there will be a corresponding DICOM Transfer Syntax, and the origin server is not expected to recompress it causing further loss. Table 10.5.2-1 contains a list of media types containing compressed pixel data from which an origin server shall be able to derive the Image Pixel Data Description Macro Attribute values.

Requirements are specified in Table 10.5.2-1 as follows:

Transform: No DICOM Transfer Syntax exists; shall be transformed by the origin server into an uncompressed or lossless compressed Transfer Syntax (the choice of which is at the discretion of the origin server).
Unchanged: Shall be encapsulated in the corresponding DICOM Transfer Syntax without further lossy compression.

Table 10.5.2-1. Media Type Transformation to Transfer Syntaxes

Media Type	Requirement
image/gif	Transform
Image/jp2	Unchanged
image/jpeg	Unchanged
image/jpx	Unchanged
image/png	Transform
video/mp4	Unchanged
video/mpeg	Unchanged
video/H265	Unchanged

Note

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.
If the number of bits per channel of an image/png file is not supported by the IOD, a lossless transformation cannot be performed.
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.
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).
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).
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).