Camera fps lower than the datasheet: turn off auto functions

You set the resolution, entered the rate you needed, and the camera sat at 200 fps while its data sheet promises 317. That gap is almost never a defective camera; it is the factory configuration. Auto exposure, auto gain, auto white balance and gamma all run on a per-frame processing budget, and until you switch them off the camera will not approach its printed rate. This guide ranks the likely causes, gives the arithmetic that separates them, walks through the fix, and shows how to keep it in place across power cycles on any area scan camera.

Why does my camera run slower than the frame rate on its data sheet?

Data-sheet rates assume the camera's auto functions and onboard image-processing blocks are switched off. One USB3 model shipped with a 200 fps limit at 320 × 240; with auto gain, auto exposure, gamma and auto white balance disabled, the same setting rose to its 1,000 fps ceiling.

Three budgets share every frame period: how long the sensor takes to read its rows, how long the exposure runs, and how long the onboard pipeline needs to process the image. The printed figure is the readout limit, measured with the pipeline bypassed. Switch auto exposure on and the camera must gather image statistics and adjust within the same frame period, so the minimum frame period grows and the ceiling drops. Gamma tables, sharpening and similar processing blocks add per-frame work of the same kind.

Cameras ship this way on purpose: the first image out of the box looks right with no tuning. The cost is a cap that looks like hardware, because the frame-rate control simply refuses to go higher.

Which limit is cutting my frame rate?

Suspect them in this order: auto functions first, exposure time second, pixel-format bandwidth third, then your software. Each one caps the rate on its own, and each has a one-minute test, so work down the list until the measured rate matches the target.

One related trap: with auto exposure still active, dim light makes the camera stretch the exposure and the rate falls to about half. The auto exposure priority walkthrough shows the mechanism and the setting that stops it.

How do I turn the auto functions off without a dark image?

Switch auto exposure, auto gain, auto white balance and gamma to manual, enter fixed values, then save the set as the startup default; do it in that order so the image stays usable while you work.

1. With the part in view and the lighting at production settings, read the exposure and gain values the auto functions have settled on. Most cameras report the applied values live.
2. Turn auto gain off first — on GenICam cameras the control is GainAuto — and enter the noted value as the manual gain.
3. Turn auto exposure off and enter the noted exposure time in microseconds.
4. Set gamma to off or 1.0. Gamma is a look-up table in the processing pipeline, so leaving it on keeps the per-frame work on the clock.
5. On a color camera, run one white balance against a white reference under the production light, then turn auto white balance off to freeze the result.
6. Write all of it to a user set and make that set the one the camera loads at startup; the user set procedure lists the steps and the readback that confirms it.

Fixed values mean the image no longer self-adjusts, and under enclosed, stable lighting that is exactly what you want. The brightness drift fix follows the same policy of turning every auto mode off, and if a manual gain entry seems to do nothing, the auto gain override article covers the usual cause.

Why does exposure time set a ceiling on frame rate?

A frame cannot finish before its exposure does, so the maximum rate is 1,000,000 divided by the exposure time in microseconds: 5,000 µs of exposure caps the camera at 200 fps, whatever the data sheet promises.

Worked example, on the camera from the first section. To hold 317 fps, the frame period is 1,000,000 / 317 ≈ 3,155 µs, about 3.2 ms, so the exposure must sit at 3.2 ms or below. If the light only supports 5 ms, the ceiling is 1,000,000 / 5,000 = 200 fps — the exact number the capped camera was showing. That coincidence is common, because an exposure cap and a processing cap look identical from a frame counter; read the applied exposure before you blame the ISP.

To shorten the exposure, add photons. Raise the light output, open the iris — a lower f-number gathers more light at the same focal length, as the M12 light-gathering rule explains — or accept more gain. The exposure, gain and image quality balance guide sets out that trade.

How do I make the settings survive a power cycle?

Write the tuned values to a user set, make that set the camera's power-on default, and read the key parameters back after a restart; until you have seen them return after a cold boot, assume they have not.

A user set is a named snapshot stored in the camera itself. Save your values to it, select it as the default loaded at power-on, then power down cold and read the auto switches, exposure time and frame-rate limit back over the connection. The startup frame-rate verification is built around that readback. If your application also writes settings at start, it must open the connection, write each value and read it back — a script that trusts the camera's memory has shipped many quietly capped systems.

Why is the rate still low once frames reach my PC?

When the camera's own counter shows the target rate but your application sees less, the bottleneck has moved to the link or the software: a shared USB controller, a heavier pixel format, or per-frame processing that cannot keep pace.

Run the camera's capture utility first. If it shows the full rate, the camera and link are sound and the application is dropping or delaying frames: conversion, copies and per-frame analysis compete with acquisition, and the acquisition-versus-processing gap article measures that split. On Linux, a small USB buffer allocation is a classic cause that looks like a camera fault — the usbfs memory and exposure fix names the parameter and the value. Writing every frame to disk while you inspect is another frequent ceiling, and this recording stuck below 20 fps walkthrough follows the same pipeline.

When is the camera itself the limit?

If the measured rate stays at or below the printed value with every auto function off, exposure short, 8-bit format and the intended ROI applied, the sensor readout is the limit and the fix is a different camera, not another setting.

Then compare printed rates at your resolution, not promises. The spread between resolutions is large: the LS-CMR-0166 lists 30 fps at 4000 × 3000, and a reduced ROI on the same class of sensor reaches into the hundreds. For higher rates, the catalog flags speed directly: the MV-CH120-11UC is a high-speed version with a global shutter.

The decision, by case:

• The ceiling jumps when the auto switches go off: settings fix. Save the user set as the power-on default and the rate stays.
• The ceiling tracks 1,000,000 divided by exposure: lighting fix. Buy photons — more light, a lower f-number, acceptable gain — not a new camera.
• The capture utility shows the full rate but your application does not: pipeline fix — buffers, conversion and disk writes, not the camera.
• Nothing moves: hardware. Pick a camera whose printed rate at your ROI clears the target with 20-30% margin, using the camera finder or the camera configurator; the cameras topic page collects the related guides.