Multi ROI camera sensor readout: several regions, one frame

You bought the megapixels for one reason: a code in the middle of the part and three fiducials near the corners. Reading 20 million pixels to inspect four small patches spends the link, the host and the frame budget on pixels the software throws away. Multi ROI readout is the sensor-side fix: the camera reads only the rectangles you list and transmits them as one compact frame. By the end of this page you can compute the payload of any region set, know whether it buys frame rate or headroom, and pick between multi ROI, a single ROI and binning.

What multi ROI readout is

Multi ROI (multiple region of interest) readout lets one capture read several disjoint rectangles from the sensor instead of the whole frame. The camera assembles the regions into a single image and transmits it once, so your software receives one frame holding the code patch and the three fiducial patches, with nothing between them. Nothing inside a region is averaged or summed: every pixel is a real sensor pixel at full resolution. What disappears is the area you skip — and readout time, conversion power and link bandwidth all fall with it.

On a GenICam camera the regions are ordinary entries in the feature tree: an index per region with its own width, height and offset, plus a count of active regions. GigE Vision and USB3 Vision streaming both carry frames made of several regions, so a multi ROI frame is standard traffic to any compliant host library. Your software sees one image and addresses each patch by its coordinates.

The choice falls out of where the features sit:

• Several small features at known, scattered positions: multi ROI.
• One contiguous cluster of features: a single ROI, centred on the optical axis where the illumination is flattest.
• Photons are the problem, not data volume: binning.

The payload arithmetic

Three numbers decide everything: bytes per frame, the payload those bytes make at your frame rate, and which ceiling that payload hits first.

Readout and payload both scale with the area you keep. A region set covering 12% of the sensor converts about 12% of the pixels and ships about 12% of the full-frame bytes. Two overheads shave the gain: every region boundary costs a few row times on the sensor, and the fixed per-frame cost — exposure and frame transfer — stays. At 16 bits per pixel, double every byte figure.

Typical image-payload ceilings, derived from the line rates minus 8b/10b coding and protocol overhead:

• GigE (1 Gbit/s line): about 100–120 MB/s.
• USB3 (5 Gbit/s line): about 350–400 MB/s.
• 10GigE (10 Gbit/s line): about 1.0–1.1 GB/s.

Skipping rows also saves sensor power, because readout and conversion dominate a CMOS sensor's consumption; sensor designers have used region-limited readout for exactly that reason for years. The sensor ceiling is the second wall: skipped rows are not converted, so readout time falls with the rows you keep, but no region scheme pushes a sensor past its maximum readout rate. The full cycle — exposure plus readout — sets that ceiling, as maximum frame rate on a hardware trigger: exposure plus readout time works through. For the frame-rate arithmetic of a region set on one camera, multi ROI camera capture: the frame rate arithmetic does the math step by step, and if the stall is on the host rather than the link, full resolution image capture is slow or stalls: size the data first applies the same sizing discipline.

Worked example: one 12 MP sensor, two links

Take two cameras built on the same sensor. The LS-CMR-0166 is a 12 MP USB3 camera on a 1/1.7" IMX226 rolling-shutter sensor, 4000 × 3000 pixels, rated 30 fps. The LS-CMR-0053 carries the same IMX226 at 12 MP over GigE and is rated 9 fps.

Two versions of the same sensor make the comparison honest:

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.

Full frame, 8-bit mono: 4000 × 3000 = 12,000,000 pixels, or 12 MB per frame. At 30 fps that is 360 MB/s, about 95% of a USB3 link's payload. At 9 fps it is 108 MB/s, which is a 1 Gbit/s link running full. Both ratings are pinned by their links, not by the sensor — the same sensor reaches 30 fps when the link allows it.

Now inspect three features with 800 × 600 regions: one code patch, two fiducials.

• Region area: 3 × (800 × 600) = 3 × 480,000 = 1,440,000 pixels, 12% of the sensor.
• Payload: 1.44 MB per frame.
• At 30 fps: 43 MB/s ≈ 0.35 Gbit/s — about 11% of a USB3 link, about 40% of a GigE link.

