Built-in camera image acquisition limits vs a machine-vision camera

Your handheld device already carries a camera, so the capture side of the project looks settled — until the part moves, the machine controller wants to know exactly when each picture was taken, and the app returns whatever its camera software decided to save. This page separates the two cases: what a built-in camera can honestly deliver, and which machine-vision camera controls replace each of its limits. You will size the exposure budget with one motion-blur calculation, check trigger and frame-rate timing against a stated frame rate, and finish with a decision rule you can apply to your own task.

What a built-in camera actually delivers

A capture call on an embedded device does not drive the sensor directly. It launches the vendor's camera application, that application runs auto exposure, auto gain and auto white balance on its own judgment, and it writes the result as a compressed file: JPEG for a still, H.264 for video. Your code receives the file, never the raw sensor data. The settings you control are the ones the app exposes — a dialog title, a quality value that selects how strong the compression is, and the resolution presets the vendor shipped.

What is missing matters more. There is no trigger input to wire, no exposure time you can express in microseconds, no stated frame rate and no fixed timing. Each capture competes with the app's startup, focus and metering logic, so the delay between two shots can wander by hundreds of milliseconds. For a human snapshot that is invisible. For an inspection station it is the whole problem.

The four controls a machine-vision camera adds

An industrial camera replaces each missing control with a counterpart you set from software:

• Fixed exposure time. You set it in microseconds and it holds frame after frame; most models also let you change it live, as described in runtime camera parameter control.
• Hardware trigger input. A photoelectric sensor or PLC output starts the exposure, so the picture is pinned to the machine event. The wiring and the logic levels are covered in wiring a GPIO output to a camera trigger input.
• Strobe output. The camera pulses the light for exactly the exposure window, which is how a short exposure stays bright enough. The pulse-versus-timestamp behavior is described in camera strobe output timing.
• Uncompressed frames. Mono or raw Bayer, 8 or 12 bit, at a stated frame rate, every frame — the same pixels in the same places, ready for measurement.

The full list of what else changes is covered in consumer camera vs machine vision camera; this page stays on acquisition control.

Motion blur sets the exposure budget

A moving part and a long exposure smear the image, so exposure time is not a brightness knob — it is a motion budget. The rule of thumb that decides it:

Keep the blur under one pixel and the part reads as sharp. A built-in camera cannot honor this budget because its auto exposure chooses the time for brightness, not for motion; indoors it typically lands between 1/60 and 1/30 s (17-33 ms).

Phone-style sensors add a second motion problem: they are rolling shutter, reading line by line, so a part crossing the view during readout comes out skewed even when the exposure itself is short. Global-shutter industrial sensors expose every pixel at once.

Worked example: conveyor at 300 mm/s

Setup: the camera views 160 mm across, on a 3 MP-class 4:3 sensor of about 2048 pixels across, and parts travel at 300 mm/s (18 m/min).

• Pixel scale: 160 mm / 2048 px = 0.078 mm/px.
• Exposure budget: 0.078 mm/px ÷ 300 mm/s = 0.00026 s = 0.26 ms.
• Built-in camera at a typical 1/60 s auto exposure: 300 mm/s × 0.017 s = 5.1 mm of smear, which is 5.1 / 0.078 = 65 pixels. The image is unreadable.
• Machine-vision camera at 0.2 ms: 300 mm/s × 0.0002 s = 0.06 mm = 0.77 pixels — inside the budget with margin.

The short exposure costs light: 17 ms down to 0.2 ms is 17 / 0.2 = 85× less light, about 6 stops. That is the gap a strobe-capable light and controller exist to close, and why cranking gain never rescues the case.

Trigger and frame-rate timing

On trigger, the maximum sustainable rate is set by exposure plus readout time, worked through in maximum frame rate on a hardware trigger. At a 120 fps rating, one frame period is 1000 / 120 = 8.3 ms, so a 0.2 ms exposure leaves 8.3 − 0.2 = 8.1 ms for readout and transfer. The budget closes comfortably.

Latency also separates the two worlds by orders of magnitude. A hardware trigger fires the exposure within tens of microseconds of the sensor signal; launching a device's camera app costs hundreds of milliseconds and varies shot to shot. If the line controller has to know when the picture was taken, only the trigger path gives an answer it can trust.

