Radial profiles are slower on large images since only the occupied bins are accumulated #107

Problem

Since #104 (which closes #103), get_radial_profile always groups the pixels with np.unique(..., return_inverse=True) before np.bincount, so that only the bins holding pixels are allocated. This avoids huge allocations with tiny pixel spacings, but the sort it involves slows down the usual case (uniform coordinates, normal step), where the bins are far fewer than the pixels and the former direct np.bincount was both safe and fast.

Measured with NumPy 2.4.4 (random image, off-pixel center, step 1):

#98 and #104 are both later than v1.3.0: without a fix, radial profiles of large images would be 2 to 3 times slower in Sigima 1.4 than in Sigima 1.3.

Proposal

Choose the grouping strategy from the number of bins, with no tuning:

• dense bins (largest bin index lower than the number of pixels, i.e. the usual case): accumulate directly with np.bincount on the bin index (converted to integers only after this test, to avoid overflows), leaving out the empty bins as before — no sort, and no more entries than pixels;
• sparse bins (tiny step): keep the current np.unique + np.bincount path.

The memory used still never exceeds the size of the image, whatever the step, and results are bit-identical in both paths (same bins, same order of accumulation). The contract of radial_profile is unchanged (version 2).

Tests: bit-identity with the former implementation on both paths (dense and sparse bins), and a guard checking that dense bins are grouped without sorting.

Reported by an independent review of Sigima 1.4 (unreleased).