ApplicationsGuide

How to choose a vision inspection camera

Choose a vision inspection camera by calculating image detail, checking lens coverage and lighting, and validating localization, counting, OCR, and codes.

LumaSpec Vision11 min read Share on LinkedIn

On this page 10 sections
  1. 011. Define the decision before choosing the camera
  2. 022. Calculate sampling from the smallest useful feature
  3. 033. Match lens coverage to placement and height variation
  4. 044. Choose lighting for the decision feature
  5. 055. Budget motion blur and decision time separately
  6. 066. Choose the processing architecture after the image trial
  7. 077. Validate difficult cases and meaningful failure behavior
  8. 088. Recognize when one camera is the wrong answer
  9. 099. Check the specification before ordering
  10. 10Questions

A camera can show a clear picture and still miss the feature that decides acceptance. Small text, touching parts, reflective labels, and moving products each impose different image requirements. The first decision is therefore not the interface or megapixel count. It is what evidence the inspection must capture.

This guide helps you choose a vision inspection camera by working backward from localization, counting, OCR, or code reading. You will define the required image detail, estimate coverage and exposure, and build an acceptance test before choosing hardware. The emphasis is on matching the image to the task, rather than comparing device feature lists.

1. Define the decision before choosing the camera

Write the inspection requirement as an observable decision. “Inspect the package” is too broad. “Confirm that the printed identifier matches the production order” defines both the image task and the validation requirement.

Use the following distinctions to identify what the camera must reveal:

Task Evidence needed in the image Common source of failure Acceptance check
Localization Stable edges, texture, or another distinctive reference Similar backgrounds or changing appearance Position error across the allowed rotation and placement range
Counting Each object distinguishable from its neighbors Overlap, touching objects, or hidden parts Correct count for difficult arrangements, not only separated parts
OCR Clearly separated character strokes Glare, weak printing, or ambiguous characters Exact text match with explicit handling of uncertain readings
Code reading Resolved bars or modules and adequate surrounding clear space Blur, reflections, damage, or insufficient sampling Correct payload, correct part association, and controlled no-read behavior

Separate identification from appearance inspection. Reading a label does not prove that the label belongs to the correct assembly. The barcode-to-part verification guide explains that distinction for similar-looking products.

Also define what happens when the system cannot decide. A missing result, an uncertain result, and a confirmed defect should not silently become the same machine state. Specify the required output and recovery path for each.

2. Calculate sampling from the smallest useful feature

Megapixels describe total pixel count, not how many pixels cover your critical feature. Start with the object-space field of view and the smallest feature that the inspection must distinguish.

For an initial estimate:

Required horizontal pixels = field width × target pixels per feature / feature width Object sampling = field width / horizontal pixels

All lengths must use the same units. The target sampling is an engineering assumption to validate, not a universal requirement for every algorithm.

Suppose a label inspection needs a 120 mm field width. Its narrowest code module measures 0.30 mm. Using an initial target of 4 pixels per module:

Required horizontal pixels = 120 × 4 / 0.30 = 1600 pixels

If the same image must distinguish 0.25 mm character strokes at an initial target of 5 pixels per stroke:

Required horizontal pixels = 120 × 5 / 0.25 = 2400 pixels

The OCR requirement now drives the horizontal sampling estimate. This does not guarantee readable text: focus, contrast, print quality, and character spacing still matter. Measure the actual strokes rather than inferring them from character height.

Use the camera resolution calculator to explore the relationship between coverage and feature sampling:

Camera resolution for the smallest feature
Units
Pixels needed
–
Sensor size
– MP
Smallest sensor that fits
–
Pixel on the part
– mm
Pixels across the feature, that sensor
–

Pixels needed = field / feature × pixels per feature on each axis (field incl. margin). The lens must resolve the pixels too: Nyquist = 1000 / (2 × pixel µm) lp/mm.

Find cameras with enough pixels Open the full calculator

Check the vertical direction independently. A camera with adequate total resolution may still lack enough pixels along the critical axis. Rotation also changes the projected feature dimensions, so test the permitted orientations rather than only the easiest alignment.

For label-specific issues beyond pixel count, use the barcode module-width guide. Keep its document-imaging context separate from the motion and triggering requirements of a production station.

3. Match lens coverage to placement and height variation

Choose coverage around the complete working envelope, not a perfectly centered sample. Include the inspection region, placement variation, and any background needed by the algorithm. Code reading also needs the clear area required by the selected symbology.

For example, a required region measuring 100 mm across with placement variation of ±10 mm needs at least:

Minimum field width = 100 + 10 + 10 = 120 mm

Any additional framing allowance increases the field width and reduces the pixels available per feature. Recalculate sampling whenever the coverage changes.

