Skip to content
Zero-ShotTeam
← All notes

Vision

Why visual inspection gets hard in the field

A vision system classifies an image from a camera or locates an object in it. Scoring high on a prepared dataset is easy; holding that score on a production line is rare. Almost none of the gap is the model — it is lighting, angle, which data was collected, and how rare the defect is.

Published
Built by
Zero-Shot Team
4 min read

Lighting matters more than the model

The same part produces two different images under morning daylight and under fluorescent light at night. If the model never learned that difference, the error rate climbs after dark and nobody knows why.

The intervention that helps most is usually hardware rather than software: fixed, controlled lighting. One light panel can buy more accuracy than months of modelling.

Reflection is the same story. On glossy surfaces, glare can become the only thing the model sees; a polarising filter or a change of angle solves it.

Camera placement is chosen once

The model learns the angle it was trained on. When maintenance shifts the camera by a couple of centimetres, accuracy drops — and the drop is silent. The system keeps running, just wrong more often.

Two safeguards: fix the camera physically, and keep a fixed reference marker in frame. If the marker is not where it should be, the system raises an alert.

That is five minutes of work at installation and weeks of diagnosis when discovered later.

The real difficulty is that defects are rare

On a well-run line the defect rate can be a few per thousand. That is a poor situation for training: collect ten thousand images and you may hold twenty examples of defects.

Three routes. Collect and set aside defective parts — the parts discarded in the normal flow are in fact the most valuable data. Augment from the defects you have. And where possible, deliberately produce defective parts under controlled conditions.

The metric changes too: 99% accuracy says nothing on a line with a one-in-a-thousand defect rate — a model that calls everything good scores 99.9%. The numbers to watch are the missed-defect rate and the false-stop rate.

The two errors do not cost the same

Passing a defective part and rejecting a good one are different failures. The first reaches the customer; the second slows the line.

So the threshold is set by business cost, not by a single 'best' value. Where an escaped defect is expensive, the threshold moves down, false stops rise, and that is accepted.

The business makes that call; the system's job is to show both rates transparently. A report offering one accuracy percentage makes the decision impossible.

The system keeps drifting after it ships

Suppliers change, material colour shifts slightly, a new product variant enters the line. The model has seen none of it.

Every deployed vision system therefore needs a feedback path: a button for the operator to say 'this is wrong', and somewhere those images accumulate. They become the next training set.

A simple monthly check is enough: did the score drop on the last month's samples. If it did, the environment changed, not the model.

In short

  • Fix the lighting first; controlled illumination often beats months of modelling.
  • Mount the camera rigidly and keep a reference marker in frame.
  • Don't discard defective parts — the rare data is the valuable data.
  • Watch missed defects and false stops, not a single accuracy percentage.
  • Give operators a 'this is wrong' button and check the score monthly; drift comes from the environment.

Common questions

How many images do we need to start?
For a narrow task, a few hundred can produce a working first version, especially when fine-tuning an existing model. What decides it is defect variety rather than total count: a thousand examples of one defect type teach less than a hundred each of five types.
What camera should we use?
For most tasks an industrial camera with a good fixed lens is enough; adding resolution usually buys less than fixing the light. The real decision is speed: without an exposure time and trigger scheme that keeps up with the line, images arrive blurred and no model can compensate.
Should processing run in the cloud or on the line?
It depends on latency and connectivity. If a stop decision must be made in under a second, processing belongs locally; a round trip to the cloud adds both delay and an outage risk. The cloud suits storing accumulated images and retraining.

More notes

All notes →