Auto exposure priority: why your frame rate drops to half

A depth rig that records color at 15 fps when the camera is set to 30 usually has nothing wrong with its USB cable. The drop is the auto-exposure priority feature working as designed: it lets the camera choose an exposure longer than one frame period, and a sensor cannot deliver a frame faster than it integrates light. This guide shows you how to read the half-rate signature, compute the exposure ceiling for your target frame rate, switch the priority off or cap it, prove the result with timestamps, and tell the remaining slow-stream causes — bandwidth, recording overhead, frame matching — apart from exposure.

Why does your frame rate drop to exactly half when auto exposure is on?

Because auto-exposure priority lets the camera stretch exposure past one frame period, and a sensor cannot deliver a frame faster than it integrates light: at 30 fps the period is 33.3 ms, so a 66.7 ms exposure forces exactly 15.0 fps. Auto-exposure priority exists for dim scenes; it trades frame rate for a longer integration so the image stays usable. Plenty of depth-camera drivers ship with it on, which is why a rig bench-tested under bright lights starts halving its rate the moment the room dims.

The signature is which stream drops. Color usually carries its own auto exposure and halves to 15 fps while the infrared pair holds 30 fps on short fixed exposures. If every stream sags together to ragged values like 22 or 26 fps, exposure is not your suspect; go straight to the host and bus checks further down. The cap mechanics behind this are laid out in depth camera frame rate drops: exposure settings cap the FPS.

How long can exposure run before it eats a frame?

The ceiling is one frame period, and the period is 1000 divided by the target rate: 33.3 ms at 30 fps, 16.7 ms at 60 fps and 10.0 ms at 100 fps; hold exposure at or below that number and the frame rate never moves.

Worked example — a 30 fps color stream in a workshop that dims through the afternoon:

• Frame period: 1000 / 30 fps = 33.3 ms.
• Auto exposure drifts up and settles at 1/15 s = 66.7 ms.
• Deliverable rate: 1000 / 66.7 ms = 15.0 fps, the observed half.
• The same 66.7 ms on a 60 fps stream (16.7 ms period): 1000 / 66.7 = 15 fps, a quarter of target.
• Practical cap to hold 30 fps: 30 ms, which keeps 3.3 ms of the period as readout margin.

Camera vendors' frame-rate application notes recommend exactly this: cap exposure at one frame period (1/30 s on a 30 fps camera) and the rate never moves. The rule binds GigE and USB3 area scan cameras just as hard — why your GigE camera frame rate drops at longer exposure times works the same math. Shutter type changes the artifacts you see, not the ceiling.

How do you turn auto-exposure priority off and pin the exposure?

Turn the priority flag off for the stream that drops, set exposure by hand just under the frame period — 30,000 µs is a workable set point for a 30 fps stream — then re-count frames; when the rate returns to 30 fps and the image is bright enough, you are done.

The switch sits next to the auto-exposure enable in the driver's exposure controls. ROS-style depth wrappers spell it auto_exposure_priority, one flag per stream, and some desktop capture apps hide it as an auto-exposure-priority checkbox. Machine-vision cameras on GigE or USB3 usually skip the flag entirely and hand you an exposure-time feature through GenICam — setting camera exposure time through a GenICam API in Python shows that call.

Work through it in this order:

1. Turn off auto-exposure priority on every stream you record, not just the one that dropped.
2. Switch those streams to manual exposure under their period: 30 ms for a 30 fps stream, 15 ms at 60 fps.
3. Recover brightness with gain before touching exposure upward; the gain tuning for near-range depth IR sensors applies here.
4. Re-run your timestamp count (next section) and check depth fill at the new settings.

For stations where you must pin rate and brightness together, a conventional global-shutter camera with direct exposure control is the predictable path: you set the period, set the exposure, and the rate stays put. All three of these are global-shutter models:

How do you prove the fix held?

Count frames against their own timestamps across a few minutes of capture: 240 frames spread over 8.02 s is 240 / 8.02 = 29.9 fps, so the stream sits at its 30 fps target and the exposure cap is doing its job.

Read the applied exposure back from frame metadata instead of trusting the GUI slider — drivers publish the value actually used per frame, and reading exposure time from frame metadata under auto exposure shows where to find it. Pass criteria: rate within about 1 fps of target across a few hundred frames, and read-back exposure under your cap on every frame.

Why does the frame rate fall back to half after you fixed it?

The usual reason is that the priority flag never applied: the parameter was misspelled, it was set on a different stream than the one dropping, or a later setting re-enabled auto exposure and overwrote your cap — all three leave the same 15 fps at a 30 fps target.

Priority and exposure controls apply per stream: color, IR1, IR2 and depth each carry their own, so a flag set on the wrong stream leaves the dropping stream untouched. Startup order bites as well — drivers that apply settings in sequence can wipe your cap with a later preset, and the startup setting-order fix for depth auto exposure walks through that failure.

Treat the log-directory warning as noise for this purpose. A message that your log folder passed 1 GB is housekeeping; clean it and move on, because log size does not set your frame rate. Confirm every change by reading values back from the running camera, never by trusting the launch line that was supposed to set them.

What if the depth stream alone stays slow while color recovers?

Then the exposure fix did its job and a second limit is throttling depth: most often the streams share one USB controller or one host process that cannot move the data, so enable one stream at a time and add streams back until the rate falls.

Work the remaining causes in this order:

1. Bus and host contention. Enable depth alone and note the ceiling; add color, then IR, then the second camera. The step where the rate falls is your hardware limit. The three-camera, one-stream-at-a-time test isolates it cleanly, and selecting each camera by serial number keeps the measurements attached to the right device.
2. Recording overhead. Compressed depth topics and image compression spend host CPU between camera and disk. While diagnosing, record raw or record fewer topics, then re-count.
3. Frame matching. Drivers that gather the closest frames of several sensors into one time-stamped set hold frames back in order to pair them. Turn matching off for one test run and compare.
4. Alignment. Reprojecting depth onto the color frame every frame adds per-frame host work. Measure one run with alignment disabled and put the cost in your budget.

Close out the job so it stays fixed:

• Write the exposure cap into the launch or config file, not the GUI.
• Print rate and read-back exposure at every session start.
• Re-run the timestamp count after any change to lighting, streams or camera count.

When should you leave auto exposure on and cap it instead?

Keep auto exposure when scene light changes faster than an operator would — loading docks, outdoor gates — and cap its maximum exposure just under the frame period: the rate holds at 30 fps while the camera still adapts exposure and gain inside the limit.

Most depth drivers expose a maximum-exposure limit for exactly this case: auto exposure stays on, gain adapts freely, and the ceiling caps the maximum exposure time to stop motion blur while the rate holds. Set the maximum to your practical cap and let the camera work between the two.

If the scene genuinely needs exposure longer than the period and the full rate at the same time, no flag delivers both — the sensor needs the photons, so add light or fit a more sensitive sensor. Every workaround trades one of the two away; that is the whole physics.

ToF depth modules are their own family: exposure is a fixed integration window per frame and the trade-off has different math, covered in the ToF exposure and frame rate trade-off guide. The shop's ToF sensing camera:

For parts, start at the depth camera category, narrow the field with the camera finder, or step into the camera configurator with your target rate and exposure cap in hand. The 3D topic page collects the rest of the depth guides, and the area scan camera category holds the conventional cameras where this same math applies unchanged. If a multi-camera host still refuses the rate after all of this, send us your stream set and timestamp counts through the contact page and we will work the bandwidth budget with you.