Why camera exposure time has a maximum limit and how to exceed it

Ask an industrial camera for 7 seconds of exposure and the answer comes back clipped to 6, or the call fails outright. The ceiling is not a driver quirk: exposure time is programmed as a count of sensor lines, and a width-limited register counts only so high. If you build low-light capture — night monitoring, fluorescence, dark reflective parts, any static scene with almost no light — this is the wall you hit. Here is where the number comes from, the one multiplication that predicts it for your sensor, and the way past it: average frames at the cap, which integrates longer and lowers noise at the same time.

Why does your camera have a maximum exposure time?

Because exposure time is not programmed in seconds but in sensor lines: one exposure equals a line count multiplied by the line time, and a 15-bit frame-length register caps that count at 32,767 lines — about 6.0 s at 0.184 ms per line.

The sensor counts, it does not measure time. Three registers hold the timing you set each frame: exposure in lines, frame length in lines, and analog gain. One line time is fixed by the readout mode and the pixel clock, so every timing number in the camera reduces to a line count times that one constant.

Frame length sets the frame period. It cannot be shorter than the image plus its readout overhead, and lengthening it inserts idle lines between frames — which is precisely how frame rate is controlled, and why frame rate falls when exposure stretches. Exposure has to fit inside the frame. On the small CMOS sensors behind most board cameras, the exposure field is 16 bits wide, enough for 65,535 lines, but the frame-length register is 15 bits — 32,767 lines — so the frame length binds first and becomes the true ceiling.

How do you work out your sensor's exposure cap?

Multiply your sensor's line time by its maximum line count: 0.183789 ms per line × 32,767 lines = 6,022 ms, which rounds to the 6-second ceiling that the common 5-megapixel board sensor hits in its slowest readout mode.

The arithmetic, shown in full:

32,767 lines × 0.183789 ms/line = 6,022.2 ms ≈ 6.0 s

The 6-second ceiling is one register width times one mode constant, nothing more. Had the frame-length register been 16 bits, the same mode would have reached 65,535 × 0.183789 ms ≈ 12.0 s, which is why the history of pushing this limit is all about raising frame length, not the exposure field.

The cap moves with the readout mode, because the mode sets the line time. A hypothetical mode reading a line in 0.045 ms stops at 32,767 × 0.045 ms ≈ 1.5 s. Find the line time in the sensor data sheet's timing tables or the driver's mode definition; your SDK's exposure range reports the result as its maximum. If the data sheet quotes line time at one pixel clock, scale it inversely — halve the pixel clock and the cap doubles, on paper.

At the cap, the frame rate settles at 1 / 6.022 s ≈ 0.17 frames per second. Plan the acquisition loop for that number, not for the camera's headline rate.

Can you raise the cap by changing the sensor clock?

No — stretching the line time through the sensor's PLL dividers corrupts the image well before the exposure doubles, because the validated timing windows on a mobile-class sensor are narrow and every timing register is already at its limit.

Slowing the pixel clock looks like free headroom: the same 32,767 lines would each take longer, and the cap would rise with them. It has been tried on exactly this class of part, and one step on the PLL divider — worth a few seconds in theory — returned torn, corrupted frames. The registers were already at maximum line width and height, with nothing left to trade. These are mobile-phone sensors, validated for millisecond exposures; a clean 6-second frame already runs past what the silicon was intended to do.

Treat the cap as a hardware constant and design around it. Two levers remain: pick a sensor whose slow mode has a long line time, and integrate longer in software.

How do you integrate longer than the exposure cap?

Take N frames at the cap and average them: N = 20 turns twenty 6-second exposures into 120 seconds of total integration, and the random noise in the average falls by √20, a factor of about 4.5.

Averaging is the workaround, and it is not a compromise on noise — it improves it. Collect frames at the cap, sum them, divide by N; total integration becomes N × t_cap while random noise — photon, thermal and read — falls by √N. The full routine, borrowed from astronomy:

1. Shoot dark frames with the lens capped: same exposure, same gain, same sensor temperature. Average them into one master dark.
2. Subtract the master dark from every light frame. This removes the dark-current offset, the hot pixels and the corner glow that dominate long exposures on small sensors.
3. Combine with a mean or a median. The median also rejects single-frame events — vibration, a stray reflection, one bloomed hot pixel.
4. Keep the stack raw. Average integers or floats, never compressed or gamma-corrected frames.

A running average is light enough to execute in real time as frames arrive — one accumulator per pixel — and stacking 300 six-second exposures is a routine astronomy workflow, not an exotic one. The loop itself, for cameras that hold a fixed frame period, is covered in averaging frames on a fixed-rate camera.

Cooling multiplies the value of every one of those steps: silicon dark current roughly doubles for every 5-8 °C of die temperature, so a heat sink or a small fan on the camera board visibly cleans long stacks. Cooled astronomy cameras reach minutes of exposure on small sensors because they hold the die cold, not because their registers count higher.

