High-speed cameras

What 'high-speed' really means in machine vision

High-speed in an industrial context is not the multi-thousand-fps slow-motion world of crash testing and ballistics; those use specialised cameras with large internal memory that record a burst and download afterwards. Machine-vision high-speed cameras stream continuously: they sustain a high frame rate indefinitely so that every part on a fast line is inspected in real time. The practical question is always rate of parts, not peak fps — how many objects pass the camera per second, and how many frames you need of each to make a reliable decision.

Two separate clocks govern whether you keep up. The first is the sensor and its readout: how quickly it can expose and shift out a frame, which sets the theoretical maximum fps at a given resolution. The second is the transport: how fast the chosen interface and the receiving hardware can move and absorb that data without back-pressure. A camera that can produce 300 fps is useless if the link can only carry 120 fps of full frames; the sensor simply waits. Specifying a high-speed system means balancing both clocks against the real trigger rate of your line, with headroom for jitter.

The fps-versus-resolution trade-off

The fundamental constraint is that frame rate and resolution trade against each other through a fixed data budget. A sensor reads out a finite number of pixels per second; spend them on a large frame and you get fewer frames, spend them on a small frame and you get more. This is why a camera quotes its maximum fps at full resolution, and a much higher number when windowed down — the two figures describe the same pixel throughput sliced differently. Sizing a high-speed camera therefore starts with the minimum resolution you genuinely need on the part, not the maximum the sensor offers.

Work the requirement backwards. Decide how many pixels must land on the smallest feature you have to detect or measure (a few pixels for presence, more for gauging or code reading), set the field of view from the part and its position tolerance, and that gives the resolution you actually need. Anything beyond that costs you frame rate and bandwidth for no inspection benefit. On fast lines it is common — and correct — to choose a moderate-resolution global-shutter sensor that hits a high frame rate cleanly rather than a high-megapixel sensor throttled down to a fraction of its speed.

Brands such as Basler, iRAYPLE and Omron/Sentech (STC) build high-speed models around fast global-shutter CMOS families precisely because those sensors offer a strong fps-per-megapixel ratio and clean readout. Match the sensor to the job: prioritise readout speed and shutter type for fast motion, and reserve very high pixel counts for the high-resolution category where dwell time allows it.

• Datasheet fps is always tied to a stated resolution — compare like for like.
• Size resolution from the smallest feature and the field of view, then take the fps that resolution allows.
• Prefer a fast moderate-resolution global-shutter sensor over a high-MP sensor crippled by throttling.
• Leave frame-rate headroom for trigger jitter and the occasional retry; running a link at 100% invites dropped frames.

Exposure, motion blur and freezing motion with strobe

High frame rate alone does not give a sharp image of a moving part — exposure time does. Motion blur is set by how far the part travels across the sensor during the exposure, so the rule is simple: keep the object's movement within roughly one pixel (or a fraction of your smallest feature) for the duration of the exposure. On a fast conveyor that can mean exposures in the tens of microseconds, far shorter than the frame period. Confusing frame rate with exposure is one of the most common high-speed mistakes; you can run 200 fps and still record smeared, unusable images if the exposure is too long.

The catch is that very short exposures starve the sensor of light, and pushing analogue gain to compensate raises noise and erodes the contrast your algorithm or AI model depends on. The professional answer is light, not gain: deliver a large amount of controlled illumination during a short window. A strobed light source pulsed in sync with the camera trigger concentrates intense illumination into the exposure window, freezing motion while keeping noise low — and it lets lamps run harder in pulse mode than they could continuously. Pair the camera's strobe/flash output with a controllable LED source and a lighting controller, and synchronise both to an encoder or part-detect trigger.

Three details make or break this in practice. Use the camera's hardware trigger and strobe output rather than software timing, so exposure and flash are deterministic and jitter-free. Confirm the sensor's exposure and trigger latency are short and stable enough for your part rate. And design the optics for the short exposure: a faster lens (lower f-number) or more light lets you keep exposure short without lifting gain, preserving image quality at speed.

