Deciding how many pixels a feature needs before you choose a camera

In short

Decide first which job you have: noticing a feature, measuring it in calibrated millimetres and rejecting a part on it are three different ones. Take the pixel budget from the algorithm that will do that job where it publishes a minimum, and otherwise from our defaults of 3 px for presence, 5 px for detection and 10 px for a size measurement, which are engineering practice rather than guaranteed thresholds. Put the field, the feature width and that budget into the calculator, which returns the nominal samples across the feature and the resolution one named axis needs. Then test detection, measurement error and reject errors separately, with the tool you will really run and on representative parts.

Three questions that one pixel count cannot answer together

Object-space sampling is the number of pixels the sensor puts on each millimetre of the part, and pixels per feature is that figure times the feature's width; the field of view reference page carries both formulas. What the number means depends on which of three questions you ask.

A feature is detected when an algorithm separates it from the background often enough under the variation you specified: illumination, surface finish, orientation and part-to-part spread. Sampling is one input, contrast and the tool are others, and the rate itself comes from a run on real parts.

A feature is measurable when three further things exist: a defined edge or model the tool fits, a calibration that maps image coordinates to millimetres, and a test that states the error, or the measurement uncertainty that goes with a result. Cognex puts it plainly: system accuracy depends on the part edge, the calibration target, the lens, the mounting, the image quality and the tool, and the only way to determine it is to test.

A part is rejectable when a decision threshold sits on that measurement and someone has counted how often it accepts bad parts and rejects good ones. Keep the three apart and you avoid the usual failure, a camera specified against the first question and held to the third at acceptance.

Where 3, 5 and 10 pixels come from, and how far they travel

Our budgets of 3, 5 and 10 px, and 16 px per character height for text and codes, are engineering practice rather than physics; the reference page says as much of its measurement mode, where the result is a sampling requirement whose accuracy still needs calibration.

Published guidance sits at the same level: a Teledyne DALSA note on line-scan selection asks for at least 3 or 4 pixels across the minimum product defect, and ends in a test of its own (vendor application note).

These counts belong to algorithms. Cognex lists at least 1.6 px of module width among the input requirements of its ReadIDMax tool for linear codes, and Teledyne DALSA states 1.5 px per bar or space for 1D and 2 px per cell for 2D for its BOA Spot ID product (vendor documentation). Each of those minima is stated for that decoder and that symbology, and neither source extends it any further. A scratch detector or a gauging tool states a requirement of its own, and that is the one its budget has to come from.

What sub-pixel localization changes, and what it leaves alone

Sub-pixel localization estimates a coordinate between integer pixel centres by fitting a model to the samples around it; Cognex does this for a correlation peak and OpenCV's cornerSubPix for a corner, refined from local image gradients (vendor and library documentation). The sensor pitch does not change. The added precision is an estimate from samples you already have, so its bias and spread follow the edge shape, the signal-to-noise ratio, the optics and the calibration, and a clean edge and a soft one with the same pixel count can localize differently. For an edge the gain runs across it rather than along it (Cognex), so measure that error on your own parts before you quote it.

Worked example: a 0.2 mm scratch and a 0.05 mm interval

The scratch lands on 3.06 px (calculated), above our 3 px presence line and below the 5 px budget chosen here; covering 160 mm at 5 px on a 0.2 mm feature calls for 4000 px (calculated) against the 2448 px installed (datasheet). Neither figure is a detection rate: the scratch's contrast, its orientation, the illumination, the lens and the algorithm are unspecified here, and each moves the outcome.

The small-field case reaches the same 4000 px requirement (calculated) from completely different geometry, which is the warning in the table: the same requirement can come out of two tasks that need completely different checks before anyone acts on the result. Its width axis carries 4096 px (datasheet), the 0.05 mm interval spans 10.24 px and a 10 mm diameter would span 2048 px (calculated). The calculator returns calibration_required, and that is the accurate summary: a 4.88 µm object pixel, and nothing about edge bias, repeatability or conformance to a tolerance. The drawing must still say whether 0.05 mm is a total width or a symmetric band; here it is only a sampled interval.

Calculate for your case

Both links carry the whole scenario: camera, field axes, working distance, feature size and pixel budget travel in the address. Open the scratch case or the small-field case and put in your own values.

