PaddleOCR on Arabic scans: blank pages and the fix

PaddleOCR 3.7 read a scanned page of Arabic Wikipedia for 37 seconds and returned an empty string. No error, no warning. It did the same on 15 of the 49 scanned articles in my Arabic OCR benchmark.

I blamed the ink first. The scans have grey ink on cream paper, and a blank page from a text detector usually means it could not see the text. I was wrong: all 49 scans have the same ink and the same paper (grey level 86 on 239), the 15 blank ones included.

PaddleOCR’s text detector found every line on those pages. The pages came back blank because of a limit of 1,000 in the step after it.

What the detector saw

Left: a printed Wikipedia article, scanned at 300 dpi (NOD dataset, CC BY 4.0). Middle: what PaddleOCR’s text detector marked as text, at full size. Right: the same page shrunk to 960 pixels on its long side.

PaddleOCR works in two steps here. A detector scores every pixel for how likely it is to be text, which gives the maps above. Then a short routine cuts the map at a threshold (0.3 by default), traces the outline of every white area, and turns each outline into a box for the recognizer to read.

On this page the detector did its job on the text: every line is a clean white bar. It also lit up the blank paper in the bottom half. That white area is full of small holes and specks, and each one is an outline of its own. At full size, the map holds 3,994 outlines, and 3,958 of them start in the bottom part of the page.

The 1,000 limit

The routine that turns outlines into boxes, DBPostProcess in PaddleX, has a max_candidates setting of 1,000. It takes the outlines in the order OpenCV returns them and stops after the thousandth. On this page OpenCV listed the outlines of the bottom of the page first, so the 1,000 slots went to specks in the blank paper, and none of those became a box. The text lines sat at positions 3,958 to 3,987 of the list. They were never read.

I counted the outlines on the maps my diagnostic script saved, and the count matches what PaddleOCR returned on every run:

Lowering the threshold is the usual advice when a detector misses text. Here it made things worse: more of the paper crossed the threshold, the outlines multiplied, and the page that had worked came back blank too.

Why some pages and not others? The blank ones hold less text and more empty paper: 3.2% of their pixels are ink, against 4.1% on the pages that worked (medians). More empty paper, more specks, more outlines. That is a correlation on 49 pages, and I did not test it further.

max_candidates is not one of the settings the PaddleOCR class accepts, and I did not patch the library to raise it.

The fix: shrink the page before detection

With its defaults for Arabic, PaddleOCR 3 hands the detector the full page: 2,480 by 3,508 pixels for these scans. Two settings cap the size of the page for the detection step only:

from paddleocr import PaddleOCR

ocr = PaddleOCR(
    lang="ar",
    use_doc_orientation_classify=False,
    use_doc_unwarping=False,
    use_textline_orientation=False,
    text_det_limit_type="max",       # cap the long side of the page...
    text_det_limit_side_len=960,     # ...at 960 px, for text detection only
)
page = ocr.predict("page.png")[0]
# page["rec_boxes"] and page["rec_texts"]: one box and its text per line piece.
# For Arabic, I group the boxes into lines and read each line right to left.

What the fix does on 96 real pages

I ran the shrunk setting on all 96 real scans and photos of the benchmark, and compared it with the default run:

The 15 blank pages now come back with text, at 23.1% of characters wrong on average. The other pages barely move: the book scans and the open books get a little worse, the single photos a little better. The detector also has a smaller image to work on, so each page runs about three times faster.

It does not make PaddleOCR good at Arabic. On the 44 real pages that every engine in my benchmark finished, the shrunk PaddleOCR got 21.0% wrong, against 5.0% for Apple Live Text and 3.9% for Surya. If you are tied to PaddleOCR, use the setting. If you are choosing an engine for Arabic, start with the full benchmark.

What I did not test

• Other PaddleOCR versions and languages. PaddleOCR 3.7.0 with lang="ar" only.
• A GPU. PaddleOCR ran on the CPU of an Apple M5 Pro, since PaddlePaddle has no Apple GPU backend. The 1,000 limit does not depend on the hardware; the seconds do.
• Other sizes than 960 and 1,920 pixels, and other kinds of documents than these printed pages.

If you run PaddleOCR in a pipeline, count the pages that come back empty. Mine had no error to catch.