Machine vision is not a camera with a model bolted on. It is an end-to-end pipeline — lighting, optics, fixturing, capture timing, and inference — where the image is formed long before any model gets to look at it, and where the weakest link caps the accuracy you can ever reach. That distinction sounds pedantic until it costs you a pilot. Teams searching for “machine vision” routinely conflate the camera with the system. The reasoning goes: point a high-resolution sensor at the line, feed the frames to a model, read off the accuracy number, ship it. When that pilot underperforms, the instinct is to retrain the model on more data. But if the defect was never rendered visible by the lighting and optics in the first place, no amount of training recovers it. You are tuning a classifier on images that do not contain the information you need. This article explains how machine vision actually works as an industrial inspection system — and why understanding the pipeline is the precondition for judging whether a given defect class is feasible at all. How Does Machine Vision Work in Practice? A working definition: machine vision is the use of imaging hardware and software together to make an automated decision about a physical object — pass/fail, present/absent, measure-and-compare — fast enough and reliably enough to act on a production line. The phrase “hardware and software together” is doing real work in that sentence. The decision quality is set by the whole chain, not the model alone. A useful way to think about it is that the image-formation stages decide what information exists in the frame, and the inference stage decides what to do with the information that survived. A model cannot recover detail that the optics blurred or that the lighting failed to expose. In our experience working on industrial CV systems, the single most common cause of a stalled inspection project is a defect class that the image-formation layer never rendered — a hairline crack that only appears under raking light, a transparent contaminant invisible without polarised illumination, a sub-pixel dimensional deviation that the chosen lens resolution simply cannot resolve. These are not model problems. They are physics problems that masquerade as model problems until someone instruments the pipeline. What Are the Components of a Machine Vision Pipeline? The pipeline runs in a fixed order, and each stage constrains everything downstream of it. Stage What it controls What it caps if done wrong Lighting Whether the defect feature produces contrast against the background at all A defect with no contrast is invisible to every downstream stage Optics (lens) Spatial resolution, depth of field, distortion, working distance Resolution sets the smallest feature size you can measure; a soft lens blurs sub-pixel detail permanently Sensor Pixel count, dynamic range, frame rate, colour vs. mono Under-resolved sensors throw away detail the optics delivered Fixturing & timing Part position, orientation, motion blur, capture trigger Inconsistent presentation injects variance the model reads as defects (false positives) Capture / acquisition Exposure, gain, synchronisation with the conveyor Mistimed capture smears moving parts; wrong exposure clips the feature Inference (model) Classification, localisation, measurement on the formed image Only as good as the information the prior stages preserved Read that table top to bottom and the central claim falls out: the image is formed before the model ever sees it, and the model’s ceiling is set by the lighting and optics, not by its own architecture. That is the one idea most “machine vision software” marketing quietly skips, because it is inconvenient to a software-only sale. If you want the hardware side of this in more depth — sensor formats, lens selection, illumination geometry — we cover how a machine vision camera works in industrial inspection as a focused companion to this overview. This article stays at the system level: how the stages compose, and where feasibility is decided. How Is Machine Vision Different from General Computer Vision? People use “machine vision” and “computer vision” almost interchangeably, and the overlap is real — both run on the same families of algorithms, and a modern inspection model is often a convolutional or transformer-based network trained in PyTorch or exported to ONNX for deployment. The difference is not the math. It is the system boundary. General computer vision typically takes an image as a given — a photo from a phone, a frame from a video stream — and asks what is in it. The imaging conditions are uncontrolled and treated as noise to be made robust against. Machine vision controls the imaging conditions deliberately, because on a production line you own the lighting, the fixture, the working distance, and the trigger. That control is the whole advantage: a defect that is hopeless under arbitrary lighting becomes trivially separable under the right illumination geometry. So “a camera with a model bolted on” is the failure mode, not the definition. Bolting a general-CV model onto an uncontrolled image throws away the one degree of freedom that makes industrial inspection tractable. This is why off-the-shelf vision components stop working at the boundaries we describe in where off-the-shelf CV stops working in manufacturing — the gap is almost always in image formation and edge-case handling, not in the model zoo. Why Does Image Formation Cap the Accuracy Any Model Can Reach? This is the load-bearing claim of the whole article, so it is worth stating precisely. A model can only separate classes that are separable in the data it receives. If the lighting and optics fail to produce contrast for a defect, the defect and the good part map to the same — or overlapping — regions of the input space. No decision boundary exists that separates them, because the information was destroyed at capture. A concrete illustration, framed as an assumption: suppose a hairline surface crack produces strong contrast only under low-angle raking light, and the line is lit with flat diffuse illumination. In configurations like this, the crack contributes almost no signal to the frame — the cracked and uncracked surfaces are nearly identical pixel-for-pixel. A model trained on those frames will plateau at a detection rate driven by whatever incidental cues leak through, not by the defect itself. Add more training data and the plateau holds, because every new image has the same missing information. The practical consequence: the variables that move detection rate most are upstream of the model. Fixing lighting and fixturing is usually cheaper and faster than over-tuning a model that can never see the defect — and it is the difference between a feasible inspection task and an impossible one. That economic point is why understanding the pipeline pays before you spend on a pilot, and it is the reasoning a feasibility assessment runs before any pilot commitment is designed to surface. How Do You Tell Whether a Defect Class Is Even Visible to the System? Here is a diagnostic checklist you can run before committing to a machine-vision project. It is deliberately about image formation, because that is where feasibility is decided. Can you produce visible contrast for the defect by hand? Under controlled lighting, can a human reliably see the defect in a still frame? If not, no model will. (observed-pattern — consistent across the industrial-CV engagements we have run; not a benchmarked rate.) Does the smallest defect exceed the resolvable feature size? Compute the millimetres-per-pixel the optics + sensor deliver at the working distance. If the defect is smaller than a few pixels, you cannot measure it reliably. Is part presentation repeatable? If parts arrive at varying position, orientation, or distance, fixturing variance becomes false-positive noise the model cannot distinguish from real defects. Is capture synchronised with line motion? Moving parts under the wrong exposure or trigger smear; the defect’s edges blur below detectability. Is there a lighting geometry that separates defect from background? Raking, backlight, coaxial, polarised, multi-spectral — if none of these produces separation, the defect class may be infeasible with conventional imaging. If a defect class fails items 1, 2, or 5, you have a physics problem, not a software problem — and that is the most valuable thing to learn before a pilot, not after. The end-to-end practical explainer of how computer vision systems for manufacturing work walks each stage in more depth if you need to brief a wider team. What Types of Machine Vision Systems Exist, and What Drives the Choice? The inspection task drives the system geometry. The four families below are the common ones; the choice is rarely about preference and almost always about what the part and the defect demand. Type What it captures Typical task 1D A single line profile, often over time Continuous web/sheet inspection — paper, film, extrusion — where a single scanned line detects streaks or breaks 2D area-scan A full 2D image in one exposure Discrete part inspection — presence/absence, surface defects, print verification on stationary or indexed parts Line-scan Builds a 2D image one line at a time as the part moves High-resolution inspection of continuously moving product (rolls, conveyors) where a single area-scan frame would lack resolution 3D Depth/height information Dimensional measurement, warpage, fill level, coplanarity — anything where the defect is geometric rather than appearance-based A useful heuristic: if the defect is an appearance (scratch, stain, missing print), a 2D or line-scan system usually suffices; if the defect is a shape (dent, height deviation, missing volume), you need 3D, because a 2D image of a height defect may show no contrast at all. Getting this wrong is another way to land in the “model can’t see it” trap — a 2D system pointed at a geometric defect is the same impossibility as flat lighting on a crack. What machine vision software actually does, then, is narrower than the marketing implies: it runs inference and decision logic on a frame whose informational content was already fixed by the hardware. The hardware decides what is visible; the software decides what to call it. Conflating those two is the root of most stalled pilots. FAQ How does machine vision work, and what does it mean in practice? Machine vision is the use of imaging hardware and software together to make an automated pass/fail or measurement decision about a physical object, fast and reliably enough to act on a production line. In practice the decision quality is set by the whole chain — lighting, optics, sensor, fixturing, capture, and inference — not by the model alone, because the image-formation stages decide what information exists in the frame before any model looks at it. What are the components of a machine vision pipeline — sensor, lighting, optics, and inference? The pipeline runs in a fixed order: lighting produces contrast for the defect, optics set spatial resolution and depth of field, the sensor captures the formed image, fixturing and timing control how the part is presented, acquisition handles exposure and synchronisation, and inference makes the decision. Each stage constrains everything downstream of it, so a weak link early in the chain caps everything that follows. How is machine vision different from general computer vision or a camera with a model bolted on? Both run on the same algorithm families, but the system boundary differs. General computer vision takes an uncontrolled image as given; machine vision deliberately controls lighting, fixturing, working distance, and trigger, because on a line you own those variables. Bolting a general-CV model onto an uncontrolled image — “a camera with a model” — discards the one degree of freedom that makes industrial inspection tractable. Why does image formation (lighting and optics) cap the accuracy any model can reach? A model can only separate classes that are separable in the data it receives. If lighting and optics fail to produce contrast for a defect, the defect and the good part overlap in the input space and no decision boundary can separate them, because the information was never captured. Adding training data does not help, since every new frame has the same missing information. What does machine vision software actually do versus what the hardware decides? The hardware — lighting, optics, sensor, fixturing — decides what is visible in the frame. The software runs inference and decision logic on that already-formed image and decides what to call it. The software’s accuracy ceiling is fixed by the information the hardware preserved, which is why over-tuning a model rarely fixes a defect the imaging never rendered. How do you tell, from how machine vision works, whether a defect class is even visible to the system? Run an image-formation check before committing: can a human see the defect under controlled lighting in a still frame; does the smallest defect exceed the resolvable feature size; is part presentation repeatable; is capture synchronised with line motion; and is there a lighting geometry that separates defect from background. Failing the contrast, resolution, or lighting items signals a physics problem rather than a software one. What are some real-world examples of machine vision in industrial inspection, and what defect classes does each address? Common examples include surface-defect inspection (scratches, stains, cracks) using raking or polarised lighting for appearance defects, print and label verification using 2D area-scan, continuous web inspection using 1D or line-scan for streaks and breaks, and dimensional or coplanarity checks using 3D systems for geometric defects. The defect type — appearance versus shape — drives which imaging geometry can render it. What types of machine vision systems exist, and how does the inspection task drive that choice? The common families are 1D (single line profile, for continuous web inspection), 2D area-scan (full image, for discrete-part surface and presence checks), line-scan (builds a 2D image as the part moves, for high-resolution moving product), and 3D (depth, for geometric defects). The rule of thumb: appearance defects suit 2D or line-scan, while shape defects require 3D, because a 2D image of a height deviation may carry no contrast at all. Where This Leaves the Feasibility Question The reason to understand how machine vision works is not academic. It tells you which variables move detection rate before you spend on a pilot — and it lets you draw the line between a defect class that conventional imaging can render and one that it cannot. Once a system reaches the line, that same image-formation and inference chain is what the production-reliability artefacts for industrial CV inspection have to instrument and keep honest over time. If you are weighing a vision-inspection project, the most useful first move is rarely choosing a model. It is cataloguing each defect class against the image-formation stages above and asking, for each one, whether the lighting and optics can render it at all. That cataloguing is exactly what a vision-pipeline feasibility audit does — and you can see how we frame that work on our computer vision and services pages.
