Two approaches, one inspection station

A manufacturing quality engineer evaluating inspection technology faces a choice with real production consequences. Traditional machine vision — rule-based, hardware-specific, configured with explicit parameters for illumination, geometry, and threshold — has been the standard for decades. AI-based computer vision — learned from data, adaptable to variation, capable of detecting defects that resist explicit rule definition — is the alternative. Both work. Both fail. The conditions under which each fails are different, and choosing the wrong approach for the wrong conditions produces either a system that is too brittle (machine vision applied to high-variation environments) or a system that is too opaque (computer vision applied to contexts that require deterministic auditability).

The decision is not a technology preference. It is a production engineering decision driven by defect complexity, environmental variation, regulatory context, and the capability of the team that will maintain the system after handover. Get any one of those wrong and the inspection station becomes a source of rework rather than a control point.

What does machine vision do well — and where does it break?

Machine vision systems operate on explicit rules. A camera captures an image. A lighting configuration optimised for the specific inspection task illuminates the target. Image processing algorithms — edge detection, blob analysis, template matching, geometric measurement, often running on libraries like OpenCV or vendor SDKs from Cognex and Keyence — extract features defined by the system integrator. A pass/fail decision is made against thresholds calibrated during commissioning.

The strengths are real. The system is deterministic (the same input produces the same output), auditable (every decision step can be traced to a configured parameter), and predictable (performance characteristics are known from commissioning). In regulatory environments — pharmaceutical manufacturing, aerospace, automotive safety-critical components — deterministic auditability is not a convenience, it is a compliance requirement. The traditional machine vision market is valued at roughly $14 billion (industry estimate, 2024; directional industry-scale figure, not an operational benchmark), reflecting decades of proven deployment in deterministic inspection tasks across millions of industrial stations globally.

The failure mode is equally clear. Machine vision breaks when inspection conditions vary beyond the configured parameters. A new product variant with different geometry requires reconfiguration. A lighting change — bulb degradation, ambient light intrusion, a reflective surface variation — shifts feature extraction and invalidates the calibrated thresholds. A defect type that does not match the configured rule set passes through undetected. Every unanticipated source of variation is a potential blind spot.

We see this pattern most clearly in mixed-product manufacturing lines, where the inspection station must handle multiple variants without manual reconfiguration for each changeover. Machine vision systems that perform excellently on a single product type accumulate complexity — and fragility — as the number of variants grows. At some point the rule tree becomes harder to maintain than the data pipeline a learned system would require.

What computer vision adds — and what it costs

AI-based computer vision learns inspection criteria from labelled examples rather than from configured rules. A convolutional neural network — trained in PyTorch or TensorFlow, often exported through ONNX for runtime deployment — develops feature representations directly from thousands of labelled defect and non-defect images. Those representations can generalise across variation that would break a rule-based system.

The strengths follow from how the representation is built. Lighting changes, product variant differences, novel defect types that fall within the learned distribution, and subtle defects that resist explicit rule definition — surface texture anomalies, colour gradients, complex shape deformations — are addressable through data rather than configuration. The system can be adapted to new conditions by retraining rather than by reconfiguring optics and thresholds, which for complex inspection tasks is often faster and more reliable. Industry survey reports and published case studies suggest AI-based visual inspection can reduce false rejection rates by 30–50% compared to traditional rule-based machine vision in high-variability environments (directional industry-scale figure, not a benchmarked guarantee; results vary by domain and implementation quality).

The costs are not trivial. Training data must be collected, labelled, and quality-assured — and in our experience across deployments, annotation inconsistency directly degrades model performance in ways that are hard to detect until production. The model is not inherently auditable: explaining why a specific unit was classified as defective requires explainability techniques (saliency maps, feature attribution) rather than inspection of a configured threshold. Model behaviour can change when retrained, so validation processes are needed that traditional machine vision’s static configuration does not require. And performance depends on training data quality in ways that are non-obvious until the model encounters production conditions the training data did not represent. Many of the same dynamics show up in our piece on why off-the-shelf computer vision models fail in production — the failure mode is rarely the model architecture itself, it is the gap between the data the model was trained on and the data the line actually produces.

The decision framework

The choice between machine vision and computer vision resolves through four factors. None of them is technology-flavoured; all of them are production engineering questions.

