47.14. Creating Lines of Response

Table of Contents

Understanding Lines of Response

In PET, each coincidence event is interpreted as two 511 keV photons detected in different crystals. If both photons originate from the same annihilation, they define a straight line that passes through the annihilation point, at least statistically. This straight line, joining the two detection positions, is called a line of response, usually abbreviated LOR.

In GATE, you do not get LORs directly from the simulation kernel. Instead, you get coincidence events containing information about the two detector hits. Creating LORs means taking this coincidence information, extracting the detector positions, and building a mathematical description of the line that joins them.

LORs are the main input to PET image reconstruction. Building them correctly is therefore a key step between a PET simulation and an image. In this chapter, you will learn how to go from coincidence data to explicit LOR descriptions suitable for later reconstruction or analysis.

Information Needed to Build an LOR

To create an LOR from one coincidence, you need, for each photon in the pair:

The 3D position of the detection point in the scanner coordinate system.
Optionally, timing information for TOF PET, which is covered elsewhere.

In a typical GATE PET simulation, the coincidence output contains at least two sets of positions, one for the first single in the pair and one for the second. Depending on how you configured the PET digitizer and coincidence sorter, these positions might be:

Crystal-level positions, usually the center of the scintillation crystal that fired.

More detailed hit positions, if you choose to store information closer to the underlying Geant4 hits.

For the purpose of LOR construction at the level of this example, crystal-center positions are sufficient. Suppose the coincidence output gives you coordinates for detector 1 as $(x_1, y_1, z_1)$ and for detector 2 as $(x_2, y_2, z_2)$, both in millimeters. The LOR is then the unique straight line that passes through these two points.

Mathematical Description of an LOR

There are several equivalent ways to describe the line through two 3D points. Two forms are especially useful in PET:

A point–direction parametric form.

A two-point representation.

In the point–direction form, you choose one of the two detection positions as a reference point, for instance the first:

$$
\mathbf{p}_0 =
\begin{pmatrix}
x_1 \\ y_1 \\ z_1
\end{pmatrix},
\qquad
\mathbf{d} =
\begin{pmatrix}
x_2 - x_1 \\ y_2 - y_1 \\ z_2 - z_1
\end{pmatrix}
$$

The LOR is then:

$$
\mathbf{p}(t) = \mathbf{p}_0 + t \, \mathbf{d}
$$

where $t$ is any real number. This representation is convenient for later geometric calculations, such as finding where the line intersects a reconstruction grid or a slice.

In the two-point representation, you simply store the pair of endpoints:

$$
\mathbf{p}_1 =
\begin{pmatrix}
x_1 \\ y_1 \\ z_1
\end{pmatrix},
\qquad
\mathbf{p}_2 =
\begin{pmatrix}
x_2 \\ y_2 \\ z_2
\end{pmatrix}
$$

Many PET reconstruction codes and file formats use this form directly. For absolute beginners, it is easier to start by thinking of an LOR as the segment that joins $\mathbf{p}_1$ and $\mathbf{p}_2$.

An LOR is fully defined by the two 3D detection positions:
$$
\text{LOR} = \{\mathbf{p} \mid \mathbf{p}(t) = \mathbf{p}_1 + t(\mathbf{p}_2 - \mathbf{p}_1),\ t \in \mathbb{R}\}
$$
Store either the two endpoints $(x_1, y_1, z_1)$ and $(x_2, y_2, z_2)$ or one point plus the direction vector.

Creating LORs from GATE Coincidence Output

Once your PET simulation is configured to record coincidences, you typically obtain a file containing coincidence events. The exact format depends on your configuration, but often it is a ROOT file or a text compatible file. In earlier chapters, you saw how to obtain coincidence information, including:

Event or run identifiers.

Energies of the two photons.

Times of detection.

Detector identifiers and positions.

To construct LORs, you will select coincidence events that pass your quality criteria, then extract the two detector positions for each event.

A typical sequence is:

Load the coincidence data using ROOT, uproot, or another tool, depending on your chosen analysis workflow.

Apply your PET energy window to reject scattered or poorly measured events. This is covered in detail in other chapters and in the PET example path, so here you will only filter coincidences to those already accepted by the previous steps.

For each remaining coincidence, read the 3D positions of detector 1 and detector 2. They are usually stored in three separate fields per detector, such as x1, y1, z1 and x2, y2, z2, or in a compressed vector form.

Construct the LOR description. At this level, storing the two endpoints is enough.

Optionally, save the LORs into a new file that contains only the information needed for reconstruction: two endpoints, energies and time stamps.

The exact names of the position fields depend on your configuration of the PET digitizer and output actors, which is described in other chapters. Here, the important idea is that every usable coincidence becomes one LOR entry in your derived data.

