Detecting vs measuring vs classifying defects

"We need to inspect the parts" can mean three fundamentally different things, and projects go wrong when nobody says which one out loud.

The three problems

1. Detection - is something there? A yes/no question per location. Output: alarm or no alarm.
2. Measurement - how big is it, exactly? A number with an uncertainty. Output: 47 um, plus or minus 3.
3. Classification - what kind of thing is it? A label. Output: scratch, not dust.

They sound like a natural progression. They are actually three different systems wearing the same camera.

Why the difference matters: requirements

The same physical defect generates completely different system requirements depending on the question:

question               sampling needed    lighting goal           validation needed
detect a 50 um void    ~15 um/px (3 px)   max contrast, any kind  detection rates
measure it to 5 um     ~5 um/px (10 px)   clean, stable edges     gauge R&R study
classify void vs dust  enough px for      consistent appearance   labeled defect
                       internal detail    across the field        library, per class

Detection tolerates ugly images with great contrast. Measurement needs calibrated optics, telecentricity, and edge stability - contrast tricks like overexposure are now forbidden because they move edges. Classification needs enough resolution to see internal structure, plus something neither of the others requires: a library of labeled examples for every class, including the rare ones.

A story of the words getting mixed up

A project was scoped as "detect solder defects" and a fast, high-contrast detection system was built. It worked. Then, in the final meeting: "Great - so it will tell us whether each defect is a bridging risk or just cosmetic, right?"

That is classification. The optics had been chosen for contrast, not for resolving internal defect structure; the image that screamed "something is here!" contained almost no information about what was there. Retrofitting classification meant new optics, new lighting, and months of collecting labeled defect examples - effectively a second project.

One sentence in the first meeting ("do you need to know what the defect is, or only that it exists?") would have changed the entire design.

Classification has a hidden dependency

Detection and measurement can be validated with good parts and a handful of defects. Classification needs many examples of every class you want to name - and the rare classes, the ones that matter most, are precisely the ones nobody has examples of. If a class has three known examples in company history, no system can learn to recognize it reliably. This is a data problem, and it should be confronted in week one, not after the hardware arrives.

The questions to ask in the first meeting

• When the system finds something, what happens next? (If the answer involves "depends what it is" - that is classification.)
• Does any number from this system feed a process control chart or a tolerance decision? (That is measurement, with all its calibration duties.)
• Or does a human look at every find anyway? (Then build the best detector you can and let the human classify - often the right answer.)

Detection, measurement, and classification are three projects. Price them, design them, and validate them as three projects - even when they share one camera.