Factor	Points to machine vision	Points to computer vision
Defect complexity	Defects fully described by geometry, tolerance, presence/absence, barcode readability, fill level	Defects resist rule-based characterisation — surface texture, variable-shape contamination, subjective quality calls
Environmental variation	Fixed lighting, single product type, stable camera geometry	Multiple variants on one line, lighting that drifts across shifts, lot-to-lot appearance variation
Regulatory context	Deterministic auditability is a compliance requirement (pharma, aerospace, safety-critical)	Validation through documented acceptance criteria, monitoring, and change control is feasible
Maintenance capability	Team has optics, lighting, and image-processing expertise	Team has data engineering, model training, and monitoring capability — or a partner that does

Defect complexity is usually the first factor to consider, because it determines whether rule-based detection is even feasible. If defects can be fully characterised by geometric rules — dimensional tolerances, presence/absence checks, barcode readability, fill-level measurement — machine vision is typically sufficient and carries lower deployment and maintenance complexity. If defects resist rule-based characterisation, computer vision is likely necessary.

Environmental variation determines whether a rule-based system will hold its calibration over time. Fixed lighting and a single product geometry favour machine vision. Multiple variants, drifting illumination, and lot-to-lot appearance variation favour learned representations.

Regulatory context changes the bar for both approaches. Computer vision can meet regulatory requirements in pharma, aerospace, and automotive safety-critical contexts, but the validation pathway is more complex — the model’s behaviour must be documented through acceptance criteria, ongoing monitoring, and a change-control process that accounts for the model’s learned (rather than configured) decision logic. If the team has no appetite for that overhead, the regulatory factor pushes back toward machine vision even when the defects look learnable.

Maintenance capability determines feasibility after handover. Deploying a computer vision system without in-house or contracted ML capability creates vendor dependency; deploying a machine vision system without optics expertise creates the same problem in a different domain. The right question is not “which is better” but “which can the team that inherits this system actually maintain in three years”.

Is computer vision AI/ML, and does that change procurement?

In current usage, AI-based computer vision systems for inspection are built on machine learning — typically deep learning models trained on labelled image data. Traditional machine vision is not learned: it is rule-based image processing. The distinction matters at procurement because the contract structure, the deliverables, and the validation evidence differ.

A traditional machine vision procurement is usually a fixed-configuration system from a vendor like Cognex or Keyence, with the system integrator responsible for optics, lighting, and rule configuration. Acceptance is binary against a defined defect set. A computer vision procurement involves data collection, annotation, model training, validation against a held-out set, and an ongoing monitoring relationship — closer to an R&D engagement with outcome ownership than to a hardware purchase. Treating one as the other is a common procurement failure mode and a leading cause of stalled inspection projects.

The hybrid option

In practice, the optimal inspection architecture for complex manufacturing environments often combines both approaches. Machine vision handles the inspection tasks where rule-based detection is sufficient and deterministic auditability is required — dimensional checks, presence/absence verification, barcode and label validation. Computer vision handles the tasks where learned detection is necessary — surface defect classification, complex contamination detection, aesthetic quality assessment.

This hybrid architecture lets each technology operate in its strength zone. The integration point is the inspection station itself: both systems share the image acquisition infrastructure, and their results are combined in a unified quality decision that feeds the manufacturing execution system. The decision of which tasks to assign to each approach requires the same production engineering assessment — defect characterisation, environmental variation analysis, regulatory requirements mapping, and maintenance capability evaluation. If that assessment has not been done, the hybrid is just two systems running side by side without a coherent decision rule.

How much does a vision inspection system cost, and where does the money go?

Cost ranges vary widely enough that headline figures are usually misleading. A single-station traditional machine vision deployment for a well-defined inspection task — fixed product, fixed lighting, fixed defect set — sits in a known band shaped by camera, optics, lighting, and integrator time. A custom computer vision deployment carries a different cost shape: less hardware-dominated, more weighted toward data collection, annotation, model development, and validation infrastructure. Ongoing cost also differs in shape. Machine vision’s recurring cost is largely maintenance and recalibration. Computer vision’s recurring cost includes monitoring, retraining when the data distribution shifts, and the people or partner who own that loop.

