Scanner crystal emission background not taken into account in singles processing computations
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 160
- Forks
- 113
- Avg merge
- 12d 15h
- Merged PRs (30d)
- 1
Description
This will impact any randoms estimation from singles and may have lead to the increased half life observed in https://github.com/UCL/STIR/pull/941. The provided plot indicates that the singles decay slower than F18 should, possibly due to LYSO crystal background.
The background activity would need to be known for each scanner from an empty scan? This is beyond the current STIR scanner implementation but could be considered in future.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the singles processing and randoms estimation paths in the STIR scanner implementation. The issue names no files or tests; determine how scanner-specific LYSO background activity could be obtained from an empty scan and where it would affect computations. Done means a concrete, maintainable approach is agreed for accounting for that background.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- data
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100