OCR on a fixed code reader: multiple text strings in one image

A packing line wants one trigger to capture two text strings — 23 characters on a transparent overwrap packet and 13 characters on the carton beneath it — then print both into the barcode on the shipping package. Can a fixed industrial code reader do it in one image, how many pixels does each character need, and where do the regions of interest go? This guide answers those with arithmetic you can reuse: a field-width budget, a working-distance and exposure calculation, an ROI plan, lighting for clear film, and the bench checks that decide the order.

Can one fixed code reader capture two text strings in a single trigger?

Yes. An image-based fixed reader takes one exposure and runs OCR over each text region you draw: the packet string and the carton string leave as two labeled results from one trigger, in two regions of interest or one if they share a block.

OCR is an image tool on the same acquisition as the code tool. Both read the identical frame, both return ASCII, and each ROI keeps its own result field, so the two strings stay separate until your logic joins them. Draw the ROIs tight around the text: a cropped region decodes faster and rejects stray artwork. The mechanics — size, placement and the cycle time you save — are in setting an ROI for inline code reading, and several marks in one frame follow the same pattern as reading multiple barcodes in one image.

How many pixels does each character need?

Give each character 25-30 pixels of height and strokes of 2-3 pixels. Below about 20 pixels, engines start confusing similar pairs such as 6 and 8; above 40 pixels you are spending field width without gaining read rate.

Dot-matrix inkjet strokes run about one eighth to one tenth of character height, so a 2 mm character at 25 pixels of height puts its 0.2-0.25 mm stroke across 2-3 pixels — the geometry OCR scoring assumes. Size from the smallest string in the scene; the larger string gains margin for free.

How wide a field do a 23-character and a 13-character string need?

About 110 mm of scene width holds both marks of the running example: 27.6 mm for the packet string, 23.4 mm for the carton string, 40 mm between them and 10 mm of margin each side, read at 0.08 mm per pixel or finer.

Worked example. Assume 2 mm characters on the packet with a 1.2 mm advance per character (about 0.6 × height for OCR-style fonts): 23 × 1.2 mm = 27.6 mm. Carton characters at 3 mm: 13 × 1.8 mm = 23.4 mm. Total width with 40 mm between the marks and 10 mm margins: 27.6 + 40 + 23.4 + 20 = 111 mm, call it 110 mm. The pixel target sets the scale: 2 mm ÷ 25 px = 0.08 mm/px, so the field needs 110 ÷ 0.08 = 1375 pixels across.

A 1280-pixel sensor delivers 110 ÷ 1280 = 0.086 mm/px, landing a 2 mm character at 23 pixels — under target and risky on dot-matrix print. A 2560-pixel sensor delivers 0.043 mm/px and 46 pixels on the same character: comfortable. The ceiling for one image follows from the same numbers: 2560 × 0.08 mm = 205 mm, so marks up to roughly 180 mm apart still share a frame. Beyond that, step up resolution before splitting the job across two readers.

The LS-CRD-0028 covers this window in one frame: 2560 x 2048 pixels at 30 fps, a 5 MP global-shutter sensor in 1/1.7-inch format, an 8 mm lens and Fast Ethernet.

Which working distance and exposure keep both strings sharp?

Mount the reader about 120 mm above the marks to make the field 110 mm wide with an 8 mm lens on a 1/1.7-inch sensor, and hold the exposure near 0.3 ms for a 150 mm/s belt so motion blur stays inside one pixel.

The 1/1.7-inch format has an active width of about 7.4 mm (typical for the format, allow ±5%). WD = 110 mm × 8 ÷ 7.4 ≈ 119 mm, so a 120 mm mount is right. Blur: 150 mm/s × 0.0003 s = 0.045 mm, just under the 0.043 mm pixel. Set the aperture near f/4: at the 2.9 µm pixel pitch of a 2560-pixel 1/1.7-inch sensor the diffraction spot is about two pixels, while f/8 softens strokes past the 2-3 pixel target. Depth of field is generous at this magnification (m ≈ 0.067): the estimate 2Nc(1+m)/m² with c = one pixel gives roughly 80 mm of total depth, so a packet riding 20-30 mm above the carton stays in focus.

Keep gain at its minimum and buy contrast with light instead; the exposure, gain and image-quality balance guide shows why gain adds noise before it adds readability. For a bench-top labeler, the LS-CRD-0047 offers 1.2 MP over USB 2.0 with a 60-120 mm reading distance and a global shutter. That band brackets the ~120 mm mount this example computes.

Check your own lens-to-distance pairing on the calculator below.

Should the two strings share one ROI or get separate ROIs?

