Camera resolution vs frame rate tradeoff: pick the stream

Most inspection cameras do two jobs at once: a detection stream that must keep up with the part rate, and full-quality frames you keep for study or audit. Those jobs want different resolutions, because frame rate falls as pixel count rises — the sensor needs longer to read the frame, and the link needs more bytes to carry it. The fix is to stop treating the camera as one stream: detect at the smallest region and resolution that still resolves your feature, preview smaller still, and archive one full frame per part at trigger rate. This page gives you the readout and bandwidth arithmetic behind that split, with worked examples you can copy.

The decision, up front

Run three streams, not one:

• Detection — the smallest region and bit depth that keeps at least 3-4 pixels across your smallest feature. This stream must match the part rate; if 640 × 480 resolves the feature, run 640 × 480.
• Preview — a quarter-scale, compressed copy of the detection stream for the HMI. A human needs a few frames per second, not thirty.
• Archive — the full sensor, one frame per trigger, written to disk.

A common robot-guidance pattern makes the point: a wrist-mounted camera whose sensor tops out at 2560 × 1920 runs its detection at 640 × 480. Quarter the width and quarter the height, and the pixel count falls to 1/16, so the sensor reads each frame in a fraction of the time. When you want the detail as well, grab a full frame on trigger instead of streaming continuously — the approach in full-resolution capture with a low-resolution preview.

Keep images out of the PLC altogether: results go there, pixels go to the HMI and the disk.

Why frame rate falls as resolution rises

Two multipliers work against high resolution: readout time inside the sensor, and bytes on the wire after it.

A CMOS sensor reads row by row at a pixel rate it cannot exceed. Four times the pixels means roughly four times the readout time, so maximum frame rate falls with area unless you crop or bin. The interface must then carry the result: a 4000 × 3000 frame at 8 bits per pixel is 4000 × 3000 × 1 B = 12 MB, and at 30 fps that is 12 MB × 30 = 360 MB/s. Your delivered frame rate is the lower of the sensor's readout limit and the link's payload.

What each interface can carry

Most area scan cameras ship on one of five interfaces, and the usable payload — not the line rate — is what you plan with:

Payloads are what is left after line encoding, packets and protocol; the GigE figure needs jumbo frames end to end, and default packet sizes land closer to 95 MB/s. For 5GBASE-T, bandwidth, cable and distance limits decide what you actually reach. Whichever interface you use, the rule is one line: delivered frame rate equals the lower of the sensor cap and the link cap.

Worked example: one sensor, two interfaces

The cleanest demonstration is two cameras that share a sensor. The LS-CMR-0053 is a 12 MP GigE camera on the IMX226 sensor, rated 9 fps. The LS-CMR-0166 is the same 12 MP IMX226 sensor on USB3, rated 30 fps at 4000 × 3000.

Run the arithmetic at 8 bits per pixel:

• Frame size: 4000 × 3000 × 1 B = 12 MB.
• GigE: 12 MB × 9 fps = 108 MB/s, about 0.86 Gbit/s — sitting on the practical GigE ceiling. The link, not the sensor, sets 9 fps.
• USB3: 12 MB × 30 fps = 360 MB/s, inside the 350-450 MB/s that USB3 sustains, so the sensor runs at its own readout limit.

Same sensor, more than three times the delivered frames: the interface chose the frame rate. Bit depth moves the same numbers — at 2 bytes per pixel the frame is 24 MB, and a 108 MB/s link delivers about 108 ÷ 24 = 4.5 fps. If you need 12 MP at part rate, pick the interface before the camera:

All 2 share: Sensor size 1/1.7". Values as printed in each product's data sheet; open a part for its drawing and full specifications.

How small can the detection stream be?

The floor is set by your smallest feature. Rules that hold across inspection work: 2 pixels is the theoretical floor, 3 pixels finds a feature, 4-5 pixels measure it.

Worked example: the smallest defect is 0.5 mm and you want 4 pixels across it, so the stream needs 0.5 ÷ 4 = 0.125 mm per pixel on the object. A 640-pixel width then covers 640 × 0.125 mm = 80 mm, and a 480-pixel height covers 480 × 0.125 mm = 60 mm. A 640 × 480 stream is sound for an 80 × 60 mm field; a 200 mm field needs 200 ÷ 0.125 = 1600 pixels across, so 1600 × 1200.

