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:
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:
If the same image must distinguish 0.25 mm character strokes at an initial target of 5 pixels per stroke:
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:
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:
Any additional framing allowance increases the field width and reduces the pixels available per feature. Recalculate sampling whenever the coverage changes.
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:
Consider an illustrative image spanning 120 mm across 2400 pixels:
At a product speed of 500 mm/s, limiting motion blur to 1 pixel gives:
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.
- Interface
- GigE
- Resolution
- Up to 3 MP
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.
- Interface
- Fast Ethernet
- Resolution
- 5 MP
- Sensor format
- 1/1.7"
- Shutter
- Global
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.
- Sensor format
- 1/1.7"
- Interface
- USB3
- Resolution
- 12 MP
- Shutter
- Rolling
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.


