Setting an ROI for inline code reading: speed and reliability gains

Most inline code readers ship with the decode search covering the whole frame. That setting is fine on the bench and expensive on the line: the reader burns its cycle scanning empty carton, and every second code, label edge and look-alike texture in the field of view is a candidate for a wrong decode. A region of interest (ROI) drawn around where the code actually lands fixes both problems at once. This guide gives the sizing rule — code size plus twice the placement tolerance, plus 10% — walks the optics and exposure arithmetic that keeps the window decodable, and lists the checks to run before you lock it in. It applies equally to fixed code readers, smart cameras and PC-based decode from area scan cameras.

What does a decode ROI buy you on the line?

Two things at once: decode time drops in proportion to the pixels you stop searching — about 33-fold in the worked example below — and wrong decodes disappear, because codes and look-alikes outside the window never become candidates.

A reader spends most of its cycle in the finder stage: scanning for bar-space edges on a 1D symbol, or the finder pattern of a 2D one, at several candidate scales. That stage's cost grows with area, so the gain from an ROI is simply the ratio of full-frame pixels to window pixels. What that search does before any decoding starts is covered in QR code finder pattern detection: locate before decoding.

The reliability gain matters just as much. With the whole frame searched, a second label on the carton, a code on the carton behind it, or a repeating print pattern can all be found — and sometimes decoded first. One window removes those candidates, the same isolation applied a level up in multiple QR codes not reading: isolate image and search failures.

The LS-CRD-0028 is a fixed reader rated at 60 codes/s, with a 2560 × 2048 sensor behind an 8 mm lens; an ROI does not raise that rating, it protects it as the field of view or code count grows. Three current platforms that take a decode ROI in their on-device tooling:

Values as printed in each product's data sheet; open a part for its drawing and full specifications.

On the MV-SC5060XM-08M-WBN — a 6 MP mono smart camera with an 8 mm focal length, M12-mount lens — the window is drawn in the on-device vision tool, so the search runs standalone with no PC.

Keep two ROIs apart while you configure. The decode ROI is software: a window inside the reader's tool. A sensor ROI (windowing) is a camera setting that reads out fewer pixels and shortens transfer. They stack — window the sensor to the part's travel band, then window the search to the code band.

How large should the ROI be around the code?

Make the ROI the code size plus twice the placement tolerance, plus 10% margin; until you have measured the tolerance, start at 2 to 3 times the code size and tighten after logging real frames.

A 10 mm square DataMatrix with ±6 mm tolerance needs 10 + 12 = 22 mm, plus 10% ≈ 24 mm on each side. If the code can arrive rotated, make the window square and large enough to cover the code's rotated diagonal — that arithmetic is in the FAQ below. If the fixture fixes orientation, a rectangle matched to the code's aspect searches fewer pixels.

A window that is too tight announces itself as intermittent no-reads that clear when you widen it — the diagnostic path in Aztec barcode not reading: diagnose empty decodes. A window that is too loose is quieter and worse: reads stay fast enough, and a wrong decode appears only when a decoy enters the frame.

How do you measure placement tolerance to size the ROI?

Log 100 to 200 frames at production speed, record the code's centre position in each, and set the tolerance to half the observed min-to-max span plus 20%.

Pull the centre coordinates from the reader's own locate output, or decode archived frames offline and log where each code sits. Measure both axes, and include every source of spread: label placement on the part, part seating in the fixture, guide-rail slop, and trigger timing. A measured min-to-max span of 10 mm gives a tolerance of 10 / 2 + 20% = 6 mm, so the ROI becomes 10 mm code + 2 × 6 mm + 10% ≈ 24 mm.

A hardware trigger — photo-eye or proximity — narrows the budget to timing jitter, typically ±2 to 3 mm, because the part is imaged at a repeatable point in its travel. A free-running reader that grabs every frame needs the full measured span.

Re-measure after any mechanical change, a new fixture, or a new label supplier. Those are the three events that most often quietly double the spread — and double the misses.

How much faster is decoding with an ROI?

The finder stage scales with the pixels searched, so a 400 × 400 window inside a 2560 × 2048 frame searches 33 times fewer pixels; total cycle time falls less, because the decode itself is unchanged.

The arithmetic: 2560 × 2048 = 5,242,880 pixels. A 400 × 400 window is 160,000 pixels. 5,242,880 ÷ 160,000 = 32.8, so call it 33-fold less search work.

Two limits keep the gain honest. The pattern decode runs the same on the crop as on the full frame, and camera readout is untouched unless you also window the sensor. On a reader that decodes on-device, the finder stage takes the larger share of the cycle, so expect total read time to drop several-fold — measure before and after on your station and keep the number.

If you must re-decode or audit later, archive the full frame and apply the ROI as a crop at decode time, the practice set out in barcode image buffer decoding: preserve pixels for reliable reads.

How do you size the optics so the ROI has enough pixels per module?

Hold at least 3 pixels per module inside the ROI — 4 is comfortable — which sets the object-side pixel size at one third of the module width or finer.

Worked example, arithmetic shown:

