Turning a code's size and module count into a camera resolution

In short

The requirement has two halves from two different places. Divide the symbol dimension by the module count on the same axis to get the module size, the smallest square cell of a 2D code or the narrowest bar of a linear one, having first settled whether that dimension includes the quiet zone. Take the pixel budget for one module from the documentation of the engine you will run, where it is normally a range and not one number. The module goes into the calculator as the feature size, and the budget travels in the prepared link below as its nPx value, which returns the pixels needed across your field: 1320 px and 200 px in the two cases here (calculated). Then check what the lens you install really delivers against the limits that decoder documents, the upper bound included wherever its documentation states one, and leave motion, focus, light and print quality to a read-rate test on your own codes.

The symbology defines the symbol, the decoder defines the pixels

ISO/IEC 16022:2024 for Data Matrix, ISO/IEC 18004:2024 for QR Code and ISO/IEC 15417:2007 with its 2026 amendment for Code 128 cover symbol characteristics, dimensions, decoding and related parameters (normative), and none of them yields a camera figure. Pixels per module, the image pixels spanning one module on the axis you control, belongs to the reading engine, its version and its mode.

Getting the module size right before anything else

Module size is the symbol dimension divided by the module count on the same axis, and DENSO WAVE works it for QR Code: a Version 3 symbol has 29 modules per side, so at 0.254 mm per module the matrix measures 7.366 mm across (vendor documentation).

The first trap is the quiet zone, the clear margin around the symbol, which lies outside the data-module matrix but inside the space the code occupies on the part. DENSO asks for four clear modules on every side, so that same symbol takes 37 module widths, or 9.398 mm, on the part (calculated from the vendor example): divide that printed area by 29 and the module comes out about 28 % too large (calculated).

The second trap is guessing the matrix, because a 10 mm Data Matrix is not automatically 22 × 22 modules: the dimensions follow the data, the encoding and the error correction of the symbol you print. Read them from the marking specification or count them on a known-good sample, which is where GS1's 2D in retail guideline also sends implementers (normative guidance). X-dimension is the name those tables use for that same module or narrow element.

Pixels per module belongs to the decoder, and it usually comes as a range

Published limits differ by engine, licence level and code family, which is the plainest evidence that no single number governs.

The upper end does real work: Basler's Basic mode for Data Matrix runs from 6 to 20 px per module, so a design that clears the floor can still leave the mode when a tight field or a coarse mark enlarges the module. Where a page publishes only a floor, as the barcode page does with its 2 px minimum line width, that floor is the whole documented requirement. The Cognex figures belong to one document and one machine: revision 25.4.1.1 of the DataMan Fixed-Mount Reference Manual, dated 2025-12-17, page 147, DataMan 503 Series with a 25 mm lens (vendor documentation). The Basler QR page gives Basic as 6 to 20 px in its summary table and 2 to 100 px in its detection paragraph, so use the version you have installed.

Worked example: a 10 mm Data Matrix and a Code 128 label

Both cases use MV-CA050-12UM, 2448 × 2048 px at 3.45 µm (datasheet), as the geometry of one known camera rather than as a reader recommendation. The 500 mm and 300 mm working distances are assumptions, measured from the lens principal plane, the optical reference plane of the thin-lens relation, and not from the camera housing.

With 10 mm excluding the quiet zone and the matrix confirmed as 22 × 22, both assumptions, the module is 0.454545 mm (calculated): at the 6 px floor the symbol needs 132 px in the image and the field needs 1320 px along the axis (calculated). The 200 px of the second column come from the assumed 0.5 mm narrow element and the documented 2 px line width, not from the 50 mm of label, whose symbol width follows the encoded content and the quiet zones.

Neither requirement survives untouched into the built system. The tool fits a lens from the series of standard focal lengths, selects a 35 mm nominal in both cases and widens the field, which costs sampling; the last four rows carry that pair. The module still lands inside the 6 to 20 px band and the narrow element still clears its 2 px floor. Those fields are thin-lens estimates, so measure the real field once the lens is focused and repeat the two divisions, as choosing a lens when the working distance is fixed sets out.

