UCL / UCL/STIR

parallelproj backproj optimisation

Open
#882 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
C++
Stars
160
Forks
113
Avg merge
12d 15h
Merged PRs (30d)
1

Description

At present, even if we do only a subset, or a single RelatedViewgram, the CPU code will be backprojecting all of the data anyway as we pass all of it, see e.g. here

The parallelproj backprojector will not backproject zeroes, but it will have first copied all of the data to the GPU, which is costly.

Easiest work-around for now seems to make a copy in CPU memory of the relevant arrays with only the non-zero data, e.g.

- count number of non-zero entries
- allocate new arrays
- copy data
- call parallelproj_backproj

Alternatively we could keep a mask (updated in actual_back_project) of viewgrams or bins, and do the copy based on the mask (would skip counting, but needs more memory and more code).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in src/recon_buildblock/Parallelproj_projector/BackProjectorByBinParallelproj.cxx around the linked call near line 129, and inspect actual_back_project and parallelproj_backproj. Determine how to pass only relevant non-zero viewgram or bin data, then verify that subset backprojection avoids copying all data to the GPU.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
computer-vision, performance
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.