OCR Accuracy for Chinese Characters at Low Resolution

The same scanner setting that produces clean, accurate English text produces Chinese text with errors scattered through it, and the errors are real characters rather than garbage. The cause is not the model. It is that a Chinese character has to carry several times as much information in the same physical space.

Information per glyph

A Latin lowercase letter has to be distinguished from twenty-five others, and most of the distinguishing happens at a coarse scale: ascenders, descenders, closed bowls, overall silhouette. Even at low resolution the silhouette survives, which is why English OCR degrades gracefully.

A Chinese character has to be distinguished from thousands. China’s State Council published the Table of General Standard Chinese Characters in June 2013, which standardises 8,105 characters, of which the first tier of 3,500 covers the overwhelming majority of everyday text. Those characters are built from components packed into a square of fixed size, so a character with twenty strokes occupies exactly the same area as one with three. The strokes get thinner and closer together instead.

Type designers have priced this in for decades, which gives an independent check on the ratio. Bitmap fonts for Chinese were standardised at 16 × 16 pixels for basic screen display, with 24 × 24, 32 × 32 and 48 × 48 sets used where quality mattered — the HZK16, HZK24 and HZK32 files that shipped with Chinese DOS systems. Latin text on the same machines rendered in an 8 × 16 cell. That is a factor of two in area at the minimum viable size, and the 16-pixel Chinese set was widely considered adequate only for reading common characters at short lengths, not for the dense ones.

The pairs that fail first

The general argument becomes concrete when you look at which characters collide. Several extremely common pairs differ by the length of one stroke or by the presence of one short mark:

• 未 and 末 — identical except for which of the two horizontal strokes is longer. At low resolution the two horizontals quantise to the same pixel width and the distinction is gone.
• 土 and 士 — the same, one stroke length apart.
• 日 and 曰 — differ in proportion only, one being taller and one wider.
• 己, 已 and 巳 — three characters differing in how far one stroke extends upward.
• 戌, 戍 and 戊 — differ by a single short stroke inside the frame.

None of these is exotic; all appear in ordinary text. And the distinguishing feature in each case is roughly one stroke-width of difference, which is the first thing lost when the glyph is rendered into too few pixels. That is the mechanism: the recognition problem is not about the character as a whole but about sub-features whose scale is one stroke, and those features vanish before the character does.

Working out the DPI floor

The arithmetic is worth doing yourself rather than accepting a scanner preset, because it tells you where your own documents sit. The conversion is that pixels equal millimetres divided by 25.4 multiplied by dots per inch.

Take a common body size in Chinese print. The traditional 五号 size is 10.5 points; a point is 1/72 inch, so a character body is about 0.1458 inch, or roughly 3.7 mm square. Then:

character body ≈ 10.5 pt = 10.5 / 72 in ≈ 0.1458 in ≈ 3.70 mm

  at 150 dpi :  0.1458 × 150 ≈ 22 px per side
  at 200 dpi :  0.1458 × 200 ≈ 29 px per side
  at 300 dpi :  0.1458 × 300 ≈ 44 px per side
  at 400 dpi :  0.1458 × 400 ≈ 58 px per side

Latin lowercase at the same 10.5 pt has an x-height of roughly
40–50% of the em, so ≈ 9 px at 150 dpi and ≈ 18 px at 300 dpi —
and it only has to separate 26 shapes at that size.

Set that against the bitmap-font evidence. Sixteen pixels per side is the floor at which common characters are readable at all, and 24 to 32 is where dense characters stop degrading. A 150 dpi scan of 10.5 pt text lands at about 22 pixels — inside the minimum but with nothing spare for a character of twenty-plus strokes, and nothing spare for the scan itself being imperfect. 300 dpi lands at about 44, comfortably above the 32-pixel high-quality bitmap size, which is why 300 is the usual recommendation and why it holds up under this derivation rather than being folklore.

The assumptions are all on the page and you should substitute your own: smaller print, a footnote size, a fax-quality source or a photograph taken at an angle all shift the numbers down, and each halving of DPI quarters the pixel area available per glyph.

What destroys strokes besides resolution

Raising the DPI does not help if a later stage throws the detail away again, and several common defaults do.

• Binarisation. Converting to pure black and white with a global threshold turns a thin grey stroke into nothing. Adaptive thresholding is better; keeping greyscale and letting the recogniser handle it is often better still for CJK, because the anti-aliased edges carry stroke-width information that a binary image discards.
• JPEG compression. The artefacts cluster at high-contrast edges, which in a page of Chinese text is everywhere. Compressing a scan to a small JPEG before OCR is one of the most common self-inflicted accuracy losses. Use a lossless format for the intermediate.
• Despeckling and noise removal. Filters that remove small connected components remove short strokes and the dots in Arabic alike. Tune them against a script-specific sample, not a default.
• Downscaling in a document pipeline. A viewer or a storage layer that normalises page images to a fixed width will silently undo a high-resolution scan. Check what your pipeline hands the OCR stage, not what the scanner produced.

Why the error is silent

A misrecognised Chinese character is nearly always another real character. There is no equivalent of the Latin OCR error that produces “rn” for “m” and leaves a non-word behind for a spell-checker to catch: the substituted character exists, it has a meaning, and the surrounding text still parses. A date, a name or a quantity can change without anything downstream noticing.

Two practical consequences. First, measure character error rate on a held-out sample rather than trusting engine confidence scores, which are calibrated to the recogniser’s own uncertainty and not to whether the result is a plausible word. Second, a language-model post-correction pass is unusually valuable here precisely because the errors are real characters in implausible contexts — the model sees a sentence that is locally well-formed and globally odd, which is exactly the signal it is good at. Feed it the candidate alternatives from the recogniser where you can get them, rather than the top-1 string alone. Downstream, the consequences for chunking are covered in sizing CJK chunks in tokens rather than characters.