direct parametric reconstruction objective function set_up and time-frame info
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 160
- Forks
- 113
- Avg merge
- 12d 15h
- Merged PRs (30d)
- 1
Description
Currently we set-up the single-time-frame objective functions always with the same density
https://github.com/UCL/STIR/blob/fe1af133aee5c44ce9fecd50993612f47d274b44/src/include/stir/recon_buildblock/PoissonLogLikelihoodWithLinearKineticModelAndDynamicProjectionData.txx#L388
This seems dangerous, as it should be a density with the correct time frame info. This seems fixable by using _dyn_image_template to construct an appropriate density. It's a bit wasteful to construct one just for this purpose, but best to be safe.
As the code currently doesn't break, it seems that our set_up functions don't check that proj_data and sensity time frame information is consistent, which seems unsafe. It's possible that they detect that the density time frame information is invalid, and then get on with things nevertheless.
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
Read the linked PoissonLogLikelihoodWithLinearKineticModelAndDynamicProjectionData.txx around line 388, then trace its set_up functions and uses of _dyn_image_template. Check how the objective-function density receives time-frame information and whether proj_data and sensitivity time frames are validated. Done means the density uses the appropriate frame information and inconsistent inputs are handled safely.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- data
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100