QR code finder pattern detection: locate before decoding

A QR symbol can be easy to recognize visually yet difficult to locate consistently with a simple threshold. Its white border may merge into the background, while unrelated squares can resemble individual markers. For a controlled imaging task, start with the three finder patterns rather than a whole-image histogram or a stored picture of one code.

This procedure explains how to generate finder candidates, check their scan-line structure, group their centers and pass a useful region to a decoder. It addresses standard QR symbols with three finder patterns, not Micro QR symbols. The objective is a repeatable locator, with explicit limits on what its geometry can establish.

1. Define the output before choosing an algorithm

Localization should return candidate symbol regions, finder centers and an orientation estimate. Decoding must then interpret the module grid, apply error correction and return the encoded data. A plausible arrangement of squares is not proof of a readable QR symbol.

Keep these outputs separate in your application:

• Candidate: image structure resembles a QR symbol.
• Located: the finder arrangement passes your geometric checks.
• Decoded: a decoder returns a valid result.
• Accepted: the returned data meets your application rules.

The image-to-validated-data workflow explains the remaining stages after localization. If an existing decoder already provides reliable detection and corner coordinates, use those outputs before building a separate locator.

A histogram cannot provide finder locations because it discards pixel positions. Two images can contain the same numbers of dark and light pixels while having completely different spatial arrangements. A whole-code template also changes with the payload and becomes sensitive to rotation and scale.

2. Check sampling before adjusting thresholds

A finder pattern occupies a square measuring seven modules across. A module is one cell of the QR grid. Across its center, the ideal dark and light runs follow this sequence:

As a starting design target, allow about four image pixels per module. This is an engineering starting point, not a universal decoder requirement. Blur, contrast, printing defects and perspective can demand more sampling.

For a hypothetical inspection, suppose the horizontal field spans 160 mm and the smallest module measures 0.5 mm. The required horizontal sampling is:

This estimate assumes a front-facing symbol and reasonably uniform image scale. Check the smallest projected modules when the label tilts. Extra sensor pixels do not repair defocus or motion blur.

Use the camera finder to compare acquisition options after establishing the sampling requirement. For blur or reflections that obscure module edges, the barcode preprocessing guide provides useful image-quality checks, although its decoding examples concern linear symbols.

3. Generate candidates from nested regions

Convert the image to grayscale and inspect its contrast before selecting a threshold. A global threshold is reasonable for evenly illuminated, clean samples. Use local thresholding when brightness varies across the label, but retain the grayscale image for later verification.

The finder structure contains a dark outer square, a light inner ring and a dark central square. In a contour hierarchy, this can appear as a dark boundary containing a light hole that contains another dark region.

A practical candidate pass is:

1. Threshold the image into dark and light regions.
2. Extract contours with their containment relationships.
3. Find nested boundaries consistent with the finder structure.
4. Reject tiny regions that cannot contain adequately sampled modules.
5. Estimate quadrilaterals, centers and local scale for the survivors.

Use containment information rather than requiring every finder to be an isolated connected component. Nearby dark modules can touch its outer boundary, and threshold artifacts can split otherwise useful contours.

Square appearance is a useful test for front-facing labels. Under perspective, expect quadrilaterals instead. Do not reject every candidate whose bounding box is not square; an axis-aligned bounding box also changes when a square rotates.

4. Confirm candidates with the run-length ratio

For each candidate, inspect lines through its estimated center. Measure alternating dark and light runs and compare them with the expected ratio. Search neighboring lines as well, because the first center estimate may miss the central region.

Normalize the measurements before comparing candidates at different scales:

For measured widths of 4, 5, 12, 4 and 3 pixels, the sum is 28 pixels and the estimated pitch is 4 pixels. The expected widths are 4, 4, 12, 4 and 4 pixels. The largest relative error is 0.25.

An initial acceptance limit of 0.30 would retain that example. Treat this as a tunable development threshold, not a QR specification or guaranteed operating limit. Save rejected examples before tightening it.

Cross-check each center in another direction. For a front-facing square finder, a line through its true center preserves the proportions even when the symbol is rotated. Lines away from the center, perspective and damaged edges can change the measurements.

When local quadrilateral edges are available, test directions aligned with those edges. Otherwise, horizontal and vertical searches are a useful first pass. Consolidate nearby detections into one center rather than counting multiple scan lines as separate finders.

5. Group three centers and estimate orientation

