Imaging Concepts

Anatomical Planes

Medical images are described relative to three standard anatomical planes of the body. Every DICOM instance encodes its orientation using the ImageOrientationPatient (0020,0037) tag — six cosines defining the row and column directions in patient space — so software can reconstruct which plane a slice belongs to without any additional metadata.

# How a viewer computes the slice position for oblique MPR:
# Given: source volume voxels in patient coordinates
# Target: arbitrary plane defined by:
#   Origin (x0, y0, z0) = centre of the reformatted slice
#   RowDir    = (r1, r2, r3)  — unit vector along image rows
#   ColDir    = (c1, c2, c3)  — unit vector along image columns
#
# For each output pixel (u, v):
#   patient_coords = origin + u*PixelSpacing*RowDir + v*PixelSpacing*ColDir
#   → trilinear interpolation of voxel at patient_coords

Synchronised Multi-Planar Views

Modern DICOM viewers display all three planes simultaneously in a 2×2 or 1×3 layout, with a 3D localiser or VRT rendering in the fourth quadrant. All views are linked — a radiologist clicks any point in any plane and all other planes immediately reformat to show the same anatomical location.

# Given: user clicks pixel (px, py) in the Axial viewport
# DICOM tags used:
#   ImagePositionPatient  (0020,0032) = slice origin in mm [x, y, z]
#   ImageOrientationPatient (0020,0037) = [Rx,Ry,Rz, Cx,Cy,Cz]
#   PixelSpacing (0028,0030) = [row_spacing, col_spacing] in mm

patient_x = origin_x + px * col_spacing * Rx + py * row_spacing * Cx
patient_y = origin_y + px * col_spacing * Ry + py * row_spacing * Cy
patient_z = origin_z + px * col_spacing * Rz + py * row_spacing * Cz

# → (patient_x, patient_y, patient_z) in mm in DICOM Patient Coordinate System
# The sagittal viewer scrolls to the slice where ImagePositionPatient.x ≈ patient_x
# The coronal viewer scrolls to the slice where ImagePositionPatient.y ≈ patient_y

MPR & 3D Rendering Modes

Beyond simple slice viewing, modern PACS workstations offer a spectrum of reconstruction modes — from thin MPR slices to full volume renders — each suited to different clinical questions.

Windowing & Display LUT

Raw DICOM pixel values in CT span −1000 to +3000+ HU — far more than the 256 grey levels a monitor can display. Windowing maps a chosen range of HU values to the full 0–255 display scale, discarding values outside the window. The two parameters are Window Center (WC) and Window Width (WW).

# Linear windowing formula:
# WC = Window Center (0028,1050)
# WW = Window Width  (0028,1051)

lo = WC - WW / 2
hi = WC + WW / 2

display_value =
  if pixel_value <= lo → 0   (black)
  if pixel_value >= hi → 255 (white)
  else → (pixel_value - lo) / WW × 255

# After Rescale (CT modality LUT):
HU = pixel_value × RescaleSlope + RescaleIntercept
# RescaleIntercept (0028,1052) is typically -1024 for CT
# RescaleSlope     (0028,1053) is typically 1

# Sigmoid windowing (DICOM PS 3.3 C.7.6.3.1.5):
# e = (pixel_value - WC + 0.5) / (WW + 1)
# display = 255 / (1 + e^(-4 × e / 1))

Clinical Window Presets

Hounsfield Unit (HU) Reference

The Hounsfield scale is a linear transformation of the linear attenuation coefficient of X-rays. Water = 0 HU, air = −1000 HU by definition. Each tissue has a characteristic HU range that allows identification on CT.

Pixel Data Encoding

Pixel data lives in tag (7FE0,0010). How those bytes are interpreted depends on several companion tags.

Photometric Interpretations

Pixel Data Encapsulation (Compressed)

# Uncompressed: (7FE0,0010) OW — raw bytes, length = Rows × Columns × SamplesPerPixel × (BitsAllocated/8)
# Example: 512×512 CT, 16-bit → 512 × 512 × 1 × 2 = 524,288 bytes

# Compressed (encapsulated): VR = OB, length = 0xFFFFFFFF (undefined)
# Format: Item sequence
  (FFFE,E000) Item  length=0  ← Basic Offset Table (may be empty)
  (FFFE,E000) Item  length=N  ← JPEG / JPEG 2000 / RLE bitstream for frame 1
  (FFFE,E000) Item  length=M  ← frame 2 ...
  (FFFE,E0DD) Sequence Delimiter

Transfer Syntaxes & Compression

A Transfer Syntax UID (stored in tag 0002,0010) defines two things: the byte ordering of non-pixel data (little vs big endian) and the compression applied to pixel data. Every DICOM association negotiates a mutually supported Transfer Syntax before data flows.