Number of Frames attribute should never have a value of zero Status Submitted Date of Last Update 2019/04/26 Person Assigned David Clunie Submitter Name John Perry Submission Date 2019/02/19 Correction Number CP-1899 Log Summary: Number of Frames attribute should never have a value of zero Name of Standard PS3.3, PS3.5 Rationale for Correction: The Number of Frames attribute should never have a value of zero, since then there would be no image. Correction Wording:

Multi-frame Module Attributes

Attribute Name	Tag	Type	Attribute Description
Number of Frames	(0028,0008)	1	Number of frames in a Multi-frame Image. See for further explanation.

A Multi-frame Image is defined as a Image whose pixel data consists of a sequential set of individual Image Pixel frames. A Multi-frame Image is transmitted as a single contiguous stream of pixels. Frame headers do not exist within the data stream. Each individual frame shall be defined (and thus can be identified) by the Attributes in the (see ). All Image IE Attributes shall be related to the first frame in the Multi-frame image. The total number of frames contained within a Multi-frame Image is conveyed in the Number of Frames (0028,0008). Number of Frames (0028,0008) shall have a value greater than zero.

Multi-frame Functional Groups Module Attributes

Attribute Name	Tag	Type	Attribute Description
Number of Frames	(0028,0008)	1	Number of frames in a multi-frame image. See for further explanation.

Amend DICOM PS3.5 as follows (changes to existing text are bold and underlined for additions and struckthrough for removals):

In a multi-frame object that is transmitted in Native Format, the individual frames are not padded. The individual frames shall be concatenated and padding bits (if necessary) apply to the complete Value Field. At least one frame shall be present. Receiving applications should be aware that some older applications may send Pixel Data with excess padding, which was not explicitly prohibited in earlier versions of the Standard. Applications should be prepared to accept such Pixel Data elements, but may delete the excess padding. In no case should a sending application place private data in the padding data.

Pixel data conveyed in the Pixel Data (7FE0,0010) may be sent either in a Native (uncompressed) Format or in an Encapsulated Format (e.g., compressed) defined outside the DICOM Standard. ... If sent in an Encapsulated Format (i.e., other than the Native Format) the Value Representation OB is used. The Pixel Cells are encoded according to the encoding process defined by one of the negotiated Transfer Syntaxes (see ). The encapsulated pixel stream of encoded pixel data is segmented into one or more Fragments, each of which conveys its own explicit length. The sequence of Fragments of the encapsulated pixel stream is terminated by a delimiter, thus allowing the support of encoding processes where the resulting length of the entire pixel stream is not known until it is entirely encoded. This Encapsulated Format supports both Single-Frame and Multi-Frame images (as defined in ). At least one frame shall be present, and hence at least one fragment will be present. Depending on the Transfer Syntax, a frame may be entirely contained within a single fragment, or may span multiple fragments to support buffering during compression or to avoid exceeding the maximum size of a fixed length fragment. A recipient can detect fragmentation of frames by comparing the number of fragments (the number of Items minus one for the Basic Offset Table) with the number of frames. Some performance optimizations may be available to a recipient in the absence of fragmentation of frames, but an implementation that fails to support such fragmentation does not conform to the Standard.