Repository navigation
Bin dense radial profiles without sorting - #108
Merged
Merged
Conversation
Since #104, get_radial_profile always grouped the pixels with np.unique and its inverse index before np.bincount, so that only the bins holding pixels were allocated. The sort it involves made radial profiles of large images 2 to 3 times slower than in Sigima 1.3 in the usual case (uniform coordinates, normal step), where the bins are far fewer than the pixels and accumulating them directly by index was both safe and fast. The bins are now accumulated directly by index when the largest bin index is lower than the number of pixels (the bin index being converted to integers only after this test), and the bins holding pixels are kept with np.unique otherwise (tiny steps): the memory used still never exceeds the size of the image, whatever the step, and the results are bit-identical in both cases (same bins, same order of accumulation). The contract of radial_profile is unchanged. Closes #107 Assisted-by: Claude Opus 5.5
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #107
Summary
Since #104,
get_radial_profilealways grouped the pixels withnp.unique(..., return_inverse=True)beforenp.bincount, so that only the bins holding pixels were allocated. The sort it involves made radial profiles of large images 2 to 3 times slower than in Sigima 1.3 in the usual case (uniform coordinates, normal step), where the bins are far fewer than the pixels.get_radial_profilenow chooses the grouping strategy from the number of bins, with no tuning:np.bincounton the bin index, empty bins left out as before — no sort, no more entries than pixels. The bin index is converted to integers only after this test, since it is unbounded for tiny steps;np.unique+np.bincountpath.radial_profileis unchanged (version 2). No release note: the slowdown was never released (Define image profiles in physical coordinates #98 and Allocate only the occupied bins of radial profiles #104 are later thanv1.3.0).Performance
Whole
get_radial_profile, random image, off-pixel center, step 1, NumPy 2.4.4 (best of 7):v1.3.0(directbincount)develop(np.unique)The small remaining difference with
v1.3.0comes from the input checks added by #104.Validation
profile_physical_unit_test.py):np.uniqueis not called for dense bins, and is called for sparse bins (this test fails ondevelop).--qualification-report: no problem (radial_profilev2 qualified, validation and replay exact).developagainst this branch:profile_app_test.py,provenance_processing_unit_test.py,interactive_processing_test.pypass (52).