Industrial OCR and OCV

OCR vs OCV: read versus verify

Although the acronyms differ by a single letter, OCR and OCV answer fundamentally different questions. Optical Character Recognition (OCR) reads characters from an image and returns the text as data — you do not necessarily know in advance what the string will be, so the system must decode each character. Optical Character Verification (OCV) instead checks a known, expected string: it confirms that the printed text is present, legible and correct, and raises a fault when it is not. OCR produces information; OCV produces a pass/fail conformity decision.

In practice many real applications combine the two. A line might OCR a variable batch code to log it for traceability, then OCV the fixed product name and dosage against the approved artwork. The distinction matters because it drives both the acceptance logic and the validation effort: an OCR result is judged on character-level accuracy, whereas an OCV result is judged on whether it correctly accepts good prints and rejects defective ones.

A useful mental model: OCR is open-ended recognition, OCV is constrained confirmation. If you already know what should be printed and your goal is to catch print defects, you almost always want OCV — it is more robust and easier to validate than asking a reader to decode text it could instead simply be checking.

Why OCV dominates regulated packaging

In pharmaceutical, medical-device and food packaging, the cost of a wrong, missing or unreadable code is measured in recalls and regulatory exposure, so the relevant task is verification against an approved reference. Lines routinely verify lot numbers, expiry dates, GTINs, dosage and warning text, and increasingly serialization data for track-and-trace. OCV is the natural fit because the expected content is defined by the master artwork and the order record, not discovered at runtime.

Because these environments are regulated, OCV systems must be repeatable and auditable. That favours deterministic, well-characterised imaging and decision thresholds, full logging of pass/fail results and the captured image, and a documented validation that demonstrates the system reliably rejects defects such as smeared, faint, double-printed or transposed text. The OCV step is often paired with a separate code reader for the 1D/2D codes themselves; see the related code-reader guidance for grading and Data Matrix verification.

The real challenge: stable, high-contrast imaging

The most common reason an OCR or OCV deployment underperforms is not the algorithm — it is the image. Text that a human reads effortlessly can be ambiguous to a vision system if contrast is low, the print is curved or specular, or motion blur smears the strokes. Get the imaging right and even modest software succeeds; get it wrong and no engine will save you. The four levers are sensor resolution, shutter type, lens and lighting.

Resolution must give the characters enough pixels to be distinguished. As a practical rule, target around 20-30 px character height and at least three to five pixels across the thinnest stroke; thin dot-matrix or laser marks need more. Work back from the smallest character and your field of view to the required megapixels, the same way you would size any inspection — the resolution and field-of-view guide covers the arithmetic. On moving lines a global-shutter camera is effectively mandatory: a rolling shutter skews and smears characters during exposure, destroying legibility.

Lighting determines contrast and repeatability more than any other single factor. Diffuse coaxial (on-axis) or dome lighting is the standard choice for printed and marked text on flat or curved surfaces because it floods the scene evenly and suppresses glare and shadows that otherwise create false rejects. Embossed or engraved characters often need low-angle (grazing) light to throw the relief into shadow. Pair this with a suitable lens — a quality C-mount lens for general work, or a telecentric lens where perspective distortion across the field must be eliminated. DCM Sistemes supplies the coaxial and dome geometries typically used for this work.

• Resolution: ~20-30 px character height, 3-5 px per stroke; size from smallest character and FOV.
• Shutter: global shutter to freeze line motion and avoid character skew/smear.
• Lens: C-mount for general use; telecentric to remove perspective distortion on text spread across the field.
• Lighting: diffuse coaxial or dome for printed/curved text; low-angle for embossed or laser-engraved marks.
• Exposure: enough light (or strobe) to keep exposure short and freeze motion at line speed.

Classic OCR vs deep-learning OCR

Classic OCR is built on template matching and hand-engineered feature extraction. With a fixed, trained font on a clean, high-contrast background it is fast, deterministic and easy to validate — ideal for crisp inkjet or thermal-transfer print on label stock. Its weakness is brittleness: as soon as characters deform, contrast drops, fonts vary, or the background becomes textured (foil, blister, curved tube, varying laser energy), match scores collapse and you trade false rejects against missed defects.

Deep-learning OCR is trained on examples rather than templates, so it tolerates the variability that defeats classic methods — dot-matrix and laser-marked codes, embossing, low contrast, partial occlusion, reflective or curved surfaces, and mixed or stylised fonts. The trade-off is that it needs representative training images (including realistic defects), more compute, and a validation approach suited to a learned model. The group's Rosepetal deep-learning inspection software targets exactly these hard-to-read cases.

Choose deterministically where you can and learn where you must. If the print is clean and the font fixed, classic OCR/OCV is simpler to deploy and defend. If you are fighting deformed, faint or variable text — or your false-reject rate from a classic tool is unacceptable — deep learning is the right tool. Where the application also needs full line integration (camera, lighting, conveyor handshakes, reject and logging), AIS Vision can specify and build the complete system rather than leaving you to integrate the pieces.

Putting it together: a selection checklist

Before specifying hardware, define the task precisely. Decide whether you are reading unknown text (OCR), verifying known text (OCV), or both, and which fields each applies to. Capture the worst-case print quality you must still accept and the defects you must reject — that pair sets your contrast and resolution budget far better than a nominal sample does.

• State the goal: OCR (read), OCV (verify), or a combination per field.
• List substrates and print types: label, foil, blister, glass, plastic, metal; inkjet, thermal, laser, embossed.
• Fix the smallest character size and field of view, then derive megapixels and choose a global-shutter camera.
• Select lens (C-mount vs telecentric) and lighting geometry (coaxial/dome vs low-angle) for stable contrast.
• Decide classic vs deep-learning OCR based on print variability and acceptable false-reject rate.
• For regulated lines, specify logging, image archiving and a validation plan up front.
• If line integration is in scope, plan triggering, rejects and traceability — or bring in an integrator.