One architectural note: smart cameras run inspection on-device and rarely expose a frame-averaging pipeline. When averaging is the plan, an area-scan camera streaming raw frames to your own code is the dependable shape.

How much does averaging 20 frames actually buy?

Averaging 20 frames multiplies collected light by 20 and divides temporal noise by √20 ≈ 4.47, so the signal-to-noise ratio improves by the same 4.47 — photon for photon what one 120-second exposure would deliver.

Run the numbers on a 6.0-second cap and a static scene. One frame collects 6 s of light with noise σ:

• Total integration: 20 × 6.0 s = 120 s, twenty times the photons of one frame.
• Noise after averaging: σ / √20 = σ / 4.47.
• Signal-to-noise: 20 ÷ 4.47 = 4.5 times a single frame.
• Acquisition time: the frame period cannot be shorter than the exposure, so 20 × 6.02 s ≈ 2.0 minutes, plus a matching dark set — another 2 minutes, or a temperature-matched dark library shot earlier.

The only thing a stack loses to a true 120-second exposure is read noise. Twenty frames means twenty read events, so that one component carries √20 ≈ 4.5 times the read noise of a single long frame. With real signal in the frame — dark current and photons above the read floor — the penalty rounds away, and the stack matches the long exposure. With near-black frames where read noise dominates, take fewer, longer frames instead of many short ones.

Gains scale with the square root, so past a few hundred frames the returns thin out. Twenty frames is the sensible default; one hundred when the scene is genuinely dark; three hundred is where even astronomy stacks tend to stop.

Which camera should you choose for long integration?

Pick a mono camera you can hold at a stable temperature, give it a host that averages frames, and read the sensor's line time before anything else — that one number sets your per-frame ceiling.

Mono beats color here: with no filter array over the pixels, every pixel receives the full spectrum, which matters when photons are scarce. Rolling shutter is fine on a static scene — nothing moves to distort. Thermal control is the spec that never appears on the data sheet, and a bare board hands the sensor PCB to your mount:

Bolt the board to a bracket that doubles as a heat sink, and the dark frames you shoot at power-up still match the ones at the end of the shift.

When the goal is noise reduction rather than total integration, frame rate does the work — a fast camera stacks up the √N gains quickly:

The 3.1 MP LS-BCM-0003 runs 120 fps, and the 6.3 MP LS-BCM-0020 runs 18 fps. At 18 fps, twenty frames arrive in about 1.1 s — quick for a 4.5× noise cut.

For the full pipeline — camera, cable, host software, averaging loop — a 20 MP mono USB3 camera streaming raw frames to your own code over C-mount optics works well:

These sensors also stay responsive into the near infrared, and dropping the IR-cut filter buys sensitivity on dimly lit outdoor scenes.

The wider selection sits in area scan cameras for cabled inspection builds, and in the board-level range below:

What should you check before trusting the stack?

Lock exposure, gain and white balance to manual, shoot dark frames at the same exposure and temperature as your lights, confirm the true exposure in each frame's metadata, and throw away frames touched by vibration or saturation.

• Lock the camera. Auto exposure drifting between frames breaks the stack's linearity. Where auto must stay, cap the maximum auto exposure time so it cannot wander.
• Read back the exposure. Do not trust the request; read the exposure time from frame metadata and confirm every frame sat at the cap.
• Match darks to lights. Same exposure, same gain, same temperature. Re-shoot the dark set when the camera warms, because dark current moves fast with heat.
• Reject bad frames. Median-combine or sigma-clip so one struck frame cannot drag the average.
• Stay off full scale. Keep bright features under about 90% of full scale; averaging cannot repair clipped highlights.

When is a long exposure the wrong tool?

When the scene moves: 6 seconds of exposure turns 1 mm/s of motion into 6 mm of blur that no software recovers, and when frames are so short that read noise dominates, one clean frame beats a stack.

Motion sets its own limit — the blur you can tolerate divided by the part speed. A 0.5 mm blur budget on a part moving 100 mm/s caps exposure at 0.5 / 100 = 5 ms, three orders of magnitude below the register cap. The correct answer there is light, not time: more illumination, a wider aperture, gain last. The mechanics are in exposure time versus shutter speed for moving parts, and with motion in the frame, shutter type starts to matter — global versus rolling shutter decides whether the image tears.

The decision, case by case:

• Static scene, cap too short: average N frames at the cap; 20 is the default, 100 for genuinely dark scenes.
• Static scene, cap long enough: take one exposure at or under the cap, and stack only if noise rather than integration is the problem.
• Moving scene: short exposure and more light; the register cap will never be your limiting number.
• Near-black, read-noise-limited: fewer, longer frames at the cap beat many short ones.

From here, run the camera finder, start the system configurator at the camera step, or contact us with your target integration time. More exposure and sensor coverage sits on the cameras topic page.