Barcode reading direction: prioritize left or right

When several barcodes appear in one image, you may want the left-hand label processed before the right-hand label. Changing barcode orientation settings does not necessarily change that selection. For application developers and controls engineers, the reliable approach is to define spatial priority outside the decoder. You can submit ordered image regions, preserve their coordinates, and apply an explicit selection rule. The key decision is whether you need the first successful region or the leftmost code across the entire image.

Define what reading direction means

Barcode reading direction can describe three different requirements. Separate them before changing decoder settings or application code.

A decoder's returned collection may reflect its internal discovery order. Unless its documentation promises a spatial ordering, do not interpret the first result as the leftmost barcode.

Choose one of these application contracts:

• Zone-first selection: inspect preferred regions in sequence and accept a valid candidate from the first successful region.
• Global spatial selection: collect candidates across the required image area, then select the leftmost or rightmost candidate.
• Ordered reporting: collect candidates and return the complete list in a defined spatial order.

Zone-first selection can reduce processing time. Global spatial selection requires sufficient search coverage before the application can claim a spatial winner.

For the wider acquisition and validation sequence, use camera-based decoding from image to validated data. When multiple symbols disappear unpredictably, first separate image-quality faults from multi-code search faults.

Prepare the image and decoder interface

You need a stable image, access to documented decoder options, and a way to associate detections with image coordinates. A C# application can implement the selection logic without modifying the decoder's internal search routines.

Before building the workflow, confirm these capabilities:

• The decoder accepts cropped images or a documented region-of-interest setting.
• It can return multiple detections, or you have a validated method for finding additional candidates.
• Detections include usable positions, such as corners, a bounding rectangle, or a documented reference point.
• You can distinguish no decode, invalid input, timeout, and application-level rejection.
• The image buffer remains valid throughout every decoding attempt.

A payload-only interface is insufficient for proving which physical label is leftmost. You need location information or a separate localization stage.

Retain one immutable source frame for each selection decision. If the left crop comes from one exposure and the right crop from another, moving labels can produce an inconsistent comparison.

Also confirm the decoder's accepted pixel format before investigating search order. The guide to decoder input-type compatibility addresses failures that occur before symbol searching begins.

Build the ordered-region workflow

Use explicit regions rather than assuming the decoder exposes a left-to-right search switch. Keep the region schedule separate from the final candidate ranking.

1. Assign a frame identifier. Attach it to every crop, detection, and final decision so asynchronous work cannot mix exposures.
2. Define the coordinate convention. For example, let the full-frame origin be the upper-left corner, with horizontal coordinates increasing rightward.
3. Create an ordered region list. For left-side priority, submit the left region first; reverse the list for right-side priority.
4. Decode each region. Record its origin, dimensions, priority, completion status, and candidate detections.
5. Restore full-frame coordinates. Convert every candidate position before comparing candidates from different crops.
6. Merge repeated observations. Identify detections of the same physical symbol in overlapping regions.
7. Apply the selection contract. Either accept from the first successful priority zone or rank the complete candidate set spatially.
8. Validate and publish. Check the selected payload against the application rules and publish an explicit success or failure state.

For zone-first selection, define whether “successful” means any decode or an application-valid decode. A readable but unexpected payload should not silently prevent inspection of a lower-priority zone unless that is the intended process rule.

If you process regions concurrently, task completion order must not become selection order. Wait until higher-priority regions have resolved before accepting a lower-priority candidate.

Size overlapping crops without losing symbols

A crop boundary can cut through a symbol or remove its quiet zone. Overlap helps, but its required size depends on the complete horizontal support needed for decoding, not just the spacing between labels.

Consider a hypothetical image measuring 2400 × 1600 pixels. A starting layout could use these horizontal intervals, with every crop covering the full image height:

The bracket notation means the lower boundary is included and the upper boundary is excluded. Neighboring crops overlap by 150 px because 900 − 750 = 150.

That overlap does not guarantee containment of a symbol whose required horizontal support is 280 px. Such a symbol can straddle a boundary and be incomplete in both neighboring crops.

For a containment-based design, use overlap at least as large as the maximum required horizontal support, with additional allowance for localization uncertainty. That support includes the symbol, quiet zones, rotation envelope, and any context required by the decoder. Image-edge clipping remains a separate limitation.

When that width is unknown, use overlapping crops as a speed optimization and retain a full-frame fallback. A successful crop schedule on a few sample labels is not proof of coverage for every permitted label size.

The guide to cropping barcode images while preserving quiet zones explains why tight crops can fail despite apparently clear bars or modules.

Remap coordinates and merge overlap detections

Store crop origins with the crop objects. Do not reconstruct offsets later from the task's position in a processing queue.

For an unscaled crop, the conversion is a translation:

Suppose the right crop begins at horizontal coordinate 1500 and a detected symbol center is at crop coordinate (120, 520). Its full-frame center is:

The same physical symbol might appear in the middle crop at horizontal coordinate 870. Its remapped position is also 870 + 750 = 1620 px.

