A written defect taxonomy
Each class is defined with your quality team — limits, examples and look-alikes that are not defects. See how to write an inspection spec.
Vision & Inspection
Train on rare defects. Test on real ones.
We engineer the dataset behind your inspection model — a defect taxonomy, audited labels, procedural and generative images of rare defects — and prove every model on real parts it has never seen.
The problem
Your worst defect is usually your rarest
The defects that cost the most are often the ones you have the fewest pictures of: a through-crack that turns up three times a year, a contamination event that has happened twice. A supervised model trained on four examples learns those four parts, not the defect.
Labels cause the next problem. One inspector calls a mark a scratch, another a scuff, a third passes it, and the model inherits the disagreement. Then the test set is built from random frames of the same few runs, the model scores 99%, and it misses defects in week two.
In industrial inspection the dataset decides more than the model architecture does. We treat it as an engineering deliverable, with the same rigor as the optics and the PLC logic.
How it works
How we build an inspection dataset
Labeling QA
Two annotators label each image independently. Your quality engineer rules on disagreements, and per-class agreement shows which classes need redefining.
Procedural synthesis
Parametric scratches, dents, missing features and contamination are rendered with controlled size, position, orientation and lighting, each with an exact pixel mask.
Generative synthesis
Image-generation models paint defects onto real images of good parts for textures that are hard to model by hand — wrinkles, stains, organic product variation.
The right model type
Anomaly detection, supervised classification or both, chosen by how much defect data exists. See anomaly detection vs supervised classification.
Models you own
Every model ships as ONNX, plus compiled builds for the target hardware — TensorRT on Jetson, or the Hailo and Qualcomm toolchains — with a model card and the recipe to retrain it.
The rule we don't break
Synthetic images train the model. Real images judge it.
Synthetic images are never in the test set. A model scored on generated images is being graded on how well it recognizes the generator's style, which tells you nothing about your line.
Before training starts, we freeze a test set of real, held-out parts — drawn from different lots, days and shifts than the training data, so near-identical frames cannot leak across. Every accuracy figure we report comes from that set.
We also train each model twice, with and without the synthetic data, and compare both on the same real test set. If the synthetic images do not improve detection on real parts, they come out of the training data, and the report says so.
Two kinds of synthetic data
Procedural vs generative defect images
| Aspect | Procedural | Generative |
|---|---|---|
| How it works | Rendered or composited from defect models with set parameters | An image model paints defects onto real images of good parts |
| Best for | Geometric defects — scratches, dents, missing features, misplaced parts | Texture-heavy defects — wrinkles, stains, discoloration, organic variation |
| Labels | Pixel-exact masks come with every image | Masks must be checked; the model may draw outside the requested region |
| Main risk | Images look too clean, so the model learns the rendering | Plausible-looking defects that never occur in real production |
Process
From image archive to validated model
-
Data audit
We inventory your images, labels and reject records, looking for leakage, duplicates, class imbalance and gaps in lot and shift coverage.
-
Taxonomy and labels
Defect classes are agreed in writing, real images are labeled and adjudicated, and the real test set is frozen before any model sees it.
-
Synthesis and training
Synthetic images fill the gaps the audit found. Candidates are trained with and without them, then compiled for the target hardware.
-
Validation and handover
Results on real held-out parts, per class, with a model card. After go-live, Perflens Care uses the same recipe for retraining.
Deliverables
What the dataset work delivers
- Defect taxonomy with class definitions, acceptance limits and look-alike examples
- Labeled dataset with a labeling guide and per-class agreement scores
- Synthetic image sets and generator settings, versioned separately from real data
- The frozen real test set and a record of where every image came from
- Validation report with per-class detection and false-reject rates, with and without synthetic data
- Model card covering training data, intended use, known limits and version history
- ONNX model files plus builds compiled for your target hardware
- A retraining recipe your team or Perflens Care can repeat
Honest fit
When synthetic data helps, and when it hurts
A good fit when
- A rare but costly defect, with at least a handful of real examples to validate against
- Inspectors disagree on classes and the model has learned their disagreement
- You already run a vision system whose model underperforms on real production
- An equipment maker needs a model it owns outright, with documentation for its customers
Probably not when
- There are no real examples of the defect at all — start with anomaly detection on good parts and collect real defects as they occur
- The defect is not visible in the images; fix the optics first
- You need a promise of zero escapes based on generated data alone
See it in context
Where rare-defect data matters
Heat-seal inspection at 180 packs per minute
Leaking seals are rare and varied, which makes a modeled snack line a natural case for careful defect data.
Read more
Pharma & medical devices
Particles, cracks and cosmetic defects that occur rarely and must be documented thoroughly.
Read more
When generated images help and when they hurt
Priya Venkataraman on the failure modes of synthetic defect data.
Read moreFAQ
Questions we hear often
How many real defect images do you need?
Enough to test against. We want real examples of every class in the frozen test set; 5–10 of a rare class is workable, but the uncertainty on its detection rate is wide, and the validation report states how wide.
Will synthetic data fix a model that performs badly?
Only if the problem is coverage — too few examples of a defect, a lighting condition or a product variant. If the problem is poor contrast or inconsistent labels, synthetic images make it worse, and the audit will tell you which you have.
Are our images used to train models for anyone else?
No. Your images, labels, synthetic sets and trained models belong to you and are used only for your systems.
Can you train models for a vision system you didn't build?
Yes. We deliver ONNX files and compiled builds for common edge targets. If your current system cannot run modern models, see vision retrofit.
What is in a model card?
What the model is for, the data it was trained and tested on, per-class results on real parts, known weaknesses, the target hardware and every version since go-live.
What does this cost?
Most clients start with a $9,500 Feasibility Sprint, which includes a baseline model. Dataset work is then scoped in writing, within an inspection project or on its own. See pricing.
Send us the defect you've only seen four times
A Feasibility Sprint tells you whether better data can close the gap — measured on your real parts, never on generated ones.