Camera ROI and frame rate: width cuts help CMOS, not CCD

You inspect the middle third of the field, but the camera still reads and ships all 15.8 million pixels of every frame, and the frame rate stays at the full-frame pace. The camera's own region of interest fixes that: write Width, Height, OffsetX and OffsetY, and only those pixels leave the sensor. Whether the same edit also buys frames per second depends on one thing - how the sensor reads out. A height cut speeds up every sensor; a width cut speeds up only CMOS, because a CCD shifts every row out whole no matter how few columns you keep. Here you will set the region with the right granularity, predict the new rate from the pixel count, check it on the bench, and decide when a smaller sensor beats a cropped one.

What an on-camera ROI actually changes

The region of interest is a camera feature, not a driver filter. On a GigE Vision camera it lives in the camera's GenICam feature map - the same register space you touch in accessing GigE camera registers at runtime from your control code - as four values: Width, Height, OffsetX and OffsetY. Once they are written, the sensor reads only the addressed rows and columns, and the camera transmits only that payload. Your acquisition buffer then holds Width × Height pixels per frame, nothing more.

Cropping in software after acquisition is not the same thing. The sensor still reads the full frame, the link still carries every byte, and the frame rate stays exactly where it was. Crop after the camera when the region must break the granularity grid; crop in the camera when you want the time back.

Two limits shape what you can write. The camera enforces OffsetX + Width ≤ sensor width and OffsetY + Height ≤ sensor height at every instant, and it accepts values only on its granularity grid - steps of 2, 4 or 8 pixels on most sensors. The increment value the features report in a GenICam browser is the number to plan around.

Where the speed comes from: CCD and CMOS readout

A CCD moves charge out of the sensor by shifting every row into a single output amplifier, one row after another. The shift clock runs at a fixed rate, and it shifts the entire row whether you keep 4872 columns or 2436. The camera can throw unwanted columns away on the way to the network cable, but the sensor has already spent the time shifting them. Remove rows, though, and you remove whole shift cycles: readout time falls in proportion to Height. On a CCD, Height is the only axis that buys frame rate.

A CMOS sensor addresses rows and columns directly. Its column-parallel ADCs convert the columns you address and skip the rest, so fewer columns means a shorter digital readout per row, and fewer rows means fewer row reads. Both axes cut readout time, and both buy frame rate - up to the point where the fixed conversion overhead per row dominates and further width cuts stop paying.

Binning interacts with the same arithmetic: 4x4 binning versus 2x2 readout shows how the readout mode, not just the pixel count, sets the frame interval.

Worked example: one sensor, four regions

The example sensor is 4872 × 3248 = 15,824,256 pixels, streaming Mono8 over GigE with a 10 ms exposure. One Mono8 frame is 15,824,256 bytes, about 15.8 MB. A GigE link moves roughly 118 MB/s of payload - 1 Gb/s ÷ 8 = 125 MB/s, less packet overhead with jumbo frames enabled - so the full frame needs 15.8 MB ÷ 118 MB/s ≈ 134 ms to transfer on its own. Give the sensor a 135 ms full-frame readout, an example input consistent with the roughly 7 fps that sensors of this size delivered over GigE at full resolution. That puts the row time at 135 ms ÷ 3248 rows ≈ 41.6 µs, and every number in the table follows from frame period = max(exposure, readout, transfer).

The offsets 1218 and 812 center each region: (4872 - 2436) ÷ 2 = 1218 and (3248 - 1624) ÷ 2 = 812, both on the even grid the granularity rules demand.

Read the CCD column against the CMOS column at half Width: identical pixel counts, identical payload, identical transfer time - and 7.4 fps against 14.8 fps. Row time is the whole difference. On the CMOS sensor, halving Width halves the row to about 20.8 µs, so readout falls to 67.5 ms just as the height cut does; the CCD's shift clock never notices the width. The 10 ms exposure stays under every frame period in the table; push exposure past the new period and exposure becomes the limiter, which is the effect why your GigE camera frame rate drops at longer exposure times quantifies.

