A camera and a model that flags defects. That is the picture most teams carry into a computer-vision project, and it is the picture that quietly sinks pilots. A manufacturing CV system is not a classifier with one accuracy number — it is a pipeline, and any stage in that pipeline can be the limiting factor that decides whether the system works on your line at all. Search “computer vision systems for manufacturing” and you will find a lot of material that reinforces the camera-plus-model mental model. It is not wrong so much as incomplete in the way that matters most. The accuracy figure quoted in a vendor demo was measured under one set of conditions — fixed lighting, clean fixturing, a curated defect set. Your conveyor, your part presentation, and your defect catalogue are different. The gap between those two worlds is where projects fail, and it is almost never in the model. This explainer walks the actual pipeline, stage by stage, and shows where the real constraints live. The goal is pipeline literacy: enough understanding to ask the right feasibility questions before committing budget to a pilot. If you want the decision framework that sits on top of this — the go/no-go logic — that lives in our explainer on when industrial computer vision inspection actually works. This article is the layer underneath it. What Does a Manufacturing CV System Actually Consist Of? When we say “pipeline,” we mean a chain of stages where the input to each one is the output of the last. A defect either survives the whole chain to be correctly flagged, or it gets lost at some stage long before the model ever sees it cleanly. Here is the chain, in the order a part travels through it. The imaging stage — controlled lighting, optics, and a camera positioned to make the defect visible. This is the stage most teams underweight and the one that most often decides the outcome. The fixturing and presentation stage — how the part is held, oriented, and moved past the camera. A part that rotates, tilts, or sits at variable distance presents a different image every time, and the model has to absorb that variance instead of spending its capacity on the defect. The defect-class catalogue — the explicit list of what counts as a defect, with examples of each class. A CV system can only detect classes it was trained on. This catalogue is a design artifact, not a detail. The trained model — the component everyone pictures. It maps an image to a prediction. It is one stage of five, not the system. The decision threshold — the rule that turns a model score into an accept/reject action, tuned against the throughput the line actually runs at. The OpenCV-and-PyTorch part of this — the model — is the most mature and the least likely to be your bottleneck. The hard parts are physical and definitional: light, motion, and the question of what a defect even is. Why Does Lighting and Fixturing Matter as Much as the Model? Here is the claim that surprises teams new to industrial vision: the imaging and fixturing stages frequently determine system performance more than the model architecture does. A flawless defect-detection model fed inconsistent images cannot recover information that was never captured. Consider a scratch on a brushed-metal surface. Under diffuse front lighting it is nearly invisible — the scratch and the surrounding finish reflect light the same way. Under low-angle grazing illumination, the scratch casts a shadow and pops out at high contrast. The defect is physically identical in both cases. The information available to the model is not. No amount of training data fixes a lighting geometry that fails to render the defect in the first place. Fixturing compounds this. If the part’s position varies run to run — because the conveyor jitters, or the part isn’t seated consistently — every captured image differs in scale, angle, and framing. The model now has to be invariant to all that variance and sensitive to a sub-millimetre defect. In practice it learns the easy invariances and loses the hard sensitivities. Tightening the fixturing is usually cheaper and more reliable than throwing model capacity at the problem. This is the long-tail variance problem at the heart of the matter. A demo runs on a few hundred clean images. A production line runs millions of parts under shifting ambient light, accumulating dust on lenses, and degrading LED illuminators. The stage where that variance is controlled — or not — is the imaging stage, which is why we treat camera, optics, and lighting selection as a first-class engineering decision rather than a procurement afterthought. The mechanics of that decision are covered in detail in our explainer on how a machine vision camera works in industrial inspection. What Does an Accuracy Number Actually Mean on a Production Line? This is where the naive mental model does the most damage. A single accuracy figure — “98% accurate” — collapses several distinct quantities into one number that means almost nothing for a production decision. On a line, you care about two error types separately, because they have completely different costs: Missed defects (false negatives) — defective parts that pass inspection. These reach the customer. The cost is warranty, recall, and reputation. False alarms (false positives) — good parts flagged as defective. These get pulled, re-inspected manually, or scrapped. The cost is throughput, labour, and yield. A system tuned to catch nearly every defect will flag more good parts; a system tuned to rarely false-alarm will miss more defects. There is no single point that is “accurate” — there is a trade-off curve, and where you sit on it is a business decision tied to the relative cost of each error type for your product. The throughput dimension makes this sharper. Suppose a line runs parts at a rate that gives the system a fixed time budget per inspection. The decision threshold has to deliver an acceptable false-positive rate at that throughput — not at the leisurely pace of a demo. A false-positive rate that looks fine on a per-part basis can generate an unmanageable flood of manual re-inspections once you multiply it by tens of thousands of parts per shift. So when a vendor quotes an accuracy number, the right questions are: accurate on whose defect set, at what false-positive rate, and at what line speed? Those three qualifiers turn a marketing figure into something you can actually scope against. The cost comparison that follows — CV inspection versus manual inspection — only becomes meaningful once the accuracy claim is decomposed this way. A Quick Diagnostic: Is This Accuracy Number Decision-Grade? Run any quoted CV accuracy figure through these checks before you trust it for a pilot decision. Question Decision-grade answer looks like Red flag On whose defect set? Measured on your defect-class catalogue and part images A generic or vendor-curated dataset Which error type? Separate false-negative and false-positive rates A single blended “accuracy %” At what throughput? False-positive rate stated at your line speed Rate measured offline or per-image Under what imaging? Same lighting/fixturing you’ll deploy Lab conditions, controlled rig Across what variance? Tested over shifts, ambient light, lens ageing A single clean capture session If most answers fall in the right column, the number is a demo artifact, not a production estimate. (Observed pattern across TechnoLynx industrial-CV engagements; not a published benchmark.) How Does the Defect-Class Catalogue Shape What the System Can Detect? A CV system detects the classes it was trained to detect. That sentence sounds obvious and is routinely ignored. The defect-class catalogue — the explicit, exampled list of defect types — is the contract between what you think the system does and what it actually does. If your catalogue contains “surface scratch,” “dent,” and “missing component,” the system will be built and validated around those three. A novel defect type — a discolouration mode that nobody enumerated, a contamination class that emerged after a supplier change — is, to the model, simply an unfamiliar good part or an out-of-distribution input it has no reliable behaviour for. It will not be caught because it was never defined. This is why the catalogue is a design decision made early, with the people who actually know the failure modes of the product. It also shapes data collection: each class needs enough examples, ideally spanning the natural variation within the class, for the model to learn it. Rare defect classes are genuinely hard — you cannot train robustly on a defect you only see a handful of times a year. Recognising which classes are well-represented and which are long-tail is part of scoping feasibility honestly. The boundary cases — where the catalogue itself is the reason off-the-shelf CV stops working — are explored in our piece on where off-the-shelf CV stops working in manufacturing QC. Does Machine Vision Differ from Computer Vision Here? The terms get used interchangeably, and the distinction is more about lineage than a hard technical boundary. “Machine vision” traditionally refers to the rule-based, deterministic inspection systems that have run on factory lines for decades — measuring dimensions, checking presence/absence, reading barcodes with classical image-processing operations. “Computer vision” in the modern sense usually implies learned models — convolutional networks or transformer-based detectors trained on examples. In a manufacturing inspection context, the practical difference is this: classical machine vision excels at well-defined, geometric, high-contrast checks where you can write down the rule (is this hole 5mm ± 0.1mm? is this label present?). Learned computer vision earns its keep on defects that are hard to specify with a rule — irregular surface flaws, subtle texture anomalies, variable-appearance defects — where you have examples but not a formula. Does the distinction change how you scope a pipeline? Yes, at one stage: the model stage. If your defect set is rule-expressible, a deterministic machine-vision approach is often more reliable, more interpretable, and cheaper to maintain than a trained model — and you should not reach for deep learning by default. If your defects resist specification, a learned model is the right tool, with all the data and validation burden that implies. Every other stage of the pipeline — imaging, fixturing, the defect catalogue, the throughput-bounded threshold — is identical regardless of which you choose. The deeper treatment of the term itself lives in our explainer on what machine vision is and how it works in industrial inspection. FAQ How does computer vision systems for manufacturing work, and what does it mean in practice? A manufacturing CV system is a pipeline, not a single classifier: controlled imaging, part fixturing and presentation, an explicit defect-class catalogue, a trained (or rule-based) model, and a decision threshold tuned to line throughput. In practice it means a defect must survive every stage to be caught — and any one stage can be the limiting factor, most often the physical imaging stage rather than the model. What are the stages of a manufacturing CV inspection pipeline, from imaging to decision? Five stages in sequence: imaging (lighting, optics, camera), fixturing and part presentation, the defect-class catalogue that defines what counts as a defect, the trained model that maps image to prediction, and the decision threshold that turns a model score into an accept/reject action at the line’s throughput. The model is one stage of five, not the system. Why does lighting and fixturing matter as much as the model itself? Because a model cannot recover information that was never captured. Lighting geometry decides whether a defect is even visible — a scratch invisible under diffuse light pops under grazing illumination. Inconsistent fixturing forces the model to absorb position and scale variance instead of focusing capacity on the defect. Tightening these physical stages is usually cheaper and more reliable than adding model capacity. What does an accuracy number actually mean on a production line, and why can it mislead? A single accuracy figure collapses distinct quantities that have different costs: missed defects (false negatives) reach customers, while false alarms (false positives) cost throughput and yield. There is a trade-off curve, not one accurate point, and the false-positive rate must hold at your actual line speed. A demo’s accuracy number measured on a curated dataset rarely predicts production behaviour. How does a defect-class catalogue shape what a CV system can and cannot detect? A CV system can only detect classes it was trained on. The defect-class catalogue is the explicit, exampled list of defect types and acts as the contract between expected and actual behaviour. A defect type nobody enumerated will not be caught, and rare classes are genuinely hard to train robustly — so recognising which classes are well-represented versus long-tail is core to honest feasibility scoping. What questions should a team answer before assuming an off-the-shelf CV system will work on their line? Decompose any accuracy claim: on whose defect set, separating false-negative and false-positive rates, at what line throughput, under what lighting and fixturing, and across what real-world variance (shifts, ambient light, lens ageing). If those answers come from lab conditions and a single clean capture session, the number is a demo artifact rather than a production estimate. How does machine vision differ from computer vision in a manufacturing inspection context, and does the distinction change how a team scopes a pipeline? Machine vision traditionally means rule-based, deterministic inspection (dimensions, presence/absence, barcodes); computer vision usually implies learned models trained on examples. The distinction changes only the model stage: rule-expressible defects favour classical machine vision, while defects that resist specification favour a learned model. Every other pipeline stage — imaging, fixturing, catalogue, threshold — is identical regardless. Where Pipeline Literacy Pays Off The reason any of this matters is that understanding the pipeline lets you ask feasibility questions in the right order, before money is committed. A team that knows imaging and fixturing dominate will photograph their own defects under candidate lighting before trusting any vendor number. A team that knows the catalogue is a contract will enumerate their defect classes honestly, including the long-tail ones. A team that knows accuracy decomposes into error types at throughput will scope cost against false-positive load, not a blended percentage. That literacy is also what makes a deployed system stay trustworthy once it is running — the same pipeline stages generate the reliability artefacts a line-side model needs, which our piece on the artefacts that keep an industrial-CV inspection line running covers in depth. And it is the foundation the feasibility audit builds on: we scope our computer vision inspection work and broader engineering services around exactly these questions, because the go/no-go decision is only as good as the pipeline understanding behind it. The honest closing question is not “how accurate is the model?” It is “which stage of my pipeline is the limiting factor — and have I measured it under the conditions my line actually runs?” Answer that before the pilot, not after.
