Start From What Must Be Resolvable

Generic engineering material, applicable to any module from any supplier.

For the non-technical side of coordinating engineering work, see cognitive offloading.

Every other decision follows from one sentence: what is the smallest thing the image must distinguish, at what distance, under what light, and how many pixels does the processing need across it.

Projects that write that sentence first specify quickly. Projects that write it last assemble a system from reassuring numbers.

The four questions

One. What is the feature? Not "the product" — the specific thing that must be distinguishable. A crack, a character, a colour difference, an edge, a presence.

An independent reference for adjacent engineering topics is Wi-Fi Alliance.

Two. How large is it, in millimetres? The dimension that matters, which for a crack is its width rather than its length.

Three. At what distance and over what area? The working distance and the field of view that must be covered, which are fixed by the installation more often than by choice.

Four. How many pixels across it does the processing need? Two or three for presence, considerably more for character reading, and a number derived from tolerance for measurement.

Four answers, and the module specification is arithmetic from there.

Why it is skipped

Because the fourth question requires knowing what the processing will be, and the processing is frequently chosen after the camera.

Which is the wrong order and is understandable: the camera feels like the concrete decision and the software feels like something to sort out later.

The consequence is a system that images well and fails at the task, and the failure appears late, when the module is designed in.

Where the processing is genuinely undecided, specify conservatively and say so — more pixels across the feature than the likely minimum, with the reasoning recorded.

What the answer changes

The sensor and the lens together, which are one decision rather than two.

The illumination, since a feature defined by a small contrast difference needs light designed for it, not merely more light.

The shutter, if anything moves. Rolling shutter skew is a geometry error, and where the task is measurement it is a correctness problem rather than an appearance one.

And whether colour is needed at all, which is a real question rather than a default.

The sentence written out

"We must distinguish a 0.3 mm crack in a 60 mm part, at 150 mm working distance, with at least three pixels across the crack width, under fixed LED illumination."

That specifies a system. A supplier can answer it, two modules can be compared against it, and a test has a pass condition.

"We need a good camera for inspection" specifies nothing, and it is what most enquiries contain.

Where the answer is genuinely unknown

Common in early development and it has a method.

Photograph the thing. Any camera, at roughly the right distance, and see whether the feature is visible and at what apparent size.

Then vary one thing — distance, light, angle — and see what improves it. An evaluation kit exists for exactly this, and an afternoon with a real sample answers what a month of specification reading does not.

Writing it down where others will read it

The sentence belongs in the requirements document, not in somebody's head.

Because it gets tested against — by whoever evaluates modules, by whoever writes the processing, and by whoever explains six months later why the chosen part was chosen.

And because it changes. A tolerance tightens, a working distance moves, a part gets smaller — and a written requirement makes the consequence visible immediately rather than at integration.

The mistake of specifying the answer

"We need a five-megapixel module with a 90-degree lens" is an answer presented as a requirement.

Which prevents anybody suggesting a better one, and hides the reasoning that would let somebody catch an error in it.

State the requirement and let the specification follow. Where you already believe you know the answer, say both — the requirement and your proposed solution — so that a supplier or a colleague can check the second against the first.

When the requirement cannot be met

It happens, and finding out early is the whole point.

Where the field of view, the feature size and the pixel requirement do not combine into any available sensor, something has to move: two cameras instead of one, a shorter working distance, a mechanical change to present the part differently.

All are cheaper decided now than after a module is designed in — and all are invisible until the sentence is written down.

The test that confirms it

A target of known dimension, photographed in the real position.

Count the pixels across it. If the number matches your calculation, the arithmetic and the installation agree.

Where it does not, one of your four answers was wrong — usually the working distance, which is measured optimistically more often than any other quantity.

Measuring rather than looking is what turns this from an impression into a specification met or not met.

A note on stating the field of view

Horizontal, vertical or diagonal — say which.

A lens quoted at 90 degrees may mean any of the three, and the horizontal figure is what your calculation needs.

The difference is substantial on a sensor that is not square, and it is a common source of a system that covers less than expected.

Ask the supplier which the figure is where it is not stated, as with any specification number.

The short version

• One sentence determines everything: the feature, its size, the distance and field of view, and the pixels the processing needs across it
• It is skipped because the fourth question needs the processing decided, and the camera usually gets chosen first
• The consequence is a system that images well and fails the task, discovered late
• The answer fixes the sensor and lens together, the illumination, the shutter type, and whether colour is needed at all
• A written specification lets a supplier answer, two modules be compared, and a test have a pass condition
• Where it is unknown, photograph the thing with any camera and vary one factor at a time