KAHIBARO
6.7. Rotation
Table of Contents
Rotation matrices
In GATE, every volume has a position and an orientation. Position is specified by a translation vector in the world coordinate system. Orientation is specified by a rotation matrix. Understanding this is essential whenever you tilt a detector, rotate a phantom, or build scanners with non‑axis‑aligned components.
A rotation matrix in three dimensions is a $3 \times 3$ matrix that describes a pure rotation around the origin. It preserves lengths and angles, and does not include any translation or scaling. When a point with coordinates $\vec{r} = (x, y, z)$ is rotated, its new coordinates $\vec{r}'$ are given by
$$
\vec{r}' = R \, \vec{r},
$$
where $R$ is the rotation matrix. In GATE you do not manipulate the matrices directly in most cases, but the framework internally uses exactly this mathematical representation.
In a right‑handed coordinate system, positive rotations follow the right‑hand rule. This means you point the thumb of your right hand along the positive axis of rotation, and your fingers curl in the direction of positive rotation. GATE and Geant4 both adopt this convention, which is standard in medical physics applications.
There are three basic rotation matrices that correspond to rotations about the $x$, $y$, and $z$ axes. If $\theta$ is the rotation angle, you can define:
Rotation about $x$ axis:
$$
R_x(\theta) =
\begin{pmatrix}
1 & 0 & 0 \\
0 & \cos \theta & -\sin \theta \\
0 & \sin \theta & \cos \theta
\end{pmatrix}
$$
Rotation about $y$ axis:
$$
R_y(\theta) =
\begin{pmatrix}
\cos \theta & 0 & \sin \theta \\
0 & 1 & 0 \\
-\sin \theta & 0 & \cos \theta
\end{pmatrix}
$$
Rotation about $z$ axis:
$$
R_z(\theta) =
\begin{pmatrix}
\cos \theta & -\sin \theta & 0 \\
\sin \theta & \cos \theta & 0 \\
0 & 0 & 1
\end{pmatrix}
$$
Any orientation you need in a GATE simulation can be built by combining rotations about these principal axes. If you apply several rotations in sequence, you multiply the corresponding matrices. For example, a rotation that first turns a detector by $\alpha$ around the $z$ axis, then by $\beta$ around the $y$ axis, is written as
$$
R = R_y(\beta) \, R_z(\alpha).
$$
The order matters because matrix multiplication is not commutative. Swapping the order $R_z(\alpha) R_y(\beta)$ generally produces a different final orientation.
In practical GATE scripts, you usually specify rotations using helper functions that create the underlying matrix from angles. Often you will encounter ways to define rotations using angles around the three main axes, sometimes referred to as Euler angles. Even if you never type the matrices yourself, it is useful to remember that you are really defining $R$, and that GATE always applies this rotation to bring a local volume coordinate system into the world coordinate system.
Many orientation issues come from confusion about which coordinate system you are rotating in. The rotation matrix is always defined with respect to the parent volume coordinate system. When you rotate a child volume, you rotate its local axes relative to its parent. If that parent is already rotated relative to the world, the child inherits that rotation on top.
Because rotations combine, small mistakes in angle or order can give completely unexpected orientations. When this happens, visualization is the fastest way to diagnose the problem. By enabling geometry visualization, you can confirm that the rotation matrix you defined is applied as you intended and that the detector or phantom is really pointing in the desired direction.
The order of axis rotations is critical. A rotation defined as $R = R_z(\gamma) R_y(\beta) R_x(\alpha)$ is not equivalent to $R' = R_x(\alpha) R_y(\beta) R_z(\gamma)$. Always be consistent about the order you apply rotations when building rotation matrices or using angle‑based helpers.
Detector orientation
Detector orientation controls how each detector volume is pointed relative to the world and to other components. For example, in PET you often want crystals to face the scanner center, in SPECT you align a gamma camera head so that its face is normal to the line connecting it to the patient, and in CT you orient detector panels to always face the rotating x‑ray source. In all of these cases you adjust only the rotation, while the detector position may remain on a simple circle or ring.
Conceptually, each detector has its own local axes. When you build the geometry, you decide which local axis represents the detector normal, which axes lie along its edges, and then you define a rotation matrix so that these local directions line up with the desired directions in the parent coordinate system. For example, if the local $z$ axis of a detector crystal is its normal, and you want that normal to point toward the world origin, you construct a rotation that carries the local $z$ axis onto the vector from the detector center to the origin.
In symmetric scanner geometries, detector orientation is commonly linked to an angular position. Imagine a ring of detectors around the $z$ axis. If detector $i$ sits at an azimuthal angle $\phi_i$ in the $xy$ plane, then you can orient it with a rotation around $z$ by $\phi_i$ so that it faces radially inward or outward. If the detector is defined locally so that its normal points along the positive $x$ axis, then a rotation of angle $\phi_i$ around $z$ will make that normal point around the ring. In other configurations, you might rotate about $y$ or $x$ to tilt detectors axially or to create oblique angles.
Detector orientation is particularly important when you simulate flat detector heads or panels. For a planar gamma camera in SPECT, the collimator holes are usually aligned along a single direction. You must orient the head so these hole axes match the incoming gamma directions you wish to measure. A small mistake here, such as a sign error in the angle, can result in a detector that looks correctly placed but actually faces away from the patient, which would block most useful photons.
You also use orientation to arrange detector modules that have internal structure. A PET block may contain an array of crystals with a certain local pattern. Replicating the same block around a ring requires both translation to distribute the blocks in space and rotation so that each block's local crystal grid is consistent with the scanner geometry. Only then can you correctly interpret detector identifiers and later reconstruct images.
Dynamic simulations rely on time‑dependent orientation as well. When you simulate rotating systems, such as SPECT or CT gantries, you change the rotation matrix over time or over projection index. At each step, the same detector head geometry is reused but with a different orientation relative to the patient or phantom. Consistency in how you define these rotations is essential for later analysis of projection angles and reconstruction.
Whenever you work with detector orientation, it is good practice to verify three aspects. First, check that the detector face is actually pointing toward the relevant region or source, not away from it. Second, confirm that lateral axes are aligned as expected, for example that the long axis of a crystal array is really parallel to the scanner axis if that is required. Third, inspect any repeated volumes to ensure that their orientations change smoothly and symmetrically around the geometry, without unexpected flips or permutations.
Incorrect detector orientation can silently corrupt simulation results. A detector that is rotated by 180° around its normal may still appear in the correct place, but it will have its sensitive face turned away from the radiation field. Always verify orientations with geometry visualization before relying on the output.
Views: 11