The bandwidth reward is large: 640 × 480 × 1 B = 0.3 MB a frame, and 0.3 MB × 30 fps = 9 MB/s, which any link carries with room to spare — the sensor's readout becomes the only limit. Size your own stream with the camera resolution calculator:

Two ways down: ROI and binning

Cropping and binning both cut pixel count; they differ in what they keep.

• Region of interest keeps the native pixel scale and drops everything outside a rectangle. Readout time falls with the cropped area, which is why small regions sustain high frame rates; the multi-ROI frame-rate arithmetic works the sums.
• Binning sums charge over a block of pixels: 2 × 2 binning quarters the pixel count and collects four times the electrons per output pixel, which helps when exposure time is short. The readout consequences are in 4×4 binning versus 2×2.

Decide by the part: a known, stable feature location takes an ROI; an unknown location with modest detail takes binning over the whole field; both together take a binned region.

One caution the frame-rate gain hides: a rolling shutter still reads lines sequentially in time, so a fast-moving part distorts no matter how high the cropped rate climbs. When parts move, give the detection stream a global shutter:

The MV-CU020-90GC is a 2.5 MP global-shutter GigE camera, the pixel-count class that keeps detection at part rate.

Archive full frames at trigger rate

The detection stream decides pass or fail; the archive proves it weeks later. Trigger one full-resolution frame per part — or per flagged part — and write it to disk; the rates stay modest. Set the camera to trigger rather than free-run, as covered in per-camera hardware trigger configuration.

Take the MV-CS200-10GC, a 20 MP camera on GigE. A 20 MP frame at 8 bits is 20 MB. One frame every 2 s is 20 MB ÷ 2 s = 10 MB/s on average, which an industrial SSD writes all day. Streaming the same camera continuously is a different problem: 20 MB × 20 fps = 400 MB/s, a 10GigE-class link and a disk array. Triggering one still from the detection result is the pattern in triggering a full-resolution still from an on-device detection; for genuinely continuous capture, plan the whole path first with streaming camera images to disk at high frame rate and the data-rate arithmetic of 2000 fps recording.

What goes to the PLC, and what to the HMI

A PLC has no use for pixels. Its registers hold bits and numbers: a 12 MB frame does not fit, and the control cycle does not need it. Send the pass/fail bit and the measurements — sending pass/fail results to a PLC covers that path — and give the images two other channels. The HMI shows a live low-resolution stream or the last triggered frame; what actually displays live in a PLC HMI sorts that choice. If the HMI pulls an MJPEG stream, MJPEG stream configuration troubleshooting lists the settings that stall one.

A smart camera shortens the path: detection runs on the device, so only results and the occasional image ever leave it. The LS-SMC-0017 is an 8.8 MP smart camera with a global shutter and a C-mount.

When the usual answer is wrong

• The feature location is unknown. An ROI has to know where to look. Bin instead, or keep full resolution and buy the interface that carries it.
• The detail is the defect. At 0.125 mm per pixel, a 0.05 mm scratch does not exist. Seeing it at 4 pixels needs 0.05 ÷ 4 = 0.0125 mm per pixel, and 80 mm ÷ 0.0125 = 6400 pixels across: full resolution at a slower rate, not a bigger ROI.
• Parts move under a rolling shutter. A higher cropped frame rate does not fix line-by-line distortion; change the shutter type or add light and shorten exposure.
• Two cameras share one host. USB3 payloads add up: two cameras at full resolution and USB timeouts at high resolution cover the buffers and pacing that fix it.
• The headline rate is not your rate. Peak fps is quoted at one mode. Run your mode, then measure the delivered frame rate before you commit the cycle time.

Checks before you commit

• Data rate at the resolution and bit depth you will run: width × height × bytes per pixel × fps, against the payload table above.
• Frame rate at your ROI or binning mode, from the camera's own table for that mode.
• Shutter type against part motion.
• Jumbo frames end to end on any GigE link.
• Host buffers and sustained disk write for the archive stream.
• A rigid mount: at 0.125 mm per pixel, 0.1 mm of vibration blurs the edge you are measuring. The camera stands category carries them; the LS-MNT-0040 is a professional slide-table stand with a 700 mm height on a 400 × 450 mm base.

Once the resolution and the interface are fixed, the camera finder and the configurator narrow the list, the cameras topic page collects related guides, and numbers you want checked go to the contact page.