A golden template comparison answers one question — where does this part differ from a known-good image? — but its raw output rarely answers it safely. A bare particle count fails a good part when one stray pixel survives thresholding, and passes a wrong part whose difference mask sweeps away to nothing. This guide sets the inspection up the way it survives on a line: register the golden image to the part, threshold the difference, clean the mask with a size filter, then judge each surviving particle on measured features. You will set every number — locate-score floor, difference threshold, filter floor, area caps — from your own good and bad parts, and leave with a release checklist that runs unchanged on a smart camera or a vision controller.
What a golden template comparison measures
A golden template is a master image of a known-good part, captured under production lighting. The compare stage takes the current image plus the locate result — position, rotation, scale — warps the master onto the part, and flags every pixel whose gray level deviates beyond the threshold limits in either direction. The output is a binary defect mask, not a verdict.
Two properties drive everything that follows. First, the logic assumes any difference beyond tolerance is a defect: exactly right for machined faces, printed labels and marked connectors, exactly wrong for brushed grain, wood or produce, where rule-based checks on stable landmarks or a trained model fit better. Second, the mask is only as good as the registration: a 1 px misregistration draws halos around every edge, so the threshold must clear your measured registration error, not an idealized noise floor. When a mask comes back empty or saturated for no visible reason, probe the acquisition stage by stage before touching a threshold.
What you need
- The golden image itself, captured under the light, lens, focus and exposure the line runs — see the warning below. If your library refuses the golden image with an invalid descriptor error, that is a known failure with a documented fix.
- 20-30 known-good parts and 10-20 known-bad parts with planted defects, to set the thresholds and prove the fail rules.
- Fixed lighting: manual exposure and gain, strobed or shrouded against ambient drift. Auto modes re-baseline the template image by image — the auto-exposure pixel analysis shows which pixels those modes watch.
- An ROI covering the defect-bearing area, not the whole part; the tighter the ROI, the lower the noise floor the threshold must clear.
- The compare stage itself: on-device in a smart camera environment, or as library calls on a vision controller.
The pipeline, step by step
- Locate the part and record the score. Pattern-match on a stable landmark; the match returns position, rotation, scale and a score. The score is the first gate: with good parts scoring 0.95-0.99 in the worked example below, the floor sits at 0.90, and anything under it returns part-not-recognized before any comparison runs.
- Register the golden image. Feed the locate pose to the warp: shift-only for a fixed fixture, rotation and scale for loose parts, perspective when the part can tilt out of plane. Leave intensity normalization off under fixed lighting — it flattens real contrast defects along with drift. If the ROI comes back invalid after the warp, that is a known rectification failure with a specific fix.
- Threshold the difference image. Set upper and lower limits, for brighter and darker deviations. Derive both from the good-part sample: run the 20-30 parts, read the worst absolute deviation (9 gray levels in the worked example), add 5-10 gray levels of margin, and land on 15.
- Clean the mask with a size filter. Keep particles above a floor of about one third of the smallest defect's pixel area — 6 px in the worked example, against a 19 px defect. Threshold-edge specks on good parts run 1-3 px, so the floor clears noise by 2× while the smallest must-catch defect passes untouched.
- Measure every surviving particle. Area, perimeter, bounding box width and length, hole count, centroid. A particle count is one number among these; it feeds the decision but never makes it.
- Decide on the rules. Fail on any particle at or above the smallest-defect area, fail on clusters, classify scratches by shape, and route mismatched images to a distinct error verdict through the two gates — score floor and flagged-area cap — before any of it runs.
The classic three-call chain many libraries wrap looks like this, with the calls exactly as one vision library ships them:
int numParticles = 0; /* int, initialized to 0 */
int threshold = 15; /* int, gray levels, from your good-part sample */
/* stages 2-3 in one call: warp the master to (xPos, yPos, rotation, scale), threshold */
VisionErrChk (IVA_CompareGoldenTemplate (image, templatePath, xPos, yPos, rotation,
scale, IMAQ_REGISTRATION_PERSPECTIVE, IMAQ_NORMALIZATION_NONE,
1, threshold, threshold, 1, 1));
/* stage 4: keep particles larger than 2 px, drop smaller specks */
imaqSizeFilter (image, image, TRUE, 2, IMAQ_KEEP_LARGE, NULL);
/* stage 5 at its weakest: a bare count */
imaqCountParticles (image, TRUE, &numParticles);
return numParticles;
Here image is the acquired frame buffer, templatePath the string path to the golden image, xPos, yPos, rotation and scale the locate results. The chain carries no gates and no features, so that return value is only as good as the day's registration. Graphical environments pack the same stages into one configured block; the walkthrough on configuring golden template match results in a graphical vision environment wires the identical parameters, gates included.
The gated decision that belongs after stage 4, in illustrative names — yours will differ; the numbers transfer:
if (locateScore < 0.90) return PART_NOT_RECOGNIZED; /* gate 1 */
if (flaggedAreaPx > roiAreaPx * 0.05) return PART_NOT_RECOGNIZED; /* gate 2 */
if (maxParticlePx >= 20) return FAIL; /* area rule */
if (mediumCount >= 3) return FAIL; /* cluster */
if (maxAspect >= 5 && maxLengthPx >= 25) return FAIL; /* scratch */
return PASS;
Worked example: set every number from your parts
The part is a 40 mm × 30 mm connector face where a 0.10 mm missing-plating spot and scratches of 0.5 mm or longer must fail. The camera looks straight down, the image is 2448 px wide over a 50 mm field of view, and the ROI covers the whole face.
From that scale:
- Noise: after a 15-gray-level threshold the good sample leaves specks of 1-3 px, so a filter floor of 6 px clears the worst by 2×.
- Area rule: any particle of 20 px or more fails — the 19 px spot plus rounding margin. Particles of 6-19 px are medium, and three or more fail as a cluster.
- Scratch rule: 0.5 mm at 49 px/mm is 25 px, so fail any bounding box 25 px long or longer with length-to-width of 5:1 or more.
- Mismatch cap: 5% of the ROI is 144,000 px; a flagged area beyond it is a flood, not a defect pattern, and the verdict is part-not-recognized.
- Score floor: 0.90, set two steps under the good sample's 0.95-0.99.
| Setting | Value here | Basis |
|---|---|---|
| Pixel scale | 49 px/mm | 2448 px / 50 mm |
| Difference threshold | 15 gray levels, up and down | worst good part 9 + 6 margin |
| Size-filter floor | 6 px of area | one third of the 19 px defect, 2× above noise |
| Fail: single particle | 20 px or more | smallest defect 4.9 px across |
| Fail: cluster | 3+ particles of 6-19 px | repeated marks |
| Fail: scratch | length 25 px+, aspect 5:1+ | 0.5 mm at 49 px/mm |
| Part-not-recognized | flagged area over 144,000 px | 5% of the 2.88 Mpx ROI |
| Locate score floor | 0.90 | good sample 0.95-0.99 |
Run the pixel budget for your own smallest defect before fixing these numbers — the calculator opens filtered to cameras that meet the result, and the pixel-rule sizing guide walks the math in full.
Why a bare count fails on a mismatched image
A count never sees the image — only what survived the filter — so it cannot tell a defect from a registration accident. Three shapes cover nearly every field complaint:
Flood. The loaded part is not the templated one. Registration still returns a pose, the difference mask covers half the frame, the keep-large filter leaves one giant particle, and the count reads 1. The verdict is a fail, but the operator reworks a part that was never the right part, and the defect log fills with nonsense.
Sweep. The dangerous direction. A different-but-similar part registers approximately, its surface pattern hovers near the threshold, and everything it flags comes out as 1-3 px specks the filter removes. The count reads zero and the line ships wrong parts.
Chronic halos. A 1 px registration error on a busy face flags edge specks everywhere, the count reads dozens, and the standard response — raising thresholds and filter floors until the count clears — removes the margin real defects needed at the same time.
The fix is structural, not tuning. Gate 1 rejects low locate scores, gate 2 rejects flagged-area floods, and both return a distinct part-not-recognized verdict the line controller can route to a re-load instead of a rework. Watch the binary mask live during commissioning: a flood or a sweep is visible in seconds and invisible in a count.
Decide on measured features, not on the count
Every surviving particle carries measurable shape, and the shape classifies the defect:
- Area — spots, missing plating, stains; the 20 px fail rule above is an area rule.
- Bounding-box aspect — a 45 px × 4 px mask measures 0.92 mm × 0.08 mm at 49 px/mm, aspect 11:1: a scratch. The same 180 px spread as 13 px × 14 px has aspect near 1:1 — a blister or stain, a different root cause under an identical particle count.
- Compactness — perimeter against area, 4πA/P², reads 1.0 for a disc and 0.24 for that 45 × 4 px scratch (P = 98 px, A = 180 px). Elongated marks score low at any orientation.
- Holes — a ring-shaped mark such as a seal gap has area but low solidity; hole count separates it from a solid blob.
- Threshold side — darker-only flags point to corrosion, missing ink or shadow; brighter-only flags point to glare, burrs or contamination. Log the side, not just the total.
Pixel-level area measurement is its own subject — the blob-area guide works the counting and calibration. The narrower point here: every rule above survives a stray 2 px speck, because a speck fails no rule. That is the entire argument for feature-based verdicts over the count.
When a golden template is the wrong tool
Three situations to recognize before building the template:
- Natural appearance variation. Brushed metal, knit, leather, produce: every acceptable difference reads as a defect, so thresholds widen until real defects hide. Move to rule-based checks on stable landmarks or a trained model — the AI-versus-rule-based comparison frames the choice, the natural-variability guide covers the hard surfaces, and the retrofit path shows how to add a model to cameras you already run.
- Geometric, not reflectance. A dent, a warp or a coplanarity fault can leave gray levels unchanged on a shiny face; no 2D threshold sees it. That is a 3D profile job.
- Uncontrolled light. Daylight, an adjacent lamp or seasonal drift breaks the contract a template makes about light. Strobe, shroud and drive the light from a constant-current controller; the ambient-light control guide shows the controls that hold a scene steady.
When the answer is a trained inspection instead, the engineering discipline does not change — dataset, acceptance test, release criteria. A defect-detection commissioning walkthrough covers that sequence step by step.
Run it on this hardware
Both halves of the split sit in the catalog. On the device, smart cameras run locate, compare, size filter and the feature decision internally and return a verdict to the line. The MV-SC5060XM-08M-WBN pairs a 6 MP mono sensor with an 8 mm M12-mount lens on GigE. Its rolling shutter suits parts stopped on a fixture; for on-the-fly exposure the MV-SC6050C-08M-XBN brings a global shutter, 5 MP color and a built-in multi-color light source.
- Interface
- GigE
- Resolution
- 6-10 MP
- Interface
- GigE
- Resolution
- 5 MP
When the pipeline needs custom code, several cameras or database logging, move it to a vision controller. The MV-VC2140-128G40-1T covers a single-camera line with an Intel N-series processor, 8 GB of memory, 3-4 LAN ports and 4 built-in light-output channels. The MV-VC3301H-128G66 steps up to an Intel Core i3-8100, 5+ LAN ports, PCIe expansion and a bundled VM6200Pro license for the compare-and-measure stages.
- LAN ports
- 3-4 LAN ports
- USB 3 ports
- 2 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
Checks before you release the inspection
- Good-part run. 30 production parts under production lighting produce zero flags, and the largest surviving speck stays under half the filter floor — 3 px against the 6 px floor here. A flagged good part is a registration or lighting fault; fix it before touching thresholds.
- Bad-part run. Every planted defect fails, and the log names which rule caught it. A defect that only trips the flood cap was not caught — it was masked by a mismatch.
- Swap test. Load a similar but wrong part. The verdict must be part-not-recognized from the score gate or the area cap: never a pass, never a bare fail with a count.
- Nudge test. Offset the part by 0.5 mm and 2°. Registration absorbs it with no flags; beyond that range the locate score drops and gate 1 fires.
- Black test. Block the lens or fire the trigger with no part present. The flooded mask must return part-not-recognized, not a crash or a count; when the image itself comes back dark, the acquisition probe from the first section is the diagnostic.
- Record keeping. Every verdict logs template version, threshold pair, filter floor and light intensity, so any past verdict can be reconstructed.
More applied pipelines like this sit on the applications topic page. To size the controller against your camera count and cycle time:
The configurator matches a camera, lens, light, light controller and cables to each other, step by step, and lists only parts that fit what you already picked.
Or send the plans to the applications team with your part drawings, defect list and cycle time, and the pipeline numbers above come back sized to your line.
Questions
How do I choose the difference threshold instead of guessing?
Run 20-30 known-good parts under production lighting and read the largest absolute pixel deviation the registered comparison produces — 9 gray levels in the worked example. Set both limits at that worst case plus 5-10 gray levels of margin, so 15 in the example. On an 8-bit sensor with fixed lighting the result usually lands between 10 and 30 gray levels, but your sample decides. Re-derive the number after any lens, exposure, gain or light change.
Why does a golden template inspection pass a wrong part?
Because the mismatch never reaches the verdict: the difference mask of a wrong part can sweep out as 1-3 px specks, the size filter removes them, and the count reads zero. Two gates close the path. Reject when the locate score falls under the floor your good-part sample sets, and reject with a part-not-recognized verdict when flagged area exceeds its cap — 5% of the ROI in the worked example. Prove both with a swap test before release.
What size filter value removes noise without hiding real defects?
Set the keep-large floor at about one third of the smallest defect's pixel area, then confirm on bad parts. The example: a 0.10 mm spot at 49 px/mm is 4.9 px across, about 19 px of area, so the floor sits at 6 px while the fail rule stays at 20 px. Threshold-edge noise on good parts runs 1-3 px, so the floor clears it by 2×. Every planted defect must survive the filter on your own bad-part sample.
When should the golden template be re-mastered?
Whenever anything in the optical chain changes: a lens swap or refocus, aperture, exposure, gain, a different light model or intensity, a moved camera mount, or a part revision. Store the golden image inside the product recipe together with the threshold pair, filter floor and feature rules, and version that recipe — an inspection that can say which template and which numbers produced each historical verdict is the one that survives an audit or a quality escape review.
Can a golden template work on shiny or textured surfaces?
Rarely as a plain pixel difference. Brushed grain, weave and gloss produce acceptable frame-to-frame variation that the compare reads as defects, so thresholds widen until real defects hide inside the noise band. The workable middle ground on repeatable specular parts is a template built from the polarized channel under diffuse light, which suppresses the moving highlights. Beyond that, move to rule-based checks on stable landmarks or a trained model for natural-variability surfaces.



