Pattern matching reference coordinate system: fix your origin

Open the vision code your setup software generates and the coordinate-system step already contains two numbers you never typed: a reference system set to 562.95 and 558.641. Nothing in the dialog explains them, zeroing them makes the first run look correct, and the second pattern match hands back NaN. Those two values are the whole subject here: what they are, where they come from, how the runtime transform uses them, and why zeroing them breaks a chain of matches. By the end you will know what to capture, what to wire and what to leave alone.

What the two numbers in the reference-system input are

The reference-system input holds the origin of the reference coordinate frame, measured in pixels on the golden (template) image. In the generated step that origin sits at x = 562.95 px, y = 558.641 px.

Image coordinates start at the top-left of the sensor: x grows to the right, y grows downward, and the unit is the pixel. The decimals are subpixel interpolation — the matcher fits the feature centre between pixel centres, so 558.641 px is an ordinary value. The frame angle is 0° here because, on the golden image, the reference frame is by definition aligned with the image axes.

These are setup constants, measured once when the step was created. They are not a per-image setting and not the expected part position. They record one fact: where the reference feature sits in the template. You never set them again for any image.

Why the transform needs a fixed frame

A pattern match returns where the feature is now, and that moves with the part. Everything you inspect with — ROI rectangles, edge positions, a robot pick point — was drawn once on the golden image, fixed to the part. The coordinate-system step connects the two: it maps golden-frame geometry into the current image using the fresh match.

Here (ref_x, ref_y) is the captured reference origin, (m_x, m_y) is the matched feature position on the live image, θ is the matched rotation about that origin, and (q_x, q_y) is any point you drew on the golden image. With θ = 0° the mapping is a pure shift: each point simply rides along as q + (m − ref).

Most vision libraries count rows downward, so the sign of θ follows from that y-down convention. Rotate a part by a known 90° at the bench, once, and record which sign your library reports.

Worked example: a 48 px shift at 0.0245 mm per pixel

Inputs: a 5 MP-class camera, 2448 × 2048 px, covering a 60 mm wide field — the sort of set-up a bench cell uses around a 50 mm part. The reference origin is the captured value (562.95, 558.641) px. The live frame is illustrative: the same feature matched at (611.15, 545.941) px, θ = 0°. The ROI corner drawn on the golden image sits at (900, 700) px.

The rule: pixel shift equals matched position minus reference position, and millimetres come from the scale, which is field of view divided by image width.

• Scale: 60 mm ÷ 2448 px = 0.0245 mm/px
• shift_x: 611.15 − 562.95 = 48.20 px → 48.20 px × 0.0245 mm/px = 1.18 mm
• shift_y: 545.941 − 558.641 = −12.70 px → 12.70 px × 0.0245 mm/px = 0.31 mm
• Mapped ROI corner: (900 + 48.20, 700 − 12.70) = (948.20, 687.30) px

The geometry follows the part: 1.18 mm down the belt, 0.31 mm across it.

The decision this drives is the search region. If the fixture spread is ±2 mm along the belt, that is 2 mm ÷ 0.0245 mm/px = 81.6 px, so the search half-width must be at least 82 px around the expected feature position — a window of about 164 px across before the feature's own size is added. A search region smaller than the real shift finds nothing, and a failed match is what hands NaN downstream.

Why 0/0 works once, then NaN on the second run

Setting the reference to (0, 0) does not break the math; it moves the fixed frame's origin to the image corner, and the transform still builds a valid frame from the first match. That is why the first run looks correct.

The damage arrives on the second pass. A chained match defines its search region relative to a coordinate frame, and if that frame came from the previous image's match — the found frame fed back where the golden reference belongs — the search region now sits where the last part was. On a tight region the feature is not there, the match returns no result, and there is no position or angle to build a frame from. The step still has to emit something, and an undefined pose propagates as NaN — not a number — through every downstream value.

One line covers it: 562.95 px and 558.641 px go in once, at setup, and stay there for every image the system ever sees.

Capturing the reference values once, correctly

