4x4 binning vs 2x2: sensor readout decides your frame rate

Set binning to 2x2 and the frame rate climbs the way you expect. Set it to 4x4 and, on many GigE cameras, the rate falls back below the 2x2 value — even though the image is four times smaller and the network link sits barely a third utilized. The cause is not bandwidth. It is where the sum happens: on the sensor, in the FPGA, or in the image signal processor (ISP). A measured 12 MP example below shows the effect, the arithmetic separates the wire, the sensor readout and the ISP, and a three-step test finds which stage sets the ceiling on your own camera.

What does binning change on a digital camera sensor?

Binning adds the values of neighboring pixels into one: done on the sensor it also shortens the sensor readout and can double the frame rate, but done downstream in an FPGA or an ISP it only shrinks the image after every pixel has already been read out.

Charge-domain binning, the classic CCD mechanism, sums electron packets before digitization: fewer conversions, shorter readout, so 2x2 can double the rate and 4x4 can quadruple it. On many machine-vision CMOS designs the sensor has no such mode, and the camera adds values digitally after readout. The sum then runs either in the FPGA — a small, fast step on the data path — or in the ISP, a processing pipeline with a fixed per-frame cost that handles debayering and format conversion. Summing four pixels multiplies signal by four while uncorrelated noise grows only twofold, so binning also buys signal-to-noise ratio. The cost is resolution: each output pixel now covers the area of four sensor pixels, and Sum mode can clip bright highlights where Average mode keeps brightness but gives up part of the signal gain.

Why can 4x4 binning be slower than 2x2?

Because 2x2 is summed in the camera's FPGA before the ISP while 4x4 has to pass through it: on a 12 MP color GigE camera the measured rate went 8.99 fps at 1x1, up to 15.11 fps at 2x2, then fell to 10.01 fps at 4x4.

The example camera has no charge-domain binning, so the sensor always reads all 12,288,000 pixels and the only variable is what happens afterward. At 2x2 the FPGA adds pairs of lines and columns on the way out, a step light enough to bypass the ISP — the 15.11 fps holds with a raw, ISP-bypassed pixel format — and the rate rises to the sensor readout ceiling. A 4x4 accumulation needs larger block sums, and on this design that work sits inside the ISP, whose fixed per-frame budget pulls the rate back down. A 5 MP sibling measured the same shape: 21.94 fps, then 35.69 fps, then 24.35 fps. The gain you keep is about 1.7x, not the 4x the smaller image suggests.

Frame times are 1 ÷ fps: 1 ÷ 8.99 s = 111 ms, 1 ÷ 15.11 s = 66 ms, 1 ÷ 10.01 s = 100 ms. The 4x4 mode spends roughly the same processing budget as full resolution — about 100 ms — which is exactly why it lands below 2x2.

Is the GigE link the limit, or the camera pipeline?

Compute the data rate and the answer falls out: the 2x2 image is 2048 × 1500 = 3,072,000 pixels, 3.07 MB at 8 bits, and 3.07 MB × 15.11 fps = 46.4 MB/s ≈ 371 Mbit/s, about 37% of a 1,000 Mbit/s GigE link — the wire is mostly idle.

Run the formula across all three settings: 12.3 MB × 8.99 fps = 110 MB/s (884 Mbit/s), 3.07 MB × 15.11 fps = 46.4 MB/s (371 Mbit/s), 0.77 MB × 10.01 fps = 7.7 MB/s (62 Mbit/s). Even the full-resolution stream leaves about 12% of the line free, and at 4x4 the link carries 6% of its capacity. The observed link utilization of roughly 40% at 2x2 matches the 371 Mbit/s figure, a good sign the arithmetic describes the real link. This is also why raising the acquisition-frame-rate setting does nothing: the camera clamps it to what the pipeline delivers, and the pipeline, not the network, is full. For the exposure side of the same story — a long shutter stretches frames just as a slow pipeline does — see the GigE frame rate and exposure time article.

How fast can the sensor itself read out?

The 15.11 fps result pins the readout: 1 ÷ 15.11 s = 66 ms per full frame, so the sensor clocks about 12.3 million pixels at roughly 186 Mpx/s — a fixed cost that no amount of binning changes, because digital binning happens after the pixels are read.

The derivation is plain division: 12,288,000 pixels ÷ 0.066 s ≈ 186 Mpx/s pixel clock, a typical figure for a 1/1.7-inch, 12 MP rolling-shutter CMOS. At full resolution the frame takes 111 ms, so the ISP path adds about 45 ms of processing on top of the 66 ms readout. Those two numbers predict the whole table: any mode that bypasses the ISP runs at the 66 ms readout rate (15.1 fps), and any mode that routes through it pays 100-111 ms (9-10 fps). Exposure sits outside this at short shutter times — at 1 ms it contributes almost nothing — but a long exposure adds directly to frame time and drags every mode down together.

