Computer Vision for Inspection: Where It Works and Where It Fails

The appeal and the catch

Visual inspection is repetitive, fatiguing and inconsistent when done by people over long shifts. It looks like an ideal automation target, and often is.

The catch is that a model sees only what the camera captured. Almost every disappointing inspection project traces back to imaging or data, not to the network.

Imaging is the highest-leverage decision

Lighting determines what is detectable. A surface crack invisible under diffuse light may be obvious under raking illumination at a low angle. A scratch on a reflective surface may only appear under dark-field illumination, where the sensor sees scattered rather than directly reflected light. Choosing the lighting geometry to make the defect maximally visible does more for accuracy than any modelling choice.

Resolution must be specified from the smallest defect. As a rule of thumb, a feature needs to span several pixels to be reliably detectable — three to five at minimum, more for subtle contrast. If a 0.5 mm crack must be found, the pixel size must be well under that.

Consistency matters more than quality. A modest camera in fixed, repeatable conditions outperforms an excellent camera under varying light and pose. Variation the model has not seen is variation it will handle badly.

Fixing imaging conditions is usually cheaper than compensating for them with a larger model and more data.

The class imbalance problem

In a functioning production line, defects are rare — often well below 1%. This creates two compounding difficulties.

Collecting defect examples is slow. A thousand images may contain a handful of defects, and those few may not span the range of defect types you care about. Deliberate collection of defective parts, including from historical scrap, is usually necessary and should be budgeted at the start.

Accuracy becomes meaningless. A model that predicts "good" for every part achieves 99.5% accuracy on a line with a 0.5% defect rate, while being entirely useless. Precision, recall and the confusion matrix are the metrics that carry information here.

The correct operating point depends on the cost asymmetry. Missing a defective safety-critical component is usually far worse than falsely flagging a good one for human review — so recall on the defect class is prioritised, and the false positive rate is negotiated against inspection capacity.

Anomaly detection as an alternative framing

When defects are rare and varied, training a classifier on defect classes may be impractical. Anomaly detection inverts the problem: model what normal looks like using abundant good examples, and flag departures from it.

This suits situations where defect types are open-ended or unknown in advance, and where good examples vastly outnumber bad ones. The trade-off is less specific output — the system reports that something is unusual, not what is wrong — and a threshold that requires tuning against a tolerable false positive rate.

What to validate before deployment

• Test on parts the model has never seen, from a different production batch, ideally a different shift and day. Same-batch splits flatter the model badly.
• Test the failure modes, not only the average. Which defect types does it miss? Are misses concentrated in a category that matters most?
• Test robustness to the variation that will actually occur: lighting drift as lamps age, dust on the lens, part positioning tolerance, seasonal changes in ambient light.
• Establish the human fallback. What happens to a flagged part, and who adjudicates? An automated system with no defined escalation path stops the line rather than helping it.

The honest framing

The realistic goal for most inspection deployments is not replacing human inspectors but triage — automatically clearing the large majority of obviously-good parts so that human attention concentrates on the ambiguous minority.

That is a smaller claim than full automation, and it is achievable, measurable, and considerably more likely to still be running in two years.