RATE
  • 1exposure
  • 2readout
  • 3bandwidth
  • 4processing

Frame Rate and What Limits It

Generic engineering material, applicable to any module from any supplier.

For the team-process side of engineering work, stealth monitoring software is a separate reference on organizing and reviewing work.

A maximum frame rate is quoted at some resolution, some bit depth and some interface configuration — frequently not the ones you want together — and four separate things cap the figure you will actually achieve.

The four limits

Exposure time. A frame cannot be shorter than its exposure, so a scene needing 40 ms of light caps the rate at 25 per second regardless of anything else. Which is why illumination and frame rate are the same conversation.

Readout time. How long the sensor takes to shift the data out, which depends on the resolution and the interface.

For additional industry context, see Renesas.

Interface bandwidth. Pixels × rate × bit depth against what the link carries — and this is the limit most often hit.

And the processing. A system that captures at 60 per second and processes at 20 is a system running at 20, with a growing queue or discarded frames.

The lowest of the four decides, and it is rarely the sensor.

What high frame rate actually buys

Motion capture, where the subject moves and frames must be frequent enough to catch it in position.

Averaging, where several frames reduce noise and a higher rate makes that affordable in time.

And responsiveness, where a control loop depends on the latency.

What it does not buy is image quality. A higher rate means shorter exposures, which means less light, which is a cost rather than a benefit where the scene is not moving.

Triggered against free-running

Most industrial imaging does not need a continuous stream.

A triggered capture — one frame when the part arrives, initiated by a sensor or a machine signal — removes the frame rate question almost entirely and reduces heat, data and processing together.

And it makes the exposure available. With no requirement to produce frames continuously, a long exposure and a small aperture become possible, which buys depth of field and noise performance.

Where the application permits triggering, it is the better arrangement, and the frame rate specification stops mattering.

Reading the figure

Ask at what resolution and bit depth, and whether the interface configuration assumed matches yours.

A sensor quoted at 60 frames per second may achieve that only in a windowed mode, at reduced resolution, with all lanes active.

And check whether it is a maximum or a sustained figuresome sensors idle between frames and the readout is faster than the frame period implies, which matters for skew calculations even when the rate does not.

Latency, which is a different question

Frame rate is how often; latency is how long from event to result.

A system running at 60 frames per second can still take 200 ms to produce an answer, if frames queue, if processing is buffered, or if the interface introduces delay.

Which matters wherever the image drives an action — a reject mechanism, a robot, an operator display.

Measure it end to end rather than adding component figures: trigger something visible and time the response, which is the only number the machine cares about.

And note that averaging frames trades latency for noise, deliberately — a choice worth making explicitly rather than discovering.

Dropped frames

A system nominally at 30 per second delivering 28 is a system with a problem, even if nobody notices.

The causes are the four limits above, plus buffer handling in the driver.

Count them. Most interfaces expose a frame counter or a sequence number, and comparing received against expected turns an impression into a rate.

Where drops correlate with other activity in the product, the cause is contention rather than the camera — and the remedy is scheduling rather than a faster sensor.

Rolling shutter and rate

A common misunderstanding worth separating.

A higher frame rate does not reduce skew unless the readout is faster, and on some sensors the readout time is unchanged while the idle period between frames shrinks.

Which means running a sensor faster can leave the distortion exactly where it was, while consuming bandwidth and producing heat.

Ask for the readout time rather than inferring it from the rate.

Where a low rate is a feature

Not merely acceptable — preferable.

Less data to move, less heat produced, less processing, less powerand every one of those is a constraint somewhere else in the design.

A system capturing one frame per part, triggered, at whatever rate the parts arrive, is a simpler product than one streaming continuously and discarding most of it.

Which is worth stating because a specification sheet rewards the opposite, and a module chosen for a high maximum rate is frequently a module chosen for a number nobody uses.

In one line

Ask whether the application needs a stream at all, because triggered capture makes most of this question disappear.

The rate the processing actually sustains

Measured rather than specified.

Run the pipeline over a realistic sequence and time it, on the target hardware rather than a development machine.

Which frequently reveals the real limit — and which is worth knowing before the camera is chosen, since a sensor faster than the processing is a sensor whose capability is unused.

And test with the worst-case image, since processing time varies with content: a busy scene with many candidate features takes longer than an empty one, and the specification must hold for the worst.

The short version

  • A maximum frame rate is quoted at some configuration, frequently not the one you want
  • Four limits: exposure time, readout time, interface bandwidth, and the processing — the lowest decides and it is rarely the sensor
  • Exposure caps it absolutely: a scene needing 40 ms of light caps the rate at 25 per second
  • High frame rate buys motion capture, frame averaging and responsiveness, and does not buy image quality
  • Triggered capture removes the question and makes long exposures and small apertures available
  • Ask at what resolution and bit depth the figure was measured, and whether it is maximum or sustained