UCL
reading of PETSIRD list-mode function
Made some progress today:
- Automatically detect BlocksOnCylindrical geometry and reconstruct with OSEM25 (1 full iteration):
PETSIRD requires additional dependencies (yardl, pinned xtensor) that are not part of STIR’s standard CI environment. The following PR therefore adds an optional, isolated CI workflow that validates PETSIRD builds without impacting existing CI jobs.
There is a problem with the TOF tests. Very likely, this happened because in this PR I allowed the use of an even number of TOF bins (because my PETSIRD files had an even number). I may have overlooked something regarding the odd number (default in the tests).
@NikEfth I've opened a new pull request, #1671, to work on those changes. Once the pull request is ready, I'll request review from you.
@NikEfth I've opened a new pull request, #1672, to work on those changes. Once the pull request is ready, I'll request review from you.
Introduce PETSIRDInfo as a dataset-level integration object for PETSIRD listmode support and refactor PETSIRD listmode classes to align with STIR’s CListRecord / CListEvent design.
PETSIRDInfo encapsulates all PETSIRD-specific static information needed by STIR, including:
- PETSIRD ScannerInformation and optional Header metadata
- construction of the corresponding STIR Scanner geometry
- mapping from PETSIRD ExpandedDetectionBins to STIR DetectionPositions
- optional forced geometry selection (cylindrical vs block)
PETSIRDInfo is immutable after construction and shared via shared_ptr<const PETSIRDInfo> by all PETSIRD-related components (CListModeDataPETSIRD, CListEventPETSIRD, normalisation, etc.), providing a single source of truth for PETSIRD → STIR interpretation.
The PETSIRD listmode implementation was updated accordingly:
- CListModeDataPETSIRD now owns PETSIRDInfo and exposes it read-only
- CListRecordPETSIRD remains a storage container and embeds CListEventPETSIRD, following existing STIR patterns
- CListEventPETSIRD stores raw PETSIRD coincidence data and performs PETSIRD expansion and geometry mapping on demand using PETSIRDInfo
- PETSIRD expansion and STIR bin mapping are kept out of the record layer
These changes preserve STIR’s separation of concerns, avoid PETSIRD logic leaking into core reconstruction code, and allow PETSIRD geometry and metadata to be reused consistently by listmode, IO, and normalisation components.