Benchmarking OCR It's pipeline

OCR It reads a screen-captured region with a bundled Tesseract.js build. This page measures that pipeline against raw Tesseract (isolating what the extension's own image preprocessing adds) and against RapidOCR, a different open-source engine — on a small, controlled, synthetic corpus with known ground truth. Reproducible with npm run bench; see tools/bench/.

Method

Six short passages, styled like a book page, are rendered under four visual conditions and OCR'd by four methods. Every method sees the exact same raw image per sample — the only variable is the OCR method itself.

Conditions

Methods compared

OCR It — Tesseract.js against the same vendored language data the extension ships, with the extension's real preprocessing (crop → ~2× upscale → contrast-stretched greyscale) imported directly from src/ocr/preprocess.js, not reimplemented.
Tesseract.js, raw — identical engine, model and recognize parameters, preprocessing switched off. Comparing this row to OCR It isolates what the preprocessing step is actually worth.
Tesseract CLI, raw — the native tesseract binary, pointed at the same .traineddata file via TESSDATA_PREFIX, so this isolates native binary vs. WASM port rather than comparing different models.
RapidOCR, raw — PP-OCRv4 models over ONNX Runtime, a different engine and model family entirely.

Metrics are Character Error Rate and Word Error Rate (Levenshtein edit distance against the known ground truth, whitespace-collapsed, case/punctuation kept), plus wall-clock recognize time with each engine kept warm (a persistent worker/process, not reloaded per image — the CLI is the one exception, since that's inherent to invoking it as a binary).

Sample size. 24 images total (6 passages × 4 conditions). This is enough to see real, repeatable differences between these specific methods on this specific corpus — it is not enough to make general claims about either engine's accuracy on documents unlike this one (see Limitations).

Results

Overall

By condition

Findings

The preprocessing step is a trade-off, not a universal win

Comparing OCR It to Tesseract.js, raw — the only difference between those two rows is the extension's own crop → upscale → contrast-stretch step:

On low-contrast text, preprocessing measurably helps — the contrast stretch is doing exactly what it's designed to do.
On blurred text, preprocessing is slightly worse than doing nothing — upscaling a soft image with smoothing compounds the softness rather than fixing it. One blurred sample went from a clean read to misreading "carriage" as "carnage" once enhance was applied.
On a plain, undegraded non-retina capture, it makes no measurable difference either way.

In other words: the README's "helps a lot on non-retina displays" claim holds specifically for the washed-out-contrast case it was written for, not as a blanket "always sharpens" claim — and it has a real, if small, cost against a genuinely soft source image.

Native binary vs. WASM: no accuracy difference, as expected

Tesseract CLI, raw and Tesseract.js, raw produce effectively identical text against the same trained data — the WASM port isn't leaving accuracy on the table. The CLI's per-call process-spawn overhead roughly cancels out the WASM runtime's own overhead, so wall-clock time lands in the same range for a single image; the real-world difference shows up over a long run, where Tesseract.js pays its setup cost once (a persistent worker) and the CLI pays it on every single page.

RapidOCR: confident, but the word boundaries collapse under blur

RapidOCR trails every Tesseract variant on both accuracy and speed across the board, and the gap is not subtle once the source is degraded: under the blurred condition its Word Error Rate is far higher than its Character Error Rate, because whole runs of words merge into one unbroken token — "thelampsswung", "wheelsfoundtheoldstoneseasily" — while it keeps reporting a high confidence score on what it did read. The characters it recognizes are largely right; the spaces between them are not, and nothing in its own confidence number flags that. For a tool whose whole job is handing off clean text (to an LLM, to search, to a transcript), that failure mode matters more than the raw character accuracy number suggests.

Limitations

Synthetic corpus, one language, one font, book-page-style prose only — real scans, photographs, and other layouts (tables, multi-column, handwriting) aren't represented here.
One open-source alternative engine. RapidOCR is tuned as much for scene-text/layout detection as for dense body text; a different competitor or a different corpus could land differently.
24 samples. Treat the specific percentages as indicative, not precise population statistics.

Reproducing this

brew install tesseract
python3 -m venv tools/bench/.venv
tools/bench/.venv/bin/pip install -r tools/bench/requirements.txt
npm install
npm run bench

Regenerates docs/bench/results.json, which this page reads directly. See tools/bench/ for the full harness.