KAHIBARO
24.1. Medical Image Formats
Table of Contents
DICOM
Digital Imaging and Communications in Medicine, or DICOM, is the dominant standard for clinical medical images. In a GATE context you typically encounter DICOM when you import patient CT data, RT structure sets, or RT plans, but here we focus on its role as an image format.
A DICOM image file is more than a picture. It contains a 2D image slice together with a large set of metadata stored as tagged attributes. For CT images, these attributes usually include information such as pixel spacing, slice thickness, image orientation and position in the patient coordinate system, and the mapping from stored pixel values to physical quantities like Hounsfield units. Many scanners store each CT slice as a separate DICOM file, so a complete CT volume is often a folder containing tens or hundreds of individual files.
DICOM uses a structured tag system. Each attribute is identified by a group and element number written as $(gggg,eeee)$. For example, $(0028,0030)$ usually stores pixel spacing, and $(0020,0032)$ stores the 3D position of the image origin of that slice in patient coordinates. In practical GATE workflows, Python libraries such as pydicom read these tags and convert them into arrays and affine transformations that can be used for voxelized geometry. You typically do not manipulate tags directly inside GATE, but you must understand that the geometry you construct depends on them.
Compression and encoding also vary in DICOM. Some files store raw uncompressed data, others use lossless or even lossy compression. Before converting DICOM to a voxel phantom, you should ensure you can read the dataset with your image processing tools and that rescaling is applied correctly to recover physical CT numbers.
DICOM is patient centric. Besides image geometry, it can contain private information, acquisition settings, and dose or contour data. For GATE simulations you usually extract only what you need for geometry and material mapping, but you must always treat original DICOM data as sensitive and ensure appropriate anonymization before using it in teaching or research examples.
In GATE workflows, DICOM CT data are not directly used as geometry. They must first be converted into a voxel image volume and then mapped to materials and densities in later steps.
MHD
MetaImage, often referred to by its .mhd header extension, is a simple medical image format widely used in research and in GATE voxelized geometry. It is composed of a human readable text header file .mhd and a separate binary data file, usually .raw or .raw.gz, that stores the voxel array.
The .mhd header describes the image size, spacing, origin, orientation, data type, and the path to the raw data file in a line based key value format. A typical header includes entries such as NDims, DimSize, ElementSpacing, ElementType, ElementDataFile, and optionally ElementByteOrderMSB and TransformMatrix. Because the file is text, you can open it in any editor to inspect and verify that the voxel dimensions and spacing match what you expect for your simulation.
MHD is convenient for GATE because it separates geometric information from patient specific metadata. In many workflows, DICOM CT data are first converted to a 3D array of Hounsfield units and then written to an MHD file. This MHD image then becomes the basis for voxelized geometry, while separate tools perform CT to material conversion. The simplicity of the format makes it easy to handle in Python with libraries such as SimpleITK or ITK, which read and write both the header and the binary volume.
The raw data file associated with an MHD header is typically stored in row major order, with voxels laid out in a consistent, predictable way. This regular layout is important for GATE when creating 3D dose maps and voxel phantoms. Because MHD does not define complex patient coordinate systems, you must pay careful attention to the origin, spacing, and any transform in the header to ensure that the image aligns with your simulation coordinates.
When using MHD images in GATE, always verify that DimSize, ElementSpacing, and the image origin are correct, because these fields directly define the size and placement of your voxelized geometry.
NIfTI
Neuroimaging Informatics Technology Initiative, or NIfTI, is a medical image format that is very common in neuroimaging research, but is also useful for general 3D and 4D image data in GATE. NIfTI typically uses the .nii extension for a single file that contains both header and image data, or .hdr/.img pairs similar to Analyze format. For GATE you normally work with .nii volumes.
A NIfTI file stores the voxel array together with metadata that describe the image dimensions, voxel sizes, and an affine transform that maps voxel indices to a real world coordinate system. This affine matrix is crucial, since it determines how the image volume should be positioned and oriented in space. In many Python workflows, libraries such as NiBabel expose this matrix directly, making it straightforward to translate NIfTI volumes into GATE geometry coordinates.
Compared with MHD, NIfTI has a more compact header structure and is designed to support multiple coordinate conventions, including scanner aligned and standardized brain spaces. For GATE simulations you must interpret the affine correctly and decide how to align the NIfTI volume with your world volume. It is common to resample or reorient the image to a simple axis aligned grid before export, to reduce the risk of orientation mistakes when creating voxelized geometries.
NIfTI also supports higher dimensional data, for example time series of 3D images, which can be useful in dynamic or motion related simulations. Although GATE’s voxel geometry usually uses static 3D images, you can process 4D NIfTI data in Python to generate multiple 3D MHD or NIfTI volumes, each corresponding to a different time point, and then use them in time dependent simulations described elsewhere in this course.
Before using a NIfTI image in GATE, check the affine transform and voxel spacing, and confirm in a visualization tool that the orientation matches your intended simulation coordinate system.
Views: 11