OCR vs OCV: character inspection for date and lot codes

A date-code station has one job: confirm the printer marked the right thing, legibly. OCR and OCV answer two different questions on the way there — OCR tells you what the characters say, OCV tells you whether they match the string you expected. Choosing badly costs money in both directions: OCR on a fixed mark adds a misread risk for data you already own, and OCV on a string you needed to capture hands you a pass signal with no data in it. This comparison gives the decision rule for date and lot codes, the pixel counts each method needs, a worked lens, depth-of-field and exposure example from a pouch line, and the camera class that fits each role.

What is the difference between OCR and OCV?

OCR reads characters it has not been told and returns the string with a confidence score; OCV compares the mark against one expected string and returns pass or fail. OCR decodes, OCV confirms — and every other difference between them follows from that split.

An OCR engine segments each glyph out of the image, classifies it against a trained font or character library, and outputs the string with a per-character score. It is the only tool that can read a value which exists nowhere else in the plant. OCV trains on known-good samples of the expected characters — or on the whole string as a single pattern — and scores the live mark against them inside a tolerance you set. It never names a character, so it cannot confuse 0 with O or 1 with I, but it also cannot tell you what it actually saw.

Which one does a date code station need?

Use OCV when the string is known before the part arrives — expiry dates, lot codes and fixed serial formats fed from the PLC or MES. Use OCR when every part carries different data you must record: serialized parts, third-party printer output, weights stamped at the filler.

The decision driver is where the truth lives. If the printer controller already knows the string, verify the mark against that source and log the string from the source; reading what you already know only adds a failure mode. If the mark is the only record — each part unique — you need OCR, and the string has to flow somewhere that survives the shift. Wiring reads, rejects and the database together is its own job; inline traceability validation: connect codes, OCR and rejects covers it end to end.

How many pixels does a character need for OCR or OCV?

Design OCR to 20 pixels of character height with a 3-pixel stroke, and OCV to 10 pixels with a 2-pixel stroke; treat 15 and 8 pixels as the floors where results start to wobble. Both floors exist for the same reason: tool decisions are made on stroke pixels, and a classifier reads more out of a stroke than a matcher does. Vendor sizing guides land in the same range — selecting a valid character image size for an OCR reader walks the method with numbers.

The rules convert straight into coverage. A 1.6 MP-class sensor with 1440 pixels across, watching 2 mm inkjet characters, tops out at a 144 mm print zone for OCR (1440 × 2 / 20) and 288 mm for OCV (1440 × 2 / 10). The same camera covers half the web when it has to read instead of match — that ratio, two to one, is the pixel cost of OCR.

Run your own character height and sensor through the calculator above: it returns the pixels landing on the mark, and the finder behind it lists cameras that deliver them.

What lens and working distance does that give?

At a 44 mm field of view on a sensor about 5.0 mm wide, magnification is 0.11, so a 12 mm lens focuses at about 120 mm working distance — compact-reader territory. The arithmetic, with inputs you can lift from your own line:

• Mark: an inkjet date, characters 2.0 mm tall, strokes 0.4 mm, print window 44 mm wide.
• Camera: 1.6 MP class, 1440 pixels across, 3.45 µm pixels — 1440 × 0.00345 mm = 4.97 mm, so call the sensor 5.0 mm wide.
• Line: 500 mm/s, with pouch height wandering ±3 mm.

Scale comes first: 1440 / 44 = 32.7 px/mm, so characters land 2.0 × 32.7 ≈ 65 px tall with 0.4 × 32.7 ≈ 13 px strokes — three times the OCR minimum before any print defect eats into it. Magnification is m = 5.0 / 44 = 0.11, and a 12 mm lens focuses at WD = 12 × 1.11 / 0.11 ≈ 121 mm; mount it at 120 mm.

Depth of field is the f-number decision. Accept 2 px of defocus — 0.061 mm on the object and 0.0067 mm on the sensor (0.061 × 0.11). Then DOF ≈ 2 × 8 × 0.0067 × 91.7 ≈ 9.8 mm at f/8, and f/4 halves that to 4.9 mm. The ±3 mm wander needs 6 mm of depth, so f/8 passes with margin and f/4 clips the edges of the run.

Here c is the acceptable blur on the sensor — two pixels is a working value. The depth-of-field line is an estimate: blur crosses your tolerance gradually, so treat the result as a limit with margin, not a wall.

If you choose OCV instead, the same camera stretches further: at a 288 mm field of view, m = 5.0 / 288 = 0.0174 and the same 12 mm lens focuses at WD = 12 × 1.0174 / 0.0174 ≈ 700 mm. One sensor then watches the whole print zone from a safe distance — the OCV dividend, bought with pixels you did not need.

