Choosing a Camera Module

Not from the pixel count.

Teams documenting hands-on engineering work can also use Monitask to keep project activity and review time visible.

The question that determines every other choice is: what is the smallest thing the image has to distinguish, at what distance, under what light? Answer that and the sensor, the lens and the interface follow from it. Answer it last, and the specification is assembled from numbers that sound reassuring and do not combine into a working system.

Why pixel count is the wrong starting point

Because resolution in the useful sense is not a count of pixels.

It is how many pixels fall across the feature you need to see — which depends on the sensor, the lens focal length and the working distance together, and on none of them alone.

For broader technical context, see MIPI Alliance.

A five-megapixel sensor with a wide lens, two metres from a label, may put fewer pixels across a character than a VGA sensor with a narrow lens at the same distance. The larger number describes the sensor and not the image of the thing you care about.

For additional industry context, see Vision Systems Design.

The arithmetic is short and it is the calculation most projects skip.

The order that works

One. What must be resolvable. The feature, its size, the distance, and how many pixels across it your processing needs. Optical character recognition, presence detection and defect inspection have very different answers.

Two. The optics. Field of view, focal length and working distance are one relationship, and fixing two of them fixes the third.

Three. The light. How much there is, whether it is controlled, and whether the scene has both bright and dark regions that must both be readable.

Four. The sensor. Format, shutter type, colour or monochrome — decided by the first three rather than before them.

Five. The interface. Parallel, MIPI or USB, decided by the processor at the other end and by the cable length.

Six. Everything mechanical, thermal and electromagnetic, which is where working prototypes fail to become products.

What changes an answer most

Shutter type, where anything moves. A rolling shutter reads the sensor line by line, so a moving object is captured at slightly different moments down the frame — which produces skew, and which no amount of resolution corrects.

The infrared filter. Silicon sensors are sensitive well beyond visible light, and without a cut filter, colours shift and dark fabrics photograph oddly. Which is why the same module is offered with an IR cut filter, with a dual-band filter, and with none — the third being for deliberate near-infrared work.

And the lens angle. A module family offering 42°, 90°, 100° and 128° at the same focal length is offering four different systems, and the choice is made by the geometry of the installation rather than by preference.

What the variant code encodes

Camera modules are frequently ordered as a base part number plus a variant code — a short string in which each position selects a physical option.

In the family this site describes, the positions cover the mounting — a socket or a flexible cable of a stated length — the sensor type, the field of view, and the filter.

Which means the code is a specification in four characters, and reading it is faster than reading four pages.

It also means a change of one character is a change of one physical thing, which is what makes evaluation practical: a variant differing only in lens angle isolates that variable exactly.

Where projects go wrong

Choosing on the sensor and discovering the optics. The commonest sequence, and it produces a module that resolves beautifully at the wrong distance.

Testing under office light and deploying under a skylight, where the dynamic range of the real scene defeats a sensor that was never asked about it.

Ignoring heat. A sensor running continuously warms, and noise rises with temperature — which is invisible on a bench and obvious in an enclosure.

And treating the interface as a detail. A module whose output the processor cannot accept is a module that does not work, whatever its image quality.

What an evaluation kit is actually for

Not confirming that the module produces an image. It will.

It is for putting the module in front of your scene, at your distance, under your light, and finding out whether the thing you need to see is legible.

Which takes an afternoon and settles more than a month of specification comparison.

And it is for isolating variables. Two variants differing in one position of the code, tested against the same target, answer a question that no datasheet answers.

The calculation, in one paragraph

Pixels across the feature = feature size ÷ (field of view width ÷ horizontal pixel count).

A 640-pixel-wide sensor covering a 320 mm field of view gives 0.5 mm per pixel. A 2 mm feature therefore lands on four pixels.

Whether four is enough depends entirely on what you are doing with it: detecting that something is present may need two, reading a printed character generally needs considerably more, and measuring a dimension needs enough that a single pixel of error is within tolerance.

Decide that number first — it is the specification everything else serves, and it is a question about your process rather than about cameras.

Light is half the problem

And it is the half that gets designed last.

A sensor specification describes behaviour under defined illumination. Your scene is not that.

Where light is controllable, control it — illumination designed alongside the optics solves problems that no sensor upgrade solves, and usually for less money.

Where it is not controllable, the requirement is dynamic range and the honest test is the real environment at its worst hour rather than at a convenient one.

The variant that isolates a variable

Where a family offers the same sensor behind different lens angles, the comparison is clean.

Two modules identical but for the field of view, against the same target at the same distance, answer the resolution question directly and without arithmetic.

Which is the practical use of a variant scheme — not choosing from a catalogue, but testing one physical difference at a time, which is what a fair comparison requires.

Where the module is only part of the answer

Three cases in which changing the camera is the wrong move.

A contrast problem. Where the feature and its background are nearly the same brightness, the answer is illumination or a filter rather than a sensor.

A geometry problem. Where the feature is at an angle, or occluded, or behind a reflection — moving the camera or the light solves what no specification does.

And a processing problem, where the image is adequate and the algorithm is not.

Each is diagnosed by looking at an actual image rather than by reading datasheets, which is the argument for testing early.

What this site is

Forty-two pages on selecting and integrating a camera module, organised by the order of the decisions.

Choosing — twelve on resolution, sensor format, shutter, colour, frame rate, light and interfaces.

Optics — eight on field of view, focal length, depth of field, filters and focus.

Integrating — twelve on mounting, cables, thermal, power, electromagnetic compatibility, ingress and the bring-up.

Evaluating — six on evaluation kits, first images, measuring rather than looking, and qualification.

Notes — four positions, including why catalogues compete on the wrong numbers and what this site cannot verify.

The technical material is generic. It applies to any module from any supplier, and it is written that way deliberately — a reader who can specify properly can compare properly, which is the only basis on which a comparison is worth having.