OCR multi-capture majority voting: stable character reads

A date or lot code that reads nine times out of ten poisons the line: operators start typing codes by hand, and the one miss in ten is the pallet that gets held. This guide is for the engineer wiring OCR on a smart camera or a vision controller who needs reads that hold up shift after shift. The fix is rarely a better threshold — it is a better decision rule. Capture the same code three to five times per part, read each frame on its own, and publish a string only when a majority of frames agree at every character position. You will get the accuracy math, the cycle-time cost, the wiring steps, the verification test and the cases where voting hides a problem you should fix in the optics instead.

How many captures does a stable OCR read need?

Capture three frames and accept a character when at least two of the three agree: that lifts a 90% single-frame read to 97.2% and a 95% read to 99.3%, while five frames push a 90% read to 99.1%.

The gain is binomial probability, so you can compute your own number before wiring anything. Let p be the chance that one frame reads the code correctly, with errors independent from frame to frame. A vote of three is correct when all three frames read correctly or exactly two do; a vote of five needs at least three of five.

Three frames is the default. Once a single frame clears 95%, the vote of three already delivers 99.3%, and a 97% frame needs only three votes to reach 99.7%. Step up to five when p sits near 0.90 and one escaped misread costs more than the roughly 100 ms the two extra frames add on a 30 fps line. The whole table rests on one assumption: frame-to-frame errors must be independent. Two frames that share the same glare are one opinion said twice, and the later section on what breaks the vote shows how to keep them apart.

What does the vote compare: whole strings or single characters?

Vote per character position and reject on any position without a majority: with three frames a position needs two matching characters, and a single three-way split anywhere rejects the whole string rather than guessing.

String-level voting wastes part of what you paid for. When frames return 508A3, B08A3 and 508A3, a string vote sees 508A3 twice and outputs it, which is fine. But when frames return 508A3, B08A3 and 50QA3, no string appears twice, so a string vote rejects a part the character vote reads cleanly: position 1 takes 5 on two votes, position 2 takes 0 on three, and the other three positions are unanimous.

Any position that ends without a majority rejects the whole read. Frames 508A3, B08A9 and 5Q8A7 leave position 5 holding 3, 9 and 7 — a three-way split — so the output is NOK, never frame A's guess. Reject any frame whose character count breaks the format before the vote runs: positions must line up or the vote compares the wrong glyphs. If the symbology carries a check character, validate the voted string against it as a second, free layer of protection.

With five frames require three matching votes, and treat a 2-2-1 split as undecided: reject the read or fire a sixth frame. Never let one high-confidence frame override a majority — that reintroduces the flakiness the vote exists to remove.

How much cycle time do the extra captures cost?

At 30 frames per second, three captures cost about 100 ms of acquisition plus your per-frame processing three times: a 20 ms read becomes roughly 160 ms total, against 53 ms for one shot.

One frame at 30 fps takes 1 ÷ 30 s ≈ 33 ms, so three frames cost 3 × 33 ≈ 100 ms of acquisition. At 20 ms per read, processing adds 3 × 20 = 60 ms, for about 160 ms against 53 ms for a single shot. Five frames come to 167 ms plus 100 ms, about 267 ms. At 60 fps the three-frame vote drops to roughly 50 ms of acquisition plus 60 ms of processing, about 110 ms.

A short strobed exposure keeps the effective rate at the camera's rating; a long free-run exposure does not, because each frame waits out its own exposure time. Processing overlaps transfer too, so these totals are the pessimistic case — the acquisition-versus-processing gap has the pipeline arithmetic. If the vision window is under 150 ms, run a 60 fps camera, or accept on two-frame agreement and fire the third frame only when the first two disagree.

What do you need in place before you add the vote?

You need five things: a trigger that fires three to five captures per part, per-frame results kept as character positions with scores, a majority rule of two-of-three or three-of-five, a reject path for any position that never reaches it, and a disagreement log that trends over time.

• A known format. Expected character count and allowed characters, so a length mismatch rejects before voting starts.
• Varied imaging between frames. Alternate the light channel or the exposure per capture, or the frames repeat one opinion — the later section on what breaks the vote shows why that costs accuracy and buys nothing.
• Per-position results. The reader step must expose every character with its score, not only the final string; most vision platforms' character-read steps do, and a character-comparison step plus a small script does the counting.
• A reject path. One NOK output and one logged image set whenever a position ends without a majority.
• A disagreement trend. Log how often the vote changed the first frame's answer; it is the early-warning metric for fading light or focus.

A single-code station can run the whole loop on the camera itself: capture, read, vote, publish one string to the PLC. The MV-SC5060XM-08M-WBN is a 6 MP mono SC5000X-series smart camera with an 8 mm M12-mount lens, a 1/2.4" sensor, a rolling shutter and a GigE interface.

Six megapixels holds small etched characters well above the 20-pixel height rule at date-code scales, and the inspection runs on the camera without a PC.

How do you wire the vote in, step by step?

Store each frame's result as one candidate per character position, count those candidates across the three to five frames, and publish the string only when every position has a majority; any undecided position rejects the read.

