A defect inspection model tests clean on the validation set, then quietly misses hairline scratches in production. The images are the same 4K frames the camera always shot — but somewhere between the sensor and the model, a resize call shrank them to 640x640 and the defect disappeared into a smear of interpolated pixels. Nobody wrote a bug. The model is doing exactly what it was trained to do. The problem is that a scratch three pixels wide at full resolution becomes zero pixels wide after an aggressive downscale, and a detector cannot find what the resize erased. This is the situation image patching exists to solve. Rather than shrink a high-resolution image to fit a model’s expected input size, you tile it into a grid of smaller crops, run inference on each crop at (or near) native resolution, and stitch the per-patch predictions back into a single whole-image result. Done well, patching recovers detection recall on small objects that whole-image downscaling destroys. Done carelessly, it multiplies your inference passes by 10-50x per image and turns a real-time pipeline into a batch job. The reason it matters is that patching is a design decision with measurable cost and measurable benefit — not a preprocessing footnote you inherit from a vendor default. How does image patching work in practice? The mechanics are simple; the consequences are not. You take an image that is too large to feed the model at full resolution, divide it into a grid of overlapping tiles, and treat each tile as an independent input. A 4000x3000 frame split into 640x640 patches with modest overlap produces on the order of 35-40 tiles. Each tile goes through the detector, produces its own set of boxes in tile-local coordinates, and those coordinates get translated back into the original image frame before the results are merged. The framework most teams reach for here is SAHI (Slicing Aided Hyper Inference), which wraps a detector like YOLO to slice, infer, and merge automatically. SAHI made the pattern accessible, but the pattern predates any single tool — anyone who has run tiled inference over satellite imagery, medical whole-slide scans, or high-resolution industrial frames has built some version of it. What changed is that the tradeoffs are now well understood enough to reason about before you commit. The key mental shift is this: patching converts a resolution problem into a throughput problem. The detail you preserve by keeping objects near their native pixel size comes directly out of your inference budget. Every patch is a forward pass. That is the entire tradeoff in one sentence, and it governs every decision below. Why can’t I just downscale a high-resolution image instead of patching it? Because small objects have a minimum pixel footprint below which no detector can find them, and downscaling drives objects below that floor. Most object detectors — YOLO variants, RT-DETR, Faster R-CNN — expect input in the 512-1024 pixel range and were trained on datasets like COCO where objects typically occupy a meaningful fraction of the frame. When you resize a 4K image to 640x640, you compress it by roughly a factor of six on each axis. An object that was 40 pixels tall becomes about 7 pixels tall. A hairline crack that was 3 pixels wide becomes sub-pixel and vanishes into interpolation. This is a concrete instance of a broader failure: off-the-shelf computer vision breaks when production conditions diverge from what the pre-trained model assumed. The model assumed objects fill a reasonable share of the frame. Your production images violate that assumption because the object that matters — a defect, a distant person, a small SKU on a packed shelf — occupies a tiny fraction of a large sensor readout. In our experience diagnosing recall failures on inspection lines, resolution mismatch is one of the most common and most silently damaging causes; the model looks healthy on aggregate metrics because it still finds the large, easy objects, and the misses cluster exactly on the cases you care about most. When resolution and object scale are the divergence point, scoping whether off-the-shelf CV can meet your accuracy target at all becomes a first-class design question rather than a tuning afterthought. Downscaling is not always wrong. If your objects are large relative to the frame — a whole product in the center of a lightbox, a vehicle filling most of a lane — downscaling is cheaper and fine. Patching earns its cost only when the objects that matter are small relative to the frame. That is the condition to check first. How do I choose patch size and overlap for my objects and resolution? Patch size should keep your smallest object of interest at a pixel footprint the detector can actually resolve — as a working heuristic, at least 20-30 pixels on its shortest side within the patch (an observed planning range, not a benchmarked threshold; the exact floor depends on your detector and object type). Work backward from there. If your smallest defect is 15 pixels at full resolution and your detector needs objects around 25 pixels to fire reliably, you need patches small enough that no downscaling happens inside the patch — meaning the patch input size matches the crop size. Overlap exists to solve one specific problem: objects that straddle a tile boundary. Without overlap, a defect sitting on the seam between two patches gets cut in half, and neither half looks like a complete object to the detector. A common starting point is 15-25% overlap between adjacent tiles, enough that any object smaller than the overlap band appears intact in at least one patch. Larger objects relative to the patch need proportionally more overlap to guarantee a clean capture. Patch strategy decision rubric Use this to decide whether — and how — to patch, before you write any code: Signal Downscale whole image Patch the image Smallest object of interest, % of frame > ~5% of frame height < ~2% of frame height Object pixel size after resize to model input Stays above ~25 px Drops below ~15 px Latency budget per image Tight / real-time Has headroom or batch-tolerant Object density Sparse Dense (many small objects) Object scale variance Uniform Mixed (some huge, some tiny) When most signals fall in the right column, patch. When they split, you are likely in a multi-scale case — run the whole image for large objects and patch only the regions that need it, rather than tiling the entire frame uniformly. What does patching cost me in inference passes, latency, and compute? The cost is the number of patches, and it compounds fast. A uniform grid of NxM tiles means N times M forward passes per image instead of one. For the 4000x3000 example split into 640x640 patches with 20% overlap, you land in the range of 35-40 passes per image. That is a 35-40x increase in inference work for a single frame (an illustrative count derived from the tiling geometry, not a measured benchmark). At real-time frame rates this is the difference between a pipeline that keeps up and one that falls hours behind. This is exactly where patch strategy stops being a computer vision concern and becomes a systems concern. Patching multiplies inference passes, so it interacts directly with GPU utilization, batching strategy, and per-image cost — the territory where inference optimization and hardware cost decisions live. Patches are independent forward passes, which is good news: they batch cleanly. Instead of 40 sequential calls you can push 40 patches through as one or a few batches, keeping the GPU saturated and amortizing kernel-launch overhead through frameworks like TensorRT or ONNX Runtime. The FLOPs do not disappear, but throughput improves substantially when the accelerator stays busy rather than idling between single-image calls. The three numbers to measure before committing are the ones that decide build-vs-buy: small-object detection recall (does patching recover the misses?), inference passes per image (what is the true multiplier for your grid?), and end-to-end per-image latency (does the batched cost fit your budget?). All three are evaluable on a sample before you build anything. How do I stitch patch-level predictions back into a coherent whole-image result, and handle boundary objects? Stitching is where naive patching produces its most visible artifact: the same object detected twice. When you use overlap — and you should — an object in the overlap band appears in two adjacent patches and produces two boxes after coordinate translation. If you simply concatenate all patch results, you double-count. The standard fix is non-maximum suppression applied globally after merging, in whole-image coordinates. Each patch’s boxes are translated from tile-local to image-global coordinates, all boxes are pooled, and NMS collapses overlapping high-confidence detections of the same class into one. This is the same NMS every detector already runs internally; the difference is that you run it a second time across patch boundaries. Getting the IoU threshold right for this cross-patch pass matters — too aggressive and you merge two genuinely adjacent small objects into one; too loose and duplicates survive. It is worth understanding what the confidence and IoU values actually mean before tuning this step, because the failure modes are subtle and metric-dependent. Objects that straddle a boundary are handled by the combination of overlap plus global NMS: overlap ensures the object appears whole in at least one patch, and global NMS ensures the whole detection wins over the two partial ones. Where this breaks down is objects larger than a single patch — a long crack spanning three tiles will never appear complete in any patch, and no amount of NMS reassembles it. That is the boundary condition where uniform tiling fails and you need either larger patches, a multi-scale approach, or a segmentation model that reasons about connected regions rather than boxes. When does image resolution push you toward a custom build? Patching is the first thing to try when a stock detector misses small objects, precisely because it is cheap to test and requires no retraining. If patching an off-the-shelf model recovers acceptable recall within your latency budget, you may not need a custom build at all — you need the right inference geometry around a model that was fine all along. That is the good outcome, and it is worth exhausting before committing to a training program. The push toward a custom build comes when patching alone cannot close the gap: when your objects are so far outside the training distribution that even at native resolution the detector does not recognize them, when the latency multiplier of the patch grid you need is incompatible with your throughput requirement, or when boundary-spanning objects break the tiling assumption fundamentally. Image patching feasibility — input resolution, object scale, and tolerable latency — is one of the requirement inputs an accuracy-target assessment weighs when deciding whether stock computer vision can meet the target or whether a bespoke model is warranted. Patching does not resolve the build-vs-buy question by itself, but it produces exactly the evidence that question needs. FAQ What’s worth understanding about image patching first? You divide a high-resolution image into a grid of overlapping tiles, run the detector on each tile at near-native resolution, translate each tile’s predictions back into whole-image coordinates, and merge them. In practice it converts a resolution problem into a throughput problem — the detail you preserve comes directly out of your inference budget, because every patch is a separate forward pass. Why can’t I just downscale a high-resolution image instead of patching it? Because downscaling drives small objects below the minimum pixel footprint a detector can resolve. Resizing a 4K image to 640x640 compresses roughly 6x per axis, so a 3-pixel-wide crack becomes sub-pixel and vanishes. Downscaling is fine when objects are large relative to the frame; it fails precisely when the objects that matter are small. How do I choose patch size and overlap for my objects and resolution? Size patches so your smallest object of interest stays above roughly 20-30 pixels on its shortest side within the patch — an observed planning range, not a fixed threshold. Set overlap (commonly 15-25%) large enough that any object smaller than the overlap band appears intact in at least one tile, which is what protects objects straddling a boundary. What does patching cost me in inference passes, latency, and compute? The cost is the patch count: an NxM grid means N×M forward passes per image. A 4K frame in 640x640 tiles with 20% overlap lands around 35-40 passes — an illustrative count from the tiling geometry, not a benchmark. Patches batch cleanly, so keeping the GPU saturated through TensorRT or ONNX Runtime recovers much of the throughput even though the FLOPs remain. How do I stitch patch-level predictions back into a coherent whole-image result? Translate each patch’s boxes into whole-image coordinates, pool them, and run non-maximum suppression globally across patch boundaries. Overlap plus global NMS is what handles boundary-straddling objects: overlap ensures the object appears whole in at least one patch, and NMS lets that complete detection win over the two partial ones without double-counting. When does image resolution make an off-the-shelf CV model fail, pushing me toward a custom build? Off-the-shelf detectors fail when production images violate the model’s assumption that objects fill a reasonable share of the frame. Try patching first — it is cheap and needs no retraining. Move toward a custom build only when patching cannot close the recall gap within your latency budget, or when boundary-spanning objects break the tiling assumption fundamentally. How do I handle objects that straddle patch boundaries without double-counting or missing them? Use overlap to guarantee the object appears whole in at least one tile, then apply global NMS after merging so the complete detection suppresses the partial duplicates. This breaks down only for objects larger than a single patch, which never appear whole anywhere — those require larger patches, a multi-scale pass, or a segmentation model that reasons about connected regions. Before you commit to retraining anything, patch a stock detector over a representative sample and measure recall, passes per image, and latency. If those three numbers land inside your budget, the model was never the problem — the inference geometry was.
