7 DICOM File Format
Prev |  | Next

# 7 DICOM File Format

The DICOM File Format provides a means to encapsulate in a file the Data Set representing a SOP Instance related to a DICOM IOD. As shown in Figure 7-1, the byte stream of the Data Set is placed into the file after the DICOM File Meta Information. Each file contains a single SOP Instance.

Figure 7-1. File-set and File Format

## 7.1 DICOM File Meta Information

The File Meta Information includes identifying information on the encapsulated Data Set. This header consists of a 128 byte File Preamble, followed by a 4 byte DICOM prefix, followed by the File Meta Elements shown in Table 7.1-1. This header shall be present in every DICOM file.

The File Preamble is available for use as defined by Application Profiles or specific implementations. This Part of the DICOM Standard does not require any structure for this fixed size Preamble. It is not required to be structured as a DICOM Data Element with a Tag and a Length. It is intended to facilitate access to the images and other data in the DICOM file by providing compatibility with a number of commonly used computer image file formats. Whether or not the File Preamble contains information, the DICOM File content shall conform to the requirements of this Part and the Data Set shall conform to the SOP Class specified in the File Meta Information.

### Note

1. If the File Preamble is not used by an Application Profile or a specific implementation, all 128 bytes shall be set to 00H. This is intended to facilitate the recognition that the Preamble is used when all 128 bytes are not set as specified above.

2. The File Preamble may for example contain information enabling a multi-media application to randomly access images stored in a DICOM Data Set. The same file can be accessed in two ways: by a multi-media application using the preamble and by a DICOM Application that ignores the preamble.

The four byte DICOM Prefix shall contain the character string "DICM" encoded as uppercase characters of the ISO 8859 G0 Character Repertoire. This four byte prefix is not structured as a DICOM Data Element with a Tag and a Length.

The Preamble and Prefix are followed by a set of DICOM Meta Elements with Tags and Lengths as defined in Table 7.1-1.

Table 7.1-1. DICOM File Meta Information

Attribute Name | Tag | Type | Attribute Description
--- | --- | --- | ---
File Preamble | No Tag or Length Fields | 1 | A fixed 128 byte field available for Application Profile or implementation specified use. If not used by an Application Profile or a specific implementation all bytes shall be set to 00H. File-set Readers or Updaters shall not rely on the content of this Preamble to determine that this File is or is not a DICOM File.
DICOM Prefix | No Tag or Length Fields | 1 | Four bytes containing the character string "DICM". This Prefix is intended to be used to recognize that this File is or not a DICOM File.
File Meta Information Group Length | (0002,0000) | 1 | Number of bytes following this File Meta Element (end of the Value field) up to and including the last File Meta Element of the Group 2 File Meta Information
File Meta Information Version | (0002,0001) | 1 | This is a two byte field where each bit identifies a version of this File Meta Information header. In version 1 the first byte value is 00H and the second value byte value is 01H. Implementations reading Files with Meta Information where this attribute has bit 0 (lsb) of the second byte set to 1 may interpret the File Meta Information as specified in this version of PS3.10. All other bits shall not be checked. ### Note A bit field where each bit identifies a version, allows explicit indication of the support of multiple previous versions. Future versions of the File Meta Information that can be read by version 1 readers will have bit 0 of the second byte set to 1
Media Storage SOP Class UID | (0002,0002) | 1 | Uniquely identifies the SOP Class associated with the Data Set. SOP Class UIDs allowed for media storage are specified in PS3.4 - Media Storage Application Profiles.
Media Storage SOP Instance UID | (0002,0003) | 1 | Uniquely identifies the SOP Instance associated with the Data Set placed in the file and following the File Meta Information.
Transfer Syntax UID | (0002,0010) | 1 | Uniquely identifies the Transfer Syntax used to encode the following Data Set. This Transfer Syntax does not apply to the File Meta Information. ### Note It is recommended to use one of the DICOM Transfer Syntaxes supporting explicit Value Representation encoding to facilitate interpretation of File Meta Element Values. JPIP Referenced Pixel Data Transfer Syntaxes are not used (see PS3.5).
Implementation Class UID | (0002,0012) | 1 | Uniquely identifies the implementation that wrote this file and its content. It provides an unambiguous identification of the type of implementation that last wrote the file in the event of interchange problems. It follows the same policies as defined by PS3.7 (association negotiation).
Implementation Version Name | (0002,0013) | 3 | Identifies a version for an Implementation Class UID (0002,0012) using up to 16 characters of the repertoire identified in Section 8.5. It follows the same policies as defined by PS3.7 (association negotiation).
Source Application Entity Title | (0002,0016) | 3 | The DICOM Application Entity (AE) Title of the AE that wrote this file's content (or last updated it). If used, it allows the tracing of the source of errors in the event of media interchange problems. The policies associated with AE Titles are the same as those defined in PS3.8. ### Note If the data set was created de novo by the application writing the file, its AE Title, if it has one, may be used. If the data set was received over the network, there is potential ambiguity as to whether the value is the same as Sending Application Entity Title (0002,0017) or Receiving Application Entity Title (0002,0018) or some other value.
Sending Application Entity Title | (0002,0017) | 3 | The DICOM Application Entity (AE) Title of the AE that sent this file's content over a network. ### Note This is the AE that was the sender (source) of the content (the data set), in the case of a data set sent over the network (i.e., the Calling AET of the SCU for a C-STORE operation). If the data set was instead created de novo by the application writing the file, it should not be present.
Receiving Application Entity Title | (0002,0018) | 3 | The DICOM Application Entity (AE) Title of the AE that received this file's content over a network. ### Note This is the AE that was the recipient (destination) of the content (the data set), in the case of a data set received over the network (i.e., the Called AET of the SCP for a C-STORE operation). If the data set was instead created de novo by the application writing the file, it should not be present.
Private Information Creator UID | (0002,0100) | 3 | The UID of the creator of the private information (0002,0102).
Private Information | (0002,0102) | 1C | Contains Private Information placed in the File Meta Information. The creator shall be identified in (0002,0100). Required if Private Information Creator UID (0002,0100) is present.

Except for the 128 byte preamble and the 4 byte prefix, the File Meta Information shall be encoded using the Explicit VR Little Endian Transfer Syntax (UID=1.2.840.10008.1.2.1) as defined in DICOM PS3.5. Values of each File Meta Element shall be padded when necessary to achieve an even length, as specified in PS3.5 by their corresponding Value Representation. The Unknown (UN) Value Representation shall not be used in the File Meta Information. For compatibility with future versions of this Standard, any Tag (0002,xxxx) not defined in Table 7.1-1 shall be ignored.

Values of all Tags (0002,xxxx) are reserved for use by this Standard and later versions of DICOM. Data Elements with a group of 0002 shall not be used in data sets other than within the File Meta Information.

### Note

PS3.5 specifies that Elements with Tags (0001,xxxx), (0003,xxxx), (0005,xxxx), and (0007,xxxx) shall not be used.

Prev |  | Next
6.2 The DICOM Media Storage Model | Home | 7.2 Data Set Encapsulation