Library / SDK
obss/sahi avatar
obss/sahi

SAHI: Sliced Inference for Small Objects in Large Images

Framework agnostic sliced/tiled inference + interactive ui + error analysis plots

5,501 stars784 forksPythonMIT

At a glance

What is it?
SAHI wraps an existing detector and runs it over overlapping tiles of a large image, then merges the results. It is a useful layer when your model misses small objects, and a poor fit when your images already match the model's training resolution.
Who is it for?
Adopt SAHI if your detector is missing small objects in images far larger than its training resolution, and you want to keep the model you already trained. Do not adopt it if your images already match the model's input size, or if you cannot absorb the extra inference cost of running the model many times per image.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 6 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The small-object problem SAHI was built around

A detector trained on 640 pixel inputs tends to miss objects that occupy a handful of pixels in a 4000 pixel satellite tile or a whole-slide pathology scan. Resizing the whole image down to the model's input shrinks those objects further. Tiling the image keeps the pixel density, but the naive version of tiling creates its own problems: objects cut in half at tile edges, and duplicate detections in the overlap region. SAHI exists to handle both the slicing and the merging. The README frames it as enabling sliced inference for detecting small objects in large images, and the repository topics point at the intended domains: remote sensing, satellite imagery, small-object detection, large-image work. The audience is practitioners who already have a working detector and a dataset where the objects are small relative to the frame, not people looking for a model to train from scratch.

How sliced inference and the merge step work

The core mechanism is a sliding window. The image is divided into overlapping tiles of a configured slice height and width, each tile is passed to the detector, and the resulting boxes or masks are mapped back into full-image coordinates. Because tiles overlap, the same object can be detected more than once, so a postprocessing step matches overlapping predictions and keeps one. The README does not spell out the matching algorithm in the excerpt available here, so the exact rule for resolving a duplicate is something to read in the slicing documentation rather than assume. Two knobs matter in practice: the overlap ratio between adjacent slices, which controls how often an object sits on a boundary, and the postprocess match threshold, which controls how aggressively duplicates are collapsed. Set overlap too low and objects at edges get truncated. Set the match threshold too loose and adjacent distinct objects of the same class can be merged into one. The library also ships a COCO slicing utility, exposed as a coco slice command, which pre-slices annotation and image files rather than slicing at inference time. That is a different workflow: it changes your dataset on disk, and the README points to a separate slicing utilities document for the details.

Model support and the framework-agnostic claim

SAHI describes itself as framework agnostic and the CLI predict command is documented as working with ultralytics, mmdet, huggingface and torchvision models. That breadth is the main reason to pick it over writing your own tiling loop: the slicing, coordinate remapping and merging are written once and reused across four different model ecosystems. The cost of that breadth is a translation layer. Each supported model family has its own output format, and SAHI has to convert each into a common prediction representation before merging. When a model family changes its output schema, that adapter is what breaks. The release history supports this reading: version 0.12.4 is labelled a CLI dependency fix, which suggests the CLI surface has needed patching independently of the core inference path. The repository also carries an oriented-object-detection topic, which matters for aerial imagery where boxes are rotated rather than axis-aligned. The README excerpt does not document how oriented boxes are handled through the merge step, so treat that as something to confirm against the docs before relying on it.

Getting it running: install and the CLI surface

The package is on PyPI as sahi and on conda-forge, so pip install sahi or a conda install from the conda-forge channel are the two documented routes. The README does not give a pinned version in the install line, so pinning is your decision. Once installed, the entry point is a CLI with subcommands. The predict command runs sliced or standard prediction on images or video using any supported model. The predict-fiftyone command runs the same prediction and opens the results in the FiftyOne app for browsing. The coco slice command slices COCO annotation and image files ahead of time. The coco fiftyone command loads multiple prediction result sets onto a COCO dataset in the FiftyOne UI, ordered by number of misdetections, which is the error-analysis half of the project rather than the inference half. There is also a Python API, since the CLI is described as wrapping the same functionality, but the README excerpt documents the commands rather than the function signatures. For the exact flag names for slice height, slice width and overlap, read docs/cli.md, which the README links directly for predict command usage.

Where SAHI is the wrong tool

Sliced inference multiplies inference cost. A 4000 pixel image tiled at 512 with overlap becomes dozens of forward passes instead of one, and the merging adds CPU work on top. If your objects are already large enough for your detector at full-image resolution, SAHI buys you nothing and costs you throughput. The same applies when your images are already close to the model's training resolution: there is no small-object problem to solve. A second limitation is that slicing does not fix a detector that is simply wrong for the domain. If the model never learned the class, tiling it more finely will not teach it. Third, the merge step is a heuristic, and heuristics have failure modes: dense scenes with many neighbouring small objects are exactly where a duplicate-suppression rule is most likely to drop a real detection. The README does not publish accuracy numbers for the merge step, and none should be assumed. Fourth, the project sits downstream of four external model libraries, so an upstream breaking change lands on SAHI's adapters, as the 0.12.4 CLI dependency fix suggests.

What you would write instead, and when that is better

The obvious alternative is a hand-written tiling loop: crop with a stride, run your detector, offset the boxes, then apply non-maximum suppression or a similar overlap rule yourself. That is perhaps fifty lines for axis-aligned boxes and a single model. It is the better choice when you support exactly one model, your boxes are axis-aligned, and you want no dependency between your inference path and a third-party adapter layer. The difference in approach is not the tiling itself, which is the same arithmetic either way, but what surrounds it: SAHI carries adapters for four model ecosystems, a COCO dataset slicer, a FiftyOne integration for inspecting predictions ordered by misdetection count, and a CLI. If you need only the tiling arithmetic, you are paying for the rest. If you need to compare predictions across model families on the same dataset, or you want the error-analysis view, the hand-written loop means rebuilding all of that. A second alternative is to sidestep the problem at the model level by training or fine-tuning at a higher input resolution, which removes the need for tiling but requires training data and compute that SAHI does not.

Maintenance, releases and the MIT licence

SAHI is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and licence text are retained. That is a permissive licence, and the practical implication is that you can vendor or fork it, which matters given the adapter-layer risk described above. This is not legal advice; read the LICENSE file and your own counsel's view if the distinction matters to you. On maintenance: the repository is not archived, the last push recorded is 2026-09-10, and the release cadence visible here shows 0.12.4, 0.12.5 and 0.12.6 within roughly six weeks in mid-2026. Frequent patch releases are a maintenance signal in both directions: the project is active, and the surface is changing often enough that patch releases are needed. The upgrade cost is concentrated in the adapter layer and the CLI. If you call the Python API directly rather than shelling out to the CLI, you are less exposed to the CLI dependency churn that 0.12.4 addressed. Pin your version, and when you upgrade, re-run your own evaluation rather than assuming the merge behaviour is unchanged between minor releases.

Editorial conclusion

Adopt SAHI if your detector is missing small objects in images far larger than its training resolution, and you want to keep the model you already trained. Do not adopt it if your images already match the model's input size, or if you cannot absorb the extra inference cost of running the model many times per image. Before committing, verify two things on your own data: whether slice height and width chosen for your image scale actually recover the objects your full-image pass missed, and whether the postprocess matching thresholds you pick merge duplicate detections across tile boundaries without deleting legitimate neighbouring objects.

Official sources

  1. License: MIT
  2. obss/sahi on GitHub
  3. Project website
  4. README
  5. Releases
Community notes

Community notes