Generate triples from the surviving candidates. For each triple, test each center as the possible right-angle vertex. With limited perspective, the two vectors from that vertex should have similar lengths and be approximately perpendicular.

A perpendicularity score near zero indicates perpendicular arms. An arm length ratio near one indicates similar lengths. Illustrative starting limits are a score below 0.20 and a length ratio below 1.25 for a near-front-facing station. These limits require validation against the allowed label tilt.

Suppose the centers are A = (40, 40), B = (96, 40) and C = (40, 96) pixels. Then u = (56, 0) and v = (0, 56). Their dot product is zero, both arms measure 56 pixels, and their length ratio is one.

If the local module pitch is 4 pixels, the estimated grid width is:

Compatibility with a valid grid width strengthens the hypothesis. It does not establish the version reliably under perspective or replace decoder validation.

Use a consistent winding for the ordered centers. Check the proposed orientation against the timing patterns between finder regions, then let the decoder validate the symbol structure. For multiple symbols, avoid assigning the same finder to competing accepted groups without resolving the conflict. The multiple-code troubleshooting workflow helps separate detection failures from incomplete search settings.

6. Refine the region before decoding

Three centers are enough to propose orientation under restricted geometry. They are not enough to determine a general projective transformation: a homography needs four suitable point correspondences or equivalent additional constraints.

For an initial front-facing implementation, use the center vectors and estimated module pitch to propose a symbol region. Include the quiet zone rather than cutting the crop at the outermost dark modules. Standard QR symbols specify a quiet zone four modules wide around the symbol.

For tilted labels, obtain more geometric evidence from finder corners, timing structure or an alignment pattern where present. Do not assume the missing fourth corner is the parallelogram completion of the other three under strong perspective.

If you resize or rectify the crop, preserve the mapping back to the original image. The coordinate-indexing guide explains why correct detections can still produce misplaced overlays.

7. Choose where the detection should run

Choose the system architecture according to the work you need to control. A custom locator needs access to images and development tools. A production reading station may be simpler with a dedicated reader, provided its documented capabilities meet the task.

Fixed code readers are the starting category for dedicated code-reading stations. The LS-CRD-0028 has a global shutter. Confirm image access, supported symbologies, trigger behavior and result handling before choosing it for your implementation.

Area scan cameras suit host-based processing when you need control over contour extraction, geometric scoring and diagnostic images. The LS-CMR-0166 uses USB3 and a rolling shutter. Account for motion distortion when evaluating that acquisition approach.

Smart cameras are another architecture to assess when processing should run on the device. Verify the actual QR tools, scripting access and diagnostic outputs; the category name alone does not establish those features.

Use the camera configuration starting point when planning host-based acquisition. Keep application sampling calculations separate from documented product specifications.

8. Validate failures, not only successful examples

Build a labeled image set containing readable symbols, unreadable symbols and scenes without symbols. Include square logos, text blocks and packaging graphics as negative examples. A clean image is not necessarily an unambiguous image.

Measure at least these outcomes separately:

• Finder recall: how often the required finder regions survive candidate generation.
• Localization recall: how often a complete symbol region reaches the decoder.
• False localizations: how often unrelated structures form an accepted group.
• Decode success: how often a located symbol produces a valid decode.
• Processing time: median and slowest relevant acquisition-to-result times.

Sweep rotation, scale, position, exposure and permitted tilt. Retain intermediate masks, run measurements, candidate centers and rejection reasons. Change one threshold at a time so improvements remain traceable.

The usual three-finder approach is the wrong starting point when partial symbols, severe damage or strong perspective dominate the task. Compare it with an established decoder on the same images before expanding a teaching prototype into a production detector.

9. Complete the commissioning checklist

• Confirm symbol type. A three-finder design does not cover every QR-family format.
• Measure minimum projected module size. Nominal print dimensions can hide inadequate sampling at maximum tilt.
• Check focus and motion. Threshold tuning cannot restore missing edge information.
• Preserve quiet-zone coverage. Tight crops can remove useful decoder context.
• Test negative scenes. Repeated square graphics are necessary rejection tests.
• Verify coordinate transforms. Overlays must refer to the original image correctly.
• Separate localization from acceptance. Only validated decoded data should advance the application workflow.
• Freeze a regression set. Repeat it after changes to optics, exposure or software.

For the next step, compare acquisition options in the camera finder, or send sample images, module dimensions, field coverage and motion conditions through application support. Those details determine whether custom localization adds value or a dedicated reading workflow is the better fit.