ML norm code should work by bucket, not by block
A pull request for this has already been merged.
- #940 by @emikhay — merged
- Dominant language
- C++
- Stars
- 160
- Forks
- 113
- Avg merge
- 12d 15h
- Merged PRs (30d)
- 1
Description
As found by @nikefth, @francescaleek and @emikhaylova, the current assumption behind symmetries in find_ML_normfactors3D that the scanner is invariant over rotations by block is often incorrect in practice. Most scanners will have a few blocks in a "bucket", and the rotational (and for some scanners even axial translation) symmetry should be applied on the bucket level.
If the symmetries are wrong, @francescaleek found that the patterns in the estimated geometric factors will incorrect (mostly underestimated).
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 at the find_ML_normfactors3D entry point and review how rotational and axial-translation symmetries are currently applied by block. Determine how those symmetries should instead operate at bucket level, then verify that estimated geometric-factor patterns are no longer incorrectly underestimated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- computer-vision
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100