The right way to compare is by total cost of ownership across the expected life of the system, including the cost of the inspection failures each approach is most likely to produce. A machine vision system that misses 2% of subtle surface defects has a different cost profile from a computer vision system that occasionally rejects good product because a lighting condition drifted outside the training distribution. Neither is uniformly cheaper.

Which production constraints push the decision?

Latency, throughput, and the physical realities of the line shape the decision before the model architecture does. A high-throughput inspection station with tens-of-milliseconds latency budget pushes toward optimised inference paths — TensorRT for NVIDIA edge hardware, quantised ONNX runtimes, or a rule-based pipeline that simply runs faster than any learned model would. The same article on deploying computer vision models on edge devices walks through the latency-and-hardware trade-offs in more depth; the short version is that the throughput target often forces the architecture choice before the defect set does.

Lighting and optics constrain both approaches. A learned model trained on images from a poorly designed optical setup inherits every weakness of that setup; a rule-based system trained on the same setup is at least transparent about which features it relies on. Neither approach makes bad optics work.

If the assessment of these constraints has not been done — if the choice between machine vision and computer vision is being made on technology preference rather than production requirements — a Production CV Readiness Assessment maps each inspection task to the appropriate approach and surfaces the constraints that will actually drive the architecture.

FAQ

Machine vision vs computer vision: which inspection approach fits my manufacturing line?

The answer is driven by four factors, not by technology preference: defect complexity, environmental variation, regulatory context, and maintenance capability. Defects that resolve to geometry, tolerance, or presence/absence checks point to machine vision. Defects that resist rule-based characterisation — surface texture, variable-shape contamination, subjective quality calls — point to computer vision. Most complex lines end up with a hybrid where each technology handles the tasks it is suited to.

What is machine vision, and how does it differ from a custom computer vision system?

Machine vision is rule-based image processing: a camera, a controlled lighting setup, and configured algorithms (edge detection, blob analysis, template matching) producing deterministic pass/fail decisions against calibrated thresholds. A custom computer vision system is learned: a model trained on labelled defect and non-defect images develops its own feature representations and classifies new images from that learned distribution. Machine vision is auditable and brittle to variation; computer vision is adaptive and harder to audit.

When does a Keyence/Cognex-style machine-vision system beat a custom CV deployment?

When the inspection environment is tightly controlled, the defect set is well-characterised by geometric rules, deterministic auditability is a regulatory requirement, and the maintenance team has optics and image-processing expertise rather than ML capability. Machine vision also wins when the throughput budget is tight enough that rule-based pipelines simply run faster than any feasible learned model. In those conditions the deployment and maintenance complexity of a custom CV system is overhead the line cannot justify.

How much does a vision inspection system cost across machine-vision versus custom-CV options?

Cost shape differs more than headline numbers. Traditional machine vision is hardware- and integrator-dominated, with recurring cost concentrated in maintenance and recalibration. Custom computer vision is weighted toward data collection, annotation, model development, validation infrastructure, and ongoing monitoring or retraining. The right comparison is total cost of ownership across the system’s expected life, including the cost of the inspection failures each approach is most likely to produce — neither is uniformly cheaper.

Is computer vision AI/ML, and does the answer change the procurement path?

Yes, current AI-based computer vision for inspection is machine learning — typically deep learning trained on labelled image data — while traditional machine vision is rule-based and not learned. The procurement path changes because the deliverables differ. A traditional machine vision purchase is closer to a configured hardware system with binary acceptance against a defined defect set. A computer vision deployment involves data collection, annotation, model training, validation, and an ongoing monitoring relationship. Treating one as the other is a common cause of stalled inspection projects.

Which production constraints (latency, lighting, throughput) push the decision one way or the other?

Tight latency and high throughput often push toward rule-based pipelines or heavily optimised inference (TensorRT, quantised ONNX) on edge hardware. Stable, controlled lighting favours machine vision; drifting illumination across shifts or lots favours learned representations. Multiple product variants on the same line push toward computer vision because reconfiguring rule-based thresholds for each variant accumulates fragility. Regulatory environments push toward whichever approach the team can validate and audit with the resources it actually has.

The decision is defensible when each factor has been examined against the specific line, not against the general category of “AI inspection” or “machine vision”. Skipping that step is what makes inspection projects fail after deployment rather than during commissioning.