Set the camera auto exposure limit instead of a tuning file

Auto exposure left to its own devices produces two complaints at once: moving parts smear, and when you clamp exposure too hard the image turns dark and noisy. If your camera stack ships prebuilt ISP tuning files, you may be stuck choosing between a 500 µs cap that starves the sensor and an 8300 µs cap that smears every moving part. You do not need a custom tuning file for the value in between. The exposure cap is one ordinary runtime parameter: set the camera auto exposure limit directly, sized from part speed and pixel size, and the tuning question disappears. This how-to gives you the number, the setting, and the check that it stayed set.

What a tuning file changes, and why you do not need a custom one

A tuning file — often shipped as a binary called a tuning blob — is a packaged image-signal-processor parameter set for one sensor module. It carries auto-exposure behavior and its limits, gain ranges, gamma and contrast curves, denoise strength and white-balance behavior, all tuned together for that module. Loading it applies the whole set at once.

Two consequences follow. First, the file is not magic: a binary named for a 500 µs exposure limit is mostly an ordinary parameter set with the auto-exposure cap parked at 500 µs — the same number you can write yourself at runtime. Second, a manual parameter overrides the file only where it touches; everything else in the file still applies. Stacking a packaged tuning under a pile of manual settings makes the final image hard to reason about. The clean path is to skip the file and write the parameters you need, the exposure cap first of all.

Machine-vision cameras on GigE Vision and USB3 Vision have no tuning file to load in the first place. Exposure time, the auto-exposure mode and its limits are ordinary GenICam camera features you read and write over the control interface, and they persist in user sets. Stacks that do ship tuning files expose the same cap as one setter call — setAutoExposureLimit on those platforms. Consumer capture APIs take a third route: they pin exposure by switching the device into a manual exposure mode with a set duration rather than exposing a separate limit. Whatever the API, the control exists, and it counts in microseconds.

Size the cap: motion budget first, frame period second

Two numbers bound the limit. The motion budget says how long a pixel may integrate before a moving part smears across it. The frame period says how long the sensor may integrate at all before the frame rate drops.

Start with blur. Half a pixel is the target for OCR, gauging and measurement; one pixel is acceptable for presence checks and sorting. Work out the pixel size in object space — field of view divided by the sensor pixel count across that direction. The part travels one pixel of blur for every budget pixel it crosses during exposure, so the largest safe exposure follows from the belt speed:

Why the frame period bounds exposure at all, and what to do when you genuinely need longer, is its own topic: why camera exposure time has a maximum limit. The blur side — choosing 0.5 px versus 1 px and what it does to the cap — is treated in capping the maximum auto exposure time to stop motion blur.

The ordering matters because most auto-exposure implementations raise exposure time before gain: on the embedded stacks that package tuning files, the documented AE default pushes exposure up before ISO. Without a cap, the loop buys brightness with exactly the variable that smears your parts. With the cap set, gain climbs instead — you trade noise, which lighting fixes, for smear, which nothing downstream fixes.

Worked example: 25 mm/s conveyor, 50 µm pixels, a 2000 µs cap

A small-parts sorting belt shows the whole calculation.

Inputs. Part speed 25 mm/s, a typical small-parts belt — time your own belt over a known distance. Object-side pixel size 50 µm, from a 100 mm field of view across 2000 pixels (100 mm ÷ 2000 px = 50 µm/px; illustrative numbers — substitute your FOV and sensor). Blur budget 1 px, the sorting-grade target. Available baked caps: 500 µs and 8300 µs, the two prebuilt tuning limits this scenario replaces. Frame rate 30 fps.

Rule. The allowed exposure is the allowed blur divided by the part speed, and the cap must also sit under the frame period. Keep the smaller of the two.

Arithmetic. 25 mm/s = 25,000 µm/s. t_max = (1 px × 50 µm/px) ÷ 25,000 µm/s = 0.002 s = 2000 µs. Frame period = 1,000,000 µs ÷ 30 fps = 33,333 µs. The motion number is smaller, so the limit is 2000 µs.

Result. The 8300 µs preset lets one pixel integrate for 8300 µs and draws 8300 ÷ 2000 = 4.15 px of smear, four times the budget. The 500 µs preset holds blur to 0.5 px but gives away 2 stops of light (2000 ÷ 500 = 4×), which you would buy back as 4× the gain and visible noise.

