Application

OCR / OCV & Code Verification

Reading a code is not verifying it. The distinction is the whole point of this application class.

Author: VisionAxiom Applications EngineeringReviewed by: VisionAxiom Technical ReviewUpdated: 2026-09-02
Food packaging line with an inkjet date-code inspection monitor over trays on a conveyor
Inkjet date-code inspection on a food packaging line

Direct answer

What is the difference between OCR and OCV?

OCR (optical character recognition) converts printed characters in an image into a text string without knowing what the text should be. OCV (optical character verification) compares what is printed against an expected string supplied by the recipe, work order or MES, and fails the part on mismatch, missing characters or degraded print quality. Code verification extends the same logic to 1D/2D symbols, adding print-quality grading against a published standard.

Four operations, often confused

Regulated packaging usually needs OCV plus code verification, because a decodable-but-marginal symbol will fail somewhere downstream in the supply chain even if your reader accepts it.

OCR
Recognize characters; output a string. No expectation supplied.
OCV
Compare printed characters to the expected string; fail on mismatch or degradation.
Code reading
Decode a 1D/2D symbol; success means decodable, not well printed.
Code verification
Grade symbol quality against ISO/IEC 15416 / 15415 style criteria under controlled optics.

Where the expected value comes from

An OCV station is only as strong as its source of truth. If the operator types the date into the vision HMI, you have verified the operator's typing. Pulling the expected string from the work order, MES or the coder's own job data closes that loop.

  • Preferred: expected string delivered from MES/ERP per work order.
  • Acceptable: string pushed from the coder controller and cross-checked by vision.
  • Weak: manual entry at the vision HMI with no second source.
  • Always: log the expected value, the read value, the verdict and the image reference.
Code-verification system output showing printed and verified date codes with pass region highlighted
Date-code verification output — printed string checked against the expected value

Imaging requirements for characters

  • Resolve enough pixels across the narrowest stroke — a common working target is several pixels per stroke, not per character.
  • Contrast, not resolution, is the usual failure: inkjet on kraft, laser on metallized film and thermal transfer on gloss each need a different lighting geometry.
  • Dot-matrix inkjet characters need enough resolution to separate dots without merging them into blobs.
  • For deforming substrates, constrain the region of interest or add a locator feature so the string is found before it is read.
Grayscale inspection capture of a carton with red and green region-of-interest boxes around printed codes
Inspection capture — ROI boxes over print and 2D code regions

Frequently asked questions

Does OCV need AI?
Usually not. Trained font libraries with verification against an expected string are deterministic, auditable and easier to validate. Learned models help mainly with severely degraded or highly variable printing.
Can one station read a date code and grade a 2D code?
Sometimes, but the optics and lighting requirements differ. Verification-grade symbol grading has specified illumination geometry, which may conflict with the best geometry for character contrast. Two stations are often cheaper than one compromised station.

Next step

Discuss your inspection problem with an engineer.

Send samples, line speed and the defect you cannot let through. We respond with an imaging assessment, not a brochure.