Coordinate Systems and Consistency

When you create LORs, consistency of coordinate systems is crucial. The positions for both detectors in a coincidence must be expressed in the same global coordinate frame.

In GATE, detector positions stored in the output are usually global coordinates, not local coordinates relative to a block or crystal. If you choose to write local coordinates instead, then you must transform them into the global frame before creating LORs. Mixing local and global coordinates within one LOR would lead to completely wrong geometry.

Another frequent source of errors is unit conversion. In GATE, positions are expressed using explicit units in your Python code, but once written into a file, they are usually stored as plain numbers. Know the convention you use in your simulation. If your output is in millimeters, keep all LOR calculations in millimeters until you explicitly convert. Never add millimeters and centimeters in the same expression.

Always build LORs from positions that:

Are in the same coordinate system, typically the global simulation frame.
Use the same length unit, for example all in millimeters.
Mixing coordinate frames or units produces incorrect LOR geometry.

Adding Time-of-Flight Information to LORs

Time-of-flight PET is introduced elsewhere, but it is useful to understand how TOF information relates to LORs.

For each coincidence, in addition to the two positions, you have detection times $t_1$ and $t_2$ for the two photons. The difference $\Delta t = t_1 - t_2$ contains information about where along the LOR the annihilation likely occurred. In an ideal system, ignoring detector and physics blurring, the distance of the annihilation point from the midpoint of the LOR is:

$$
\Delta x = \frac{c \, \Delta t}{2}
$$

where $c$ is the speed of light expressed in the same time and length units that you use for $t_1$ and $t_2$.

In practice, detector timing resolution blurs this relationship significantly. Even so, TOF information is usually stored together with the LOR endpoints, for use by TOF-capable reconstruction algorithms. When you build LORs for a TOF PET example, you should therefore not discard the time information.

In a TOF-aware LOR record, you might store:

The two endpoints of the LOR, $(x_1, y_1, z_1)$ and $(x_2, y_2, z_2)$.

The time stamps $t_1$ and $t_2$, or directly the time difference $\Delta t$.

The energies of both photons.

The event identifier to allow later classification into true, scattered, and random coincidences.

For TOF PET, the position of the annihilation along the LOR is related to the detection time difference by:
$$
\Delta x = \frac{c \, \Delta t}{2}
$$
Use consistent units, for example $c \approx 0.3\ \text{mm/ps}$ if time is in picoseconds and length in millimeters.

Storing LORs for Reconstruction

Once you can build LORs in your analysis environment, you need to store them in a way that reconstruction software can read. There is no single standard for simulated LOR files, but several common patterns exist.

A simple and flexible choice for educational purposes is a text or binary table where each row corresponds to one LOR. Such a table may contain:

Coordinates of the first endpoint $x_1, y_1, z_1$.

Coordinates of the second endpoint $x_2, y_2, z_2$.

Energies $E_1, E_2$.

Optional detection times $t_1, t_2$ or their difference $\Delta t$.

An event or random index.

A possible layout for such a table is:

Column	Meaning	Units
x1	First detector x position	mm
y1	First detector y position	mm
z1	First detector z position	mm
x2	Second detector x position	mm
y2	Second detector y position	mm
z2	Second detector z position	mm
E1	First photon energy	keV or MeV
E2	Second photon energy	keV or MeV
t1	First detection time	ns or ps
t2	Second detection time	ns or ps
evtID	Event identifier	dimensionless

You may not need all columns for a simple, non TOF PET example. However, designing your LOR format to be extensible from the beginning makes it easier to add new information later without breaking your existing analysis scripts.

In more advanced workflows, you can convert your LORs into specialized raw data formats expected by reconstruction packages. These formats are beyond the scope of an introductory course. For the moment, a simple tabular representation with clear columns is sufficient.

Using LORs in the Practical PET Example

Within the practical PET scanner example, the steps related to LORs fit near the end of the chain:

You built the scanner geometry and added an F-18 source.

You configured the PET physics and the digitizer to generate singles and coincidences.

You applied an energy window to reject non physical or scattered events.

Now you take the cleaned coincidence dataset and convert it into LORs.

The minimal tasks for this chapter in the example are:

For each coincidence that passes your selection, read the 3D positions of the two detectors.

Store these positions and any other needed fields, such as energies and times, into a table that represents LORs.

Optionally, examine a subset of LORs to verify that they match your scanner geometry, for example by plotting the endpoints in the transverse plane.

These LOR records will then serve as the input for further analysis or as a bridge to external reconstruction software. Even if reconstruction is not part of this particular course, you now understand how simulated PET coincidences become the mathematical lines that form the basis of PET images.