Computer-Vision Quality Inspection: Five Myths

Walk any finishing line and you'll hear the same pitch from a vendor or a plant manager who just got back from a trade show: put a camera over the conveyor, point a model at it, and bad parts stop reaching the customer. The hardware is cheaper than it's ever been, the demos look clean, and the slide deck promises zero escapes. Some of that holds up. A well-built vision cell does see things an operator on the eighth hour of a shift will miss, and it sees them on every part, not a sampled handful.

The trouble is the gap between the demo and the line. Most of what goes wrong with computer-vision quality inspection isn't the neural network. It's the claims that get made around it. Here are five we hear most often, and what actually holds up once the cell is bolted to a real process.

"Install the camera and you'll catch every defect"

A vision system catches the defects it was built to catch, under the conditions it was built for. That's a narrower promise than "every defect," and the difference is where escapes live.

Two failure modes matter. A false reject throws away a good part. A false accept lets a bad one through. You can tune a system to be paranoid and reject anything marginal, but then your scrap and rework climb and the operators start overriding the call. Tune it the other way and the escapes return. There's no setting that drives both to zero, so the honest question isn't whether the system is perfect. It's whether its error rate beats the human baseline it replaces, and on which defect classes.

That baseline is worth respecting. Human visual inspection has been studied since the 1950s, and the picture is consistent: performance varies with the inspector, the defect, fatigue, and pacing, and it's modelled as two separate steps, search and decision, each with its own error (See, 2012). People are good at flagging the gross, obvious flaw and unreliable on the subtle one that shows up once a shift. A vision cell inverts that. It's relentless on the defect it knows and blind to the one nobody showed it. So the cell doesn't make inspection infallible. It moves the error from "tired human, variable" to "consistent machine, fixed blind spots," and a fixed blind spot is at least something you can find and close.

The phrase "trained to catch defects" hides a lot. A model learns a distribution of defect appearances from the examples it was shown, lit and presented the way the cell lights and presents them. Show it scratches and dents and it gets good at scratches and dents. Then a contamination type nobody anticipated comes down the line, looking nothing like the training set, and the model passes it without hesitation because, as far as it knows, the part is fine. The defect it can't catch isn't a bug in the network. It's a hole in the specification of what counts as bad, and that specification is human work. The useful discipline is to enumerate the defect classes you actually care about, confirm the imaging makes each one visible, and validate the cell class by class rather than trusting a single headline accuracy figure.

This is also why "one hundred percent inspection" gets oversold. Inspecting every part is genuinely better than sampling for catching the rare, scattered defect. But total inspection that runs at, say, eighty or ninety percent detection on a given flaw isn't the same as a guarantee, and acceptance-sampling theory has said so for decades. Under ISO 2859-1, the sampling standard most plants already work to, even a lot held to a tight acceptance quality limit carries a defined consumer's risk; lots right at the AQL still sit around a ninety-five percent probability of acceptance by design (ISO 2859-1:1999). Automated full inspection lowers that risk. It doesn't repeal it.

"You need thousands of labeled defect images before it works"

This one stops projects before they start. A plant looks at the volume of scrap it would have to photograph and label, decides it'll take a year to collect a training set, and shelves the idea. The premise is out of date.

Two approaches get around the data wall. The first is to learn the defect directly but from very few examples. A segmentation-based model published in the Journal of Intelligent Manufacturing learned surface-crack detection from roughly twenty-five to thirty defective samples, rather than the hundreds or thousands the field assumed, and still outperformed the commercial software it was benchmarked against (Tabernik et al., 2020). For a process that throws one cracked part a week, twenty-five samples is a quarter's worth of scrap, not a decade's.

The second approach sidesteps defect images entirely. Anomaly-detection methods train only on good parts, learn what normal looks like, and flag anything that deviates. That suits real production, where you have thousands of good units and almost no defects, and where the next defect may be a type you've never seen. The MVTec AD benchmark was built precisely to push this line of work: more than five thousand images across fifteen categories of objects and textures, with over seventy defect types, all annotated to the pixel (Bergmann et al., 2019). Its other contribution was a reality check. When the authors ran the anomaly-detection methods of the day against it, none was close to solved, which tells you the technique is real but not automatic.

There's a third lever, and it's the one most likely to be oversold in turn: synthetic data. You can render or composite defect images, or use generative models to multiply the few real ones you have. Done carefully, augmentation stretches a thin dataset. Done lazily, it teaches the model the statistics of your renderer instead of the statistics of your process, and it fails the day a real defect doesn't match the synthetic one. So treat synthetic data as a way to train, never as a way to validate. Your test set has to be real parts, real defects, lit on the real cell. If you let synthetic images into the validation set you're grading the model on its own homework.

So the data question isn't "do we have thousands of labeled defects." It's "do we have a stable definition of a good part, and a handful of real defects to validate against." Most lines have the first and can collect the second in weeks.

"Deep learning makes rule-based machine vision obsolete"

The opposite is closer to the truth. The two solve different problems, and a working cell usually runs both.

Rule-based machine vision is deterministic. You tell it to measure a bore to a tolerance, read a date code, confirm a connector has the right pin count, check that a cap is present and seated. Give it the same pixels and it returns the same answer, every time, and you can explain exactly why it passed or failed. For dimensional and presence-absence checks that map to a drawing, that's exactly what you want, and it's auditable in a way a learned model isn't.

Deep learning earns its place on the problems rules can't express. "Is this weld porous," "is this casting surface acceptable," "is that a stain or a reflection" are judgments with thousands of acceptable variations and no clean threshold. A learned model captures that fuzziness. But it brings its own bill: it needs representative data, it can drift when the process or the lighting shifts, and on a bad day it'll fail in ways that are hard to explain to a customer auditor. Where does that leave a real cell? Usually with deterministic tools doing the metrology and gauging, and a learned model doing the cosmetic and texture judgment, each fenced off so a failure in one doesn't quietly corrupt the other.