How sensor width, working distance and field of view set the focal length Rays from the edges of the sensor pass through the lens and spread to the edges of the field of view. The ratio of sensor width to field of view is the magnification m.CameraField of view (FOV)Working distance (WD)≈ fsensor width slensm = s / FOVf = WD × m / (1 + m)
How sensor width, working distance and field of view set the focal length. Rays from the edges of the sensor pass through the lens and spread to the edges of the field of view. The ratio of sensor width to field of view is the magnification m.

Record working distance from a clearly defined reference, along with the allowed object-height range. The relationship among field of view, sensor dimensions, focal length, and working distance determines whether the proposed optics can cover the task.

A wider view can simplify mounting, but it does not provide free coverage. At a fixed image width, increasing the field from 120 mm to 180 mm reduces feature sampling to 120 / 180 = 0.67 of its previous value. A feature previously spanning 6 pixels would span about 4 pixels.

The lens selection guide covers the optical decisions behind this tradeoff. For the actual capture trial, follow the lens and lighting test plan.

Test focus at the nearest and farthest object positions, including image corners. If localization requires accurate object-space coordinates, include calibration error and perspective effects in the acceptance test. A sharp image alone does not establish measurement accuracy.

4. Choose lighting for the decision feature

The best-looking image is not necessarily the easiest image to inspect. Your objective is repeatable separation between the feature of interest and everything the algorithm should ignore.

For localization, emphasize a stable contour or texture. For counting, distinguish adjacent objects rather than merely brightening their upper surfaces. For OCR, preserve the separation between character strokes and the label background. For codes, avoid reflections that erase groups of bars or modules.

Compare candidate illumination arrangements using unchanged camera settings. Otherwise, automatic exposure or gain can hide the effect of a lighting change. Record which arrangement preserves useful contrast across the complete sample set.

The lighting selection guide connects illumination geometry to inspection tasks. It is a better starting point than selecting a light solely because it is integrated into a camera.

Color is useful when color differences carry inspection information. It is not automatically helpful for dark characters on a bright label. Likewise, polarization or a different illumination wavelength should be tested against the actual material rather than assumed to solve every reflection.

When several tools share an image, identify conflicting needs early. A lighting arrangement that emphasizes raised edges may obscure printed text. Separate captures can be preferable to compromising every task in a single exposure.

5. Budget motion blur and decision time separately

A camera's nominal frame rate does not tell you whether moving detail will remain readable. Motion during exposure determines blur, while the complete acquisition and processing sequence determines when the result becomes available.

For approximately constant lateral motion:

Blur in pixels = speed × exposure time / object sampling Maximum exposure time = allowed blur × object sampling / speed

Consider an illustrative image spanning 120 mm across 2400 pixels:

Object sampling = 120 / 2400 = 0.05 mm/pixel

At a product speed of 500 mm/s, limiting motion blur to 1 pixel gives:

Maximum exposure time = 1 × 0.05 / 500 = 0.0001 s = 0.1 ms

This is a starting exposure budget, not a promise of successful inspection. Fine text or low-contrast edges may require less blur. Shorter exposures also need enough illumination to maintain useful image signal.

Shutter behavior matters separately. Rolling-shutter readout can distort moving geometry even when individual rows have short exposures. Validate the complete acquisition mode under actual motion; do not assume that an interface or resolution class establishes motion performance.

Then budget result latency. At 120 parts per minute, the average interval is 60 / 120 = 0.5 seconds per part. The usable decision window may be shorter because the output must reach the machine before the part passes a downstream decision point.

Measure trigger response, acquisition, processing, communication, and timing variation together. For host-based processing, the asynchronous frame-matching guide explains how to keep delayed results associated with the correct image.

6. Choose the processing architecture after the image trial

Once the image requirements are credible, decide where processing should run. The following comparison concerns system architecture; it does not establish the supported tools of any individual product.

Architecture Useful starting point What to verify before selection
Smart camera A contained inspection with processing on the device Required tools, tool combinations, processing time, output data, and supported job management
Fixed code reader Identification is the principal task Symbologies, simultaneous-code behavior, trigger modes, payload handling, and no-read reporting
Area scan camera with separate processing Custom algorithms or broader control over image processing Acquisition compatibility, processing resources, software licensing, synchronization, and result interfaces

Browse smart cameras when on-device inspection fits the task. Treat the LS-SMC-0063 as a candidate to evaluate against the image and integration requirements. Confirm the required inspection tools in the product documentation before selecting it.

Smart cameras & vision sensors1.6 MP smart camera, 60 fps, 16 mm lens, white light (polarized, transparent light) (LS-SMC-0063)LS-SMC-0063
Interface
GigE
Resolution
Up to 3 MP
$1,110.00View part

Browse fixed code readers when identification is the main requirement. The LS-CRD-0028 is a candidate for that evaluation. Confirm code support, coverage, trigger behavior, and result delivery rather than assuming that successful bench decoding proves production suitability.

Fixed code readers2560 x 2048 fixed code reader, 30 fps, 60 codes/s, 8 mm lens (LS-CRD-0028)LS-CRD-0028
Interface
Fast Ethernet
Resolution
5 MP
Sensor format
1/1.7"
Shutter
Global
$920.00View part