• Set exposure from part velocity, not frame rate — keep motion under ~1 pixel during the exposure.
• Strobe a controlled light in sync with the trigger to freeze motion without raising gain and noise.
• Drive timing from the camera's hardware trigger / strobe output, synced to an encoder or sensor.
• Use a faster lens and more light rather than gain to keep short exposures clean.

Interface and bandwidth: the real speed limit

For continuous high-speed work the interface usually sets the ceiling, not the sensor. The data rate is resolution times bit depth times frame rate, and it must fit inside the interface's bandwidth with margin. GigE Vision (about 1 Gbit/s, ~115 MB/s usable) is the easy-to-integrate default with long cable reach, but it caps full-frame fps quickly; it suits modest resolutions or moderate speeds. USB3 Vision offers roughly 350–400 MB/s over short cables and is a strong single-camera high-bandwidth choice. For genuinely demanding cases, 10 GigE lifts the ceiling around tenfold, and CoaXPress (CXP) scales to several gigabytes per second over coax with deterministic, low-latency transfer and power-over-coax — the standard pairing for the fastest sensors.

Choose the interface from the sustained data rate the inspection demands, then leave headroom. A link run at its theoretical maximum has no slack for protocol overhead, host scheduling or bursty triggers, and the result is dropped frames or growing latency. It is also worth distinguishing burst from sustained throughput: a camera with on-board buffering can absorb a short burst above the link rate, but if your average part rate exceeds what the interface can carry continuously, the buffer fills and you start losing frames. Size for the sustained case.

The catalog spans these interfaces across Basler, iRAYPLE and Omron/Sentech, so the camera can be matched to the bandwidth the application actually needs. As a rough hierarchy: GigE for reach and simplicity at modest speed; USB3 for a fast single-camera link over short runs; 10 GigE or CoaXPress when full-resolution frame rate outruns the others.

• Data rate = resolution × bit depth × fps — it must fit the interface with margin.
• GigE: long reach, easy integration, lowest ceiling. USB3: ~350–400 MB/s, short single-camera links.
• 10 GigE and CoaXPress: highest sustained throughput, deterministic, for the fastest sensors.
• Size for sustained throughput, not a momentary burst the on-board buffer can absorb.

ROI, binning, global shutter and the frame grabber

When you need more speed than full-frame readout allows, two on-sensor tools recover it. A region of interest (ROI / AOI) reads out only the rows and columns you care about; because frame rate scales with the area read, cropping to a band or a small window can multiply fps dramatically — ideal when parts pass through a known strip of the field. Binning combines neighbouring pixels, trading resolution for lower data volume and higher sensitivity, which helps when light is scarce at short exposures and you do not need every pixel. Both reduce the data that has to cross the interface, easing the bandwidth ceiling as well as lifting the sensor's fps.

Shutter type is non-negotiable for fast motion. A global shutter exposes every pixel at the same instant, so a moving part is captured without distortion. A rolling shutter exposes rows sequentially and will skew or smear a fast-moving object, even with a short exposure, because different rows see the part at different positions. High-speed machine-vision cameras are therefore almost always global shutter, and you should treat that as a hard requirement whenever the object moves during acquisition.

For the most demanding sustained rates, a frame grabber earns its place. With CoaXPress or Camera Link, the grabber handles deterministic, low-latency capture, offloads the host CPU, can drive precise trigger and strobe timing, and reliably sustains throughput that a software-only NIC stack may not. For GigE and USB3 the host receives directly, so a properly specified NIC, driver and PC matter just as much — a fast camera behind an undersized host will still drop frames. Decide early whether the architecture is grabber-based (CXP/Camera Link) or host-based (GigE/USB3), because it shapes the camera choice, the cabling and the PC build.

• ROI/AOI: read fewer rows/columns to multiply fps and cut bandwidth on a known part path.
• Binning: combine pixels to lower data volume and raise sensitivity when you can spare resolution.
• Global shutter is mandatory for moving parts; a rolling shutter skews fast motion.
• Use a frame grabber (CXP/Camera Link) for deterministic, sustained capture; for GigE/USB3 specify the host NIC and PC to match.