Define Fragment Status Letter Ballot Date of Last Update 2024/08/24 Person Assigned David Clunie Submitter Name Jörg Riesmeier Submission Date 2024/01/08 Correction Number CP-2389 Log Summary: Define Fragment and Frame Name of Standard PS3.3, PS3.5, PS3.18 Rationale for Correction: The terms "Fragment" and "Frame" and "Pixel Data Stream" are used without formal definitions, across multiple parts. Add them, as well as editorial instruction to capitalize throughout. Also capitalize "Multi-frame Image" and "Cine Run" throughout. Also, factor out implicit definitions. Correction Wording: This Part of the Standard makes use of the following terms defined in : Basic Offset Table BOT . Extended Offset Table EOT . Encapsulated Format See Encapsulated Format in PS3.5. Fragment See Fragment in PS3.5. Native Format See Native Format in PS3.5. Cine Run A set of temporally related fFrames acquired at constant or variable frame rates. This term incorporates the general class of serialography (archaic). A Cine Run is typically encoded as a mMulti-frame iImage. Frame A single two-dimensional pixel plane of a Multi-frame Image. Multi-frame Image Image that contains multiple two-dimensional pixel planes. Amend DICOM PS3.5 as follows (changes to existing text are bold and underlined for additions and struckthrough for removals):

Frame See Frame in PS3.3. Multi-frame Image . Encapsulated Format The Pixel Data Stream is encoded in a form wherein Fragments are contained within Item Tags within the Pixel Data (7FE0,0010) Data Element, usually used for compressed data. Fragment One part or all of a Pixel Data Stream encoded within Encapsulated Pixel Data. Fragmentable Encapsulated Transfer Syntax A Transfer Syntax that allows the Encapsulated Format Pixel Data Stream to be split into one or more Fragments. Native Format The Pixel Data Stream is encoded in an uncompressed form and occupies the entire Value of the Pixel Data (7FE0,0010) Data Element. Pixel Data Graphical data (e.g., images) of variable pixel-depth encoded in the Pixel Data, Float Pixel Data or Double Float Pixel Data Element. Pixel Data Stream The compressed or uncompressed octet-stream that constitutes the Pixel Data itself, without any DICOM-specific encapsulation structures. Non-Fragmentable Encapsulated Transfer Syntax A Transfer Syntax that requires the entire Encapsulated Format Pixel Data Stream be encoded in a single Fragment.

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). ... Pixel Data conveyed in the Float Pixel Data (7FE0,0008) or Double Float Pixel Data (7FE0,0009) shall be in a Native (uncompressed) Format if encoded in a Standard Transfer Syntax. In future, if Standard Transfer Syntaxes are defined for compression of Float Pixel Data (7FE0,0008) or Double Float Pixel Data (7FE0,0009), this constraint may be relaxed and Encapsulated Format permitted. This constraint does not apply to Private Transfer Syntaxes. If Pixel Data (7FE0,0010) is sent in a Native Format, the Value Representation OW is most often required. The Value Representation OB may also be used for Pixel Data (7FE0,0010) in cases where Bits Allocated has a Value less than or equal to 8, but only with Transfer Syntaxes where the Value Representation is explicitly conveyed (see ). ... Float Pixel Data (7FE0,0008) is sent in Native Format; the Value Representation shall be OF, Bits Allocated (0028,0100) shall be 32, Bits Stored (0028,0101), High Bit (0028,0102) and Pixel Representation (0028,0103) shall not be present. Double Float Pixel Data (7FE0,0009) is sent in Native Format; the Value Representation shall be OD, Bits Allocated (0028,0100) shall be 64, Bits Stored (0028,0101) and High Bit (0028,0102) and Pixel Representation (0028,0103) shall not be present. Native format Pixel Cells are encoded as the direct concatenation of the bits of each Pixel Cell, ... 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 ). A Fragmentable Encapsulated Transfer Syntax allows the encapsulated pixel stream of encoded pixel data to be split into one or more Fragments. A Non-Fragmentable Encapsulated Transfer Syntax requires the entire encapsulated pixel stream of encoded pixel data to be encoded in a single Fragment. ... The Sequence of Fragments of the encapsulated pixel stream is terminated by a Sequence Delimiter Item, thus allowing the support of encoding processes where the resulting length of the entire pixel stream is not known until it is entirely encoded. Encapsulated Formats support both Single-Frame and Multi-Fframe images (as defined in ). At least one Frame shall be present, and hence at least one Fragment will be present. Depending on the Fragmentable Encapsulated 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. The total size of the encapsulated pixel stream, not including any trailing padding in the last Fragment, if known, may be encoded in Encapsulated Pixel Data Value Total Length (7FE0,0003); see and .

