How Cameras and Barcode Readers Verify Product Identity

Every serialized pack on a line gets a different code. How does the line know that the code on box 4,812 is the one it was supposed to print, and not the one meant for box 4,811 — or nothing at all? The answer is a camera, a comparison and a reject device working together, hundreds of times a minute.

This guide explains how inline read-back works, why the comparison matters more than the read, and how offline verifiers fit alongside.

Reading is easy; comparing is the point

Decoding a 2D code is something any smartphone can do. On a packaging line, a read on its own is not very useful. The real question is: is this the code we expected on this specific pack?

That turns the camera into a checker, not just a reader. Line software keeps a record of which serial it sent to the coder for each pack. When the pack reaches the camera, the software compares what was read with that record.

An analogy: a cloakroom attendant who hands out numbered tickets. Being able to read a ticket is trivial. The skill is checking that ticket 214 is being handed back for coat 214.

The three outcomes

Every pack that passes the camera produces one of three results.

A mismatch deserves special attention. One mismatch may be a stray pack. Several in a row usually mean the sequence has slipped — for example, a pack was removed by hand between the coder and the camera, so every subsequent comparison is off by one. Good line software detects that pattern and stops, rather than rejecting a whole run of good packs.

Tracking the pack along the conveyor

To compare, the software must know which pack is in front of the camera. On most lines it does this by tracking position, not by guessing.

• A sensor detects each pack at the coder and the software records "pack N, serial S".
• An encoder on the conveyor reports how far the belt has moved, so the software knows when pack N should reach the camera, and later the reject device.
• When the camera fires for pack N, the result is attached to serial S.

This is sometimes called a shift register or tracking queue — a conveyor-length memory of which pack is where. It is also why manual intervention between stations is risky: lifting a pack off the belt breaks the link between position and identity unless the system is told.

Rejecting — and confirming the reject

When the result is a mismatch or no-read, the software tells a reject device — an air jet, pusher or diverter — to remove that pack when it arrives. The timing must be accurate: firing a fraction too early or late removes the wrong pack.

A reject command is not a reject. Air pressure can drop, a pusher can jam, a pack can bounce back. A careful line adds reject confirmation: a sensor in the reject chute, or a check point after the reject device, that proves the pack actually left. If confirmation does not arrive, the line should stop, because an unverified pack may now be heading for a carton.

The point generalises: a camera decode, a reject command and a confirmed removal are different facts from different devices. We cover the wider set of these distinctions in why "printed" is not the same as "verified".

What makes inline reading reliable

Getting dependable reads at line speed is mainly about the physical setup.

• Lighting. Controlled, consistent light, often shielded from ambient light, chosen for the surface — matte cartons and glossy film behave very differently.
• Position. The code must land in the camera's field of view every time. Variations in pack position or code placement cause no-reads that look like print faults.
• Focus and resolution. The camera must resolve each module of the 2D code at the distance and speed involved.
• Processing time. The decode and comparison must finish before the pack reaches the reject point.

When a line has a high no-read rate, the cause is often one of these rather than the coder.

Where offline verifiers fit

An inline camera answers "is the expected code readable here, on this pack?". It does not answer "is this code printed well enough to read on scanners elsewhere?" That is the job of a barcode verifier — an instrument that grades a printed symbol against ISO/IEC 15415 for 2D codes or ISO/IEC 15416 for linear barcodes.

Verifiers are usually used offline: a quality technician takes sample packs at the start of a run, after a changeover and at intervals during production. For general retail barcodes, GS1 specifies a minimum grade of 1.5 (C). Some inline vision systems can also report quality indicators, but an inline identity check should not be described as a formal grade unless the setup actually conforms to the grading method.

So the practical division is: inline camera on every pack for identity, offline verifier on samples for quality. Together they give you both answers.

Why camera evidence drives what happens next

On a serialized line, the camera result decides the pack's future. Only packs with a confirmed match should be eligible for packing into a carton. That rule protects aggregation — the record of which serials sit in which carton and pallet — from including unreadable or unexpected codes. See what aggregation is in product traceability.

It also protects the serial records themselves. A serial marked "verified" should mean a camera matched it on a real pack, and a rejected serial should never be issued again. These rules are part of what keeps serialization exactly-once: what exactly-once serialization means in plain English.

Example: the camera on Line 3

On Maison Ardent's fictional Line 3, a fixed reader sits a short distance after the coder, under a shielded light, aimed at the base of each perfume box. At 120 boxes a minute, it has well under half a second per box.

For simplicity, call the serial the software sent for the first box "S1", the next "S2", and so on. The reader returns S1 for the first box — match, the box moves on. For the second box it returns nothing — the air jet fires and a chute sensor confirms the box left. For the third box the software expects S3 but reads S5 — a mismatch. The next two boxes are also two ahead of expectation, and the software stops the line: someone had lifted two boxes off the belt to inspect them. The supervisor reconciles the removed boxes before restarting.

That stop is the system working. The full sequence of stations around it is described in the journey of a serialized product through a packaging line.