In OpenCV, when does cv2.adaptiveThreshold beat a global threshold?

## The failure it is built for A global threshold assigns one intensity cut to the entire frame. That is correct only when illumination is uniform. In practice it rarely is: a desk lamp on one side of a page, a curved book spine, vignetting from a wide lens, a shadow from the operator's hand. A single cut is then simultaneously too high in the dim corner (real ink lost) and too low in the bright corner (paper texture promoted to foreground). The signature symptom is a scan where one half is entirely black and the other is speckled. The insight behind adaptive thresholding is that illumination varies **slowly** across the image while the features you care about - strokes, edges, small parts - vary **quickly**. If you threshold a pixel against its own local surroundings, the slow component cancels and only the local contrast survives. ## The signature ``` dst = cv2.adaptiveThreshold(src, maxValue, adaptiveMethod, thresholdType, blockSize, C) ``` Unlike `cv2.threshold` it returns only the image - there is no threshold value to report back, because there are as many thresholds as pixels. **src** must be 8-bit single-channel. Convert to grayscale first. **maxValue** is the value written to pixels that pass, normally 255. **adaptiveMethod** is either `cv2.ADAPTIVE_THRESH_MEAN_C`, where the local threshold is the arithmetic mean of the `blockSize x blockSize` neighbourhood, or `cv2.ADAPTIVE_THRESH_GAUSSIAN_C`, where it is a Gaussian-weighted mean centred on the pixel. The Gaussian variant weights nearby pixels more heavily and generally produces smoother, less blocky output; the mean variant is marginally cheaper. **thresholdType** may only be `cv2.THRESH_BINARY` or `cv2.THRESH_BINARY_INV`. The truncation modes are not supported here, and neither is the Otsu flag - Otsu is a global histogram method and the two are mutually exclusive approaches. **blockSize** is the neighbourhood side length. It must be **odd** and greater than 1; an even value raises an error rather than being rounded, which is the most common first-run mistake with this function. **C** is a constant subtracted from the computed local mean. Positive C raises the bar for becoming foreground. ## Tuning blockSize and C These two are the whole job, and both have physical meaning. `blockSize` sets the scale at which illumination is considered constant. Too small and the neighbourhood sits entirely inside a thick stroke, so the stroke's own interior becomes its own background and hollows out - you get outlines instead of solid characters. Too large and you drift back toward a global threshold, reintroducing the shadow problem. The working rule is that blockSize should be several times the stroke or feature width but well under the scale over which lighting changes. For scanned text at typical resolutions, values in the tens are normal. `C` is the noise margin. With C = 0, a pixel just barely below its local mean flips to foreground, so any flat region - blank paper, empty conveyor - is thresholded on sensor noise alone and comes out as dense salt-and-pepper speckle. This is not a bug in the method; local thresholding has no concept of "there is nothing here." Raising C by a few grey levels demands real local contrast and clears most of it. Increase C until blank areas are clean, then stop - push further and thin strokes start dropping out. ## The clean-up that always follows Even well-tuned, adaptive thresholding produces more isolated speckle than a global threshold does. The standard remedy is a morphological opening with a small elliptical element, which deletes anything thinner than the kernel while leaving real strokes at their original width. If strokes come out broken, follow with a closing. Skipping this step and going straight to `cv2.findContours` is why naive document pipelines report thousands of tiny contours. ## Choosing between the three thresholding strategies A **fixed** value belongs only in a sealed enclosure with locked exposure, where it is the fastest and most predictable option. **Otsu** suits scenes where overall brightness drifts frame to frame but is uniform within each frame, and it hands you back the value it chose, which is a useful health signal. **Adaptive** is for illumination that varies *within* the frame - documents, curved surfaces, uncontrolled ambient light - and is the default for OCR preprocessing and hand-held capture. A hybrid is often best in industrial settings: estimate the illumination field once (a morphological tophat, or a heavy blur used as a background estimate), divide or subtract it out, then apply Otsu to the flattened image. That keeps a single reportable threshold value while removing the gradient, and avoids adaptive thresholding's speckle in genuinely empty regions. ## What it cannot fix Adaptive thresholding needs local contrast to exist. If foreground and background have the same intensity in a region - a grey part on a grey belt, ink that has faded to the paper's tone - no local statistic recovers it. At that point the fix is upstream: lighting geometry, a colour channel that separates the two, or a different feature altogether.