DCM File Documentation

Summary

A DICOM Image (.dcm) is a medical scan — an X-ray, CT, MRI, ultrasound or mammogram — stored in the DICOM standard, which bundles the image pixel data together with patient and study metadata in one file. Its MIME type is application/dicom. A DICOM file begins with a 128-byte preamble and the marker DICM at byte offset 128. Free viewers such as MicroDicom, Horos or Weasis open it.

Technical details

FeatureValue
Full nameDICOM — Digital Imaging and Communications in Medicine
File extension.dcm (often none on hospital media)
MIME typeapplication/dicom
Format typeMedical imaging file (image + patient/study metadata)
DeveloperNEMA / DICOM Standards Committee
IntroducedDICOM 3.0 (1993); predecessor ACR-NEMA 1985
Standard / specDICOM PS3.10 (media storage and file format)
Open standardYes
Preamble128 bytes, usually all zeros
Magic number44 49 43 4D (“DICM”) at offset 128
Data elementTag (group,element) + VR + length + value
Byte orderSet by the Transfer Syntax; File Meta group is little-endian explicit-VR
Bit depthCommonly 12–16-bit grayscale with window/level
Pixel Data tag(7FE0,0010)
Pixel compressionUncompressed, RLE, JPEG, JPEG-LS, JPEG 2000
Series modelOne scan = many .dcm slices reconstructed into a volume
Index fileDICOMDIR on hospital CDs/DVDs
Related extensions.dicom, .ima, .img, .nii, .stl
Specificationdicomstandard.org/current
File signature (magic bytes)
44 49 43 4D

Offset 128 (not the start of the file), 4 bytes, ASCII DICM. A DICOM Part 10 file opens with a 128-byte preamble — usually all zeros — and the DICM prefix sits immediately after it at byte 128. The File Meta Information that follows is always encoded little-endian with explicit VR, regardless of the transfer syntax used for the image body. Note the caveats: some raw or older DICOM files omit the preamble and marker entirely, so the absence of DICM does not prove a file is not DICOM, and hospital discs frequently store the files with no .dcm extension inside a DICOMDIR-indexed folder.

What is a DCM file?

A .dcm file is a single DICOM object: one medical image plus the metadata that describes it. DICOM (Digital Imaging and Communications in Medicine) is the international standard for storing and transmitting medical images, maintained by NEMA and the DICOM Standards Committee since DICOM 3.0 in 1993 (its predecessor, ACR-NEMA, dates to 1985). The file bundles the actual pixel data of an X-ray, CT, MRI, ultrasound or mammogram together with a large set of tagged attributes: patient name and ID, date of birth, the imaging modality, study and series identifiers, scanner model, slice position and the acquisition parameters.

That combination is what makes DICOM more than a picture format. It is a self-describing medical record, and the same standard also defines the network protocol hospitals use to move images between scanners and PACS archives. The everyday encounter is a patient handed a CD, DVD or USB stick after a scan, wanting to view it at home or send it to another doctor. The sections below describe how the bytes are actually organised.

The 128-byte preamble and the DICM prefix

A DICOM Part 10 file — the on-disk form defined in the standard’s PS3.10 — does not begin with its signature. It opens with a 128-byte preamble whose contents the standard leaves undefined; when unused it is set entirely to zeros. Its purpose is to let a DICOM file also be a valid file of some other format, by leaving room at the front for that format’s own header. Only after those 128 bytes come the four ASCII characters DICM (44 49 43 4D) at byte offset 128, the actual magic that identifies the file.

Offset   Size    Contents
0        128     Preamble (usually all 0x00)
128      4       "DICM" magic
132      ...     File Meta Information (group 0002)
                 always little-endian, explicit VR
...      ...     Data Set (image + attributes),
                 encoded per the Transfer Syntax UID

Two practical consequences follow. First, a viewer cannot recognise DICOM by reading the opening bytes; it must seek to offset 128. Second, some raw or older DICOM streams omit the preamble and DICM marker altogether, so the absence of the magic does not prove a file is not DICOM — which is exactly why hospital discs, where files often carry no .dcm extension, are opened by pointing a viewer at the whole folder rather than at one file.

Data elements: tag, VR, length, value

Everything after the header — both the metadata and the image — is a sequence of data elements, and they all share the same shape. Each element is identified by a tag, an ordered pair of 16-bit unsigned integers written as (group,element), for example (0010,0010) for Patient’s Name or (0008,0060) for Modality. The tag is followed by a Value Representation (VR), a two-letter code giving the data type, then a length, then the value itself.

Explicit VR, short form (most VRs):
  [ group:2 ][ element:2 ][ VR:2 ][ length:2 ][ value:length ]

Explicit VR, long form (OB, OW, OF, SQ, UT, UN):
  [ group:2 ][ element:2 ][ VR:2 ][ reserved:2 ][ length:4 ][ value ]

Implicit VR:
  [ group:2 ][ element:2 ][ length:4 ][ value ]   (VR looked up from a dictionary)

