A spec sheet lists an exposure range such as 10 µs to 30 s, and on a timing-critical line the first question is whether the 10 µs minimum buys a 10 µs frame. It does not. Exposure is only how long the sensor collects light; readout, the drain of a few million pixels into memory, is a separate budget you compute yourself. Below is the calculation, the settings that move the number, and the checks that keep a cycle-time or distortion estimate honest — before you order anything from the area scan cameras range.
Does the minimum exposure on a spec sheet include readout time?
No — a range such as 10 µs to 30 s covers integration only: the 10 µs minimum is how briefly the pixels gather charge, and clocking those rows off the sensor afterwards is a separate step with its own, usually much larger, time.
The minimum comes from the sensor's electronic shutter: how fast the reset and charge transfer can be pulsed, and at what granularity the exposure clock steps. Machine-vision CMOS sensors commonly bottom out between 1 and 20 µs, and the printed value is measured with light alone — it says nothing about how long the frame then takes to leave the sensor.
The two numbers answer different questions. Exposure decides how much light you collect and how much motion blur you accept. Readout decides when the frame is ready and how fast frames can repeat. On a global-shutter sensor the sequence is clean: all rows integrate together, then the frame drains. On a rolling shutter the two interleave row by row, which is why readout turns up in the geometry of moving parts.
How do you calculate sensor readout time?
Divide the rows you output by the line rate the camera reports: a 3,000-row frame reading at 90,000 lines/s takes 3,000 / 90,000 s = 33.3 ms, and every setting that lowers that line rate stretches the same division.
The line rate is the camera's row clock. In a GenICam node map it is the AcquisitionLineRate feature, readable through any SDK's node-map browser once the camera connects; the row count is the image height you actually transmit, which ROI and binning can change.
Take the LS-CMR-0166: a 12 MP USB3 camera on a 1/1.7" rolling-shutter sensor, rated 4000 × 3000 at 30 fps. Its full-resolution frame period is 1 / 30 s — the same figure as the division above — so the readout dominates and works out to roughly 90,000 lines/s for 3,000 rows. Treat it as an estimate: some cameras add a small fixed latency, and the real rate follows your settings.
- Sensor format
- 1/1.7"
- Interface
- USB3
- Resolution
- 12 MP
- Shutter
- Rolling
How can you know readout time before buying?
Invert the frame rate printed for full resolution: readout time ≈ 1 / frame rate, so the 33 ms from the worked example is what 30 fps implies, 60 fps about 17 ms, and a 5 fps large-format sensor about 200 ms.
The shortcut holds because a datasheet's maximum frame rate, taken at the shortest exposure, is bounded by the readout: a rolling shutter streams rows continuously, and a global shutter in overlap mode starts the next integration during the drain. It drifts when the interface, not the sensor, sets the pace — bandwidth-limited GigE configurations are the usual case — and when your exposure runs longer than the readout.
After arrival, close the loop: read AcquisitionLineRate from the node map and multiply by your output rows, then compare with the estimate. When a value refuses to set or reads oddly, query its range first — the habit in query the option range before setting exposure or gain applies to line rate too.
What moves the readout time after the camera arrives?
Four controls move the line rate, some of them severely: output rows, binning, pixel format, and on-camera image processing — drop the rate from 90,000 to 30,000 lines/s and the readout stretches to 3,000 / 30,000 s = 100 ms, a factor of three.
- Output rows. An ROI crops height, and readout follows the rows you transmit, not the sensor's full height.
- Binning. 2 × 2 binning halves the row count, cutting the base readout to about 16.7 ms — and halving resolution with it.
- Pixel format. Moving from 8-bit to 16-bit output doubles the bytes per pixel; on a bandwidth-limited interface the line rate falls roughly in half.
- On-camera processing. Firmware debayering and other image-pipeline steps slow the readout; on cameras that process in firmware the loss can reach two to three times.
- Pixel clock. Firmware-set on most cameras and rarely yours to change.
Does a short exposure give you a fast frame rate?
No — once exposure sits below the readout, it stops setting the pace: a 10 µs exposure adds almost nothing to the 33 ms readout, so the frame stays near 30 fps, while a 50 ms exposure stretches the frame to 50 + 33 = 83 ms, about 12 fps without overlap.
Without overlap the camera waits for the drain before exposing again, so the times stack: three frames at 10 ms exposure and 50 ms readout take 3 × (10 + 50) = 180 ms. With overlap enabled, the next integration runs during the drain and the period settles near the larger of the two numbers — that same 50 ms exposure frames at about 20 fps.
The full arithmetic is in compute camera frame time from exposure and readout, and the triggered case in maximum frame rate on a hardware trigger. Long exposures are their own slowdown, the pattern in why your GigE camera frame rate drops at longer exposure times. When a triggered camera refuses short exposures, the cause is usually signal timing rather than the sensor floor: see minimum exposure time in trigger mode: find the real cause.
When does readout time distort a moving part?
Only on a rolling shutter: rows expose at staggered times, so a part moving 200 mm/s shifts 200 × 0.033 = 6.6 mm between the first and last row of the 33 ms readout, and edges shear by that amount.
A global shutter exposes every row at the same instant, so readout adds nothing to geometry — motion blur stays speed × exposure, which 200 mm/s under a 10 µs exposure confines to 200 × 0.00001 = 2 µm. Rolling-shutter skew, not the exposure floor, is what wrecks measurements on fast lines.
If you can tolerate some skew, budget it like any tolerance: displacement = speed × readout. At 50 mm/s the error is 50 × 0.033 ≈ 1.7 mm — fine for presence checks, unacceptable for a 0.1 mm gauge.
Which cameras keep readout short enough for the job?
Decide the shutter first, then size the readout: global shutter for anything that moves while measured, rolling shutter acceptable for presented parts, and the rows you output — not the megapixel count alone — set each frame's time.
Where motion rules the error budget, a global-shutter high-speed model removes skew entirely. The MV-CH120-11UC is a 12 MP USB3 camera on a 1.1" sensor with a global shutter and a C-mount, built as the high-speed version of its line.
- Sensor format
- 1.1"
- Lens mount
- C-mount
- Interface
- USB3
- Resolution
- 12 MP
For a presented part, a long readout only costs cycle time. The MV-CS200-10GC pairs a 20 MP, 1" rolling-shutter sensor with GigE. Bandwidth sets expectations here: an 8-bit frame of 20 MP is 20 MB, GigE leaves about 110 MB/s after protocol overhead, and 110 / 20 = 5.5 fps, so full-resolution transfer runs near 180 ms. Over USB3's practical 350 to 400 MB/s the same frame works out near 55 ms, about 18 fps.
- Sensor format
- 1"
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- 16-25 MP
In between sit 30 fps 12 MP USB3 models like the worked example: short readout for slow lines, wide exposure range for integration-heavy tasks, and skew of 1.7 mm or less at part speeds up to 50 mm/s — enough for presence and classification work.
What should you check before ordering?
Run the numbers in this order and the first timing measurement will hold no surprises: read the exposure range as integration only, invert the full-resolution frame rate into a readout estimate, then adjust for the configuration you plan to run.
- Exposure floor: the minimum is the light-integration limit, 10 µs class on modern CMOS. Blur is speed × exposure, so light, not the shutter, usually sets how short you can go.
- Readout estimate: 1 / datasheet fps at full resolution — 30 fps gives the 33 ms figure from the worked example.
- Configuration deltas: planned ROI height, binning, pixel format, on-camera processing; redo the rows ÷ line-rate division for each.
- Motion budget: rolling-shutter skew = speed × readout; 200 mm/s × 33 ms ≈ 6.6 mm. Above your tolerance, specify a global shutter.
- Cycle time: triggered period = exposure + readout without overlap; overlap keeps frames near the readout pace.
When the budget is tight, the camera finder filters by resolution, shutter and interface, the camera configurator walks the choices in order, and more timing reading sits on the cameras topic page. Bring a timing budget that will not close to the contact page.
Questions
Why does my measured frame rate fall below the datasheet number?
Datasheet rates assume a reference configuration: usually 8-bit output, no on-camera processing, and the stated ROI. A 16-bit pixel format doubles the bytes per pixel and can roughly halve the rate on a bandwidth-limited interface, and GigE tops out near 110 MB/s, so a 12 MB 8-bit frame cannot exceed about 9 fps. Switch back to the reference settings, compare, then query the line rate in your own configuration.
How short an exposure do I need to keep motion blur off my features?
Budget blur as speed × exposure and keep it under the smallest feature you must resolve: 0.1 mm of allowed blur at 200 mm/s needs 0.1 / 200 s = 0.5 ms. The 10 µs class minimum on a modern CMOS sensor sits far below that, so the shutter floor rarely decides blur — how much light you can deliver in the short pulse usually does. Size illumination first, then set exposure.
Does the top of the exposure range, such as 30 s, exclude readout too?
Yes — the maximum is integration only as well. At long exposures the frame period becomes exposure + readout, and a 33 ms readout adds nothing measurable to a 30 s frame. The limits that start to matter are different ones: sensor warming, dark current filling pixels during multi-second integrations, and drift of the fixture. Keep integration long only when the signal genuinely requires it.
Can I shorten readout by reading out only part of the sensor?
Yes — readout scales with the rows you transmit, so a height ROI is the cheapest speed gain there is. On the 3,000-row, 90,000 lines/s example, limiting height to 1,000 rows cuts the readout to 1,000 / 90,000 s ≈ 11 ms. Binning 2 × 2 reaches a similar halving while keeping the full field, at the cost of resolution. Leave width unchanged unless the interface bandwidth is the limit.


