SAHI 0.12.2 is out: postprocessing no longer allocates a quadratic matrix

[onuralpszr]

SAHI 0.12.2 is out. pip install -U sahi

It fixes out-of-memory failures and severe slowdowns when postprocessing large detection counts.

What broke

0.11 used a shapely STRtree and only compared boxes the index reported as nearby. 0.12 replaced it with a dense N x N overlap matrix, which is O(N^2) in time and memory whatever the layout. nmm_from_matrix added five more N x N bool arrays, and the TorchVision backend had no size guard, so it built seven N x N tensors on the GPU and ran out of memory first. For the 33337 boxes in #1374 that is 33337^2 * 4 = 4.14 GiB in a single allocation.

The fix

The greedy loops only ever use matrix >= match_threshold, never the metric values. So the thresholded adjacency is now built directly from the pairs an STRtree reports as intersecting, stored as CSR. The dense matrix is never allocated. shapely was already a dependency.

NumPy, TorchVision and Numba all route large inputs there. Inputs below 2000 boxes stay on the dense path, where it is faster, and so does any non-positive threshold, since that matches disjoint pairs the intersection prefilter never enumerates.

Numbers

33337 boxes, IOS metric, threshold 0.3, on an i7-13850HX with an RTX 4000 Ada Laptop (12 GB). Outputs are identical before and after: 6571 predictions for greedy_nmm, 4639 for nmm.

CPU:

backend	greedy_nmm before	after	nmm before	after
numpy	15.88s	0.18s	27.06s	0.21s
torchvision	6.22s	0.18s	17.34s	0.21s
numba	1.53s	1.55s	18.56s	0.22s

CUDA:

backend	greedy_nmm before	after	nmm before	after
numpy	15.93s	0.26s	27.00s	0.21s
torchvision	OOM, 4.14 GiB	0.17s	OOM, 4.14 GiB	0.23s
numba	1.09s	1.09s	18.82s	0.22s

Worth knowing

Above the 2000-box cutoff the TorchVision backend delegates to the NumPy sparse functions, so it no longer uses the GPU for those inputs. It is far faster than the dense GPU path was, but the backend name no longer implies GPU execution there.

The dense TorchVision path computed the metric in float32 while the sparse path uses the input dtype, so a pair sitting exactly on the threshold could round differently between them. Nothing in the test suite hit this.

Also in 0.12.2

RF-DETR local models loadable by class name (#1394), an MMDetection RepeatDataset fix in has_mask (#1387), enforced dependency and minimum-version checks in import_utils (#1377), OpenCV distributions kept on one version (#1393), and completed Chinese documentation (#1371).

Full notes: https://github.com/obss/sahi/releases/tag/0.12.2

If you hit the OOM or the slowdown before, please upgrade and let us know how it goes.