Draw one ROI per string by default: separate regions keep each result labeled and independently validated, and the reader concatenates them in ROI order. Share a single ROI only when both strings sit on one straight line at the same height, a few characters apart.

Separate ROIs let you validate each string against its own expectation — 23 characters here, 13 there — before anything reaches the print queue. A shared ROI risks the engine swallowing label artwork as characters and loses per-string confidence values. Angle matters too: an overwrap packet rotates a few degrees relative to the carton, and two regions tolerate that independent skew. Gate each ROI result on confidence before concatenation; how to judge whether a decode is trustworthy sets the threshold logic.

What makes text on a transparent packet readable?

Contrast decides, and lighting creates the contrast: printed ink wants direct or polarized light, molded characters want raking light that turns relief into shadow, and the working target is a stroke-to-background gray difference of at least 30-40% of full scale.

Clear film is the hard case: ambient light and the gloss of the wrap reflect straight into the lens and wash the strokes out. Polarization removes that specular component, so a polarized reader over the packet ROI plus a plain white-light source over the carton ROI is the standard split. Molded or embossed characters carry almost no gray contrast — their depth is the signal — so rake light across them at a low angle and let the shadows form the characters.

The MV-IDB005EXI-05NRP carries the polarized optics for the film mark: 1.3 MP, a 4.63 mm focal length, a 70 mm focus distance, an M5.8 mount and Fast Ethernet.

For printed carton text that only lacks light, the MV-ID813M-05S-WBN-SR integrates a white-light illuminator with its 1.3 MP sensor, 4.9 mm focal length and GigE interface.

Grade the print on the worst sample, the way date code print quality inspection does — not on the fresh label from the first meter of a new ribbon.

Do you need a code reader or a smart camera for an OCR-only job?

Choose a fixed code reader when code reading plus OCR is the whole job; choose a smart camera when the station must also run presence checks, measurement or AI tools. Confirm how OCR is licensed on the line you buy — per-device add-on or bundled — before you commit.

Vision sensors and smart cameras in smart cameras run the same OCR tooling plus general inspection; dedicated units in fixed code readers are tuned for decode throughput and simple integration. The license split matters more than the hardware: on some product lines OCR is a paid add-on per device, on others it ships with the firmware, and that difference can flip the choice across a 20-reader installation. Decide by tool count: if barcode and OCR are the only tools, the code reader wins; anything else on the same trigger pushes you to the smart camera.

The four readers that span this decision:

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

Pick the 5 MP body for windows of 110-200 mm like this example, a 12 MP body when three or more strings or wider spacing push past 200 mm, and the 20 MP logistics reader when one camera must cover a full carton face from a taller mount. An integrated-light compact suits tight cells; a C-mount body takes interchangeable glass for unusual fields.

How do the captured strings become the package barcode?

Concatenate in a fixed order — packet string first, then carton string, 36 characters plus your separator — trim spaces, and encode as Code 128: about 115 mm of label at a 0.25 mm module, or a Data Matrix of roughly 10 mm square when the label is small.

Code 128 spends 11 modules per character, plus start, checksum and stop: 37 × 11 + 35 = 442 modules. Add 10-module quiet zones each side and print at a 0.25 mm module: 462 × 0.25 mm ≈ 115 mm of label. If that is too wide, a 32 x 32 Data Matrix at the same 0.25 mm module is an 8 mm symbol plus quiet zone — call it 10 mm square — and holds a 36-character payload with room to spare.

On the PLC side the two strings are ASCII buffers with fixed start indexes: storing ASCII barcode strings in PLC memory shows the byte and word layout, and planning the barcode reader to PLC link covers the transport, so the concatenation happens in one place rather than two.

What do you verify on samples before ordering?

Put 50 of your worst parts on the bench, not five of the best: confirm at least 25 pixels of character height, 30% gray contrast, zero misreads across the set, and cycle time with both tools running at your real line rate.

• Pixel height. Measure the smallest string on screen; accept 25 px or more, remount or raise resolution if it falls below.
• Contrast. Histogram each ROI and require a stroke-to-background difference of 30% of full scale on the worst print, with gain at minimum.
• Misreads. A wrong character is worse than a no-read: require zero misreads over the 50-part set and gate both ROIs on confidence plus expected length.
• Cycle. Run the code tool and OCR together at line rate and leave transfer margin; a timing budget that holds with one tool can fail with two.
• Label. Scan the generated Code 128 with a second reader before releasing the design to the printer.

Size your own window with the numbers above, then filter bodies by resolution and interface in the camera finder, step through a full set-up in the configurator, or browse the other code reading guides. For a second opinion on a hard mark, contact the applications team with your string lengths, character heights and belt speed.