When does the GigE wire become the limit instead?

At full resolution the wire wins: 4096 × 3000 at 8 bits is 12.3 MB per frame, and 12.3 MB × 8.99 fps = 110 MB/s ≈ 884 Mbit/s, about 88% of a 1 Gbit/s line — close to the practical ceiling once Ethernet, IP and protocol overhead are paid.

A 1 Gbit/s link moves 125 MB/s at the physical layer, and with jumbo frames the usable payload lands around 115-120 MB/s, so full-resolution 12 MP 8-bit mono over GigE saturates in the 9 fps class. Color costs three times the bytes: a 24-bit RGB stream of the same frame would need about 330 MB/s, nearly three wires' worth, which is why full-rate color belongs on faster interfaces. The fixes, in order of cost, are bytes (raw or mono pixel formats), pixels (a smaller region of interest) and hardware (a faster interface). If you are choosing hardware rather than tuning, start from the area scan cameras category and filter by interface first.

For the same 12 MP, 1/1.7-inch sensor class on GigE, the catalog prints 9 fps at full resolution — exactly where the arithmetic above puts the ceiling.

How do you find the limit on your own camera?

Measure the rate at binning 1, 2 and 4 with a short exposure and everything else at default, convert each result to Mbit/s, and read the pattern: whichever stage sits at its ceiling while the wire stays idle is the one that sets your limit.

1. Set exposure to a short value such as 1 ms so shutter time cannot limit the rate, and leave gain, packet size and every other setting at default.
2. Record the achieved frame rate at binning 1, 2 and 4, then once more at 2x2 with a raw or ISP-bypassed pixel format if the camera offers one — the jump between the two is the ISP's cost, measured directly.
3. Convert each result with the formula above and compare it with about 1,000 Mbit/s of line rate on GigE, or roughly 3,500-4,000 Mbit/s usable on USB3.

Read the results this way:

• Wire at 85% or more of capacity: interface-bound. Shrink the image, cut bytes per pixel, or move to a faster interface.
• Wire idle and the raw format jumps the rate: ISP-bound. Keep the raw format in production if your tools accept Bayer, or choose a camera that bins before the ISP.
• Rate unchanged by format and pinned at 1 ÷ frame time: sensor-bound. Only a smaller region of interest or a faster sensor helps.

The frame-rate bottleneck article walks this same search stage by stage, and the USB link bandwidth article covers the interface side, where a shared hub or small packet size mimics these symptoms.

Does binning still buy anything at 4x4?

Yes — summing four pixels combines their signal while uncorrelated noise grows only by 2, so the signal-to-noise ratio roughly doubles, about 6 dB, worth two stops in shot-noise terms; it is just not a speed feature on cameras without on-sensor binning.

Use 4x4 deliberately: dim or flickering scenes, coarse presence-and-position checks, any task whose smallest feature is far larger than the binned pixel. The resolution cost is real: 2x2 doubles the sampling pitch, so a 5 µm pixel grid behaves like a 10 µm grid and the smallest resolvable feature doubles with it. That relaxes the sensor-lens match — a lens chosen for the full pixel count has margin to spare at 2x2, as the Nyquist limit and camera resolution article works through. If you need the noise gain at full resolution, keep 1x1 and average frames in software; that preserves the pixel grid and costs host processing time instead of camera rate.

What raises frame rate if binning will not?

Shrink the readout or widen the pipe: a smaller region of interest cuts rows directly, a raw pixel format removes the ISP stage, and a faster interface moves full frames — the same 12 MP sensor that prints 9 fps over GigE prints 30 fps over USB3.

Rank the options by cost. Region of interest is free and scales with readout: on a readout-bound camera, halving the rows roughly halves the frame time. Pixel format is free too: mono or raw 8-bit cuts bytes per pixel and, on ISP-bound designs, removes the processing stage altogether. Interface hardware is the big lever. The shop stocks one 12 MP sensor family on both GigE and USB3, and the catalog rates tell the story: 9 fps against 30 fps at 4000 × 3000, a 3.3x gain from the wire alone, because 12 MB × 30 fps = 360 MB/s ≈ 2.9 Gbit/s — a load only a USB3-class link or faster carries. Compare the two versions of that sensor:

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.

The LS-CMR-0053 prints 9 fps over GigE; the LS-CMR-0166 prints 30 fps over USB3, both on the same IMX226, 1/1.7-inch, 12 MP rolling-shutter sensor.

Decision: on a GigE camera of this design, credit binning with about 1.5-1.7x at 2x2 and treat every 4x4 figure as unmeasured until the three-step test says otherwise; if the cell needs more throughput than the sensor readout allows, buy the faster interface rather than binning the problem away. The camera finder filters area scan models by interface, resolution and shutter, and the camera step of the configurator pairs the sensor with a lens and light that keep up. More on this topic sits on the cameras learn page.