Machine vision and computer vision are not synonyms, and conflating them turns inspection-system procurement into a coin toss. Machine vision is a rule-based, hardware-specific inspection stack — Keyence, Cognex, Basler cameras, deterministic filters running on a PLC or embedded PC. Computer vision is a learned, generalisable software discipline — convolutional networks and, increasingly, vision transformers running on GPUs or accelerators. The distinction matters because each one fails differently in production, and the failure mode determines which approach belongs on which line. The short version: machine vision wins when the part, the lighting, and the defect class are fixed and the auditor needs a deterministic pass/fail trail. Computer vision wins when variation is the point — surface defects that don’t repeat, mixed SKUs, or assemblies that change with each customer order. Most real plants need both, but the hybrid only works if the boundary between them is drawn deliberately rather than by accident. What is machine vision, and how does it differ from a custom computer vision system? Machine vision is an integrated system: industrial camera, controlled lighting, a deterministic image-processing pipeline, and an I/O channel that ejects bad parts. The software runs simple, auditable operations — thresholding, blob analysis, edge templates, barcode and OCR decoders, dimensional measurement against a CAD reference. The pipeline is configured once, validated against sample parts, and then expected to behave identically for years. Cognex In-Sight, Keyence CV-X, MVTec HALCON, and Matrox Imaging Library sit in this category. A custom computer vision system inverts the assumption set. Instead of writing rules, we train a model — typically a CNN, increasingly a transformer — on labelled examples of what acceptable and unacceptable look like. PyTorch and ONNX dominate the training side; TensorRT and OpenVINO handle deployment to NVIDIA Jetson or Intel hardware at the edge. The model generalises across lighting and viewpoint variation that would break a rule-based filter, but it introduces a different problem: the decision logic is no longer inspectable line by line, and validation becomes statistical rather than deterministic. In our experience across manufacturing engagements, the gap between the two is widest on auditability. A machine vision system can be re-validated by replaying the pipeline against archived images and showing identical output. A computer vision system requires a held-out test set, confusion matrices, and a model-governance trail. Quality teams that have built their auditing process around the first model find the second one uncomfortable until they rebuild the process around it. When does a Keyence- or Cognex-style machine vision system beat a custom CV deployment? There are five conditions where the rule-based stack is the right answer, and they tend to co-occur: Variation is engineered out of the scene. Fixed jigging, controlled lighting (often telecentric or coaxial), and a single part type per line. The defect classes are enumerable. Missing component, wrong colour, dimension out of tolerance, barcode unreadable. Not “anything that looks subtly wrong.” Throughput requires deterministic latency. Inspection cycle ≤ 50 ms with a hard ceiling, not a 95th-percentile target. Auditability is a contractual requirement. Regulated industries — automotive safety-critical parts, pharma, aerospace — where the inspection logic itself must be reviewable. The maintenance team is electrical or controls engineers, not ML engineers. They will own this system for ten years; the tooling has to match the staff. When four or five of these hold, a Keyence or Cognex deployment will outperform a custom CV system on every operational metric that matters, and it will cost less to maintain. This is not a benchmarked rate across all plants — it is the pattern we see when the decision is made deliberately. The decision framework The five factors that determine the choice, in order of weight: Factor Push toward machine vision Push toward computer vision Variation in scene Low — fixed jig, fixed lighting High — mixed SKUs, ambient light, varied orientation Defect type Enumerable, geometric, measurable Subtle, novel, surface-level, “looks wrong” Throughput ceiling Hard real-time (deterministic) Soft real-time (statistical SLA) Auditability requirement Regulated, per-decision review Statistical validation acceptable Maintenance team Controls / automation engineers ML / data engineering capability available Score each factor against your actual line. If four or more push the same direction, the answer is unambiguous. If the factors split, you are looking at a hybrid architecture — and the hybrid only works if you draw the routing boundary explicitly rather than letting it emerge. Hybrid architectures: the routing boundary matters A hybrid vision system runs both pipelines against the same image stream and routes decisions by case. The common pattern is a fast deterministic filter handling the bulk of throughput, with a learned model inspecting only the uncertain cases or a specific defect class. This is not “machine vision plus a sprinkle of AI” — the routing logic is itself an engineering decision that affects throughput, audit trail, and false-positive rate. A car parts manufacturer we worked with needed both high-speed dimensional inspection and flexible defect detection. The machine vision module checked part dimensions and painted-surface continuity at 500 units per minute using edge detection and blob analysis. A CNN running on a Jetson then screened roughly one part in ten for subtle surface cracks that the rule set could not specify — the kind of defect that emerges from process drift rather than a known failure mode. Flagged items routed to manual review. In that engagement, hybrid routing cut defect escape by roughly 80% without slowing the line. This is a project-specific outcome on a single deployment, not a benchmark for the architecture class. The point worth generalising: the hybrid wins when the slow path is statistically rare. If the CNN ends up inspecting 60% of parts because the rule-based filter cannot decide, the architecture is no longer hybrid — it is a slow CV system with a deterministic preamble. How much does a vision inspection system cost across the two paths? Capital cost is the wrong frame. Both stacks have a hardware cost (cameras, lighting, compute), an integration cost (calibration, fixturing, software configuration), and a lifecycle cost (maintenance, drift correction, retraining). The shapes differ: A machine vision deployment front-loads cost into hardware and integration. Once the line is validated, ongoing cost is low — lens cleaning, lighting checks, periodic recalibration. The integration cost dominates the first year. A computer vision deployment front-loads cost into data — labelling thousands of images, building a validation set, setting up monitoring. The integration cost is lower but never goes to zero, because models drift as the production environment drifts. MLOps is a permanent line item. The procurement path differs as well. Machine vision is a vendor purchase with a system integrator — Keyence, Cognex, and their channel partners do this end-to-end. Custom computer vision is an engineering engagement, either internal or with a partner who owns the model lifecycle. The wrong procurement path applied to the right approach is its own failure mode: trying to buy custom CV like a Cognex system, or trying to spec a Keyence deployment like an ML project, both produce systems that nobody can maintain. Is computer vision AI/ML, and does the answer change the procurement path? Computer vision is one application domain within machine learning. CNNs, vision transformers, segmentation models like SAM, and detection architectures like YOLO are all learned models trained on labelled data. So the answer to the first half is yes — modern computer vision is AI/ML. Whether that changes the procurement path depends on what you are buying. A pre-trained, packaged inference product (a vendor’s defect-classification appliance) procures more like machine vision than like an ML engagement. A bespoke model trained on your data, deployed on your hardware, with a retraining cycle owned by your team — that procures like custom software development with an ML lifecycle attached. Asking “is this AI?” is less useful than asking “who owns the model after deployment?” Production constraints that push the decision Latency, lighting, and throughput each push the decision in distinct ways: Latency. Hard real-time ceilings — under 20 ms with no tail — favour machine vision. Soft SLAs with 95th-percentile targets accommodate CV inference, especially with TensorRT optimisation, INT8 quantisation, and pruning. Lighting control. If you can engineer the lighting, machine vision becomes much stronger because the rule set sees a stable scene. If lighting is mixed or ambient, the rule set fragments and CV’s invariance to illumination is the deciding factor. Throughput. Above ~1000 parts per minute with deterministic cycle time, machine vision is usually the only path. Below that, the CV path is open if the other factors permit. These are operational considerations we apply on each engagement, not universal thresholds. The numbers shift with hardware generation — a Jetson Orin can do things a Jetson Nano could not — but the structure of the trade-off is stable. What to measure before deciding Before committing to either path, three measurements are worth making on the actual line, not the spec sheet: Defect class entropy. Pull 500 historical defects and classify them. If 90% fall into five named categories, machine vision can probably handle it. If the long tail is dominated by “operator marked it as a defect but cannot describe the rule,” that is a CV problem. Lighting variance. Photograph a fixed reference part across a full shift, including operator-induced variation. If the histograms are stable, machine vision will hold. If they drift visibly, the rule set will need constant tuning. Cycle-time headroom. Measure the actual inspection budget, not the line speed. A 200-ppm line with a 100 ms inspection window is a different problem from a 200-ppm line with a 15 ms window. These measurements feed into the decision framework table above. They also become the validation baseline for whichever system you choose — the choice itself is documented, and the system can be audited against the conditions that justified it. For the deeper structural argument, see our decision framework for choosing between machine vision and custom CV in manufacturing. For the QC-system view, see computer vision for quality control in manufacturing. FAQ Machine vision vs computer vision: which inspection approach fits my manufacturing line? Score your line against five factors: scene variation, defect type, throughput ceiling, auditability requirement, and maintenance team skillset. If four or more push toward enumerable defects in a controlled scene with hard real-time and audit requirements, machine vision fits. If they push toward variation and subtle defects with statistical SLAs, computer vision fits. Mixed scores mean a hybrid with an explicit routing boundary. What is machine vision, and how does it differ from a custom computer vision system? Machine vision is a deterministic, rule-based inspection stack with industrial cameras, controlled lighting, and auditable image-processing pipelines on embedded hardware. A custom computer vision system uses learned models — CNNs or transformers — trained on labelled data and deployed on GPU or accelerator hardware. The first is inspectable line by line; the second is validated statistically. When does a Keyence/Cognex-style machine vision system beat a custom CV deployment? When variation is engineered out of the scene, defect classes are enumerable, throughput requires deterministic latency, auditability is contractual, and the maintenance team is controls engineers rather than ML engineers. When four or five of these hold, the rule-based stack outperforms custom CV on operational metrics and costs less to maintain. How much does a vision inspection system cost across machine-vision versus custom-CV options? The two paths have different cost shapes. Machine vision front-loads cost into hardware and integration, then runs cheap. Custom computer vision front-loads cost into labelled data and validation, with permanent MLOps costs for monitoring and retraining. Vendor procurement (Keyence, Cognex) differs from custom engineering engagements — the wrong procurement path applied to the right approach produces unmaintainable systems. Is computer vision AI/ML, and does the answer change the procurement path? Modern computer vision is a domain within machine learning. Whether that changes procurement depends on what you are buying: a packaged inference product procures like machine vision, while a bespoke model with a retraining cycle procures like custom software development with an ML lifecycle. The useful question is “who owns the model after deployment?” Which production constraints (latency, lighting, throughput) push the decision one way or the other? Hard real-time ceilings under 20 ms favour machine vision; soft SLAs accommodate CV inference. Engineered lighting favours machine vision; mixed ambient light favours CV’s invariance to illumination. Throughputs above ~1000 parts per minute with deterministic cycle time usually require machine vision; lower throughputs leave the CV path open.
