Computer vision quality control: where it breaks on the line
Computer vision quality control rests on three assumptions: the defect will be within the camera's field of view, line lighting will not drift, and the sample will represent the whole batch.
In practice, each one breaks—and then a missed defect is discovered not by the operator but by the end customer.
The first failure point is viewing geometry.
The camera sees one plane at one angle: a dent on the end face, a burr under the edge, a defect on the back side of the part do not enter the frame, and the system confidently returns "good." The field of view is designed for a specific product range—when the size type changes, it is recalculated rather than reusing the previous scheme.
The second is lighting stability on the line. Glare from a polished surface, dust settled on protective glass, lamp replacement, or light from shop windows shift brightness and contrast, and detection thresholds cease to match the image. A model tuned to one light mode begins either missing defects or rejecting good product as scrap.
The third is sampling inspection. It saves cycle time and therefore lives on lines for years, but catches process drift after it has already unfolded: the control part passes inspection, and the entire batch goes to the customer. Then comes batch return, shipment stop, and manual warehouse review.
Failures are linked: 100% inspection instead of sampling is useless if the defect is outside the field of view or lighting is unstable. We analyze how this is closed by the installation scheme and operating procedure.
Measurable effects: what actually changes on the line
The count starts from the current state of the line. Before implementation, we take baseline values on a labeled sample: missed defect rate, spread of verdicts between shifts, actual inspection completeness under sampling inspection per ISO 2859.
Missed defect rate is calculated on frames not present in the training set, including borderline ones—scratches at the threshold of distinguishability, edge defects, glare.
The sensitivity threshold is set in the inspection profile, so it is shifted according to the cost of error: where a miss is more expensive, where false rejection is more expensive.
Rejection repeatability is the second measurable shift: the camera does not get tired by the end of a shift, and the same part gets the same verdict from different operators.
Inspection completeness changes qualitatively—every frame is checked, including areas behind clamps and end faces where an operator physically does not look.
Changeover time when switching to a new size type depends on geometry. If lighting and angle are preserved, it is enough to switch the inspection profile with new reference images—that is minutes of setup technician work.
If optics or part position change, short reconfiguration is needed on a small sample of captured frames.
A whole class of failures related to the human factor disappears: a miss on a tired shift, a "by eye" decision, disagreement between two inspectors on one part.
The system does not replace the process engineer—it removes routine from them and leaves the review of disputed cases.
Implementation options: from an off-the-shelf module to your own model
The choice of option is determined by three things: stability of the imaging scene, availability of an archive of labeled frames, and defect class—scratch, underfill, label misalignment, or seam geometry violation. Below are real alternatives and what each one limits in the project.
| Option | When it fits | Limitations |
|---|---|---|
| Off-the-shelf inspection module | Standard product on a conveyor, defects visible to the eye, fixed imaging scene | Catches only predefined classes; on new product range and lighting changes gives false triggers, retraining unavailable |
| Custom model on labeled frames | Non-standard defects, there is an imaging archive and resources for labeling several thousand frames | Requires labeling discipline and drift control: after a raw material batch change, the model is rechecked and retrained |
| Hybrid of rules and model | Defect is described by a brightness threshold or geometry, the rest is variable | Rules and model pull the result in different directions—threshold tuning and conflict review on real frames are needed |
| Inspection with operator confirmation | High cost of a missed defect, rare classes, statistics needed for retraining | Limits line speed and requires a workstation; on a flow of several items per second it cannot keep up |
The limitations of the method should be acknowledged in advance: vision does not replace metrology, is sensitive to stability of lighting and optics, and the false trigger rate directly determines whether operators will trust the system.
Therefore, we always tie the choice of option to which defect is more expensive to miss and what rejection rate production is prepared for.
Implementation stages: audit, scheme, tuning, validation, handover
The workflow is built from the real flow, not from equipment selection: first we record which defects need to be caught and under what conditions they are visible at all, and only then select optics and light. Each step has a verifiable result, so the project does not stretch into an indefinite timeline.
- Line survey and collection of defective samples. We look at movement speeds, lighting variations, vibrations, contamination zones. In parallel, we build a library of good and defective samples—for rare defects this takes weeks.
- Scheme of fields of view and lighting. We select imaging points, angles, and illumination so that the defect contrasts with the background rather than blending into it. We coordinate mounts, dust protection, and service access.
- Defect labeling and tuning. We label samples by class—scratch, dent, lack of fusion, misalignment—train the model, and select the sensitivity threshold. Labeling errors are cheaper to catch on the bench than on the flow.
- Acceptance runs on the real flow. The system operates in observation mode for several shifts: we count misses and false triggers and bring them to an agreed level. The decision is made by numbers, not by a demo.
- Integration with the rejection unit. The signal goes to an ejector, lamp, or line stop with a delay such that defective product is removed before packaging.
- Handover and shift training. Operators receive instructions, review of disputed frames, and a procedure for actions when a new defect type appears; model retraining is described as a separate scenario.
Deliverable package: configurations, diagrams, procedures
Computer vision on the line does not live in a presentation but in a shift—so what matters is exactly what will remain with your engineers after launch.
We hand over a working package that can be used to operate the system, replicate it to neighboring lines, and retrain it without our involvement.
- Saved configurations—a profile for each product range: areas of interest, sensitivity thresholds, set of checks. Switching between products is done from the interface, without rebuilding.
- Equipment and lighting layout diagram—camera mounting, distance and angle to the conveyor, requirements for background and stray light. Using it, installation on a second line is repeated without "by eye" selection.
- Access rights matrix—who changes thresholds, who stops the flow, who only views statistics. Every threshold change is logged with author and time.
- Rejection logic description—which defects are critical, which are permissible, where the tolerance boundary is. Disputed cases are reviewed separately so the shift does not decide them on its own.
- Operator action procedure on trigger—how many parts to check manually, when to stop the line, whom to notify, and how to record false triggers.
- Retraining procedure—how to accumulate and label frames, how often to update the model, and how to validate a new version on a holdout set before putting it into operation.
Such a package makes the system predictable when a shift, supplier, or line relocation changes—and removes dependence on one person who "knows how everything is set up here."
Case: rejection on a packaging line—metrics before and after
Before: misses depended on the shift
Inspection on the packaging line was done by sampling: an operator looked at some boxes at the output, the rest went out with a "good" mark. The missed defect rate reached several percent, and the spread between shifts was twofold—the night shift missed noticeably more.
Each such batch came back as a claim, and the review took up to half an hour per case: pull the inspection log, find the frame, restore who saw what.
What was changed and what became
A camera station was installed at the packer output, and the model was trained on an archive of actually rejected batches, not staged frames: film scuffing, label misalignment, incomplete seam.
Labeling was accelerated with semi-automatic pre-labeling based on OpenCV—the operator only confirmed the defect type. The confidence threshold was selected so that disputed triggers did not stop the line but went into a separate queue with the frame and shift label.
The missed defect rate dropped to tenths of a percent, and the spread between shifts almost disappeared: the decision is made by the model, not by operator attention at the end of a night shift.
Reviewing a disputed trigger takes minutes—the frame, defect type, and operator decision are already in the inspection log, and retraining uses the same labels.
The number of claims per batch over a comparable period decreased severalfold: the dispute is resolved not by correspondence but by exporting from the log—you can see which frame, which shift, which decision.
Rollback to manual mode remains for each defect type: if the model comes into disagreement with the process engineer, the threshold is raised, and the line operates under the previous procedure.
What to do if an inspection system is already installed on the line
Upgrading an existing system is usually possible if the camera image is reproducible and the defect is physically visible in the current angle and spectrum.
We start not with the model but with an audit of fields of view: part obstruction by tooling, glare, stray light from neighboring lamps, vibration, and positioning play.
Until the scene is stabilized, re-tuning thresholds gives a fluctuating result—errors move between shifts and batches.
We look at labeling separately. Errors are more often not in the network architecture but in it: different labelers assign the same defect to different classes, borderline cases are thrown out, classes are visually indistinguishable.
Rebuilding the labeling with a unified procedure and a validation set removes some false triggers without changing the algorithm.
Threshold re-tuning is a task with two error costs: a defect reaching the client and a false line stop. We select the threshold on a holdout set, separately for each zone and defect class, not one value for the entire line.
Replacement is justified when the defect is not physically visible: wrong angle, insufficient contrast, no illumination for the required defect type, line built on a closed platform such as Cognex without access to settings.
Then we compare replacing cameras and illumination with upgrading based on metrics on an archive of recorded images—separately by shifts and batches.
Technical doubts: lighting, labeling, false triggers
Engineering objections surface not in a demo but in operation: how the model will behave when the raw material batch changes, how many frames need to be labeled to reach working accuracy, what to do if the inspection unit fails.
None of these scenarios requires rebuilding the solution from scratch—each has a procedure: batch calibration, confidence threshold by defect class, backup circuit, and relabeling queue.
Will the model "drift" when the raw material batch changes?
Surface texture and gloss shift the features, and accuracy drops. The reference sample of the batch is compared with statistics from previous ones: if there is a discrepancy, the system itself signals drift, and calibration takes several dozen frames instead of retraining. The growth of false triggers is immediately visible by the confidence threshold.
How much labeling is needed for working accuracy?
We count class coverage, not total volume: the starting set is several hundred frames per defect type, including borderline cases and good product. After that the set grows by itself—the operator sends disputed frames to the relabeling queue, and retraining runs on the real flow.
What happens if the inspection unit fails?
The system reports camera or module unavailability and switches the section to frame accumulation mode without a verdict: product moves under the current procedure, not a false "all good." After recovery, the frames are re-run.
How is a new defect type added?
We label samples and retrain the model while preserving the old set so that already working classes do not degrade. Before release, we run the retrospective set and compare verdicts with the previous configuration.
Let's discuss the task: where work on the line begins
To avoid building defect detection on assumptions, a minimum of input data is needed from your side at the start.
We request it before kickoff: then the timeline estimate relies on the real picture of the section, not on averaged assumptions, and the first run on the line does not turn into rework of an already agreed model.
What is needed to start:
- Line description: sequence of operations, bottlenecks, product movement rate, and range of item dimensions.
- Defect samples: sets of images for each defect class plus images of good product—they are used to tune the trigger threshold.
- Acceptance requirements: which defects must not be missed, which are permissible, what share of misses and false triggers is considered working.
- Imaging conditions: camera mounting points, nature of lighting and its change during a shift, vibrations, network access at the section.
- Operator procedure: what happens on a signal—conveyor stop, item diversion, or a mark in the shift log.
- Test batch and run window: time when the line can be occupied for setup without loss of output.
- Person responsible for acceptance on your side: the person who confirms criteria and labeling of disputed cases.
Describe the task—we will return with an estimate and work plan: stages, duration of each, what we do and what is required from you at each step.
