Clarify JPIP and Resource Category in DICOM Web Services Context defines Resource Categories that correspond to different SOP Classes. The following sections map each Resource Category to appropriate DICOM and Rendered media types.

Resource Categories

Resource Category	Definition
Single Frame Image	This category includes all resources that are: Instances of a single frame SOP Class, or Instances of a multi-frame SOP Class that contain only one frame, or a single frame selected from an Instance of a multi-frame SOP Class.
Multi-Frame Image	This category includes all resources that are Instances of a multi-frame SOP Class, that are not Video and that contain more than one frame.
Video	This category includes all resources that contain more than one frame and are: Instances encoded in the MPEG family of Transfer Syntaxes (which includes MPEG2, MPEG-4 AVC/H.264 and HEVC/H.265), or time-based (motion) multi-frame images that the origin server is capable of encoding in the MPEG family.
Text	This category includes all resources that contain: the SR Document Content Module (see ), such as narrative text, Structured Reports, CAD, measurement reports, and key object selection documents, or the Encapsulated Document Module (see ).
Other	This category includes all resources that are not included above, for example waveforms.

The Resource Category is independent of the Transfer Syntax used to natively encode or return the Resource. In particular, if the Transfer Syntax is one of the JPIP Transfer Syntaxes, for which the pixel data is not included in the returned objects in but rather a URL of the JPIP provider for retrieving the pixel data is present in the metadata, the Resource Category will still be Single Frame Image or Multi-Frame Image, and not Text or Other.

The Default Transfer Syntax for DICOM objects contained in a payload shall be Explicit VR Little Endian Uncompressed "1.2.840.10008.1.2.1". If the Transfer Syntax is not specified in a message, then the Default Transfer Syntax 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 form that is of such length that it cannot be encoded in the Explicit VR Little Endian Transfer Syntax. This is different from the Default Transfer Syntax defined in , which is Implicit VR Little Endian. Every origin server is required to be able to convert any Data Set it is going to return into the Explicit VR Little Endian Transfer Syntax, regardless of the form in which it originally received or stored the Data Set, except in the cases of when the decompressed Pixel Data is too large to encode in the Explicit VR Little Endian Transfer Syntax or is received in a lossy compressed form. In the case of lossy compressed Pixel Data, the origin server is permitted to return the lossy compressed Transfer Syntax appropriate to the lossy form that was received. In the case of lossless compressed Pixel Data that is too large to encode in the Explicit VR Little Endian Transfer Syntax, the origin server is permitted to return any appropriate lossless compression Transfer Syntax, not necessarily that in which the image was received, as an alternative to the Explicit VR Little Endian Transfer Syntax. If transcoding to the Explicit VR Little Endian Transfer Syntax, a VR of UN may be needed for the encoding of Data Elements with explicit VR whose value length exceeds 65534 (216-2) (FFFEH, the largest even length unsigned 16 bit number) but which are defined to have a 16 bit explicit VR length field. See . Implicit VR Little Endian, or Explicit VR Big Endian shall not be used. The response payload encoding requirements are defined in . The transfer syntax can be one of the JPIP Transfer Syntaxes, in which case the returned objects will contain the URL of the JPIP provider for retrieving the pixel data. The origin server may support additional Transfer Syntaxes.