The decisions follow directly. On the USB3 camera, keep 30 fps and reclaim the link: load falls from about 95% to about 11%, leaving room for a second camera or a slower host. On the GigE camera, the region set breaks the 9 fps pin — the payload fits the link even at the sensor's 30 fps ceiling, so the camera runs 3.3× faster and still leaves most of the link free.

Multi ROI vs single ROI vs binning

Binning sums neighbouring pixel values before the output: analog binning adds charges ahead of the conversion, so fewer values are converted and the frame rate rises; digital binning adds after conversion, which brightens the image while the sensor still reads every pixel. ROI vs binning vs subsampling: choosing faster acquisition compares those three on one sensor, and 4x4 binning vs 2x2: sensor readout decides your frame rate shows why the readout, not the arithmetic, sets the gain.

The per-case calls: fixtured part with scattered features, multi ROI. Features in one zone, single ROI centred on the optical axis. Dark image with detail to spare, binning. Unfixtured parts anywhere in the view, full frame and software search.

Where multi ROI earns its keep

Fixtured assemblies are the heartland: connector pin fields, weld inspection points and stamped features at fixed coordinates. A fixture makes 'known position' true, and the region set never changes. Codes plus presence checks in one shot follow the same pattern — read the data-matrix code and prove four screws seated in a single capture, the one-image-many-checks approach argued in detect multiple part types in one image instead of per-type locates.

Embedded hosts, where the link budget is shared with everything else on the board. The USB3 bandwidth and CPU budget discipline that a depth camera on an ARM SBC works through applies to any camera on a small host, and a region set is the simplest way to spend less. For a compact build:

That board camera carries the other half of the argument — a 1/1.8" IMX252 global shutter rated 120 fps, so moving parts and scattered regions live in one part number.

Large inspection sensors gain the most, because the skipped fraction grows with sensor size. The MV-CS200-10UM puts 20 MP on a 1" IMX183 sensor over USB3.0; a corners-plus-centre region set on a sensor that size is a small fraction of the frame.

Smart cameras: when processing runs on the device, capture rate and processing rate must match or the buffers fill — the failure mode smart camera image buffers full: match capture to processing rate dissects. A region set lowers both sides at once. Browse smart cameras for that architecture.

Limits and failure modes

Positions must stay known. Multi ROI assumes the feature lands inside its rectangle, so pad each region by at least twice the worst positional tolerance and re-check the fixture after any mechanical change. Parts that float anywhere in the view need a full frame and software search instead.

Region count and alignment are fixed by the sensor's readout logic — usually two to four rectangles, with no software way to add more. Four covers the classic pattern: a centre code and three corner fiducials.

The optics do not shrink. You crop on the sensor, not in the lens: the lens still covers the whole field, the working distance is unchanged, and the pixel size and exposure per pixel are unchanged. Multi ROI saves data, not photons — a dim feature needs light, not a readout mode.

The capability itself is per sensor family. When multiple regions are required, pick the camera by sensor and interface first — area scan cameras for inspection stations, board-level cameras for embedded builds — and the active region count appears in the camera's feature list.

Before you commit

• Pull region coordinates from a full-frame golden image, then pad each region by at least twice the worst positional tolerance.
• Compute the payload at your bit depth with the formula above and set it against the link ceilings; decide whether you are buying frame rate or headroom.
• Keep the pixels-per-feature requirement per region — every region keeps full pixels, so it is the same number as full frame. The camera resolution calculator does it in one pass.

• Test the skew with a moving target if the sensor has a rolling shutter.
• Keep a full-frame configuration for commissioning and diagnostics; switch region sets between runs, not mid-stream.
• Filter the camera finder by sensor format and interface, or start the camera step of the system configurator.

If the region layout is unusual — many small patches, odd aspect ratios — send the feature map through the contact page and we will run the payload arithmetic with you.