How much exposure does a moving date code need?

At 32.7 px/mm on a belt running 500 mm/s, a 100 µs strobe pulse smears the mark by 1.6 px — noise against a 13 px stroke — while a 1 ms free-run exposure smears it by 16 px and starves both tools. Freeze the part with light, not with luck: 500 mm/s × 0.0001 s = 0.05 mm of travel, and 0.05 mm × 32.7 px/mm = 1.6 px of blur.

Trigger the strobe from the encoder or photocell rather than from software timing. The wiring choices are the same three as any fixed reader, and fixed barcode reader trigger modes: sensor, serial or free-run names them. Spec a global-shutter sensor on a moving web: a rolling shutter adds shear on top of blur, tilting characters that neither tool was trained on.

Which camera class fits OCV, and which fits OCR?

For a fixed date code, OCV is vision-sensor work: a 1 to 5 MP sensor with an integrated lens clears the pixel rules with margin. OCR that must capture variable strings — wide zones, small marks, dot peen — earns a 5 to 12 MP code reader or an area-scan camera.

For the OCV end, vision sensors pack sensor, lens, light and tools into one body. The MV-SCB007EC-12S-WBN is a 1.6 MP vision sensor behind a 12 mm lens with manual focus — the exact optics the worked example calls for.

When the string must leave the station, move up to fixed code readers. The LS-CRD-0028 reads at 2560 × 2048 pixels, 30 fps and 60 codes/s behind an 8 mm lens, and text on the same box is routine — OCR on a fixed code reader: multiple text strings in one image shows the set-up.

When the zone is wide or the marks are small, step up in pixels:

The MV-CH120-11UC is a 12 MP USB3 camera on the IMX304 sensor with a global shutter; the LS-SMC-0017 is an 8.8 MP smart camera with a global shutter and a C-mount, so the lens is yours to choose. Both live in area scan cameras country, or in a smart camera that keeps the PC off the line.

Where the string goes next matters as much as the sensor: smart camera OCR string output over TCP: how to send it covers pushing reads to a PLC. And if you are weighing writing your own OCR against buying, building custom OCR for bottle inspection against a bought reader walks that trade.

When is the usual choice wrong?

OCV is the wrong tool when the reference string can be wrong, when the data must be captured, or when the mark has to scan downstream; OCR is the wrong tool on fixed strings, decorative fonts and broken strokes. Each failure has a signature, and most fixes are not "switch tools".

OCV compares against what it is fed. A stale PLC clock or yesterday's recipe produces a confident pass on a wrong date — fix the reference feed, not the camera. And an OCV pass says nothing about a warehouse scanner reading the mark later: if the code has to scan downstream, add print-quality grading to the station, as date code print quality inspection: verify the string, grade the print does. Barcodes carry ISO/IEC 15416 and 15415 print grades for exactly this reason; human-readable text has no equivalent ISO grade, so your pixel rules are the spec.

OCR on a fixed string buys risk and nothing else. When OCR is the right call, trust still has to be earned — barcode read confidence: how to judge whether a decode is trustworthy gives the confidence numbers that separate a read from a guess. Decorative and outline fonts break OCR training before anything else does; OCR font selection: pick typefaces machines read reliably is the short list of what to print. When characters vanish from results, the filter chain is usually the thief: OCR missing characters: diagnose text filtering errors.

Dot-peened and laser-etched marks defeat OCR segmentation because their strokes are dot chains, not lines. Train OCV on the real mark and drive the part past on an encoder; dynamic character verification for dot peen marking shows the moving-part version.

What should you check before ordering?

Run this list before you order anything: it settles method, pixels, optics, motion and data flow in one pass, and every line ends in a number or a named owner. That is what keeps a station from reading what it already knew, or verifying what it never captured.

• Method: for OCV, the expected-string source — who writes it, and what updates it at job change and midnight rollover. For OCR, where the string lands and how no-reads route.
• Pixels: smallest character height on the part, times the rule (20 px for OCR, 10 px for OCV), checked against scale from the resolution calculator.
• Optics: m, working distance and depth of field from the formulas; mounting space at the distance they give; f-number chosen from the depth you need, not from habit.
• Motion: belt speed in mm/s, exposure sized for no more than 2 px of blur, strobe duty ceiling set on the controller, global shutter on the sensor.
• Surface: shiny film, curved pouches and embossed cartons change the light before they change the camera — the lessons in reading QR codes on reflective and curved surfaces carry over to text.
• Handshake: trigger source and the result path to the PLC, agreed before the first image is taken.

Once the method is settled, size the station:

For marks that sit outside these rules — curved, transparent, or moving faster than the strobe can freeze — the contact page puts the question in front of an applications engineer.