What is a DCM file

A DCM file is a DICOM object on disk — usually with the .dcm extension, sometimes with no extension at all. It is not “what is DICOM” (the standard). It is the container: pixel data plus a tag-value header, so a CT slice is never an anonymous picture.

If you meant what DICOM the standard is (file + protocol + language) → what is DICOM. If you meant read the file in Python → how to read DICOM files. If you meant open / view it (RadiAnt, MicroDicom, a browser) → how to open a DCM file or the list at DICOM viewer software. If you meant convert the series to NIfTI → DICOM to NIfTI.

This page is the file. It is not a viewer-pick guide and it is not a protocol how-to.

Two halves

Every DCM file is two things glued together.

• Pixel data. The image — one slice, a multi-frame loop, or (in some objects) a stack. Bit depth is usually 12- or 16-bit, not the 8-bit of a phone JPEG. Compression, if any, is often lossless.
• The header. Data elements that say who, when, on which machine, at what spacing. Without that header the pixels are a postcard. With it, they are a record.

The file starts with a 128-byte preamble and the four bytes DICM. After that: a list of elements. Each element is a tag plus a value. The tag is the address. The value is the content.

Tags you will actually see

Tag	Name	What it holds
(0010,0010)	Patient’s Name	Who this instance belongs to
(0008,0020)	Study Date	The day of the exam
(0008,0070)	Manufacturer	Who built the scanner
(0028,0010)	Rows	Pixel rows (height)
(0028,0011)	Columns	Pixel columns (width)

There are hundreds more — UIDs, laterality, window center/width, Image Position (Patient). A viewer or a script reads the tags it cares about and ignores the rest. The pairing is the point: (0010,0010) is Patient’s Name in Germany and in Canada. That is why a CD from one hospital opens on another hospital’s station.

How those objects nest — Patient, Study, Series, Image — and how they move on the wire is what is DICOM. This page stops at the file.

Why the files are big

A DCM is larger than a screenshot of the same slice for three boring reasons.

• Bit depth. 12- or 16-bit grayscale holds the dynamic range a CT window needs. An 8-bit JPEG has already thrown most of it away.
• Compression. Diagnostic use prefers uncompressed or lossless. Lossy JPEG is a presentation copy, not the record.
• Stacks. A “file” people talk about is often a series: hundreds of slices, each its own instance, sometimes bundled in a ZIP or a directory that looks like one thing. A 500-slice CT is a pile, not a 200 KB photo.

Converting to JPEG for a slide is fine. Converting to JPEG and deleting the DCM is how you lose the patient, the spacing, and the window.

Opening one, briefly

A normal photo app will not parse the header. You need a DICOM viewer. Patient CD / quick look: RadiAnt or MicroDicom. Research / 3D: 3D Slicer or Horos. Hospital: the PACS workstation. That pick-a-viewer job is how to open a DCM file and DICOM viewer software. This page will not become a second copy of those.

If the job is code — dcmread, .pixel_array, windowing — that is how to read DICOM files.

FAQ

Is DICOM the same as a DCM file?

No. DICOM is the standard (the blueprint). A DCM file is one object written to that blueprint (the house). You can have DICOM without ever seeing a .dcm — a C-STORE on the wire is still DICOM. You should not have a .dcm that ignores the standard.

Can I convert it to JPEG?

Yes, as a picture. No, as a medical record. The JPEG keeps pixels (usually 8-bit) and drops tags. Keep the DCM as the source.

Why won’t it double-click?

Windows and macOS do not ship a DICOM viewer. Install one, or use a browser opener if you only need a look. Do not rename .dcm to .jpg.

Is every medical image a DCM?

In the clinic, almost every diagnostic image that left a modality is a DICOM object. Research stacks are often converted to NIfTI. That conversion is DICOM to NIfTI, not this file-format page.

PYCAD builds viewers and pipelines that have to read these files, not screenshots of them. Case studies.