KAHIBARO
27.4. Assigning Detector IDs
Table of Contents
Ring
In a PET scanner model each detection element must be uniquely identifiable so that you can later reconstruct where an interaction occurred. In GATE this is done by attaching integer identifiers to volumes, which are then copied into hit and singles data by the digitizer chain. You already created a PET ring and repeated detector blocks and crystals in previous sections. Here the goal is not to describe the geometry again, but to connect that repetition pattern to meaningful detector IDs.
At the highest level is the ring index. This is relevant if you have more than one axial ring of detector blocks, for example a multi‑ring clinical PET scanner. Even if you model only one ring it is useful to define a ring ID, because many PET analysis tools and reconstruction codes are naturally organized as [ring, module, crystal] indices.
In OpenGATE you do not assign the ring ID by hand to every crystal. Instead you define a hierarchy of "repeaters" that generate copies, and you define a matching hierarchy of readout or ID levels that tell GATE how to translate copy numbers into detector IDs. Conceptually the mapping works like this:
$$
\text{detector\_ID} = f(\text{ring\_copy}, \text{module\_copy}, \text{crystal\_copy})
$$
Here $\text{ring\_copy}$ is the copy number produced by the ring repetition. For a single ring it is usually 0 for all blocks. For multiple rings it runs from 0 to $N_\text{rings} - 1$ along the axial direction.
You typically define one "readout" level that corresponds to the physical ring. In OpenGATE this is set on the detector volume that is repeated along the axis. In the digitizer configuration you then specify that this level should become a field such as "ringID" in the singles and coincidence output. The digitizer will automatically propagate the ring copy number into this field for every recorded event.
When planning IDs it is important to decide whether ring ID will be used as a separate index, or whether you want to fold it into a single composite index. For example, you may store a single integer "detectorID" defined by
$$
\text{detectorID} = \text{ringID} \times N_\text{modules\_per\_ring} \times N_\text{crystals\_per\_module} + \text{moduleID} \times N_\text{crystals\_per\_module} + \text{crystalID}
$$
This mapping preserves uniqueness and can later be inverted if needed. The important point is that GATE provides the building blocks, ringID, moduleID, crystalID, that you can combine in whatever way is convenient for your analysis.
For a multi‑ring PET, always verify that the ring copy index increases along the scanner axis in the direction you expect, and that the number of rings used in any composite ID formula matches the geometry definition.
Module
Below the ring level the geometry usually contains detector modules or blocks. A module groups several crystals into a mechanical unit and is often reused many times around the ring. In GATE the module ID identifies which block along the ring detected the event.
Modules are typically generated with an angular repeater around the scanner axis. The repeater assigns a copy number to each repeated module, which ranges from 0 to $N_\text{modules} - 1$. This copy number is what becomes the moduleID in your data. The first task in assigning module IDs is therefore to align the geometry repetition with the logical ordering you want.
For example, suppose you have 24 modules placed uniformly in a ring. If the repeater defines 24 copies and starts at angle 0, then module copy 0 corresponds to angle 0, copy 1 to $15^\circ$, copy 2 to $30^\circ$, and so on. You can define moduleID equal to this copy number. Later, during analysis, you can convert a moduleID back to an azimuthal angle with
$$
\phi = \frac{2\pi}{N_\text{modules}} \times \text{moduleID}.
$$
Different designs may use several nested module levels, such as "block", "sub‑module", and "crystal row". For a beginner PET scanner you normally begin with a simple two‑level structure: module and crystal. When you configure your digitizer chain, you must refer to the correct volume names and their copy numbers to create the desired moduleID field. The module volume must be declared as a readout level so that its copy number is accessible in the singles and coincidences.
It is important to be consistent. Decide on a fixed direction along the ring for increasing moduleID, for instance counter‑clockwise as seen from the scanner front, and keep this convention throughout your simulations. This avoids confusion when comparing different runs, or when integrating with reconstruction software that expects a particular ring orientation.
In some workflows you may want to assign physical coordinates to a module directly instead of using IDs. For example, you might compute the center position of each module from its radius and angle and store it together with the moduleID. However, even in this case the integer ID is useful, because it provides a compact and unambiguous way to refer to the module in later analysis.
Make sure the number of modules in the digitizer configuration exactly matches the number of modules created by the geometry repeater. A mismatch will lead to ambiguous or incorrect moduleID assignments in the output.
Crystal
The final and most detailed level is the individual scintillation crystal. For PET image reconstruction you need to know which exact crystal detected each photon, because this defines the end points of the line of response. Crystal IDs must therefore be unique within a module, and the combination of ringID, moduleID, and crystalID must be unique in the whole scanner.
In a typical block detector, crystals are arranged in a 2D grid, for example $N_x$ crystals in the transaxial direction and $N_y$ crystals in the axial direction. GATE can generate these crystals using a linear or 2D repeater relative to the module volume. Each repetition level creates copy numbers, such as $\text{ix}$ and $\text{iy}$, which you then map to a one‑dimensional crystalID.
A convenient mapping is
$$
\text{crystalID} = \text{iy} \times N_x + \text{ix},
$$
where $\text{ix}$ and $\text{iy}$ index the crystal column and row within the block. With this formula, crystal 0 is in the first column and first row, crystal $N_x - 1$ is in the last column of the first row, and crystal $N_x$ is the first crystal of the second row. You can choose any indexing order you like, row‑major or column‑major, as long as you document it and use it consistently.
In OpenGATE, the crystal volume is usually declared as a readout level in the digitizer. The digitizer then reads the relevant copy numbers for each hit and builds the final integer crystalID according to your mapping. This crystalID is stored with each single event and is later available for coincidence building and analysis. It is essential that you verify this mapping with a simple test, for instance by placing a point source in front of a particular crystal and checking that the recorded crystalID matches the expected position.
If your scanner uses continuous crystals or light sharing, the geometry may still discretize the detector into virtual crystals or readout channels. In that case you treat these channels in the same way as physical crystals and assign them IDs using the same principles.
To simplify later analysis, many users also define a combined detectorID that merges ring, module, and crystal into a single integer. Using the numbers $N_\text{rings}$, $N_\text{modules}$, and $N_\text{crystals}$ per module, you can define
$$
\text{detectorID} =
\left(
\text{ringID} \times N_\text{modules} + \text{moduleID}
\right) \times N_\text{crystals}
+ \text{crystalID}.
$$
This formula provides a unique index for every crystal in the scanner, independent of how many rings and modules you have.
Always test the crystalID assignment by irradiating known positions and inspecting the recorded IDs. A wrong crystal indexing scheme will not produce an obvious runtime error but will silently corrupt all reconstructed PET data.
The combination of ring, module, and crystal IDs is the bridge between your geometric model and the recorded PET events. Once you have a clear, documented, and tested ID scheme, you can confidently move on to configuring the digitizer and analyzing singles and coincidences.
Views: 4