• Part: DataMatrix, 10 × 10 mm, module width 0.25 mm, tolerance ±6 mm.
• Camera: 5 MP, 2560 × 2048, 1/1.7-inch sensor, about 7.4 mm wide.
• Field of view: 150 mm across the belt.
• Magnification m = 7.4 / 150 = 0.049.
• Object-side pixel = 150 / 2560 = 0.059 mm.
• Pixels per module = 0.25 / 0.059 = 4.2 — above the 3-pixel floor with margin.
• Lens at 250 mm working distance: f = 250 × 0.049 / (1 + 0.049) = 11.7 mm → a 12 mm lens.
• ROI: 24 mm / 0.059 = 407 px → set 400 × 400.

Depth of field decides whether the code stays this sharp through height variation. With the circle of confusion at 2 pixels (2 × 0.0029 mm = 0.0058 mm) and the lens stopped to f/4:

That is ±10 mm of height tolerance around nominal focus — match it against the fixture's worst case before committing the working distance. The formula is the standard thin-lens approximation; treat ±10 mm as a planning number and confirm it on the bench.

On a tighter pixel budget the same 3-pixel rule shrinks the field of view instead: a 1.3 MP sensor — about 1280 pixels across — at 0.083 mm/px, the limit for 0.25 mm modules, covers about a 106 mm field of view. Reader options in that class include the MV-ID3013PM-12M-WBN, a 1.3 MP compact code reader with a 12 mm focal length and a global shutter.

How short must the exposure be for a moving code?

Keep blur under one pixel: exposure ≤ object-side pixel ÷ surface speed, so 0.059 mm ÷ 500 mm/s = 118 µs — run 100 µs, or strobe a pulse of that width.

An ROI cannot fix motion blur; it only changes what gets searched. At 500 mm/s the code crosses one 0.25 mm module in half a millisecond, so a 1 ms exposure smears two modules into one grey band. Freeze it at the source, with the timing trade-offs covered in exposure time vs shutter speed for moving-part inspection and the pulse-width arithmetic in high speed barcode verification: size the strobe pulse.

Short exposure starves light. Raise illumination rather than gain — gain amplifies noise, and noise eats decode margin on small modules first. Strobed illuminators driven at these pulse widths are bright: respect the manufacturer's stated eye-safety distance and shield the line of sight where operators stand.

How do you keep the ROI robust when part position varies?

Re-teach from logged production frames after every mechanical change, and once the code's spread grows past half the ROI, replace the fixed window with a coarse full-frame locate followed by a small read ROI.

That two-stage pattern — find roughly, then read precisely — is how stations with wide position spread stay fast; the locate tools are the subject of how to find wafer 2D code locations before inspection. Size the read window by the same rule, with the tolerance now being locate error rather than part wander — usually a few pixels.

Give auto exposure its own patch. Pointing it at a finder-driven rectangle invites gain oscillation, the failure dissected in auto exposure ROI instability from detection feedback. A fixed patch of representative brightness, taught once, holds exposure steady while the decode window moves.

For multiple SKUs with different code positions, teach one ROI per SKU and select it by recipe; one large union window reopens the wrong-code surface you closed. When codes arrive skewed or glary, correct with preprocessing before widening anything — the toolbox is in 1D barcode preprocessing for rotation, blur and glare. And grade what you accept: barcode read confidence: how to judge whether a decode is trustworthy sets the thresholds.

When is a full-frame read the better choice?

Read full frame when the code position is genuinely unknown, when unrelated codes must be read in one image, or when the whole frame is archived for traceability — budget a faster reader or a smaller field of view for it.

Parcel sortation, where the label lands anywhere on the face, is the honest case: search everything, and pay in pixels. The MV-CS200-10UM puts 20 MP on a 1-inch sensor over USB3 with a C-mount, and a PC pipeline can still crop to the located code before decoding — full-frame locate, ROI decode. On fixed readers, check the arithmetic before adding a window at all: a station passing 20 parts per minute needs one decode every 3 s, comfortably inside a 60 codes/s rating, so there the ROI earns its keep in wrong-code protection, not speed.

What checks close out an ROI set-up?

Run the seven checks below before release; the two that catch most field failures are the wrong-code test — a decoy code placed outside the window — and the tolerance re-measurement after any mechanical change.

1. 100–200 production frames logged; tolerance set to half the min-to-max span + 20%.
2. ROI = code size + 2 × tolerance, plus 10% margin; square if rotation is uncontrolled.
3. At least 3 pixels per module inside the ROI, 4 for margin.
4. Exposure ≤ object-side pixel ÷ surface speed: 100 µs at 0.059 mm and 500 mm/s.
5. Depth of field covers the fixture's height range: ±10 mm at f/4 in the example.
6. Wrong-code test passes: a decoy outside the window is never decoded.
7. A golden part decodes inside the window at every shift start.

If the station is still on paper, work the numbers from the code outward in the camera finder, or step through the configurator below with code size and tolerance in hand. When the geometry fights you — large tolerance, small module — send those two numbers through the contact page for a second pass before you order.