{
  "id": 13360090,
  "title": "Measure ink and lighting before you binarize an image for OCR",
  "url": "https://urgent.news/2026/10/10/measure-ink-and-lighting-before-you-binarize-an-image-for-ocr",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-10T08:03:34.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/iterandum/measure-ink-and-lighting-before-you-binarize-an-image-for-ocr-34oa"
  },
  "original_language": "en",
  "account": "Before employing any thresholding method in client-side OCR pipelines for internal tools that handle screenshots and photos of printed notices, it is crucial to measure and analyze two key factors: the darkness of the ink and the variations in paper brightness across the image.\n\nThe most common approach involves converting the image to grayscale and applying a fixed threshold at a value of 128. However, this method has two significant flaws. Firstly, it discards text that is lighter than the cutoff, effectively losing important information. Secondly, under uneven lighting conditions, the global threshold applies a uniform value across the entire image, resulting in whole regions being painted black. These issues do not generate any errors; instead, the OCR call returns fewer characters, potentially compromising the accuracy of the recognition process.\n\nTo illustrate these problems, the author tested various scenarios using a web page they created (a made-up Chinese notice) and sampled screenshots at different resolutions, including an 11 px footer in #999 gray on #f5f5f5. The author employed ImgIng (https://imging.ai/) with its default Professional OCR tier, Fast OCR, and Ultimate OCR, comparing their performance against tesseract.js 5 with default parameters on an Apple M4 Mac. The results showed that even with higher thresholds, the text was either completely lost or significantly degraded, particularly when dealing with colored backgrounds and uneven lighting.\n\nTo mitigate these issues, the author proposes measuring the darkness of the ink and analyzing the paper brightness drift before applying any threshold. This approach involves reading the grayscale image, defining a trimming factor to exclude the desk border, and applying local dilation to estimate the paper brightness. The code then reports the minimum ink density, the lowest paper brightness percentile, and the Otsu threshold value, along with a verdict indicating whether the fixed threshold will erase the text or if a global threshold will blacken the paper instead.\n\nIn conclusion, before implementing any thresholding technique in client-side OCR pipelines for internal tools processing screenshots and photos of printed notices, it is essential to perform a thorough audit of the ink darkness and paper brightness variation. By doing so, developers can avoid discarding crucial text and prevent recognition errors caused by uneven lighting or other artifacts.",
  "summary": "My team is looking at client-side OCR for an internal tool where people attach screenshots and photos of printed notices. The first preprocessing snippet anyone pastes into that kind of pipeline is grayscale plus a fixed threshold at 128. It's one line of OpenCV, so before it got near our upload flow I spent an evening measuring what it does. It fails in two quiet ways. It deletes text lighter…",
  "key_points": [
    "Measure ink darkness and paper brightness variation before thresholding",
    "Fixed threshold discards light text and blackens uneven lighting areas",
    "Measure ink density, paper brightness percentile, and Otsu threshold value"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}