KAHIBARO
33.5. Rotating CT Geometry
Table of Contents
Projection angles
In a CT simulation, rotation is represented by a series of discrete projection angles. The X ray source and detector array are placed at a fixed radius from the rotation center, which is usually the center of the patient or phantom. At each projection angle, you simulate X ray transport for that specific orientation, record the detector signal, and then step to the next angle.
In GATE, you typically choose a starting angle, an angular step, and a number of projections. The projections then cover a full or partial rotation. For a simple fan beam CT around the $z$ axis, the angle is usually defined in the transverse $x y$ plane.
A common configuration is to cover $360^\circ$ with equal angular spacing. If you have $N$ projections, the angular step is often
$$
\Delta \theta = \frac{360^\circ}{N}.
$$
You might prefer a $180^\circ$ plus fan angle range in some CT geometries, but for a basic introductory simulation it is safest to use a full $360^\circ$ rotation, since it is easy to understand and covers all possible views of the object.
In a Python based GATE simulation, you will typically store the list of projection angles as a NumPy array. For example, if you want 360 projections with a 1 degree step, you create an array from $0^\circ$ to $359^\circ$. At each angle, you update the rotation of the source and detector, run the simulation for the photons corresponding to that projection, and then save the output with a filename that encodes the angle. This stepwise approach makes it straightforward to assemble sinograms in the later CT projection data chapter.
The choice of number of projections affects both image quality and computation time. More projections provide smoother sinograms and can reduce streak artifacts in reconstruction, but also require more simulated events. In practice, you trade off the number of projections, the number of photons per projection, and the total runtime. For didactic simulations, you can start with a small set of projections, for example 90 angles with a 4 degree step, and later increase the angular sampling once your workflow is working.
It is important to keep the angle definition consistent across your simulation and analysis. Decide whether your angle is measured from the positive $x$ axis, whether it increases clockwise or counterclockwise, and whether you define the detector position as opposite the source along the same rotation radius. Document this convention clearly, because you will need it when you convert detector positions to sinogram coordinates.
For a CT simulation, choose the number of projections $N$ and define the angular step as $\Delta \theta = 360^\circ / N$. Keep the angle convention (axis, direction, origin) consistent between geometry setup and data analysis.
A small table can help you visualize typical choices for projection angles and how they affect coverage.
| Number of projections $N$ | Angular step $\Delta \theta$ | Coverage | Typical use |
|---|---|---|---|
| 60 | $6^\circ$ | $360^\circ$ | Very coarse, quick tests |
| 90 | $4^\circ$ | $360^\circ$ | Basic teaching examples |
| 180 | $2^\circ$ | $360^\circ$ | Moderate image quality |
| 360 | $1^\circ$ | $360^\circ$ | Finer sampling, better sinograms |
When you later reconstruct CT images, the projection angles become part of the reconstruction geometry. The reconstruction code needs to know the exact list of angles used in the simulation to correctly backproject the measured signals. Saving the angle list in a simple text or NumPy file, next to the projection data, is a good habit for reproducibility.
Scanner motion
Rotating CT geometry in GATE is implemented by moving the X ray source and detector as a rigid system around the phantom. In a fan beam geometry, the distance between source and rotation center, and between detector and rotation center, stays constant. Only the angle around the rotation axis changes. For a simple two dimensional setup, you rotate the system around the $z$ axis while the patient remains fixed.
In a Python driven simulation, scanner motion is usually modeled as a sequence of static configurations instead of a continuous mechanical rotation. For each projection angle, you compute the current source and detector positions from their initial positions through a rotation transformation. Conceptually, you apply a rotation matrix
$$
R_z(\theta) =
\begin{pmatrix}
\cos \theta & -\sin \theta & 0 \\
\sin \theta & \cos \theta & 0 \\
0 & 0 & 1
\end{pmatrix},
$$
to the initial position vectors in the $x y$ plane.
For instance, if your source is initially located at $(R, 0, 0)$ with respect to the rotation center, and your detector array is initially centered at $(-R, 0, 0)$, then at angle $\theta$ their positions become
$$
\vec{r}_\text{source}(\theta) = R_z(\theta) \cdot
\begin{pmatrix}
R \\ 0 \\ 0
\end{pmatrix},
\quad
\vec{r}_\text{detector}(\theta) = R_z(\theta) \cdot
\begin{pmatrix}
- R \\ 0 \\ 0
\end{pmatrix}.
$$
You set these positions using the geometry API before running the events for that particular projection. Once the simulation for that angle is finished, you move to the next angle, update the positions, and run again. The phantom does not move, which corresponds to a classical third generation CT scanner with a stationary patient and rotating gantry.
For a rotating CT scanner, keep the source and detector at fixed radii from the rotation center and update their positions by applying a pure rotation around the chosen axis for each projection angle.
Besides position, scanner motion also affects orientation. The detector plane must always face the source, and the fan beam must be correctly aligned with the detector elements. A simple way to maintain this geometry is to rotate the entire source detector assembly as a rigid body, instead of trying to rotate each component independently. In GATE, this can be done by defining a logical parent volume that represents the gantry and then rotating this gantry volume around the rotation axis. All child volumes, including source holder and detector array, inherit the motion.
For a basic beginner simulation, you can avoid explicit parent gantry volumes and apply consistent rotations separately to the source and detector, as long as you keep their relative positions symmetric about the rotation center. This is sufficient for educational projects where you only need a single circular orbit without complex tilts.
The scanner motion can be coupled to acquisition time if you want to mimic continuous rotation. In an advanced workflow, you may define time intervals during which the scanner stays at a given angle, simulate a portion of events for that interval, then advance both angle and time. For introductory work, it is simpler to ignore time and treat each angle as an independent static configuration, then combine the results afterward.
When you compute projection data, you will rely on the known scanner motion to derive the geometry for each recorded event. For example, you can convert a detected photon position on the detector into a ray that originates from the source position at the corresponding projection angle. This is the ray that contributes to a particular bin in the sinogram.
Finally, scanner motion must be consistent with any rotation you apply to the phantom or patient. In standard CT simulations, the patient remains fixed and only the scanner moves. If you ever decide to rotate the phantom instead, then you must not also rotate the scanner around the same axis, or you will double count the motion. Decide early whether your simulation represents a rotating gantry, a rotating patient, or a combination, and keep that choice fixed throughout your geometry definitions.
Views: 11