... ... ... The encoding of the Data Elements of the Data Set shall be as follows according to their Value Representations: ... For the Value Representations OB, OL, OV and OW, the encoding shall meet the following specification depending on the Data Element Tag: Pixel Data (7FE0,0010) may be encapsulated or native. ... If encapsulated, it has the Value Representation OB and is an octet-stream resulting from one of the encoding processes. It contains the encoded pPixel dData sStream fragmented into one or more Item(s). This Pixel Data Stream may represent a Single or Multi-frame Image. See and . The Length of the Data Element (7FE0,0010) shall be set to the Value for Undefined Length (FFFFFFFFH). Each Data Stream Fragment encoded according to the specific encoding process shall be encapsulated as a DICOM Item with a specific Data Element Tag of Value (FFFE,E000). The Item Tag is followed by a 4 byte Value (Item) Length Field encoding the explicit number of bytes of the Item. Whether more than one fFragment per fFrame is permitted or not is defined per Transfer Syntax. All items containing an encoded fFragment shall be made of an even number of bytes greater or equal to two. The last fFragment of a fFrame may be padded, if necessary, to meet the sSequence iItem format requirements of the DICOM Standard. Any necessary padding may be added in the JPEG or JPEG-LS compressed data stream as per ISO 10918-1 and ISO 14495-1 such that the End of Image (EOI) marker ends on an even byte boundary, or may be appended after the EOI marker, depending on the implementation. ISO 10918-1 and ISO 14495-1 define the ability to add any number of padding bytes FFH before any marker (all of which also begin with FFH). It is strongly recommended that FFH padding bytes not be added before the Start of Image (SOI) marker. The first Item in the Sequence of Items before the encoded Pixel Data Stream shall be a Basic Offset Table item. The Basic Offset Table Item Value, however, is not required to be present: When the Item Value is not present, the Item Length shall be zero (00000000H) (see ). When the Item Value is present, the Basic Offset Table Item Value shall contain concatenated 32-bit unsigned integer values that are byte offsets to the first byte of the Item Tag of the first fragment for each frame in the Sequence of Items. These offsets are measured from the first byte of the first Item Tag following the Basic Offset Table item (see ). For a Multi-Fframe Image containing only one frame or a Single Frame Image, the Basic Offset Table Item Value may be present or not. If present it will contain a single 00000000H value. Decoders of encapsulated pixel data, whether Single Frame or Multi-Fframe, need to accept both an empty Basic Offset Table (zero length) and a Basic Offset Table filled with 32 bit offset values. A Basic Offset Table Item Value is not permitted (i.e., the Item Length of the first Item will be zero) if Extended Offset Table (7FE0,0001) is present. This Sequence of Items is terminated by a Sequence Delimiter Item with the Tag (FFFE,E0DD) and an Value (Item) Length Field of Value (00000000H) (i.e., no Value Field shall be present). ...

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

This Part of the Standard makes use of the following terms defined in : Frame See Frame in PS3.3. Multi-frame Image . This Part of the Standard makes use of the following terms defined in : Encapsulated Format See Encapsulated Format in PS3.5. Fragment See Fragment in PS3.5. Native Format See Native Format in PS3.5. Bulk Data An object that contains an octet-stream containing one or more Value Fields (typically containing large data, such as Pixel Data) extracted from a DICOM Dataset. See . The octet-stream does not include the Attribute Tag, Value Representation, or Attribute Length. For the value of a fFrame of a Pixel Data Attribute encoded in an compressedEncapsulated Transfer Syntax, it does not include the Basic Offset Table and Pixel Data Stream Fragment Item tags and lengths. Metadata A DICOM Dataset where zero or more elements (typically containing large data, such as Pixel Data) have been replaced with Bulkdata URIs. Metadata does not include the Group 0002 File Meta Information Data Elements, which describe but are not part of a Dataset, per .