A concrete pairing makes the point. On a filled and capped container you might run a deterministic tool to confirm the cap is present, seated, and the right colour, a second to verify the fill level against a fixed reference, and an optical character check on the lot code, all of them explainable and gauge-able. Then a learned model rides alongside to judge the label surface for smears, wrinkles, and misregistration, the cosmetic call no threshold captures cleanly. Each runs in its own lane, each fails in a way you can diagnose, and the part only ships when all of them agree.

Treating deep learning as a replacement rather than an addition is how plants end up using a model to do a job a fixed-threshold gauge would have done better, cheaper, and with a clean audit trail. Pick the tool for the defect, not for the brochure.

"It's a smart camera, not an engineering project"

This is the costliest myth, because it puts the money in the wrong place. The model gets the budget and the attention. The imaging gets an afterthought. Then the cell underperforms and everyone blames the algorithm.

No model recovers information the camera never captured. If the defect doesn't show up as contrast in the image, no amount of training conjures it back. That's why lighting, not software, is the first thing an honest integrator fixes. Cognex, which has been building these systems for decades, puts it plainly in its own engineering guidance: poor lighting is the most common cause of poor machine-vision performance, and good lighting maximizes contrast on the feature you care about while suppressing everything else (Cognex, machine-vision lighting guidance). The technique matters as much as the brightness. Dark-field lighting at a shallow angle makes a scratch flare white against a dark surface; a dome gives you glare-free light on a shiny part; a backlight turns a dimensional check into a crisp silhouette. Get that wrong and you're asking the network to guess.

Motion is the next thing the brochure skips. On a moving line you're fighting exposure time against blur, and a part that smears across a few pixels can erase the very feature you're hunting. That's the difference between an area-scan camera triggered on a stationary part and a line-scan setup integrated with an encoder so the image stays sharp at speed. The plant floor adds its own insults: dust on the lens, vibration that shifts focus, heat haze near an oven, condensation, swarf. None of that appears in a clean demo room, and all of it degrades the image the model has to work from. A cell that holds accuracy in a lab and loses it in production usually lost it to the environment, not the math.

Optics, working distance, sensor resolution, and fixturing carry the same weight. If a part can rotate or sit at a slightly different height each cycle, the model sees a moving target and its accuracy collapses, not because it's a weak model but because the presentation isn't repeatable. This is measurement, and measurement has rules. NIST has spent years building the science and the test methods for exactly this, working through ASTM Committee E57 on industrial 3D imaging and publishing a standards roadmap for 3D imaging in robotic assembly so that a vision system's performance can be stated and verified rather than asserted (NIST, Measurement Science for Manufacturing Robotics). A cell whose repeatability you can't quantify isn't an inspection system. It's a camera with opinions.

The practical reading: budget the imaging chain like the engineering work it is. Lighting, optics, mechanical presentation, and a way to measure repeatability come before the clever part. Skip that and the smartest model on the market will still hand you noise.

"Automated inspection replaces the quality operator"

It changes the operator's job. It doesn't delete it, and the plants that pretend otherwise are the ones that quietly drift back to manual checks within a year.

Start with drift. A model is trained on the process as it was. The process never holds still. A new resin lot, a tweaked anneal, a supplier change, a worn tool, a different ambient light through the skylight in summer, and the images shift under the model. Detection quietly degrades, and nothing on the HMI announces it. Catching that needs a person who understands both the product and the model, watching reject rates and reviewing borderline calls, and triggering a retrain before the escapes pile up. Who decides a marginal part is genuinely good and feeds that decision back? Not the camera.

Then there's everything past the pass/fail. A vision cell flags a defect; it doesn't tell you the die is wearing or the upstream bath drifted out of spec. Root cause is still human work, and it's the work that actually stops the defect being made in the first place. The cell is a faster, more consistent detector feeding that loop, not a substitute for it. Quality systems already assume a person stands behind the records: ISO 9001:2015 requires controlled documented information and proper handling of nonconforming output, and "the model said so" doesn't satisfy an auditor on its own (ISO 9001:2015). Someone owns the evidence.

There's also the question nobody likes to ask out loud: who decides what a defect is? A model is only as consistent as the labels it learned from, and labels come from people. Put two seasoned inspectors in front of the same borderline cosmetic blemish and they'll often disagree on the call. If they disagree, the training data is contradictory, and the model splits the difference in ways no one intended. Pinning down the standard, with boundary samples that say "this passes, that fails," is the same discipline a quality engineer brings to a gauge study, and it's just as human. The vision cell doesn't resolve that ambiguity. It industrialises whatever decision you fed it, good or bad, at full line rate.

And the edge cases never stop arriving. Real production throws oddities a finite training set never saw, and a good operator is the one who recognises a novel failure for what it is and pulls the line before a pallet of it ships. The honest framing is the one we take into deployment work: the system carries the repetitive, high-volume, fatigue-prone part of inspection so the skilled people can spend their hours on drift, root cause, and the genuinely ambiguous part. That's a better use of an experienced inspector than staring at the thousandth identical part hoping to stay sharp. It also happens to be where the technology pays for itself.

If you build it that way, with the imaging engineered, the right tool on each defect, a sane data strategy, and a person owning drift and root cause, computer-vision inspection earns its keep. Built on the myths, it becomes an expensive camera that everyone learns to override. The difference isn't the algorithm. It's the engineering and the honesty around it. (For the record, that's also why our own edge telemetry and analytics platform treats the model as one instrument among many, and why our industrial AI deployment work starts with the lighting rig, not the network.)