Skip to content
GPU-assistedUpload required

Prepare an Image for OCR

This does not read your document. It conditions the picture so that whatever reads it afterwards has an easier job, which is a different and much more reliable thing to offer. Recognition engines fail in a small number of specific ways — glyphs below their minimum size, soft edges, ink too close in tone to paper, and paper texture mistaken for marks — and each step here targets one of them. No model runs, so no character is ever invented.

Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.

Add to Chrome — free

Drop an image here, or click to browse

Up to 25 MB. Uploaded temporarily, deleted after processing.

GPU-assisted — results vary slightly between runs.

What it does

  • Resampled to give glyphs enough pixels
  • Edges recovered and ink separated from paper
  • Paper tone flattened to a few levels
  • No generative model in the chain

How to use OCR Preprocessing

  1. 1

    Start from the best capture you have

    Resampling cannot add detail that was never recorded. A sharper original beats any amount of processing, so rescan rather than rescue where you can.

  2. 2

    Run the conditioning

    The image is enlarged, sharpened, contrast separated, and reduced to a few tone levels, in that order.

  3. 3

    Feed the result to your OCR engine

    This produces an image, not text. Run it through whatever recognition tool you use and compare the accuracy against the untreated original.

How it works

Four operations, in a fixed order, with no model anywhere in the chain. The output is a deterministic function of your upload.

First the image is resampled with lanczos filtering to about four megapixels. Then it is sharpened. Then its contrast is raised. Then it is quantized to four tone levels with dithering switched off.

Each of those addresses a different documented failure mode, and the order matters as much as the steps.

Recognition fails in a small number of ways

Text recognition is not a general vision problem. It is a narrow one, and it breaks along predictable lines.

The first is glyph size. Engines are trained on characters at a certain scale and have an effective floor below which accuracy does not degrade gracefully — it collapses. Text photographed small, or scanned at a low setting, sits under that floor and returns nothing usable.

The second is edge definition. Recognition depends on the boundary between ink and paper being decisive. Soft edges from a slightly out-of-focus capture, from compression, or from resampling make every letter's outline ambiguous, and similar characters start swapping.

The third is separation. If ink is dark gray and paper is light gray, the two distributions overlap and no reliable division exists between them.

The fourth is false marks. Paper grain, speckle, dust, and print showing through from the reverse of the sheet all look like small dark things, which is exactly what a character is.

What each step does

Resampling to four megapixels addresses the first failure. This adds no information — interpolation cannot recover detail that was never captured — but it presents the detail that exists at a size the engine was built to read. That distinction matters: a fundamentally unreadable scan stays unreadable, while a readable one that was merely too small becomes readable.

Sharpening addresses the second. Enlargement is inherently softening, so the sharpen restores the abruptness at the ink boundary that the interpolation just smoothed away. It is applied immediately after the resize for that reason.

Raising contrast addresses the third. It pulls the ink and paper distributions apart before anything tries to divide them.

Quantizing to four levels addresses the fourth. Every pixel is forced onto one of a handful of values, so the continuous range where paper texture and faint bleed live is simply removed. Dithering is disabled deliberately — dithering preserves apparent tone by scattering dots, and scattered dots are precisely the artifact that would be read as marks.

This is destructive, and it should be

Worth stating plainly, because it is a reasonable thing to be surprised by.

The output of this page is a worse photograph than the input. Tone is gone, texture is gone, anything that depended on a gradient is flattened. If you print it, it will look harsh.

That is the intent. The result is not for a person to look at — it is an intermediate file for a machine, and every property removed was removed because it makes recognition harder rather than easier.

So keep your original. This is a working copy for one specific purpose, not a replacement for the scan.

Measure it rather than trusting it

The last thing worth saying is that this is a set of reasonable defaults, not a guarantee.

Recognition accuracy depends on your engine, the language, the typeface, and the condition of the source, and it is entirely possible for a particular document to score worse after conditioning than before — most often when the tone reduction takes a light stroke with it.

The check is quick. Run your engine on the original and on the conditioned copy and compare the output. Because nothing here is random, the comparison is stable and the conclusion you draw holds for every document like that one.

Publication gate

This page ships once the workflow has been run against a low-resolution scan, a faded photocopy, a page with print showing through from the reverse, and a page mixing text with a photograph, with recognition accuracy measured against the untreated original in each case.

Examples

Small text in a low-resolution scan

scan.jpg - 1200x1600, body text about ten pixels tall
prathom-ocr-preprocessing.png - 1736x2312

The clearest win. Many engines have a minimum glyph height, and text below it fails entirely rather than partially, so meeting the threshold changes nothing into something.

Gray photocopy

copy.jpg - 2000x2800, faded print on gray paper
copy-ready.png - 1700x2380

Contrast separation plus tone reduction is what this case needs, since the ink and paper start only a few levels apart.

Frequently asked questions

Does this actually extract the text?

No. It produces a cleaned image and nothing else. Recognition is a separate step you run afterwards with whatever engine you already use. Treating them as separate is deliberate — the conditioning is deterministic and checkable, while recognition accuracy depends on the engine, the language, and the typeface.

How can enlarging help if it adds no information?

Because the limitation is not information, it is the engine's minimum size. Recognition models are trained at particular glyph scales and degrade sharply below them, so text at eight pixels tall can fail completely while the same text resampled to twenty is read correctly. Interpolation adds no detail; it presents the existing detail at a size the reader can work with.

Why reduce the image to only a few tone levels?

Because paper is not uniform and engines can treat its texture, speckle, and print bleed as marks. Collapsing everything to a handful of levels forces each pixel to commit to ink or paper and removes the middle ground the noise lives in. It is destructive on purpose.

When should I not use this?

When the page is not mostly text. The tone reduction wrecks photographs, charts with subtle shading, and anything where a gradient carries meaning. It is built for documents you intend to read as characters, and it will happily ruin the illustration next to them.

Is the AI OCR Preprocessing tool free, and do I need an account?

It is free and there is nothing to register for. No account is created, no address is collected, and no reduced-quality preview is withheld for a plan that does not exist. The constraints that do apply come from the workflow itself rather than from billing: 25 MB in, a shared GPU queue, and a thirty-minute window to collect the output.