How to increase camera frame rate with ROI and pixel clock

Your camera's headline frame rate assumes full resolution, a short exposure and an empty link — three conditions an inline cell rarely meets. The fix is usually two settings, not a new camera: the region of interest, which on modern CMOS sensors cuts readout in both the x and y axes, and the pixel clock, which sets the rate pixels leave the sensor. This guide shows where your current ceiling sits, what each lever gains, and how to keep the higher data rate stable over cable and host. The worked example drives a 12 MP USB3 camera from our area scan cameras range to twice its catalog frame rate.

Find the ceiling before you change a setting

Frame rate is the lowest of three ceilings, and only the setting that owns the lowest one pays you back:

The first line is sensor readout: pixels per second divided by pixels per frame. The second is the interface: bytes the link can carry divided by bytes per frame. The third is your exposure: on a triggered global-shutter camera the period is exposure plus readout; on a rolling-shutter camera in continuous run the period tracks the longer of the two, because the sensor exposes the next rows while it reads out the current ones.

Bytes per pixel: 8-bit mono and raw Bayer are 1 byte; packed 10-bit is 1.25 and packed 12-bit is 1.5; unpacked 12-bit is 2 bytes; RGB is 3. Link rates to plan on, after encoding and protocol overhead:

Sensor timing also carries blanking rows and pixels, typically a few percent to about 15 percent on top of the active array, so measured rates land slightly under these estimates. On USB2 the same arithmetic caps far lower — USB2 bandwidth and 5 MP frame rate works a full example.

Cut the ROI in both axes

Fewer rows read out, less time per frame — partial scan has always worked that way. What changed on current CMOS sensors is the x axis: the sensor skips the columns outside the window instead of reading the full line and discarding most of it. Older designs, and CCDs, only gain from height; there a narrower window saves host bandwidth but not frame time — camera ROI and frame rate: width cuts help CMOS, not CCD covers the difference.

Run the arithmetic on an illustrative 1920 × 1200 window: 2,304,000 pixels per frame. Halve the height to 1920 × 600 and you read 1,152,000 pixels — at the same pixel clock, about twice the frame rate. Halve both axes to 960 × 600 and you read 576,000 pixels, a quarter of the work, for about four times the rate. Blanking trims each gain slightly.

Two checks decide whether a window is usable: it must still resolve the part — four to five pixels across the smallest measured feature is the usual guideline — and it must sit inside the offsets the camera software accepts, which it will tell you the moment you type an illegal number. Cropping at the camera also cuts the host's processing load before a byte reaches the PC, which cropping the ROI at the source covers in detail.

Raise the pixel clock

The pixel clock is the rate the sensor shifts pixels out, and at a fixed window the frame rate scales with it almost linearly. To hit a target rate, size the clock the other way round:

The illustrative 1920 × 1200 window at 60 fps needs 2,304,000 px × 60 = 138,240,000 px/s, about 138 MHz; add 15 percent blanking and you are at roughly 160 MHz. If the camera's clock range tops out below that number, the rate is unreachable at that window no matter what the interface can do.

In practice you raise the clock in small steps inside the camera software and re-measure after each step; the camera clamps at its stated maximum. The gains are real but bounded — one maker's pixel-clock overdrive release claimed about 30 percent on USB3 models — so treat the clock as the last tens of percent and the ROI as the multiples.

Worked example: 60 fps from a 12 MP USB3 camera

Inputs, each with its source:

