Measured
OCR benchmark, including what it gets wrong
Every figure below names its method, its hardware and its date. Where a measurement is thin, it says so on the same line as the number.
Updated · Senithu Software Solutions
What we verified
Measured directly against the production service this week. Each one is reproducible from the method beside it.
| Measurement | Result | Method | Date |
|---|---|---|---|
| Reading a digital PDF from its text layer | 0.057 s | Same single-page PDF read twice: once from its embedded text layer, once rasterised at 150 DPI and recognised. Wall clock, warm. | 2026-08-01 |
| Recognising that same page as an image instead | 0.508 s | The comparison run above. Nine times slower, and it introduced an error the text layer did not have. | 2026-08-01 |
| Throughput, digital PDFs | 7.58 pages/s | 40 jobs submitted at once, six concurrent workers, timed from first submission to last completion. | 2026-08-01 |
| Throughput, scanned pages through recognition | 3.13 pages/s | 30 jobs, same conditions, single-page scanned PDFs with no text layer. | 2026-08-01 |
| Recognition languages installed | 161 | Counted on the production host from the engine’s own language list. | 2026-08-01 |
| Page segmentation mode made no measurable difference | no change | A multi-column CV layout read at PSM 6 (uniform block) and PSM 3 (automatic). Output identical apart from one comma. A negative result, published because we had assumed otherwise. | 2026-08-01 |
Hardware: Contabo Cloud VPS 8 — 8 vCPU AMD EPYC (avx2, no avx512), 23 GiB RAM, Ubuntu 24.04.4 LTS. Tesseract 5.3.4 at OMP_THREAD_LIMIT=1, six concurrent workers, warm runs, queue drained between measurements.
Engine comparison — preliminary
Five engines on the same two samples, 30 July 2026. Read the caveat first; it is not a footnote.
Preliminary, v0.1. Two synthetic samples only — one clean rendered invoice, one degraded copy (rotated 3.5°, gaussian noise, blur, −25 contrast) simulating a phone photo. This is indicative of behaviour, not a measure of general accuracy. A 500-document corpus run is scheduled and will supersede it. Published in this state because a comparison with its limits stated is more useful than none.
| Engine | Clean | Degraded | Errors | Outcome |
|---|---|---|---|---|
| Tesseract 5.3.4Read “No,” for “No.” Fastest safe option; our default. | 0.62 s | 0.97 s | 1 | In use |
| EasyOCR (torch 2.13)Perfect on the degraded sample. Slow, so we route to it rather than default to it. | 12.79 s | 7.50 s | 0 | In use |
| PaddleOCR 2.10.0Fastest of all, and disqualified: it converted the thousands separator in currency amounts, turning 1,250.00 into 1.250.00. | 0.59 s | 0.50 s | 8 | Excluded |
| PaddleOCR 3.7.0Accurate but strictly dominated on this CPU — slower AND less accurate than EasyOCR (oneDNN unavailable here). | 9.67 s | 11.68 s | 1 | Excluded |
| OCRmyPDF 15.2.0Searchable PDF/A-2B output. Different job, measured for completeness. | 1.85 s | — | — | In use |
What it gets wrong
Reproduced on our own service. Published because a limit you can check is worth more than an accuracy percentage you cannot.
- Known limit
Capital I becomes lowercase l on recognised images
In a sans-serif face at 150 DPI the two glyphs are identical. On a real CV this turned a subject heading into a different word. Reading the text layer instead avoids it entirely.
AI & Data ScienceAl & Data Science - Known limit
Arabic returns the right letters in the wrong order
Characters are recognised accurately but come back in visual rather than logical order, so words read backwards. Right-to-left output needs reordering before use.
فاتورة ضريبيةةيبيرض ةروتاف - Known limit
Arabic-Indic numerals are unreliable
Eastern Arabic digits are not read dependably in either language mode. Do not trust numeric fields in Arabic documents without review.
١٢٣ ٤٥٦١١١ 01 - Disqualified
A faster engine that corrupts money
PaddleOCR 2.x was the fastest engine we measured and is excluded by default: it rewrote the thousands separator as a decimal point. On an invoice that is a thousandfold error, silently.
1,250.001.250.00
Defects this measuring found
Each was live in production and invisible until something was measured. All four are fixed; they are listed because the reason to measure is to find them.
- A multi-page PDF handed to the image path returned page 1 only, reporting pageCount 1 with no error. Silent truncation is worse than a failure, because the caller cannot tell.
- A palette-compressed BMP — what Windows Paint writes by default — failed to decode entirely on a format we publicly support.
- Recognised text was joined word by word with spaces, flattening an eight-line note into one line. The line structure was computed for reading order, then discarded.
- Digital PDFs were rasterised and recognised rather than read, importing OCR’s errors into documents whose text was already exact.
Methodology
- One host, named. Contabo Cloud VPS 8 — 8 vCPU AMD EPYC (avx2, no avx512), 23 GiB RAM, Ubuntu 24.04.4 LTS. Tesseract 5.3.4 at OMP_THREAD_LIMIT=1, six concurrent workers, warm runs, queue drained between measurements.
- Warm runs. Engines are loaded before timing, so figures exclude first-load cost. That flatters every engine equally.
- Wall clock, not CPU time. What the caller waits for is what we report.
- Small samples, stated. The engine comparison used two synthetic documents. The verified table uses single real documents per measurement. Neither is a corpus, and neither is presented as one.
- Single host, no cluster. Throughput figures describe this machine at six concurrent workers, not a scaled deployment.
- Superseding run scheduled. A 500-document corpus with per-field precision will replace the preliminary table. Until it exists, this page says so.