Lighting, product variability, false rejects and data: the decisions that matter before talking about megapixels.
1. Build a defect library
The starting point is not the camera but the defect: size, contrast, orientation, frequency, variability and criticality. You need good and bad samples, ideally from the real process. Without that base, the project may optimise a demo rather than production.
2. Stabilise what the camera sees
Lighting, part position, vibration, speed and optical contamination often determine robustness more than nominal sensor resolution. A good concept first reduces physical variability in the image.
3. Define false reject and false accept logic
An inspection that “detects 99%” means little without the tested population and the cost of errors. Separate false accepts, false rejects, indeterminate cases and the manual-review strategy.
4. Test at real line speed
Performance must be verified at the real cycle time, through product changes, motion and actual cleanliness conditions. Processing time, trigger, reject actuation and synchronisation are part of the system.
| Topic | Question | Expected evidence |
|---|---|---|
| Defect | What is actually non-conforming? | Sample library |
| Optics | Is the defect visible in all conditions? | Lighting / position trials |
| Algorithm | What false-reject / false-accept trade-off? | Test matrix |
| Speed | Does the cycle remain stable at real speed? | Dynamic trial |
| Traceability | What data is stored and why? | Image / code / result / timestamp |
5. Prepare the data use case
Not every image needs to be stored. But useful production data — reference, result, defect, batch, timestamp and reject cause — should be defined early if traceability or continuous improvement is part of the objective.
General technical scoping note. Regulatory applicability, performance and responsibilities must be confirmed project by project.