A link opens the page in its defect mode, with the speed at 0 mm/s, so the small-field address enters 0.05 mm as a feature width and returns a sampling answer; enter your real line speed when you also want the exposure limit.

The page does more than a link carries. It has a measurement mode with an accuracy-target field and a choice of how many pixels you want across that target, both typed in by hand. Run the small-field scenario there, with a 0.05 mm target and 10 px across it, and it returns a 0.005 mm limit per pixel and 4000 px across the 20 mm width, so 200 px/mm is required against the 204.8 px/mm this camera gives (calculated). That is a requirement on discretization, not the error you will achieve.

The public optics API has no accuracy-target parameter, so a tolerance-driven question goes through the page or through us: send us the tolerance with the drawing and we run that case for you.

Equipment that fits this example

The two cameras in the table are named for their pixel counts and nothing more: 2448 × 2048 px in MV-CA050-12UM and 4096 × 3000 px in MV-CH120-10UM, both at 3.45 × 3.45 µm (datasheet).

When the arithmetic asks for more pixels, as the scratch case does, MV-CH240-10YM-C-NN offers 5312 × 4608 px at 2.74 × 2.74 µm (datasheet), above the 4000 px that example needs on its width axis. That settles the arithmetic and only the arithmetic; the focal length for the same field, the mount and the image circle all stay open. Send us the part number and we confirm the pairing.

Common mistakes

• Reading the required-resolution figure as a verdict on the camera is the common one: passing 4000 px on one named axis settles the sampling test on that axis alone, leaving the second axis, lens contrast, motion blur and focus spread unchecked. Look at an image of the part before accepting the number.
• Carrying a decoder's published minimum into surface or dimensional work fails quietly, since the 1.6 px of module width ReadIDMax lists is an input requirement of that tool on symbols whose geometry it knows. Take a scratch or gauging tool's budget from its own documentation, or from a test on your samples.
• Treating the object pixel as the measurement error produces a specification nobody can hold: 4.88 µm is the object-space length of one sensor pixel, while the error of a fitted edge comes from calibration, edge definition and repeatability. Get that number from a calibration and a repeat measurement on your own parts.
• Taking what an example link returns as a tolerance answer mixes up the page's two modes, because the link opens the defect mode where a 0.05 mm entry is simply a feature width. Switch to the measurement mode for a requirement computed from a tolerance.

When this rule breaks

The sampling equations are per-axis and blind to everything optical. They count a feature measured across the axis you entered, so a feature running at an angle projects a different width onto it, and that projected width is what belongs in the field.

Moving the same feature elsewhere in the frame is a separate matter. At constant local magnification and without distortion the nominal count stays what it was, wherever the feature sits; it changes only when something specific changes it, such as distortion, a perspective angle or a different projected width. Corner contrast, relative illumination and lens contrast transfer can fall off on their own, and whether they do is a question about the lens and the mounting you actually use. Look at the same feature at the edge of the field and at the centre with that hardware: where the corner image is visibly weaker, a detection can be lost there while the nominal count stays identical.

The arithmetic also stays defined where it stops being useful on its own. A feature width times pixels per millimetre returns a number below two pixels as readily as above it, and what can be done with that number depends on the signal, the optics and the algorithm.

Finally, the pixels have to be worth having. Edmund Optics warns that an object-pixel calculation does not state what a system can distinguish: the contrast the lens still transfers at the size of your feature, the illumination and the focus all act before the sensor samples anything. Motion spends the same budget, since blur equals velocity times exposure time times pixels per millimetre, and defocus changes edge contrast rather than the pixel pitch; the exposure and strobe article and the depth-of-field article take each of those further.

Next step

Write down four things before you ask for a camera: the field on a named axis, the smallest feature you must act on, the decision you will make about it, and the tool that will make it. Send those with your parts and we recalculate the nominal sampling for that field and feature, then write the test plan for the decision you named: what to run on representative parts, and what result counts as a pass.

Related

• Choosing a lens when the working distance is fixed
• Setting the exposure for a moving part, and deciding whether the light should be pulsed
• Deciding whether the depth of field covers your part-position spread

How this material was prepared

Prepared with MVisionPro AI agents from stated sources and the calculation core; MVisionPro retains editorial responsibility. A physical test or human engineering review is claimed only when explicitly stated. Read the editorial method.

Editorial status: verified. Content updated 2026-09-21.