OCR (Optical Character Recognition)

Optical character recognition (OCR) is the technology that turns text visible inside an image into machine-readable text. It reads pixels that happen to look like letters - on a scanned invoice, a product label, a slide exported as a picture, a photographed sign - and outputs the words themselves, so software can index, search, copy, and analyse them.

Without OCR, an image is an opaque block of pixels to a search index. With it, every word printed inside that image behaves like any other piece of metadata.

How OCR works

Modern OCR runs as a short pipeline, and each stage explains one of its failure modes:

Pre-processing. The image is deskewed, de-noised, and converted to high contrast. This is why a crooked phone photo of a page reads worse than a flat scan.
Text detection. The engine locates the regions of the image that contain text, and works out reading order: columns, captions, table cells.
Character and word recognition. Each detected region is decoded into characters. Contemporary engines use neural networks that recognise whole words and lines rather than isolated glyphs, which is why they handle joined and irregular type far better than the template-matching systems of the 1990s.
Language modelling. A statistical model corrects unlikely results in context, so rn is not mistaken for m in a word the language never produces.

The output is plain text, usually with a per-word confidence score and the coordinates of each word inside the image.

Optical text recognition, ICR, and handwriting

"Optical text recognition" is used interchangeably with OCR. Two related terms are narrower: ICR (intelligent character recognition) targets handwriting, and OMR (optical mark recognition) reads checkboxes and filled bubbles rather than characters. Printed type remains the case OCR handles most reliably; cursive handwriting is still the hardest.

What OCR is for in a DAM

A large share of any media library carries its most identifying information as pixels rather than as fields:

The product name and variant on a packshot label.
The headline and offer on a scanned print advertisement.
The SKU on a datasheet that was archived as an image.
The claim, the legal line, or the expiry date on packaging artwork.
Slide text in a deck exported to PNG, and any rendition generated from it.

None of that is findable by conventional search, because as far as the index is concerned the file contains no words. OCR extracts the text at ingestion and attaches it to the asset, so searching for a product name returns the packaging photo and not just the files somebody remembered to tag.

It also feeds everything downstream. Extracted text becomes input for semantic search, gives automation rules something to match on, and supports compliance work: an audit trail is far more useful when you can prove which version of a claim appeared on which artwork. For archives it is transformative - decades of scanned print material become searchable without anyone retyping a word.

How accurate is OCR?

Accuracy follows the source, not the engine. On clean, high-resolution scans of printed text, current engines routinely exceed 99% character accuracy. On low-resolution images, heavy compression, stylised display type, text over busy photography, or tight coloured backgrounds, results degrade to partial extraction.

The practical consequence is that OCR text should be treated as a searchable layer, not a canonical transcription. It is excellent for finding an asset. It is not a substitute for the approved copy of a legal line.

Running an OCR check on your library

An OCR check is a review pass over what was extracted, and it is worth doing once after a bulk import:

Search for a handful of terms you know appear only inside images, and confirm the right assets come back.
Spot-check the extracted text on your hardest formats: dense packaging, low-resolution legacy scans, screenshots of interfaces.
Look at coverage rather than individual pages. If a whole class of assets returns nothing, the problem is usually source resolution or an unsupported file type, not the engine.
Re-run extraction after you replace low-resolution originals with better ones.

OCR in freedam

In freedam, OCR runs automatically during ingestion. No configuration, no per-file action, no separate queue to babysit. The extracted text is indexed alongside the asset's other metadata, so it is matched by ordinary keyword search, by advanced filters, and by semantic search, and it is available to automation rules and to the API.

Because it is part of ingestion rather than an add-on, every asset that enters the library - by upload, by folder sync, or through the API - is covered the same way.