Decision. Set the auto exposure limit to 2000 µs on this line. Above roughly 2100 µs the 1 px budget breaks (2100 µs is 1.05 px of smear); below roughly 1000 µs every further halving costs a stop of light or gain. Raise the cap only when you add light to match it.

Set the limit in four steps

1. Compute the cap in microseconds from the motion budget and the frame period, and keep the smaller number.
2. Find the control before you stream. On a GigE Vision or USB3 Vision camera it sits in the parameter tree beside the exposure-time and auto-exposure-mode features, under a name that reads like auto exposure time limit or max exposure, in µs. On the tuning-file stacks it is the single setAutoExposureLimit call. Write it before acquisition starts: settings written mid-stream are ignored by more than one camera family. If the limit seems to have no effect, the startup-settings checklist for an ignored auto-exposure upper limit walks the ordering problem.
3. Leave the exposure mode on continuous auto so the loop can work anywhere between zero and your cap. Steer the level with the brightness target if you also need a held gray level — the auto-exposure brightness target for inspection works alongside the cap, not instead of it.
4. Save the parameters into a user set that loads on power-up. A saved user set that loads on startup is what carries the cap through a power cycle, so the line does not restart at 8300 µs on Monday.

Confirm the cap is actually applied

Log the exposure time the camera reports, frame by frame, while AE runs; most APIs let you read it back each frame. Cover the light for two seconds and uncover it: the trace should rise in the darker frames and stop flat at your cap. A trace that climbs past the cap means the write did not take. A trace that never reaches the cap means you have light to spare and the cap is idle for now.

Then check blur on a real moving part, not just the number. Capture at line speed and measure the smear across a straight edge in pixels: at 25 mm/s and 2000 µs the arithmetic says 1 px, so a larger smear means the belt is faster or the pixels bigger than assumed. Recompute; do not tune by eye.

No limit control? Three fallbacks

Minimal firmware sometimes hides the auto-exposure limit. In order of preference:

• Manual exposure. Fix exposure at the computed value and steer brightness with light and gain — the most deterministic option on a stable-lit line anyway. The workaround when a camera has no software exposure control and the manual-exposure initialization order cover the details.
• Steer AE with its brightness target and measurement region. Lower the target level and narrow the region to the part; the loop converges earlier and settles on shorter exposures. Indirect, but it moves the same variable.
• Buy the headroom with light. Going from an 8300 µs world to a 2000 µs cap needs 4.15× more light on the part for the same gray level — about 2 stops — met with brighter machine vision lights or a wider aperture, never with a longer exposure.

Rolling shutter or global shutter for the moving part

The cap fixes blur; shutter type fixes shape. A rolling shutter exposes line by line, so a fast part comes out skewed — upright edges lean — even with blur inside budget. Slow belts and short caps keep the skew invisible; fast parts and geometry checks want a global shutter. The frame period still rules: at 30 fps it is 33,333 µs, so a 2000 µs exposure fills 6% of it and leaves the rate untouched.

Any camera whose frame period clears the cap can run the worked example. One that does, straight from the catalog:

Where geometry matters at speed, both of these hold global shutters:

All 2 share: Sensor type CMOS, global shutter; Exposure mode Off/Once/Continuous exposure mode; Binning Supports 1 × 1, 2 × 2, 4 × 4; Decimation Supports 1 × 1, 2 × 2, 4 × 4; Lens mount C-mount; Weight Approx. 100 g (0.2 lb.); Certification CE, RoHS, KC; Mono/color Color. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

Pick by pixel size and interface rather than resolution alone: the MV-CU020-90GC pairs a GMAX4002 global-shutter sensor with GigE on a 1/1.7" format, and the MV-CH120-11UC runs an IMX304 sensor at 12 MP over USB3 as the high-speed version. Long cable runs and modest feature sizes favor the GigE part; fine features at speed favor the 12 MP USB3 one.

Common mistakes

• Loading the tuning file after your own settings. The file wins wherever it touches; load it first or not at all, and write your parameters last.
• Writing the cap after the stream is up. Some cameras take it live, some ignore it silently — write before streaming and read the value back.
• Skipping the user set. The cap reverts at the next power cycle and the line restarts at 8300 µs.
• Capping exposure without a light budget. AE parks at your cap, gain maxes out and noise replaces blur as the defect. Every stop of exposure you remove wants a stop of light or gain back.

If you are sizing this against real hardware, the camera finder filters by shutter type, interface and resolution, and the area scan cameras category is the shelf these parts come from. More on exposure control sits in the cameras topic.