Visual Quality Inspection with Computer Vision

For manufacturers, we build visual inspection systems end to end: camera and lighting assessment, acceptance testing, line integration and monitoring after go-live.

Which quality problems does it solve?

Visual quality inspection means building a system that inspects every part on the line with the same attention and rejects the defective ones. Set up well, it works where operators tire, where sampling misses defects and where manual measurement is too slow.

We start by matching the problem to the right vision task, because the data, labelling and acceptance test all follow from that choice.

Quality problem	Suitable approach	What the system returns
Surface defects such as scratches, stains or cracks	Segmentation or anomaly detection	Where the defect is and how large, plus an accept/reject decision
Missing, wrong or reversed components	Object detection	Whether each expected component is present and in place
Label, date and lot-code checks	OCR and code reading	The text read and its comparison with the expected value
Dimension or position deviation	Classical image processing and measurement	A measurement against tolerance
Colour and shade differences	Classical methods or classification under controlled light	Deviation from the reference
Packaging and fill integrity	Classification or object detection	A pass/fail decision with an image record

Not every problem needs deep learning. Measuring a part that sits still under controlled light is cheaper and easier to explain with classical methods. Our computer vision and image recognition service page explains the technical differences between these tasks.

What we deliver

Feasibility and imaging design

Using sample images from your line, we test whether the defect is visible to a camera at all, then recommend the camera, lens, lighting and trigger setup.

You know the images are good enough before anyone trains a model.

Data collection and labelling guide

Together with your quality team we write down which images to collect and how to label borderline cases.

Two people stop giving the same part different verdicts.

Model and decision thresholds

An adapted pre-trained model, a custom model or a classical method; thresholds are set from what a missed defect and a false alarm cost you.

The system is tuned to your tolerance for each kind of error.

Line integration and operator screen

The decision goes to the reject mechanism, the PLC, your production tracking system or an operator screen. Uncertain cases go to human review.

The result triggers an action on the line, not a report.

Acceptance test report

Using images never seen in training, results are reported separately by defect type, product, shift and lighting condition.

You accept the system with its weak spots visible, not on one average.

Monitoring and retraining loop

After go-live we track image drift, false alarms and operator corrections, and plan retraining for new defect types.

Day-one performance does not quietly decay.

Send us a few images from your line and we will tell you whether the defect can be caught on camera.

Assess your line

How the pilot works

The pilot measures whether the system works on your line, with your products, before you commit to a full rollout. You decide whether to continue at the end of every step.

Define the decision and the cost of errors
We write down what the system must catch, what happens to a rejected part, and whether a missed defect or an unnecessary rejection costs more.
Sample images and a line visit
Existing images or a short capture on the line show how visible the defects are, how fast the line runs and where equipment can be mounted.
Imaging setup
Where needed we test cameras, lenses and lighting, so image quality is fixed before the model is.
Data and labelling
Good and defective examples are collected, labelled against the guide, and a separate test set is put aside.
Pilot and acceptance test
The system is measured against acceptance criteria written in advance, on the held-out set and in real line conditions.
Integration and handover
The decision is connected to the reject mechanism or your systems, and operators are trained.
Monitoring
Performance is tracked as products, lighting or cameras change, and the model is updated when needed.

Missed defects or false alarms?

Every visual inspection system involves a trade-off: lower the threshold and fewer defects slip through, but more good parts are rejected for nothing. Which side costs more depends on the product, the customer and the checks that follow the line. So we set thresholds from your error costs, not from a technical default.

Separate thresholds per defect type. A safety-relevant defect and a cosmetic one do not have to share a threshold.
Human review for uncertain cases. Parts the system is unsure about go to an operator, and the review workload is measured separately.
Image records. The image behind every rejection can be kept, so disputes, root-cause analysis and retraining draw on the same record.

Our article on computer vision for quality control covers camera placement, false alarms and review flows from an engineering point of view.

If you have few defect examples

On a good line defects are rare, which means labelled defect data is scarce. That does not stop a project, but it changes the approach:

Anomaly detection can start from images of good parts only and flag anything that departs from normal.
Few-shot vision methods make clear which labels you actually need.
Whether the location or the area of a defect matters decides between segmentation and object detection.
For label and code checks, OCR, detection and vision-language models do different jobs.

Images do not have to leave the factory

Inference can run on an edge device next to the line or on the factory's own server. That keeps latency low and production images inside your network. The cloud adds flexibility for images processed in batches and for jobs where latency is not critical. If images contain personal data such as workers' faces, masking and retention rules are designed as part of the installation.

Tell us your line speed, your product variants and your most expensive defects, and we will scope the pilot together.

Plan a pilot call

What drives the price?

In visual inspection projects the conditions on the line drive the price more than the model does. Each item is listed separately in the proposal:

The number of products and variants, and how many defect types there are and how subtle they are.
Line speed and how quickly a decision is needed.
Whether new cameras, lenses or lighting are required.
How much image data already exists and how much labelling is needed.
The systems to integrate with: reject mechanism, PLC, production tracking or quality systems.
Edge hardware and the number of lines or stations to equip.

We quote the pilot as a fixed-scope engagement. Once the pilot is accepted, rollout is planned line by line, and after go-live monitoring and retraining run under a monthly support agreement. If you are not yet sure which job is ready for a pilot, you can start with a discovery under our AI consulting service.

What we need from you

Sample images. Good and defective parts captured in real line conditions; if you have none, we plan a short capture.
A defect catalogue. The defect definitions and limit samples your quality team already uses.
A quality expert. Someone who makes the final call on borderline cases and signs off the labelling rules.
Access to the line. Planned access for installation, trials and acceptance testing, plus operators to take part in the tests.

Frequently asked questions

Will a visual inspection system replace our operators?

The aim is not to remove operators but to inspect every part with the same attention. The system makes the clear calls itself and sends parts it is unsure about to an operator, whose decisions are then used to improve the system.

We have very few defect examples. Can we still start?

Yes. Anomaly detection, which learns from good parts only, or few-shot methods can get you started. We decide which route fits after looking at sample images.

Do we need a separate model for every product variant?

Not always. If variants look alike, one model may be enough; if they differ a lot, separate models or thresholds per product group are planned. The decision is based on the per-product results of the acceptance test.

Can the system keep up with our line speed?

Line speed and the time allowed for a decision are among the first inputs to the pilot. Camera, hardware and model are chosen for that time budget and measured again in the acceptance test.

What happens if the pilot falls short?

Because the acceptance criteria are written before the pilot, the result is not a matter of opinion. If the criteria are not met, we report why and say plainly whether changes to imaging, data or approach are worth pursuing.

Do production images leave the factory?

Not if you do not want them to. The model can run on an edge device next to the line or on the factory's own server.

Visual Quality Inspection: Catch Defects on the Line