The two columns hold two requirements built on different inputs: 1320 px and 200 px are floors for different fields, features and decoder conditions, so reading them side by side ranks no camera and no code family, and settles no purchase. Each scenario closes on its own terms, with the field it really needs, the working distance the machine holds, the limits that decoder documents and margin for motion, focus and light.

Calculate for your case

The link carries the whole scenario: camera, both field axes, working distance, the module as the feature size and the pixels-per-module figure as the pixel budget. Open the Data Matrix case or the Code 128 case, replace the camera, the field and the distance with your own, and take the derivation from the field of view reference page.

The feature-size field takes the module or the narrow element and never the whole symbol, so entering 10 mm there answers a different question. The pixels-per-feature control offers quick buttons of 3, 5, 10 and 16, which is why the 6 px and the 2 px of these examples travel in the address: to try another figure, edit the nPx value in the link, which accepts any number from 2 to 20. Outside that span, where Cognex's 1.2 px and Basler Pro's 100 px ceiling sit, divide by hand instead. Field width divided by module size and multiplied by the budget gives the pixels needed; module size multiplied by resolution and divided by field gives the pixels delivered.

Run that check at both ends of the code range the station will see, since the smallest module tests the floor and the largest module in the tightest field tests any ceiling that decoder documents. Both links set the speed to 0 mm/s, so enter your real line speed when you also want the exposure ceiling from exposure, motion blur and strobe.

What a reader datasheet has to state

MV-CA050-12UM supplies the geometry of both cases, 2448 × 2048 px at 3.45 µm (datasheet), a measuring stick for the arithmetic above and not a proposed reader. A reader record becomes checkable against a code once its distances arrive together with the symbology and the X-dimension they belong to, which is how the MV-IDH9000B entry reads: 1280 × 1024 px, with a 5 mil Data Matrix placed at 5 to 79 mm for that variant (datasheet). Those are that device's own conditions, a 5 mil mark held within 79 mm, while the two cases here sit at 300 mm and 500 mm, so the entry shows the shape of a specification you can check and fits neither scenario. Send us the part number with your symbology and X-dimension and we confirm what its datasheet states.

Common mistakes

• Dividing the printed size by the module count without checking the quiet zone is the commonest slip; dividing by 29 where 37 was right makes the QR module roughly a quarter too large, and every pixel figure after it looks safe when it is not.
• One engine's minimum does not travel to another project, because the 1.2, 2, 2.5, 3 and 6 px per module above belong to named products in named modes.
• Checking only the floor leaves a published ceiling untested: a code that fills more of the frame than planned leaves the 6 to 20 px band from the coarse side, and the frame still looks good while the decode fails.
• Our calculator's 16 px on character height belongs to text recognition (our calculator's defaults) and settles nothing about modules, and a sensor resolution quoted without the field at the code plane gives no pixels per module at all.
• A successful decode is not a quality result, because decoding recovers the data from one frame while verification measures the symbol against a defined grading method.

When this rule breaks

The arithmetic describes one static, well-lit, in-focus frame. The decoder pages that publish a module range also constrain polarity, element gaps, finder patterns, slant and contrast, and none of that appears in a pixel count (vendor documentation). Motion blur spends the very pixels the module needs, defocus softens module edges without touching the pixel pitch, and glare or a damaged mark removes the contrast the decoder relied on; why a code does not read takes them in order.

The smallest feature the tool reports, 0.245098 mm in the Data Matrix case (calculated), is the module the chosen budget would still sample at the requested field, and not the smallest code your line will read: that comes from images across your real code range with a measured read rate and false-read rate.

Next step

Send us the symbology, the symbol dimension with its module count, whether that dimension includes the quiet zone, the field at the code plane and the decoder you intend to run. We recalculate the sampling, say what that reader variant's datasheet settles, and name what has to be tested on your samples.

Related

• Why a code does not read, and what to check first
• Choosing an industrial code reader: fixed or handheld, label or direct part mark
• Choosing a lens when the working distance is fixed
• Setting the exposure for a moving part, and deciding whether the light should be pulsed

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.