The VR names the type: PN is a person name, DA a date, US an unsigned short, UI a unique identifier, OW other-word (16-bit pixel words), SQ a nested sequence of items. Whether the VR is written into the file at all depends on the transfer syntax: in explicit VR the two-letter code is present, while in implicit VR it is omitted and the reader looks the VR up from the standard data dictionary by tag. For most VRs the length is a 16-bit field, but the bulk types (OB, OW, OF, SQ, UT, UN) reserve two bytes and use a 32-bit length so a value can exceed 64 KB — which pixel data always does. Elements are stored in ascending tag order, and because each carries its own length a reader can skip any element it does not recognise.

File Meta Information and the transfer syntax

The first block of data elements after DICM is the File Meta Information, all in group 0002. This block is special: it is always encoded little-endian with explicit VR, no matter how the rest of the file is stored, so that any reader can parse it unconditionally. Its key element is the Transfer Syntax UID, tag (0002,0010). That UID is a dotted identifier that tells the reader two things about the main Data Set that follows: its byte order and VR style (little-endian explicit, little-endian implicit, or the legacy big-endian explicit), and whether the pixel data is compressed and with which codec. The meta block also carries the SOP Class UID, which states what kind of object this is — a CT image, an MR image, a structured report — and the implementation that wrote it. A reader parses the meta group first, reads the transfer syntax, then switches its decoder to that encoding for the rest of the file.

Pixel Data, bit depth and window/level

The image itself is one data element: Pixel Data, tag (7FE0,0010). How to interpret its bytes is governed by other elements in the same file: Rows and Columns give the dimensions, Bits Allocated and Bits Stored give the depth, Samples per Pixel distinguishes grayscale from colour, and Photometric Interpretation says whether higher values are brighter or darker. The pixels may be stored uncompressed, or compressed with RLE, JPEG, JPEG-LS or JPEG 2000, as declared by the transfer syntax; compressed pixel data is broken into fragments inside the element using an encapsulated, delimited layout.

The technically important point is dynamic range. A CT or MRI stores grayscale at high bit depth, commonly 12 to 16 bits per pixel, far more tonal range than the 8 bits an ordinary JPG or PNG holds. Radiologists view that range through window/level controls: the Window Center and Window Width elements define a linear mapping from a slice of the stored values onto the visible 0–255 range, and adjusting them is how the same CT image is read for bone, soft tissue or lung without re-acquiring anything. This is also why exporting a slice to JPG is lossy in a way that matters clinically: the export bakes in one window/level and discards the rest of the range, so a JPG cannot substitute for the original DICOM in a diagnosis.

Series, volumes and the DICOMDIR index

A single scan is rarely one file. A CT or MRI produces a series of many slices — often hundreds — each stored as its own .dcm, tied together by shared Study and Series identifiers and ordered by slice position. A viewer reads the whole series and reconstructs a 3D volume from it, which is what lets it scroll through the body or render it in three dimensions. Because the image data is genuinely volumetric, DICOM sits closer to a 3D image format than to a flat picture. To make a disc navigable, hospital media include a DICOMDIR file, a special DICOM object that indexes every study, series and image on the disc and points to the (often extensionless) image files in the folder tree. Pointing a viewer at the DICOMDIR, or simply at the containing folder, is how the disc is opened when the individual files have no .dcm suffix.

Privacy: the patient data embedded in every DICOM

A DICOM file is passive image data and does not execute code, so opening a scan from your own hospital is safe. The real concern is privacy, and it is inherent to the format rather than to any attack. The metadata elements embed directly identifiable information: full patient name in (0010,0010), patient ID in (0010,0020), date of birth in (0010,0030), and often the referring physician, accession number and institution. Anyone who opens the file sees them. Before sharing a scan publicly, posting it to a forum, or handing it to a researcher, run the viewer’s anonymise / de-identify function, which strips or blanks those tags. Treat an unexpected “medical” file received online with the same caution as any unknown download, and only open DICOM obtained from a legitimate medical source.

Frequently asked questions

Why is the DICOM signature at byte 128 instead of the start?

The standard puts a 128-byte preamble at the front of a Part 10 file, then the DICM marker at offset 128. The preamble exists so the file can double as a valid file of another format, leaving space for that format’s header. A reader therefore seeks to offset 128 to confirm DICOM; the preamble itself is usually all zeros.

The files on my hospital disc have no extension — are they DICOM?

Almost certainly yes. Hospital media routinely store DICOM images with no .dcm extension, indexed by a DICOMDIR file. Open the whole folder, or the DICOMDIR, in a DICOM viewer (MicroDicom on Windows, Horos on macOS, Weasis on any system) and it detects the files by the DICM marker at byte 128 rather than by name.

Why can’t I just save a DICOM as a JPG?

You can export a slice, but DICOM stores 12–16-bit grayscale viewed through adjustable window/level, whereas JPG is 8-bit. The export fixes one brightness/contrast setting and discards the rest of the tonal range, so it loses diagnostic information and strips the metadata. For a real second opinion, send the original DICOM, not a JPG.

References