Browse area scan cameras when the application needs separate processing. The LS-CMR-0166 is a candidate for an acquisition-based architecture. Check optics, acquisition support, motion behavior, and the complete processing path against the trial requirements.

Area scan cameras12 MP USB3 area scan camera, IMX226, 1/1.7" rolling shutter, 30 fps, 4000 × 3000 resolution (LS-CMR-0166)LS-CMR-0166
Sensor format
1/1.7"
Interface
USB3
Resolution
12 MP
Shutter
Rolling
$560.00View partBuild a system with it

Use the camera finder to narrow hardware only after defining coverage, sampling, shutter needs, and processing architecture. An Ethernet interface alone does not establish support for a particular machine-control protocol or result format.

7. Validate difficult cases and meaningful failure behavior

Build the acceptance set around variation, not just sample quantity. Include placement extremes, allowed rotations, height variation, different print batches, weak contrast, and difficult but acceptable surface finishes. Add confirmed defects and incorrect identifiers where those belong to the task.

For OCR, compare complete strings and preserve leading zeros. For codes, validate the decoded content against the production requirement, not merely whether any payload was returned. The camera decoding and validation guide explains the separation between image acquisition, decoding, and data acceptance.

Measure missed defects and false rejections separately. Suppose 1,000 inspected samples include 100 known defects. Missing 2 defects gives a defect miss rate of 2 / 100 = 2%. Rejecting 9 of the 900 acceptable samples gives a false-rejection rate of 9 / 900 = 1%. A single overall accuracy figure would conceal these different consequences.

Zero observed failures is useful evidence, but it does not prove a zero failure probability. Record the tested conditions and avoid extending the claim to untested product families or operating ranges.

For identification tasks, barcode read confidence adds checks beyond a successful decode. Keep inspection decisions separate from any safety function unless the complete safety-related system is designed and validated for that purpose.

8. Recognize when one camera is the wrong answer

More resolution will not reveal a hidden feature. A touching pile may need mechanical separation before counting. Text on opposite sides of an object may need another view or controlled presentation. Glare that completely obscures printing needs a capture change, not simply a more permissive threshold.

A single image may also be the wrong compromise when localization, OCR, and code reading need different exposure or lighting conditions. Compare separate captures against their added acquisition time and synchronization requirements.

Use a simpler rule-based method when a stable feature directly expresses the acceptance condition. Consider other processing approaches when acceptable appearance varies too widely for those rules. The AI and rule-based inspection comparison addresses that later algorithm choice; neither approach removes the need for informative images.

9. Check the specification before ordering

Use this final checklist to turn the trial into a purchasing specification:

  • Decision: State the exact acceptance condition and the required response to uncertainty.
  • Coverage: Record the inspection region, placement variation, object heights, and mounting constraints.
  • Sampling: Measure the smallest relevant feature and calculate pixels across it in both image directions.
  • Optics: Confirm focus and usable detail across the complete field and height range.
  • Lighting: Retain images showing useful contrast on difficult acceptable and defective samples.
  • Motion: Record speed, exposure, shutter behavior, and trigger conditions used during validation.
  • Timing: Measure worst-case decision delivery, not only average processing time.
  • Integration: Confirm supported interfaces, result formats, software licensing, and job-change behavior.
  • Acceptance: Agree on sample coverage, missed-defect limits, false-rejection limits, and no-result handling.

Start the camera configurator with those requirements, or contact the applications team with representative images and the calculation sheet. The next step is to resolve the largest remaining capture uncertainty—not to select a camera from resolution alone.

Questions

What should I specify before choosing a vision inspection camera?

Start with the inspection decision, the smallest relevant feature, the required coverage, and the conditions under which parts appear. These requirements determine useful sampling, optics, lighting, and exposure. Compare camera architectures only after representative images show that the decision feature remains visible.

How much resolution do OCR and code reading need?

There is no universal megapixel requirement. Calculate the pixels needed across the smallest module or character stroke within your full field of view. Then validate the estimate with real printing, motion, focus variation, and lighting. Total megapixels alone do not establish readable detail.

Can one camera handle localization, counting, OCR, and codes?

A shared image can work when every tool receives adequate detail, contrast, coverage, and exposure. Confirm that the selected device supports the required tools together. If their capture requirements conflict, separate images or views may provide a more reliable inspection than one compromised setup.

Does a successful barcode read prove the inspection works?

A successful read shows that a payload was recovered under that test condition. It does not establish correct part association, acceptable print quality, or reliable performance across production variation. Validate the content, timing, sample range, and response to missing or ambiguous readings separately.

When should I choose separate processing instead of a smart camera?

Consider separate processing when the task needs custom algorithms, coordinated image handling, or processing flexibility beyond the evaluated on-device tools. Include acquisition support, computing resources, software licensing, and result synchronization in the decision. A smart camera can reduce system components when its documented capabilities fit the complete task.