On a CCD, a width cut returns bandwidth and nothing else, so use it only when the link is the bottleneck - when frames per second is the goal, Height or a smaller sensor is the move.

Set the region step by step

1. Baseline the frame period first - timestamps in your acquisition loop or the fps readout in your SDK - at the exposure you actually run. You need this number to tell a readout limit from an exposure limit after the change.
2. Stop acquisition. Most cameras reject writes to Width, Height, OffsetX and OffsetY while the sensor is streaming, so write the region before acquisition starts.
3. Set size before position. Write the new Width and Height first, then OffsetX and OffsetY. OffsetX + Width must stay within the sensor at every write; shrinking the size first can never break that rule, while pushing the offsets out with the old size usually gets rejected. For the centered half-size region above: Width 2436, Height 1624, then OffsetX 1218, OffsetY 812.
4. Stay on the granularity grid. Round your targets to the increment the features report - the 2, 4 or 8 pixel steps - and recompute the offsets so the region stays centered. An off-grid write is rounded silently, and the region lands a few pixels from where you wanted it.
5. Restart and check the payload. The buffer must now be Width × Height × bytes per pixel; for Mono8 the row stride equals Width in bytes. Code that still allocates the full-frame stride puts every row after the first in the wrong place - the classic symptom of a region set in the camera that the receiving code never heard about.
6. Measure and compare against the table's logic: payload scales with Width × Height, readout scales with Height on every sensor and with Width only on CMOS. A width cut that returns bandwidth but no frames means a CCD or a firmware-cropping camera.
7. Persist the region if it must survive power cycles: load it into the camera's startup user set, or write it in code before every acquisition start. The write-then-read-back pattern is identical to setting camera exposure time through a GenICam API; only the feature names differ.

When the width cut does nothing

Three cases break the CCD-versus-CMOS rule, and one measurement settles all of them: log the frame period at the shortest exposure the camera allows, then compare across region settings.

First, firmware cropping. A few cameras read the full sensor and cut the region in the FPGA on the way out. The payload shrinks and the pace does not, and no camera setting changes that. Second, the row-time floor. On CMOS, a width cut shortens the digital part of each row, but the conversion overhead per row is fixed; below roughly a quarter of full width that overhead dominates and further cuts stop paying. Third, the trigger. A triggered camera follows its trigger pace, and the region only sets how quickly the camera is armed for the next one; troubleshooting a triggered camera's frame rate walks that path end to end.

When the ROI math says you need a different camera

If the arithmetic ends with you inspecting two of sixteen megapixels forever, the faster path is a sensor that natively matches the field of view: no offsets to manage, no granularity fights, and full frame rate without surgery. A 2.5 MP region is the most common landing point after this math. The MV-CU020-90GC covers it with its native 2.5 MP color frame over GigE and a global shutter, so the rate arrives without cropping at all.

Large fields want large sensors, and trimming a 20 MP ROI down to 12 MP still leaves a serious payload. The LS-CMR-0166 delivers its full 4000 × 3000 resolution at 30 fps over USB3.

Checks before you trust the new frame rate

• Name the sensor technology before you commit to a number: the camera's data sheet lists the sensor, and the sensor name settles CCD versus CMOS.
• Keep exposure under the new period with margin: at 67 ms per frame, hold exposure near 55 ms or less so overhead cannot push you over.
• Watch link health after any region change, because a mis-set region can look like a transport fault; horizontal lines from GigE Vision packet loss shows the symptom.
• Count several disjoint regions separately if your camera exposes multiple ROIs; the multi-ROI frame-rate arithmetic shows how their rates combine.
• Budget the link before the sensor: payload × target rate against the usable link rate, worked fully in how much frame rate fits down a GigE Vision link.

The decision, and where to point it

Cut Height whenever the inspection allows it; every sensor gains in proportion. Add a width cut when the sensor is CMOS. Skip it on CCD, and spend the effort on Height, exposure or a smaller sensor. When the region is a small fixed fraction of the sensor, buy the sensor that matches the region instead of cropping the big one forever. From this arithmetic to a parts list: the area scan cameras category, the camera finder, the camera step of the configurator, and the systems topic page for the rest of the integration guides.