Without remapping, those detections appear to occupy different positions. Sorting their local coordinates could select the wrong label or create a false duplicate count.

If crops are resized, rotated, or otherwise transformed, retain the transformation and apply its inverse to reported positions. For a crop resized by a scale factor s, coordinates must first be divided by s, then translated by the crop origin. Confirm the decoder's coordinate convention before implementing that calculation.

For duplicate merging, consider payload, symbology, and geometric agreement together. Matching text alone is insufficient because separate physical labels can legitimately carry identical data.

A practical merge test asks whether two detections have matching payloads and positions consistent with the same symbol. Set geometric tolerances from observed localization variation and the minimum spacing between separate labels. Do not adopt an arbitrary overlap threshold without checking closely spaced examples.

Use barcode detection coordinate indexing when cropped detections, overlays, and payload lists become misaligned. Keep the original observations attached to each merged candidate for diagnosis.

Select deterministically and handle incomplete searches

Choose a physical reference point for ranking. The center of a detected symbol is often convenient, but it is not equivalent to its left edge. Long and short labels can change order depending on that choice.

For leftmost-center selection, use ascending full-frame horizontal center. For rightmost-center selection, use descending horizontal center. Then define tie-breakers, such as ascending vertical center, symbology, and ordinal payload text.

If otherwise equivalent candidates still tie, use a stable geometric representation or treat them as equivalent. Do not use asynchronous completion time as a final tie-breaker.

A generic processing sequence is:

frame = capture_one_frame()
observations = decode_required_regions(frame)
candidates = remap_and_merge(observations)
valid_candidates = apply_payload_rules(candidates)
selection = rank_using_declared_spatial_policy(valid_candidates)
publish(selection, frame_id, search_completion_state)

This pseudocode describes application structure, not a particular decoder API. For zone-first behavior, evaluate each completed priority zone before moving to the next, while respecting the declared validation rule.

A single-result decoder may return an arbitrary candidate from a crowded region. If completeness matters, use a documented multi-code capability or a validated additional-search method. The guide to iterative decoding of multiple barcodes covers that separate problem.

Record search completeness explicitly. A timeout after searching the left region is not equivalent to a completed global search. Report “preferred-zone candidate found” or an application-specific incomplete state rather than claiming a proven global winner.

Verify boundaries, duplicates, and timing

Build a test set that challenges the selection rule, not just basic readability.

• Place a single label at the left edge, center, and right edge.
• Put different payloads in opposite corners and reverse the priority setting.
• Place a symbol across each crop boundary, including its quiet zones.
• Present identical payloads on separate physical labels.
• Rotate labels through the permitted operating angles.
• Test a readable but disallowed payload in the preferred region.
• Delay one decoding task to test concurrent completion order.
• Force a timeout and confirm that incomplete searches remain identifiable.

For each frame, save the crop schedule, remapped geometry, merge decisions, chosen candidate, and selection reason. Draw overlays from the same candidate records used for selection, rather than maintaining a separate coordinate list.

Check the time budget with measurements. For a hypothetical rate of 20 frames/s, the available period is 1000 / 20 = 50 ms. Three sequential attempts taking 12 ms each, plus 8 ms of other work, consume 3 × 12 + 8 = 44 ms, leaving 6 ms.

Those figures are an example budget, not reader specifications. Full-frame fallback, image copies, and difficult no-read cases can consume the remaining time. Measure the complete pipeline under sustained load and define what happens when processing exceeds the frame period.

Choose the hardware boundary and release checklist

Use fixed code readers when you want decoding close to acquisition, but confirm their documented region, multi-code, and output-order capabilities. An interface connection alone does not establish those software functions.

The LS-CRD-0028 is a fixed-reader candidate to evaluate. Confirm the required search and position-reporting functions before choosing it for spatial-priority logic.

Use area scan cameras when a host application will own cropping, coordinate transforms, and ranking. The LS-CMR-0166 is an acquisition candidate; it does not by itself establish decoder behavior.

For smart cameras, check whether the documented on-device tools can express the complete selection contract. The LS-SMC-0063 is a candidate to assess against those requirements, not an assumed substitute for custom application logic.

Compare acquisition options in the camera finder. If a moving scene is involved, evaluate shutter behavior, exposure, and illumination separately from the search policy.

Ordered crops are the wrong primary solution when the real problem is unsupported orientation, invalid image input, poor focus, or payload parsing. They also provide little value when the process requires every visible code and the decoder already supplies a complete localized candidate set. In that case, sort the detections directly.

Before release, confirm:

• The contract says zone-first, global selection, or ordered reporting.
• Left and right refer to a documented image coordinate system.
• Every crop retains its frame identifier and transform.
• Overlap handling preserves separate labels with identical payloads.
• Timeout behavior does not imply unproven search completeness.
• Tests cover boundary symbols and out-of-order task completion.

Start an acquisition design with the camera configurator, or send representative images and your selection contract through application support. Include the desired priority, label positions, permitted rotations, and cycle-time limit so the hardware and software boundaries can be assessed together.