Learn to read CBCT

Guide

What is DICOM? A guide for dental students

After this guide you will know what a DICOM file actually contains, how a folder of slices becomes a volume, what spacing and compression terms mean, and which fields hold a patient's identity.

A file format, and more

DICOM stands for Digital Imaging and Communications in Medicine. It is the standard that medical and dental imaging devices use to store images and to exchange them. The standard covers far more than files: it also defines how scanners, archives and workstations talk to each other over a network. For a student with a CBCT export in hand, the part that matters is the file format, and that is what this guide covers.

A DICOM file is not a picture with a header. It is a long list of tagged fields, called data elements, followed by the pixel data as one more element at the end. Each tag is a pair of numbers, such as (0028,0030), that identifies what the field means, and each field has a value representation that says whether it holds text, a number, a date or raw bytes. A viewer walks the list, picks out the tags it needs, and uses them to interpret the pixels. Without the tags the pixels are meaningless: there is no way to know their size, their spacing, their orientation or how to map them to grey.

Series, slices and how a volume is rebuilt

DICOM organises images in a hierarchy. A patient has studies, a study has series, and a series has instances, which for a CBCT are the individual slices. Every level carries a unique identifier; the Series Instance UID is the one that ties a folder of slice files together. A typical CBCT export is one series written as one file per axial slice, so a scan of 320 slices arrives as 320 files. Some systems write a single multi-frame file that holds all the slices at once.

The order of the files on disk means nothing. Each slice carries an Image Position (Patient) tag, the coordinates of its first voxel in millimetres, and an Image Orientation (Patient) tag that says which way its rows and columns point. A viewer projects each position onto the slice normal, sorts the slices along it, checks that the gaps between them are regular and that no slice appears twice, and then stacks them into a volume. JawAtlas does exactly this, flags gaps and duplicates, and needs at least four slices to call something a series. The orientation guide explains how the orientation tag becomes the R, L, A, P, H and F labels on screen.

Pixel spacing and slice thickness

Two tags turn pixels into millimetres. Pixel Spacing gives the distance between the centres of neighbouring pixels within a slice, as a row spacing and a column spacing. Slice Thickness gives the nominal thickness of each slice, and Spacing Between Slices, when present, gives the distance from one slice centre to the next. For a volume to be reconstructed correctly, the spacing between slices is what matters; thickness and spacing are often equal on CBCT but do not have to be.

Together these numbers define the voxel. On the demo scan in JawAtlas the pixel spacing is 0.266 mm in both directions and the slices are 0.252 mm apart, so each voxel is a near-cube of about a quarter of a millimetre. Every measurement in the app, length or angle, is calibrated from these tags rather than from the picture, which is why it reads in millimetres. The field of view and voxel size guide looks at what these numbers mean for what you can see.

Transfer syntaxes in plain words

A transfer syntax is the tag that says how the bytes in the file are laid out and whether the pixel data is compressed. The names are intimidating but the ideas are simple.

Implicit and Explicit VR Little Endian are the two uncompressed layouts. They differ only in whether each field states its own value representation. The pixels are stored as plain numbers, one after another. Deflated wraps the whole file in the same general purpose compression used by ZIP; it is reversed exactly on reading. RLE Lossless is run length encoding, which stores a run of identical bytes as a count and a value. JPEG Lossless (processes 14 and 70) uses a prediction scheme that reproduces every grey value exactly, despite sharing a name with the lossy JPEG used for photographs.

All of these are lossless: the grey values that come out are the grey values that went in. JawAtlas reads all of them. It rejects three others. Lossy JPEG discards information to make the file smaller, so the grey values are altered and fine detail is smoothed; for a scan meant for study, that is not acceptable. JPEG 2000 and JPEG-LS have lossless modes, but they are complex codecs that the app does not implement. In each case the rejection is per file, with a message naming the syntax, and the fix is the same: export again as uncompressed or JPEG Lossless. The import how-to covers what to do when a file is refused.

Which tags carry patient identity

DICOM was designed for hospitals, so a file routinely carries the patient's name, patient ID, birth date, sex, age and sometimes an address, as well as the accession number, the institution name and address, and the names of referring, performing and operating staff. These live in well known tags, mostly in the (0010,xxxx) patient group and the (0008,xxxx) study group. Any file you receive for study should be assumed to contain them unless it has been anonymised on purpose.

JawAtlas never stores these fields. The importer works from a whitelist of technical tags, the ones needed to build the volume: rows and columns, bits allocated and stored, pixel representation, photometric interpretation, pixel spacing, slice thickness and spacing, image position and orientation, rescale slope and intercept, transfer syntax, series and study UIDs, frame count and the pixel data itself. Identity tags are not on the list, so they are never read into app storage. Scan files are also protected by iOS data protection, and the app contains no networking code, so nothing can leave the device. The offline and private page describes this in more detail. For teaching material, use datasets that were anonymised and released for the purpose, such as those on the free CBCT datasets page.

Exporting a CBCT scan as DICOM

Scanner software differs, so this is a general description rather than a menu path. Look for an export, save as or send function and choose DICOM as the format; most CBCT systems offer a choice between a single multi-frame file and one file per slice, and either works. If there is a compression option, choose uncompressed or lossless. If there is an anonymise option and the scan is for teaching, use it. Exporting a whole folder is normal: it will contain the slice files and often a small DICOMDIR index and a bundled viewer, which can be ignored.

Once the folder is on your device, JawAtlas imports it through the Files app, as a ZIP archive by AirDrop or any share sheet, or as a shared case package from another JawAtlas user. See importing DICOM from Files and importing by AirDrop. If a scan refuses to import, the most common reasons are a lossy transfer syntax, fewer than four slices, or a folder that mixes several series together.

JawAtlas is an education and training aid. It is not a medical device and must not be used for diagnosis, treatment planning or any clinical decision.

Last reviewed 2026-10-13