move motion related classes from experimental to the normal locations
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 160
- Forks
- 113
- Avg merge
- 12d 15h
- Merged PRs (30d)
- 1
Description
We currently have 2 sets of motion-related code:
- created by @ctsoumpas, used by PoissonLogLikelihoodWithLinearModelForMeanAndGatedProjDataWithMotion, see https://github.com/UCL/STIR/tree/master/src/spatial_transformation_buildblock
- a (mostly) older version created by @KrisThielemans, include files and definitions. This has files for rigid motion (and Polaris tracking), but also non-rigid. The latter functionality largely overlaps with @ctsoumpas's version. The main difference is
- it defines the "transpose" (really adjoint) warp, and therefore doesn't need the inverse transformation to optimise the log-likelihood (and indeed does it theoretically better)
- it also allows incorporating the Jacobian of the transformation
I checked quite a while ago, and at that point @ctoumpas' version was faster. I don't really know why, but @rijobro is putting in changes to avoid repeatedly warping images for every projection of RelatedViewgrams, see PR #239 , which might fix this.
Note that the 2nd version is currently not compiled by default (you have to create a extra_dirs.cmake in local for that).
The question now is how we merge these 2 versions. This issue is to discuss this further.
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
Compare the motion code under src/spatial_transformation_buildblock with the files in src/include/local/stir/motion and src/local/motion; the latter is only compiled through local/extra_dirs.cmake. Read PR #239 for the related warping changes and assess the adjoint and Jacobian functionality. Done requires an agreed merge plan for the overlapping implementations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- computer-vision
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100