The 120 fps figure above is the printed rating of the LS-BCM-0003, a 3.1 MP USB3 board-level camera with an IMX252 sensor and a 1/1.8-inch global shutter.

Uncompressed frames and the bandwidth they cost

A built-in camera returns one compressed file per capture. A machine-vision camera streams raw pixels for every frame, which is what thresholds, defect sizing and any measurement need. Compression is lossy exactly where you look: artifacts concentrate around edges and fine texture, the same structures a defect check judges.

The cost is bandwidth. Take a 12 MP camera producing 4000 × 3000 mono frames at 30 fps: 4000 × 3000 × 1 byte = 12 MB per frame, and 12 MB × 30 = 360 MB/s, about 2.9 Gbit/s before protocol overhead. A GigE link moves roughly 118 MB/s of usable data, a USB3 link about 400 MB/s. So a 12 MP stream needs USB3 or faster, while 1-3 MP cameras at moderate rates fit GigE with room to spare.

For measurement-grade fields, the MV-CH120-11UC is a 12 MP USB3 color area scan camera with a global shutter, a 1.1-inch sensor and a C-mount.

Built-in vs machine-vision, capability by capability

When the built-in camera is enough

All four of these hold, and the device camera is the right tool: the part is stationary during capture and a 17 ms exposure would not smear it; the judgment is presence, color or a code read coarse enough for a human to verify; the lighting does not change between shots; nothing is measured to a dimension. Label-on-box confirmation, operator reference photos and large 1D codes that span hundreds of pixels all live here.

When the target is a PC rather than an embedded device, USB capture has its own driver and resolution constraints — see USB camera drivers and resolution limits on a PC.

Choosing the camera when it is not

Pixel scale first. Multiply the smallest feature you must see by 2 pixels, then divide the field of view by that. At the scale of the worked example, catching a 0.16 mm feature needs 0.08 mm/px, so 160 mm / 0.08 mm/px = 2000 pixels across — 3 MP class (2048 px across), not 2 MP (1600 px). The camera resolution calculator runs the same computation from your field of view and smallest feature.

Global shutter. Anything that moves during exposure needs a global-shutter sensor; rolling smear cannot be repaired downstream.

Interface. Multiply pixels × bytes per pixel × fps and compare with roughly 118 MB/s usable on GigE and 400 MB/s on USB3.

Form factor. Building the camera into your own housing points at board-level models; a standard station points at a C-mount area scan. Choosing between board modules has its own checklist in board camera evaluation for inspection systems, and powering a board — from the host port or a clean 5 V rail — is compared in camera power: USB vs external 5 V.

The smallest honest step up from a built-in camera is a board-level GigE model: the MV-CB016-10GM-M-W is a 1.6 MP mono board camera with a global shutter and an M12 lens mount.

For a standard C-mount station at a moderate rate, the MV-CU020-90GC is a 2.5 MP GigE color area scan camera with a global shutter and a 1/1.7-inch sensor.

Checks before you order

• Exposure budget: speed × time must stay under pixel scale; use half the budget as the setting.
• Trigger voltage: the input is logic-level; a 24 V PLC output needs the camera's isolated input or a level shifter.
• Bandwidth: pixels × bytes × fps against the interface's usable rate, with headroom.
• Light: at 0.2 ms you need about 6 stops more light than at 17 ms — plan a strobed light and controller, not just gain.
• Rate: parts per second on the line must stay under the triggered rate of 1 / (exposure + readout).
• Optics: a board camera needs a lens ordered for its mount (M12 or C-mount) and a repeatable working distance.

The decision

State it plainly. If the part is still, the judgment is coarse and the light is stable, keep the built-in camera and spend the effort on software. The moment a part moves at 300 mm/s, a machine event must time the capture, or a dimension gets measured, no setting inside a capture app recovers the case: order a machine-vision camera with a global shutter, set exposure from the blur budget (0.26 ms in the worked example), trigger it from the machine sensor, strobe the light, and size the interface from the bandwidth numbers.

For a compact build, start from board-level cameras; for a standard station, area scan cameras. The camera finder filters both by shutter, interface and resolution, and the camera step of the configurator walks the whole chain. If the case sits between the two, send us the part speed and the smallest feature on the contact page — the exposure budget is a five-minute calculation.