A practical defect-vision project starts with 50–100 images, then usually needs 30–100 real examples of each defect type for a proof of concept and 100–500+ per important defect for production [S2][S4].
Transfer learning or anomaly detection can reduce the labeled-data requirement, while classification, object detection, and pixel segmentation impose different labeling burdens [S3].
Working Data Targets by Project Stage
For a feasibility check, collect 50–100 good-part images and 10–20 examples of each target defect. This stage tests whether the defect is visible under the selected camera, lens, and lighting arrangement before a larger labeling effort begins [S2][S4].
A proof of concept typically expands to 300–1,000 good images and 30–100 real images per defect class. A production model may require 1,000–5,000 or more good images and 100–500 or more examples of each important defect, especially when the dataset must cover multiple lots, shifts, suppliers, and borderline conditions [S4].
These are planning ranges, not guarantees. Defect visibility, part variability, class count, label consistency, and the selected learning method determine the final dataset size [S3][S4]. A dataset with many good images but only a handful of defect examples can still perform poorly because class imbalance prevents adequate defect learning [S3].
Comparing the Main Training Approaches
A transfer-learned detector typically needs a few hundred labeled images per defect class, whereas training an object detector from scratch can require a few thousand [S3]. Transfer learning is therefore the normal starting point for a custom production detector, especially when compute and engineering resources are limited [S3].
Anomaly detection learns the appearance of normal production and can begin from good-part images, requiring as few as a few dozen defect examples when defect types cannot all be enumerated [S3][S4]. This approach suits rare or evolving defects, but it does not automatically provide a precise defect category or defect location without additional validation.
Zero-shot and few-shot vision-language models can begin with zero to a handful of examples, which makes them useful for rapidly testing alternative prompts or defect definitions [S3]. They should not be treated as equivalent to a fully trained, production-validated detector because their deployment behavior still depends on image resolution, task formulation, and representative testing.
For a direct comparison, transfer learning balances labeled-data demand at a few hundred examples per defect class, anomaly detection minimizes labeled defects to a few dozen, and training from scratch shifts the burden to several thousand examples per class [S3]. The choice should follow the production objective, available defect taxonomy, and required output.
Image Count Does Not Replace Dataset Balance
Defect classes are naturally rarer than good parts on a well-running line, so collecting genuine defects may take longer than collecting normal images [S3]. Deliberately sampling known higher-defect batches, retaining every production escape, and recording lot, shift, supplier, and camera metadata can expose coverage gaps that a larger random dataset would conceal [S3][S4].
Use a written definition for every defect class, including acceptance limits, reject examples, and a size threshold. Two inspectors should label the same 100 images to measure agreement, after which the disputed cases should be resolved by refining the standard [S4]. Borderline examples are useful training material because they define the model’s decision boundary [S4].
Repeated images of one damaged object do not create equivalent independent evidence. Taking 20 or 50 near-identical photographs of the same defective bolt can overstate dataset size and weaken conclusions about generalization [S7]. Defect examples should cover different physical parts and production conditions, while augmentation should introduce controlled rotation, brightness, and occlusion variation rather than masquerade as new defects [S5].
Resolution Can Defeat Any Dataset Size
The smallest target defect should span approximately 3–5 pixels for a practical imaging rule of thumb [S4]. In a 50 mm field of view captured by a 2,448-pixel-wide camera, spatial resolution is approximately 0.020 mm per pixel, so a 0.1 mm scratch spans about 4.9 pixels and remains workable [S4].
A 0.04 mm scratch occupies only about 2 pixels under the same geometry. That defect is below the recommended 3–5-pixel span, requiring a smaller field of view, a higher-resolution camera, or lighting that increases contrast before additional training images are collected [S4].
This check must also consider model preprocessing, because resizing can remove pixels from a small defect. A vision controller may resize or crop frames for inference, so the acquired image and the model input should be evaluated together. Likewise, changing the vision light source can determine whether a faint scratch is visible before data collection begins.
Synthetic Data Has Narrow, Measurable Value
Synthetic examples can improve a small real dataset, but their contribution must be measured rather than assumed. In one experiment, a model trained with 10 real scratch images detected 33% of scratch defects; adding 50 generated images raised that result to 75% [S6]. This demonstrates that generated data can be useful, not that synthetic images can replace comprehensive real-world coverage.
Synthetic data is most defensible when the defect geometry is controlled, generated labels are verified, and performance is tested on real defects. A synthetic image can teach appearance variation, but it cannot automatically reproduce every combination of material response, illumination, optics, production process, and operator handling found on a line.
For rare classes, a sensible sequence is to establish a real baseline, add synthetic samples, retrain, and measure the change in false rejects and missed defects on held-out production images. If 50 generated images contribute no measurable gain, they add annotation and review effort without improving the deployed model [S6].
Validation Sets and Failure Modes Define Success
Training, validation, and test images must remain separate, with the test set representing actual production conditions and never used to tune the model. A production evaluation should include borderline parts and report false-reject and escape rates rather than relying only on aggregate accuracy [S4].
Training accuracy can improve along a power-law-style curve: the first few hundred images usually deliver the largest gains, while each additional batch contributes less [S2]. A result based on only 16 test images cannot support a general claim, which illustrates why an independent test set must be large enough to represent the intended deployment conditions [S1].
Common failure modes include collecting thousands of near-duplicate frames, accepting inconsistent defect labels, overrepresenting one lot or shift, and validating on images drawn from the same collection session as the training set. A model should also be tested on data collected later, because lighting, suppliers, machine settings, and defect prevalence can change after deployment [S5].
Choosing a Defect Data Strategy
For a custom detector, begin with 50–100 images for feasibility, reach 30–100 real defect examples per class for an initial model, and plan toward 100–500+ per important defect for production coverage [S2][S4]. Select transfer learning when defect categories are known, anomaly detection when defects are rare or difficult to enumerate, and synthetic augmentation when verified generated examples improve a measured real-data baseline [S3][S6].
The most trackable next signal is not a promised image count but a learning curve: add a controlled batch of labeled examples, hold out production data, and record the change in recall, false rejects, and missed defects. The collection plan should continue only while each added batch improves a decision-relevant metric, and a model update should be rolled back if production validation shows degradation, as covered in the field procedure for rolling back a bad model update on the shop floor.