Read multiple barcodes in one image with iterative decoding

A decoder that returns one barcode does not necessarily need a separate search region for every label. If it provides reliable location information, you can search a working image, hide each decoded symbol, and search again. This approach helps when the number and positions of codes change between images. The challenge is deciding which detections are genuinely new, preventing masks from damaging neighboring symbols, and reporting incomplete searches honestly. Keep the original image unchanged throughout the process.

Choose native enumeration before building a loop

First check the decoder's documented capabilities. A supported multi-result operation is usually preferable to repeatedly calling a single-result tool. It may provide better candidate management and avoid searching the entire image after every successful decode.

Use iterative decoding when the available operation returns one result, supplies usable geometry, and permits processing a modified image. Do not assume that a fixed code reader or smart camera exposes these functions simply because it reads barcodes.

If several codes should already be appearing through a multi-result interface, start with isolating image and search faults. That is a different problem from adding enumeration around a deliberately single-result operation.

Check image sampling and processing time

An enumeration loop cannot recover detail that acquisition never captured. Measure the narrowest bar or smallest module at the least favorable position in the image.

For an approximately front-facing label, estimate horizontal sampling using:

Suppose the horizontal field of view is 120 mm and the smallest module is 0.25 mm. Using 4 pixels per module as an initial design target gives:

120 mm × 4 pixels/module ÷ 0.25 mm/module = 1920 pixels

An image 2400 pixels wide would provide approximately:

2400 pixels × 0.25 mm ÷ 120 mm = 5 pixels per module

This is a sampling estimate, not a guaranteed decoding threshold. Focus, contrast, orientation, motion blur, and the decoder's documented requirements still matter. Perspective can reduce sampling at one edge of a tilted label. The camera resolution calculator helps translate feature size and field of view into an initial pixel requirement.

Repeated decoding also consumes time. Suppose an illustrative frame contains 6 readable codes, each search takes 12 ms, and validation plus masking takes 2 ms per attempt. Including a final unsuccessful search gives:

7 attempts × (12 ms + 2 ms) = 98 ms

Those times are assumptions for budgeting, not product performance claims. Measure representative difficult frames, not only average successful reads. The guide to CPU time versus wall-clock time explains which timing measurement reflects the application's actual wait.

Prepare separate source, working, and result data

Retain an immutable source image for validation, display, and diagnostics. Create a separate, writable image for masking. In C#, assigning another variable to an image object may only create another reference; use the image library's documented deep-copy operation when independent pixel storage is required.

Also establish ownership of acquisition buffers. If the capture system reuses memory after a frame is released, either retain that buffer through the supported mechanism or copy it before processing. A changing source image invalidates both geometry and duplicate checks.

Prepare these records before starting:

• A source-frame identifier and acquisition timestamp.
• A working image with documented pixel format, dimensions, and row layout.
• A result list containing payload, symbology, source-image geometry, and validation status.
• A mask history identifying which accepted symbol caused each modification.
• Attempt, elapsed-time, and accepted-result limits.
• An explicit termination reason, separate from the decoded results.

Preserve payload bytes when the decoder exposes them. A displayed string may not retain all distinctions involving control characters or encoding.

Resolve input representation problems before debugging enumeration. The guide to barcode decoder image compatibility covers the difference between valid image pixels and an incompatible input container.

Implement the decode, validate, and mask cycle

The following steps describe application logic rather than a particular software API. Map each operation to the decoder's documented methods.

1. Start from an independent working copy. Clear the current frame's results and mask history. Start a monotonic elapsed-time measurement.
2. Check the remaining limits. Stop before another call if its permitted duration would exceed the remaining frame budget. Check the attempt and accepted-result caps separately.
3. Decode one result. Search the current working image. Distinguish a normal no-read from an invalid input, unsupported setting, exception, or timeout.
4. Validate the returned geometry. Reject empty, degenerate, or out-of-bounds regions. Convert any crop-relative coordinates into source-image coordinates before further comparisons.
5. Check for an existing physical detection. Compare the candidate with previous results using location as well as payload and symbology. A repeated location must not increase the count.
6. Validate against the unchanged source. Decode an appropriate source-image region, retaining the symbol and its quiet zone. Confirm that the payload, symbology, and location agree before accepting a result found after masking.
7. Record a new accepted result. Save its source geometry and payload before modifying the working image. Keep validation failures in diagnostics rather than the accepted list.
8. Mask the symbol and confirm progress. Apply a valid mask, verify that it changed relevant pixels, and repeat. If the same candidate keeps returning, use a bounded recovery attempt or stop with a no-progress status.

Original-image validation helps reject candidates caused by artificial mask boundaries. However, a cropped validation call can return a different nearby symbol. Match its location as well as its data; an identical payload is not enough.

Keep acquisition, processing, and display ownership separate. Draw result outlines on a display copy or overlay, never onto the source used for validation.

Build masks that do not erase neighboring codes