1. Shoot the golden image under production conditions: production lens at working focus, production light at production intensity, production exposure.
2. Seat the part against its fixture datum and let the setup step find the reference feature. It writes the origin for you — (562.95, 558.641) px in this example — together with the 0° golden angle.
3. Leave the values as captured. Do not zero them, and do not paste numbers from another recipe.
4. Wire the runtime so the reference input receives those constants on every cycle.
5. Recapture after any hardware change: another lens, a refocus, a nudged camera mount, moved lighting, a new fixture. Each shifts the scale, the origin or both, and the old values are wrong by exactly that amount.

A grey live image is the classic sign that the runtime image no longer matches the golden one — camera works in setup but grey image at runtime walks that fault. Parameter drift matters too: an exposure or gain changed at runtime shifts grey levels and can move a subpixel centroid, which runtime camera parameter control puts in safe bounds.

Choosing the reference feature and sizing the search region

Pick a feature with high contrast against its surroundings, unique inside the search region, stable through process variation, and close to the geometry you inspect — rotation about the origin displaces distant ROI points the most. A feature symmetric under 180° can lock onto itself and report a false angle; pattern match flips 180 degrees is the fix for exactly that.

Size the search region from the largest expected shift, converted with your scale. In the worked example, ±2 mm at 0.0245 mm/px demands a half-width of 82 px; add the feature's half-size and a margin, then round up. Keep it no larger than it needs to be: doubling the half-width quadruples the searched area, which is where the update rate goes when pattern matching runs slow. If the template itself fails to score, check its size against the template-image-too-small fix.

When you can skip the reference frame

If the fixture is rigid, the part repeats within a few pixels cycle to cycle, and one fixed ROI covers the inspection, image coordinates already are a part frame — leave the coordinate-system step out. Add it when parts arrive loose: a conveyor, a robot drop station, a bowl feed, fixture slack, or any rotation.

Two neighbouring cases: measurements combined across separate exposures belong in one consistent frame, which coordinate matching across exposures handles; and anything sent to a robot needs this pixel frame chained into the tool frame, which eye-in-hand pixel-to-world coordinates walks through.

What to run the chain on

A few-hundred-pixel template with a compact search window typically matches in single-digit to low-tens of milliseconds on a current embedded processor; the search window, not the frame math, sets the time. Single-feature jobs run on the device, and smart cameras carry the whole chain — capture, match, transform, decision — on the camera itself.

Both of these run the chain on the camera over GigE:

The MV-SC5060XM-08M-WBN is the SC5000X series' 6 MP mono model: rolling shutter, M12-mount 8 mm lens, GigE. The LS-SMC-0063 bakes optics discipline into the hardware — 1.6 MP at 60 fps with an integrated 16 mm lens and white light — so the golden image and the production image come from an identical optical path by construction.

Multi-camera cells, heavier templates and PLC handshakes move the chain to a vision controller; filter the range by LAN ports, memory and processor to match the camera count and cycle time you need.

The MV-VC3301H-128G66 marks the entry point there: Intel Core i3, 8 GB of memory, 5+ LAN ports, 4 built-in light channels and the VM6200Pro runtime licence included.

Checks before production, and the decision

• The reference input holds the captured golden values, (562.95, 558.641) px here — never 0/0, never another recipe's numbers.
• No step consumes its own previous output as a reference.
• Search half-width at least the largest expected shift: 82 px per ±2 mm at 0.0245 mm/px in the example.
• Angle sign verified with a part rotated a known 90°.
• Scale spot-checked with a ruler in the part plane: 60 mm ÷ 2448 px = 0.0245 mm/px.
• Mapped ROIs drawn as an overlay land where you expect on a part placed deliberately off-centre; pattern matching overlay not showing shows how to draw them.

Decision per case: loose parts and chained matches — keep the captured reference constants, size the search to the shift, feed nothing back. Rigid fixture and one fixed ROI — skip the reference frame entirely. New lens, camera, light geometry or fixture — recapture the golden image before the next run. A part larger than one field of view changes the geometry chain, and template matching a part larger than the field of view explains that path.

If you are sizing hardware, start from the smart-camera finder or walk the whole cell in the configurator below. The systems topic page collects the pattern-matching fixes that sit around this one.

Every order includes free expert support, so if the chain still returns NaN after these checks, send us the step and its wiring through the contact page.