• Camera: the LS-CMR-0166 — 12 MP, IMX226, rolling shutter, 4000 × 3000 resolution, 30 fps, USB3 (product data).
• Target: 60 fps (the application).
• Pixel format: 8-bit mono, 1 byte per pixel (the inspection needs grey levels only).
• Link ceiling: 400 MB/s to plan on (USB3's 5 Gbit/s line rate after encoding and overhead).

Rule: the delivered rate is the lowest of readout, link and exposure — compute all three.

1. Bytes per frame: 4000 × 3000 px × 1 B/px = 12,000,000 B = 12 MB.
2. Today's load: 12 MB × 30 fps = 360 MB/s — 360 / 400 = 90 percent of the USB3 ceiling. The link owns the current limit.
3. Full frame at 60 fps: 12 MB × 60 = 720 MB/s. No USB3 link carries that; the target is unreachable at full frame.
4. Halve the height: 4000 × 1500 = 6,000,000 px = 6 MB per frame. At 60 fps that is 6 MB × 60 = 360 MB/s — exactly the rate the camera already sustains.
5. Readout check: full-frame delivery of 12 Mp at 30 fps implies the sensor chain sustains 12,000,000 × 30 = 360 Mp/s. A 6 Mp window at that rate reads out in 6,000,000 / 360,000,000 = 16.7 ms, which is 1 / 0.0167 s = 60 fps.
6. Exposure: cap it at 16 ms. In continuous run the rolling shutter overlaps exposure with readout, so the 16.7 ms readout sets the period and 60 fps stands.

Result: 4000 × 1500 at 60 fps, 360 MB/s on USB3.

Decision: any stream above roughly 400 MB/s leaves USB3 — shrink the window, stay in 8-bit, or move to 10GigE or CoaXPress. Color triples the load: 6 Mp × 3 B/px = 18 MB per frame, and 18 MB × 60 fps = 1.08 GB/s, which is 10GigE territory.

The camera behind the numbers:

The interface is the hard ceiling

The cleanest proof that the link owns the ceiling is the same IMX226 sensor behind two different interfaces:

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.

Over GigE that sensor tops out at 9 fps; over USB3, 30 fps. Twelve megabytes per frame at 9 fps is 108 MB/s — a saturated gigabit link. The same 12 MB at 30 fps is 360 MB/s, comfortable on USB3. Nothing about the sensor changed; only the pipe did.

When the window cannot shrink and the rate cannot drop, change the pipe. The MV-CH250-25TC-F-NF moves a 25 MP global-shutter PYTHON25K stream over 10GigE.

For speed at moderate resolution, the MV-CH120-11UC pairs a 12 MP IMX304 sensor with USB3 in a high-speed configuration.

Then keep the host side stable, because that is what eats the gains you just made:

• Cable rated for the rate and as short as the cell allows — USB-C cable timeouts on a USB3 camera maps length against data rate.
• One camera per USB3 controller; sharing with storage or a second camera splits the same 400 MB/s.
• If frames arrive and then vanish, raise the host receive buffer first — two USB3 cameras at full resolution shows the setting.
• On embedded hosts, USB3 cameras sometimes enumerate at a lower link speed — read USB3 cameras falling back to a slower link on embedded GPU hosts before blaming the sensor.

Step by step

1. Measure delivered fps, not requested fps: enable the frame counter and per-frame timestamp chunk data — chunk data on camera frames explains the fields — and let it run for a few minutes.
2. Compute the data rate: rows × columns × bytes per pixel × fps, and place it against the interface table above.
3. Name the owner of the limit: the lowest of the three ceilings. Work that one only.
4. Cut the window height, re-measure, and keep cutting while the rate follows.
5. Test the width: halve it; a rise means the sensor windows in x, a flat reading means revert — width there is a bandwidth cut only.
6. Raise the pixel clock in small steps, re-checking the frame counter after each; stop at the camera's maximum or at the first dropped frame.
7. Cap exposure to the new period — 1/fps — and on a hardware-triggered camera keep exposure plus readout inside the trigger period: maximum frame rate on a hardware trigger has the arithmetic.
8. Still short? Halve the pixels with 4×4 binning vs 2×2: sensor readout decides your frame rate, or filter the camera finder by interface and step up.

When these levers will not help

Exposure-bound: at 50 ms of exposure the ceiling is 1 / 0.050 s = 20 fps, whatever the clock or the window say. The fix is photons — a stronger light, a wider aperture — not timing. If you overdrive a strobed light to get there, stay inside its rated overdrive duty cycle.

Link-bound: the camera is already delivering every byte the cable carries. More clock, or a window smaller than the part needs, just moves the failure point.

Trigger-bound: a hardware-triggered camera cannot answer a trigger that arrives before the previous frame finished — exposure plus readout, every time. The same arithmetic from the trigger's side is worked through in troubleshooting a triggered frame rate ceiling.

Host-bound: CPU pegged or buffers overflowing. A faster PC pays only here, so compare the frame counter against the trigger count before you spend money on hardware.

Checklist before you commit

• Delivered fps measured against requested, using the camera's own frame counter — a preview window's estimate is not evidence.
• Data rate computed with margin: plan at least 10-15 percent below the interface's practical ceiling.
• Width test done, so you know whether x-windowing pays before you promise a rate.
• Exposure at or below the new frame period, and inside the trigger period on triggered systems.
• Cable rated and short; the controller carries this camera alone.
• The window still resolves the part: four to five pixels across the smallest measured feature.

If the arithmetic still lands short, the decision is a faster interface, not more tuning: filter by interface in the camera finder, walk the camera step of the system configurator, read more on the cameras topic page, or raise your numbers with us through the contact page.

Everything in the example ships from the area scan range: