Camera ROI cropping at the source: reduce bandwidth before the host

Cropping in software after the image arrives feels free, but the full frame has already crossed the camera link, consumed bus bandwidth and been copied into host memory. If you are hitting a frame-rate ceiling, saturating a shared USB3 or GigE bus, or burning CPU on frames you throw away, the crop has to happen inside the camera. This explainer covers what hardware region-of-interest (ROI) readout is, the arithmetic that makes it worth doing, which GenICam features control it, why depth-plus-RGB devices often cannot do it at all, and what to do instead. It is written for anyone integrating industrial cameras into a vision or robotics pipeline.

What hardware ROI cropping actually is

A readout ROI (sometimes called an area of interest, or AOI) is an instruction to the sensor itself: transfer only rows y0 to y0+H and columns x0 to x0+W, and skip the rest. Because the skipped pixels never leave the sensor, every stage downstream shrinks:

• The camera's internal readout time per frame drops, so the maximum frame rate rises.
• The link carries fewer bytes, so a shared bus can host more cameras or a longer cable run.
• The host processes, copies and queues fewer pixels, cutting CPU load.

A software crop — slicing a NumPy array or an OpenCV Mat after acquisition — achieves none of these. The pixels you discard still cost you their full bandwidth on the way in. The distinction matters most on multi-camera systems, where the shared bus is the bottleneck; the guide to multi-camera RGB synchronization covers how exposure timing interacts with that same ceiling.

The bandwidth arithmetic

Sensor data rate is simple multiplication:

A worked example: a 3088 × 2076 rolling-shutter sensor in mono8 transfers 6.4 MP per frame, about 6.4 MB. At 30 fps that is roughly 192 MB/s — already more than a single USB3 link sustains in practice, and a large share of a GigE link's ~125 MB/s. Now crop to the central 1544 × 1038 window, one quarter of the pixels:

• 1544 × 1038 × 1 byte × 30 fps ≈ 48 MB/s.
• Same frame rate, one quarter of the bus load — or, run the same link at up to about 120 fps within the same budget.

Add 2×2 binning on top and you are at 772 × 519 pixels, roughly 12 MB/s at 30 fps, with better signal-to-noise from the summed charges. If you are sizing the camera itself for this, the camera resolution calculator tells you how many pixels your feature actually needs — often far fewer than the full sensor.

The GenICam features that do it

On any GenICam-compliant industrial camera — GigE Vision and USB3 Vision models alike — the crop is exposed as standard features in the acquisition control group:

• Width and Height: the size of the readout window in pixels.
• OffsetX and OffsetY: where the window sits on the sensor. Many sensors require even offsets or a minimum step, and the sum of offset plus size must stay inside the sensor.
• BinningHorizontal / BinningVertical: sum or average adjacent pixels on the sensor, cutting resolution and bandwidth while gaining light.
• DecimationHorizontal / DecimationVertical: skip every Nth pixel or row, cutting bandwidth without the noise benefit.

The usual sequence is: stop acquisition, set Width and Height first, then OffsetX and OffsetY, then restart. Setting the offsets before the size can push the window off the sensor and produce a range error. If a feature you expect is missing, the discovery technique in GenICam exposure feature discovery for missing attributes applies to ROI features too — they may be hidden behind a selector or an implementation-specific naming.

Which cameras support it

Virtually every industrial area scan and board-level camera in the area scan cameras and board-level cameras ranges exposes full readout ROI, binning and decimation through GenICam, because the underlying CMOS sensors support windowed readout in hardware.

The MV-CU020-90GC is a typical compact GigE choice for a fixed inspection window, and the USB3 LS-CMR-0053 works the same way on a USB3 Vision stack. On the embedded side, the MV-CB016-10GM-M-W shows that even a small board-level module keeps the full feature set — the selection guide to board level camera selection for embedded vision machines goes deeper on matching these modules to compute-limited hosts, where saving host CPU matters most.

When the answer is no: depth-plus-RGB devices

Commodity depth-plus-RGB cameras are the common disappointment here. Their depth stream is usually produced by an onboard processing pipeline (structured-light or ToF correlation) that needs the full sensor readout to compute; firmware cropping of the depth image is simply not offered. What the SDK does expose is an auto-exposure ROI — a metering window that tells the exposure algorithm which pixels matter. That changes exposure behavior, not readout, and not bandwidth. Mixing the two up is the single most frequent confusion with these devices; the symptom of the metering variant feeding back into image statistics is covered in auto exposure ROI instability from detection feedback.

Before giving up, check two things on the specific model:

1. Whether the depth stream offers resolution presets or a "region mode" separate from the exposure ROI. Some do, at a fixed set of sizes rather than arbitrary windows — the practice of depth camera ROI z-layer configuration shows what that looks like when a vendor does expose it.
2. Whether the RGB stream, which is often a separate conventional sensor, supports its own windowing even when the depth stream does not.

For fixed-mount industrial 3D sensing, laser profilers and structured-light cameras in the 3D sensors range handle windowing differently again — profile height and ROI are set in the sensor's own configuration rather than in a general camera API. The MV-DT01WMU ToF camera is one example of the depth-camera class where you should verify cropping support against the documentation before designing around it.

What to do when firmware cropping is unavailable

If the camera cannot crop, change the optics so fewer wasted pixels exist in the first place:

• Longer focal length or shorter working distance. Fill the frame with the object of interest. The relation is the standard imaging formula: magnification m = sensor width / field of view, and f = WD × m / (1 + m). If the object occupies only a quarter of the sensor width, you are transferring four times the pixels you need.
• A lower-resolution variant of the same camera family. If your measurement only needs 1000 pixels across the part, a 12 MP sensor is paying bandwidth for nothing.
• Reduce depth or RGB stream resolution in the SDK where presets exist, even if arbitrary windows do not.
• Accept the software crop, but budget the link for the full frame: check frame-rate limits against pixel format and exposure as described in RGB camera frame rate limits so the uncropped stream still fits your bus.

The lens format trade-offs involved in matching sensor size to optics are explained in lens sensor format explained; cropping does not change the lens's field of view, only which part of it you keep.

Checks before you order

1. Confirm in the camera's feature list that Width, Height, OffsetX and OffsetY are writable, not fixed.
2. Note any constraint steps: minimum ROI size, even offsets, and whether binning is available at the resolution you want.
3. Compute your target bytes per second with the formula above and compare against the link (roughly 125 MB/s for GigE, ~350-400 MB/s practical for USB3).
4. If depth data is involved, confirm in writing that the depth stream supports cropping or resolution modes — an auto-exposure ROI is not that.
5. Check the camera's maximum frame rate at your ROI size in the documentation, since readout limits, not the bus, can cap you first.

Quick checklist

• Prefer hardware ROI over software crops wherever bandwidth or CPU is a constraint.
• Set Width/Height before OffsetX/OffsetY; stop acquisition first.
• Use binning for low light plus bandwidth; decimation for bandwidth only.
• An auto-exposure ROI meters, it does not crop.
• Depth-plus-RGB devices: check presets, then fix it with the lens or working distance.
• Size the bus for the uncropped frame unless the crop is truly in firmware.

If you are unsure whether a specific model supports windowed readout at the size you need, send the part list and frame-rate target through the contact page and we will check it against the data sheets, or start from the camera finder and the system configurator.