-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ML norm code should work by bucket, not by block #838
Comments
Some comments:
|
I have given this a shot and while I thought it would be nice and easy, there are ~180 uses of |
This is a hard set of change to a lot of variables, but not all. Therefore, I will save this for later. See UCL#838
#940 solves this without the renaming. That still needs to be done. |
Super-block versions of find_ML_normfactors3D.cxx and apply_normfactors3D.cxx Fixes #838
re-opened such that we don't forget to rename all the internal functions |
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).
The text was updated successfully, but these errors were encountered: