Camera startup time to first image under one second

Your specification says the camera powers on and delivers a usable image within one second — a triggered capture, a battery-powered event logger, an inspection point that is only powered when needed. You measure seven seconds and assume the sensor is slow. It almost never is. On a small module those seconds are consumed by the auto-exposure controller walking toward the right exposure a fraction of a stop at a time, one adjustment every few frames. Freeze exposure, gain and white balance before the stream opens and the first frame is already correct: power-on-to-image collapses to bring-up time plus one frame period. This guide shows how to time the budget, apply the manual settings in the right order, warm-start the values from the previous run, and prove the result with power-cycle tests.

Where the seconds actually go

Three clocks run between applying power and the first usable image.

The first is boot and bring-up: power rails, sensor clocks, driver or device-tree work on an embedded board, then the interface handshake. On a healthy system this is a fraction of a second; when it stretches into seconds the cause is power, clocks or the device tree, not exposure — see MIPI sensors that are detected but never stream for that diagnosis.

The second is the first frame itself: one frame period at the full-resolution rate, 66.7 ms at 15 fps or 33.3 ms at 30 fps.

The third is the one that surprises people: auto-exposure convergence. AE is a feedback loop — it measures each frame, computes a correction and applies it. Published implementations deliberately bound the rate of change: one camera maker's documentation caps the shift at about 1/8 stop per frame, and controllers described in the patent literature apply a fresh exposure only every two or three frames so the previous one has time to act. Research controllers permitted to take large steps converge in 3-5 frames; the conservative loop in a small module does not.

Because convergence is counted in frames, wall-clock time is frames divided by frame rate. High resolution lowers the frame rate, so the same 96 frames take twice as long. Dim scenes stretch it again: when AE lengthens the exposure, the frame period itself grows and the loop slows — the same mechanism behind a USB3 camera's frame rate collapsing under long exposure.

Worked example: six stops dark at 15 fps

The case is the one behind this guide: a 2 MP module running 1600 × 1200 (UXGA), powered on to take a single picture, against a one-second specification.

Inputs, with their source:

• Full-resolution rate: 15 fps — typical for this module class on a constrained interface; the measured 7 s delay reproduced at the end of this example is consistent with it.
• Scene-correct exposure: 10 ms, read from the metadata after AE converges under the real lighting.
• Power-on default exposure: 0.16 ms — a bright-scene default 6 stops short, since 2^6 = 64 and 10 ms ÷ 64 = 0.156 ms.
• AE step: at most 1/8 stop per adjustment, with a new value every 2 frames — the conservative, documented values.
• Bring-up to the first streamed frame: 0.5 s, measured with the auto modes off. Measure yours the same way.
• Budget: 1.0 s from power valid to acceptable image.

Cold start, auto exposure left on:

• Adjustments: 6 stops ÷ 0.125 stops = 48.
• Frames: 48 × 2 = 96.
• Time: 0.5 s + 97 frames ÷ 15 fps = 0.5 s + 6.47 s = 6.97 s — the ~7 s the field measures.

Manual exposure, applied before streaming:

• Frames: 1. Time: 0.5 s + 1 ÷ 15 s = 0.57 s. Passes with 0.43 s of margin (43%).

Auto exposure kept, warm start from a stored value within 1 stop:

• Adjustments: 1 ÷ 0.125 = 8, so frames = 16.
• At 30 fps: 0.5 s + 17 ÷ 30 s = 1.07 s — fails by 70 ms.
• At 60 fps: 0.5 s + 17 ÷ 60 s = 0.78 s — passes.

Decision: freeze exposure before streaming and the one-second budget passes at any frame rate you will run. Keep the loop only when the start point is stored within about 1 stop and the sustained rate is 60 fps or higher — or cut the 0.5 s bring-up to buy the loop its margin.

Fix it in six steps

1. Measure the baseline. Stamp the host clock when power becomes valid and with every frame received, and log the exposure and gain each frame carries — per-frame exposure and gain metadata makes this a readout, not a guess. Run ten power cycles and keep the worst time. If frames-to-settle ÷ measured fps reproduces most of it, convergence is your cost.
2. Converge once, on purpose. Let auto exposure run under the deployed lighting, then read the exposure time from the frame metadata under auto exposure. For colour, record the white-balance channels too.
3. Store the values. Write them where they survive power-off — your host configuration, or the camera's user-set memory. This is the warm start the arithmetic above depends on.
4. Apply manual settings before acquisition starts. Initialization order decides whether frame 1 already carries them: set exposure, gain and white balance to fixed values, then open the stream, following the initialization order for manual exposure before streaming. Values pushed after streaming begins arrive late or miss the first frames — the same ordering trap as auto-exposure limits that are not applied at startup.
5. Turn every auto mode off. A mode left in auto keeps correcting through the run, and the drift surfaces as brightness or colour wobble minutes later — the classic brightness drift caused by auto modes left on.
6. Verify, worst case first. Twenty power cycles with the dimmest deployment scene included. Pass when the worst power-on-to-acceptable-frame is ≤ 0.8 × budget, frame 1 metadata equals the stored settings every cycle, frame 1 mean brightness is within 5% of frame 50, and nothing drifts across a 30-minute run.

