A model holding 99% detection at 270 parts an hour is not winning on the algorithm. It is winning because the smallest defect it has to catch lands on enough pixels for a decision to be possible at all. The AI model is not the first decision in a vision project. The pixel budget is. If the defect you care about is three pixels wide in the image, no amount of deep learning will find it reliably — and no retrain will fix it, because the information was never captured.
This is the reframe that saves projects: resolution is a calculation you do before you choose a model, a camera, or a vendor. It is the same arithmetic every time, and it fits on one line.
The one calculation
Three numbers decide whether a defect is detectable:
- Smallest defect size — the real dimension of the smallest thing you must catch, in millimetres.
- Pixels per defect — how many pixels you need across that defect for the model to decide. The working range is 3 pixels (marginal) to 5 pixels (robust). Use 4 as a sane default.
- Field of view — how much of the part or web one camera has to see, in millimetres.
From those you get everything:
Pixel size at the object = smallest defect ÷ pixels per defectRequired sensor resolution = field of view ÷ pixel size at the object
That is the whole model. Work it once and you know the camera you need, how many cameras the line needs, and whether the project is even physically possible before anyone demos anything.
A worked example you can copy
Say your smallest defect is 0.5 mm and you want robust detection, so 4 pixels per defect.
- Pixel size at the object = 0.5 mm ÷ 4 = 0.125 mm per pixel.
Your inspection has to cover a 500 mm web width.
- Required horizontal resolution = 500 mm ÷ 0.125 mm/px = 4,000 pixels.
A single 4K-class camera (around 4,096 pixels wide) covers it. One camera, done.
Now widen the web to 1,000 mm and nothing else changes:
- Required resolution = 1,000 ÷ 0.125 = 8,000 pixels.
Now you need an 8K sensor or two 4K cameras tiled across the web. The defect did not change. The field of view did, and the camera count doubled with it.
One more number, because a moving line adds it. At a line speed of 2 m/s (2,000 mm/s), to keep motion blur under a single pixel the exposure must be shorter than:
- 0.125 mm ÷ 2,000 mm/s = 62.5 microseconds.
No ambient factory light delivers a usable image in 62.5 microseconds. That is why a fast line needs a strobe, not a brighter model. The resolution math and the exposure math together tell you the whole capture spec — before the vision software is even in the room.
The two failures the math prevents
Almost every "the model can't catch it" complaint is one of two arithmetic errors wearing an AI costume.
Undersampling is the common one. The defect lands on 2 pixels instead of 4 or 5. At 2 pixels the model is guessing, so it escapes defects, so the team schedules a retrain, which does nothing, because the image never contained the defect clearly enough to learn from. Months disappear into retraining a model to see something the camera cannot resolve. The fix is a lens or a camera, not a dataset.
Oversampling is the quiet one, and it shows up on the invoice instead of the escape log. A line specified at 0.1 mm/px when 0.125 would have been robust needs more resolution than it can use — higher-cost sensors, or more cameras tiled across the same web, or both. The detection rate does not improve, because 0.125 was already enough. You simply paid for pixels no defect needed.
| Symptom on the line | What it's blamed on | What it usually is |
|---|---|---|
| Small defects escape intermittently | "The model needs more training" | Undersampling — defect on 2–3 px |
| Escapes cluster at higher line speed | "The model drifts" | Exposure too long — motion blur |
| Edge features wash out under bright light | "The model is weak on edges" | Lighting geometry, not resolution |
| System cost 2–3× a comparable line, same catch rate | "AI vision is expensive" | Oversampling — resolution spec'd past need |
The cost delta is the moat
Here is the part no vendor comparison shows you, because it cuts against selling more hardware. Take the 500 mm web at 0.5 mm defects. Specified correctly at 0.125 mm/px, it is one 4K camera. Specified at 0.08 mm/px "to be safe," it needs roughly 6,250 pixels across the same web — pushing you to a higher-resolution sensor or a second camera, plus the extra lighting and mounting that come with it. Same defects caught, same 99% achievable, and a bill that can run two to three times higher for zero detection benefit. The pixel budget is where vision projects quietly overspend, and it is invisible unless you did the arithmetic yourself.
This is why the capture spec, not the model, is where the Auto Parts customer (Client A) holds 99% across more than 8,000 variants: every part family's recipe locks the resolution and exposure to what the defect actually requires before the model runs. The same discipline is what makes inline electrode-web inspection possible on fast battery lines, where web speed and defect size set the pixel budget first. Get the budget right and the model has a chance. Get it wrong and the best model on the market is reading an image that never held the answer.
The rule
Before you evaluate a vision vendor, do the arithmetic: smallest defect, divided by four, is your pixel size; field of view divided by that is your camera. If the defect comes out at three pixels or fewer, no model will save it, and the honest move is to change the optics, not the algorithm. The pixel budget is the first decision. Everything downstream, including the AI, depends on it being right.
Send us your smallest defect size, your field of view, and your line speed, and within two weeks we return the worked resolution-and-exposure spec for your line: the pixel size you need, the camera count it implies, the strobe requirement at your speed, and where a correctly specified line would sit against an over-specified one on cost. No contract until the arithmetic is on paper.
Send three numbers and get your line's worked pixel budget and camera count back in two weeks.