For a two-dimensional symbol, a decoder may return a quadrilateral around the symbol. Confirm what those points represent: the symbol boundary, a fitted search region, or another documented geometry. Mask only the region needed to prevent that symbol from being decoded again.

A polygon generally preserves more neighboring image content than its enclosing axis-aligned rectangle. This matters when labels are rotated or closely spaced. Do not automatically expand every mask to include a generous quiet zone; that expansion can destroy another symbol's required clear area.

Choose a uniform fill compatible with the observed local background where practical. Avoid arbitrary high-contrast patterns that introduce new edges. Filling does not make the modified image trustworthy by itself, which is why source-image validation remains useful.

For a one-dimensional barcode, a returned scan line may cross the bars without describing their full height. Painting over that line alone can leave enough intact bars for the same code to decode again. Conversely, extending it across the whole image can erase unrelated labels. Obtain a supported symbol boundary or a validated label region before masking.

For blur, rotation, or glare that already prevents the first successful read, address acquisition or barcode preprocessing before adding more enumeration attempts.

Count physical symbols, not unique payload strings

Two packages can legitimately carry the same barcode value. Deduplicating only by text would incorrectly merge them into one detection.

Use a frame-local identity combining payload, symbology, and geometry. For example, strongly overlapping polygons with matching data are plausible repeated detections. Spatially separated symbols with matching data should remain separate results.

Any numerical tolerance needs validation against your label spacing and localization variation. An overlap ratio above 0.8 could be an initial repeated-detection test, but it is not a universal threshold. Elongated regions, partial localization, and tight packing can require another comparison using center distance or corner displacement.

Handle contradictory data at the same location as an ambiguity, not another physical barcode. Retain the evidence and validate against the source image before deciding which result to accept.

Keep coordinate conversions explicit whenever you crop, resize, or rotate an image. The guide to barcode detection coordinate indexing helps prevent a correctly decoded symbol from receiving the wrong outline or mask.

Finally, distinguish repeated detections within one image from repeated appearances across successive frames. A frame-local mask loop does not solve conveyor duplicate detection with overlapping images.

Define stopping conditions and verify coverage

Use several independent stopping conditions. Illustrative configuration values might include a maximum of 16 attempts, 12 accepted results, and a 150 ms frame budget. These are application choices, not decoder specifications.

An elapsed-time check between calls cannot interrupt a blocking decode. To enforce a deadline, use the decoder's documented per-call timeout or cancellation facility and account for validation and copying time. If cancellation is unavailable, describe the budget as advisory rather than guaranteed.

A final no-read is not an inventory check. An unreadable symbol, an unsupported symbology, or a symbol damaged by an earlier mask may remain visible.

Build a labeled test set containing empty images, identical payloads at different positions, edge labels, rotated labels, tight spacing, damaged printing, and deliberately unreadable symbols. Compare accepted detections against known physical locations. Report missed symbols, incorrect extra detections, payload errors, latency, and termination reasons separately.

Interpret any decoder score according to its documentation. The guide to judging barcode read confidence explains why a successful decode is not a complete acceptance policy.

Choose hardware around image and software access

Choose the architecture before choosing a reader. Browse fixed code readers when you want an integrated reading device, but confirm native multi-result behavior, result geometry, and image access through its documented interface.

The LS-CRD-0028 is a fixed code reader with a global shutter. Its listed hardware attributes do not establish support for a host-controlled masking loop.

Consider smart cameras when processing should run on the device. Confirm that the supported toolchain can copy images, modify working pixels, repeat decoding, and return an explicit partial-result status.

The LS-SMC-0063 is a smart camera with a GigE interface. Verify the required software operations separately from the hardware selection.

Use area scan cameras when a host application needs direct image ownership and control over the enumeration algorithm. Confirm acquisition compatibility, exposure requirements, and decoder licensing before committing to that architecture.

The LS-CMR-0166 is a USB3 area scan camera with a rolling shutter. For moving labels, assess motion distortion as well as blur during exposure.

Compare acquisition options in the camera finder. Do not infer barcode enumeration capability from interface type, pixel count, or nominal acquisition rate.

Final implementation and ordering checklist

Before deployment, confirm each item against saved source images and measured timing:

• Native multi-result support checked: avoid a custom loop when a documented operation already meets the requirement.
• Source pixels protected: copying and buffer ownership prevent masking or acquisition from altering evidence.
• Geometry verified: masks use actual symbol regions, not assumed scan-line extents.
• Identical payloads tested: separate physical labels remain separate results.
• Neighboring symbols preserved: rotated and tightly packed labels survive earlier masks.
• Artificial detections rejected: accepted results agree with unchanged source-image evidence.
• Limits observable: every frame returns results, elapsed time, attempt count, and a termination reason.
• Acceptance defined: downstream logic distinguishes a complete expected set from a partial search.

Continue with camera decoding and validated output data when integrating these results into the station's acceptance logic. For hardware selection, start the camera configurator, or contact applications support with representative images, smallest module size, field of view, and the required frame deadline.