If the lighting genuinely changes

Fixed exposure assumes fixed illumination. Where that does not hold, keep the loop but bound and shorten it:

• Cap the maximum exposure time so a dark scene cannot stretch the frame period and stall the loop — see capping the maximum auto-exposure time. Cap gain too; the two caps define the loop's worst case.
• Warm-start from the stored values of the previous run, so the loop covers only the change since power-off.
• Characterize the worst case once: start from the dimmest plausible scene, count frames to settle, divide by the measured fps.
• If that worst case breaks the budget, shrink the error instead: more light shortens the required exposure and moves the stored start point closer, a higher sustained frame rate divides the wall-clock time, and a faster bring-up buys margin.

Choosing a camera for a fast first frame

Three data-sheet lines decide the outcome: sustained frame rate at full resolution, manual exposure and gain that can be applied at initialization, and the interface's bring-up overhead. Shutter type does not change startup — a global shutter matters for distortion on moving parts, which is a separate decision.

For a camera inside your own hardware, the board-level cameras range is built for it; for a fixed industrial install, the area scan cameras do the same job in a housed C-mount form. The camera finder filters both by interface, resolution, shutter and sensor format, and the camera configurator walks the whole chain. For the full selection drill — mounts, module size, interface trade-offs — see Board level camera selection for embedded vision machines.

The LS-BCM-0003 pairs a 3.1 MP global-shutter IMX252 sensor (1/1.8") with 120 fps over USB3 and a C-mount. At that rate one frame is 8.3 ms: frame 1 arrives 8.3 ms after the stream opens, and a warm-started 17-frame loop settles in 0.14 s.

The MV-CB016-10GM-M-W is the compact head for the same treatment: 1.6 MP mono, global shutter, M12 mount, GigE.

For a fixed mount, MV-CU020-90GC provides 2.5 MP colour on GigE with a 1/1.7" GMAX4002 global shutter and a C-mount.

Resolution is the tax line. The LS-BCM-0020 reads 6.3 MP at 18 fps over GigE (IMX178, 1/1.8" rolling shutter, CS-mount). At 18 fps a frame lasts 55.6 ms, so the 97-frame cold walk costs 5.4 s and even a warm 17-frame start costs 0.94 s before bring-up. For continuous inspection that rate is irrelevant; for an event-triggered one-second capture, fix the exposure and treat 18 fps as the first-frame latency.

When the usual advice is wrong

Start small, then switch to full resolution. It sounds like a shortcut warm-up, but on many modules the resolution change re-initializes the sensor and its image pipeline, and some refuse the change until the next restart — a module's supported modes are set by how sensor resolution modes work. Budget the full-resolution rate from frame 1 instead; that is what the arithmetic above assumes.

A faster sensor will fix it. The silicon was never slow. In the worked example the hardware delivered a frame every 66.7 ms the whole time; the loop consumed 96 of them. Configuration moves this number, not the part number.

Just run a higher frame rate. Division helps only after you shrink the frame count. From a cold six-stop error, even 120 fps leaves 0.5 s + 97 ÷ 120 s = 1.31 s — over budget. Warm start first; then frame rate buys margin.

Checks before you commit

• Worst-case power-on-to-acceptable-frame over 20 cycles, dimmest scene included, ≤ 0.8 × budget (0.8 s against a 1.0 s budget).
• Frame 1 exposure and gain metadata equal the stored settings on every cycle.
• Mean brightness of frame 1 within 5% of frame 50; nothing drifts across a 30-minute run.
• Every auto mode reports off at stream start.
• Sustained fps at the boot resolution measured on your host, not read from a table — every conversion above divides by it.

If those numbers hold, the one-second specification is met by configuration, on hardware you already have. Size the rest of the chain in the camera configurator, or contact us with your frame rate and bring-up measurements and we will check the budget with you. More guides on exposure, startup and camera behaviour sit on the cameras topic page.