1. Fix the format. Set the expected character count and allowed characters. Any frame whose count differs is rejected outright, before voting starts.
2. Trigger the captures. Fire three frames per part, five when the accuracy table calls for it. If your platform grabs a set from one trigger, the multi-image capture per trigger pattern covers the timing; vary the light channel or the exposure between frames.
3. Read each frame alone. Keep one character-plus-score pair per position. Never feed frame 2 the corrected output of frame 1.
4. Count and decide. At each position, take the candidate with the most votes: 2 of 3, or 3 of 5.
5. Reject on splits. A three-way split at any position sinks the whole string, and so does a 2-2-1 split across five frames.
6. Keep the region tight, then validate. Identical read regions and segmentation across frames, then a format and check-character pass on the voted string — the same ROI discipline as seven-segment display OCR.
7. Publish two values. The voted string, plus a vote-quality figure — how many positions were unanimous — with the dissenting frames logged as images.

On a smart camera the counting lives in the platform's logic or script tool next to a character-comparison step; on a PC-based line it is a dozen lines around your existing read call. Either way the loop touches only the per-position results, so the reader itself stays untouched.

How do you verify the vote actually raised the accuracy?

Run 50 to 100 parts with known ground truth through the full vote and score three numbers: correct accepts, wrong accepts and rejects; a working vote drives wrong accepts near zero and holds disagreement-driven rejects under about 5%.

Build the set from production parts, including ones that fail each known way: the glare angle, the faint etch, the smudged inkjet. Correct accepts should land near the accuracy table's prediction, wrong accepts at zero or one, and rejects explained by split positions you can see in the log. Then force a failure on the bench — tilt a part until one position splits three ways — and confirm the PLC receives NOK, not frame 1's string.

Production adds one more metric: how often the vote changed the first frame's answer. Under 1-2% means imaging was already healthy and the vote is insurance; over 5-10% means the optics are marginal and need light or focus work, because a vote that decides constantly can eventually decide wrong. On a packaging line, fold that vote-quality figure into the per-unit record next to the other checks — the inline packaging inspection guide shows the tracking pattern.

What breaks the vote and turns the extra frames into dead weight?

Identical frames break it: if three captures differ by nothing but noise the vote inherits one answer three times, so vary the light, the exposure or the part's position between frames or the extra captures add cycle time and zero accuracy.

Four patterns produce those identical opinions:

• Same light, same part, same angle. The glare that turns a 5 into a B in frame 1 turns it in frames 2 and 3 as well, and the wrong character wins unanimously. Alternate light channels or nudge the strobe angle between frames.
• Auto-exposure hunting. A camera that re-exposes every frame produces three images that differ in brightness, not in information. Lock the exposure and vary it deliberately — alternating two exposures per trigger does this without a serial link.
• Blur in every frame. A part still moving at capture, or focus that drifted across the shift, puts the same smear in all frames. Vote on sharp frames or fix the trigger delay.
• A sliding read region. If segmentation moves between frames, position 4 in frame 2 is a different glyph than position 4 in frame 1, and the vote compares nonsense.

The symptom shows in the log: frames that agree 100% of the time are one picture taken three times. If disagreements never appear, the vote is costing cycle time and buying nothing.

When is majority voting the wrong fix?

Skip the vote when frames fail for the same reason every time: characters under about 20 pixels tall, a misread that repeats identically in every frame, or a code that should be verified rather than read — fix the optics or switch methods instead.

Start with pixels. The workable floor for reliable OCR is roughly 20 pixels of character height, and 30 or more for dot-matrix or low-contrast etch; below that, characters lose the strokes that tell them apart and every frame fails the same way. The arithmetic is short: a 1.6 mm character needs 20 ÷ 1.6 = 12.5 pixels per millimetre, and over a 20 mm wide field of view that is 20 × 12.5 = 250 pixels of sensor width — a floor essentially every camera in production clears. When an image looks soft, the enemy is blur and contrast, which no vote can touch.

A misread that repeats identically in every frame votes itself in unanimously, so check the disagreement log before scaling up the frame count: a character that is wrong the same way at zero disagreements needs a moved light, not more frames.

Switch methods when the question changes. If you need to know whether the print is good rather than what it says, that is verification, not reading — the OCR versus OCV comparison sets out the split. If the text is a fixed constant, compare the image region against the expected template instead of voting on free reads.

Which set-up should you order?

Match the hardware to the station: a 6 MP smart camera votes on device for a single code, a controller with built-in light channels drives multi-camera or alternating-light cells, and a compact vision sensor covers one tight code at close range.

Multi-camera cells, and any rig that alternates light channels per capture, want a controller. The MV-VC2140-128G40-1T carries 4 built-in light-output channels, 3-4 LAN ports, 2 USB 3 ports and an N97 processor with 8 GB of memory, a 128 GB SSD and a 1 TB HDD.

Two of its light channels alternating between frames give the vote exactly the variation it needs, and the spare LAN ports take the rest of the cell's cameras.

A single tight code at a fixed close range runs on a compact vision sensor. The MV-SCB007EC-12S-WBN pairs a 1.6 MP color sensor (1/2.9" format, global shutter) with a 12 mm manual-focus M12-mount lens over Fast Ethernet.

Browse the smart cameras category or the camera finder for a one-camera station, and the vision controllers category when the cell grows; the system configurator walks the whole chain from camera to mount. More line-side examples sit on the applications topic page, and if you would rather talk the code layout through first, contact us — or request a quote for volume pricing, with free expert support included on every order.