Ask how a machine recognizes a defect and the answer depends enormously on which approach the system uses. Two systems doing apparently the same job can work in fundamentally different ways, requiring different expertise to build, different effort to maintain, and behaving differently when conditions change.
That distinction matters to anyone evaluating these systems, because it determines who can build one, how long it takes, what happens when the product changes, and what kind of problems the system handles well.
The field of computer vision programming has shifted substantially over the past decade, and understanding the two broad approaches, and how they are increasingly combined, explains most of what has changed about what these systems can do.
The Rule-Based Approach
Traditional machine vision works by explicit instruction. An engineer defines the operations the system performs and the criteria it applies.
The typical sequence involves acquiring an image, processing it to enhance the features of interest, extracting measurements, and comparing those measurements against defined thresholds.
The operations are well established: edge detection, thresholding, pattern matching against a reference, blob analysis to identify connected regions, and geometric measurement.
The decision logic is explicit. A part passes if a measured dimension falls within tolerance, or if a matched pattern exceeds a similarity score.
The strengths are real. The system is deterministic and its behaviour is fully explainable, which matters in regulated environments. It is precise for dimensional work. It requires no training data. And it runs fast on modest hardware.
The limits are equally real. Every condition has to be anticipated and encoded. Variation in lighting, orientation, or part appearance that was not planned for causes failures. Defects that are obvious to a person but difficult to define numerically are difficult to detect. And the tuning effort grows quickly as the variation the system must tolerate increases.
The Learned Approach
Machine learning approaches work differently. Rather than being told what to look for, the system learns from examples.
A model is trained on images labelled as acceptable or defective, or with defect regions marked, and it learns the visual characteristics that distinguish them.
Neural networks designed for image analysis identify features at multiple levels of abstraction, building from simple edges and textures toward complex patterns, without a person specifying what those features should be.
The strengths address exactly what rule-based systems struggle with. Defects that are recognizable but hard to define explicitly become tractable. Natural variation in appearance is tolerated far better. Complex textured surfaces, organic products, and cosmetic assessment all become feasible.
The costs are different. Training data is required, and for defect detection that means examples of defects, which are by definition less common than good parts. The model’s reasoning is harder to explain, which matters where validation requirements demand it. Compute requirements are higher. And performance depends heavily on whether the production conditions resemble the training data.
Combining Both
Most capable systems now use elements of each rather than choosing one.
Rule-based processing handles what it does well: locating the part, establishing orientation, measuring dimensions, and reading codes.
Learned models handle the assessments that resist explicit definition: surface quality, cosmetic defects, and anomalies that vary in appearance.
Rules also constrain learned outputs, applying business logic to model results so that the overall decision remains predictable and auditable.
This division plays to the strengths of each and keeps the explainable parts explainable, which matters for validation and for troubleshooting.
Who Can Build These Systems Now
The skill requirement has changed considerably, which is the practical development for most manufacturers.
Traditional development required specialist vision engineers writing and tuning code, and that expertise was scarce and expensive.
Platform-based approaches have moved much of this into configuration rather than programming. A person who understands the manufacturing process, but not deep learning, can now assemble training examples, define what constitutes a defect, and produce a working model.
That shift matters because the scarce knowledge in most facilities is not software expertise. It is understanding which defects matter, what they look like, and how the process actually behaves, and that knowledge sits with quality and production staff.
Specialist expertise remains valuable for difficult applications, unusual imaging requirements, and complex integration. It is no longer a prerequisite for every project.
Getting a Model to Work in Production
Building something that performs in a demonstration is considerably easier than building something that performs on a line.
Training data has to represent production reality, including the variation in lighting, part positioning, and appearance that actually occurs rather than the controlled conditions of a sample collection.
Defect examples need to cover the range of what occurs, and collecting them is often the longest part of a project because defects are rare by design.
Labelling consistency matters enormously. Where two people label the same borderline case differently, the model learns the inconsistency.
Class imbalance, meaning far more good parts than defective ones, requires deliberate handling or the model learns to pass everything.
Validation should use data the model has not seen, from conditions it will actually face, and the relevant measures are false negatives and false positives rather than overall accuracy, since those two errors have very different costs.
Ongoing monitoring is necessary because conditions drift. Materials change, lighting ages, and processes are adjusted, and a model that performed well at deployment can degrade quietly without anyone noticing until someone checks.
