Event camera data format: coordinates and timestamps, not pixels

An event camera sends no pictures. Every pixel watches its own brightness and speaks only when that brightness crosses a fixed change threshold, so the output is a stream of small records — pixel column, pixel row, polarity, timestamp — and a pixel that stands still sends nothing. That inversion is what trips engineers up on first contact: there is no frame, no exposure time, no gray value, and no fixed number of bytes per second. This explainer covers what actually sits in that data format, how to read it, how to fold it into tools that expect images, and when the honest answer is a conventional global-shutter camera instead. A conveyor example works the arithmetic end to end.

What sits in the stream: four numbers per event

Each event carries exactly four values: the pixel's column x, its row y, a timestamp t, and a polarity p. Polarity is ON when the pixel got brighter past the threshold and OFF when it got darker; in code it usually arrives as +1 or −1. Timestamps typically carry microsecond precision, and the stream is just these tuples in time order.

Two consequences follow directly. No event ever carries a brightness value, so gray levels, color and surface appearance are simply not in the stream — only where each pixel changed, when, and in which direction. And the change threshold lives in the sensor's configuration, so changes smaller than it never appear; that is the number a trial on the real part, under the real lighting, has to confirm.

The numbers that drive the format

Temporal resolution better than 100 μs is the headline specification of this sensor class. Inverted, that is more than 10,000 timestamped changes per second from a single pixel, a rate a conventional camera only matches by running above 10,000 fps. The second number is data volume, and it is set by motion rather than by sensor size:

A quiet scene costs almost nothing; a busy one bursts. Whatever interface and host you choose must survive the busiest moment of the cycle, not the average — event camera data throughput when events exceed the link covers exactly that failure.

Worked example: a part edge crossing at 0.5 m/s

Take illustrative but typical numbers: a 1/1.8"-class sensor with a 7.2 mm active width and 3.45 μm pixels (about 2,090 columns), a 180 mm field of view, a moving edge 200 pixels tall, and a 300 mm working distance.

1. Magnification m = 7.2 mm ÷ 180 mm = 0.04 (1:25).
2. One pixel covers 3.45 μm ÷ 0.04 = 86 μm of the part.
3. At 0.5 m/s = 500,000 μm/s, the edge sweeps 500,000 ÷ 86 ≈ 5,800 pixels per second.
4. A frame camera freezing that to one pixel of blur needs an exposure of 86 μm ÷ 500,000 μm/s ≈ 172 μs, and sampling the trajectory at one-pixel steps means about 5,800 fps. Even on a modest 640 × 480 region that is 307,200 pixels × 5,800 fps ≈ 1.78 GB/s of 8-bit data.
5. The event camera fires on the leading and trailing edges instead: 2 × 200 pixels in motion × 5,800 px/s ≈ 2.3 million events per second. Packed as a plain 9-byte struct — a 32-bit timestamp, two 16-bit coordinates, an 8-bit polarity field — that is about 21 MB/s, roughly 85× less than the frame stream, and vendor encodings pack tighter still.
6. The lens: f = working distance × m ÷ (1 + m) = 300 mm × 0.04 ÷ 1.04 ≈ 11.5 mm, so a 12 mm C-mount lens covers the field. The lens focal length calculator repeats this for any other distance.

Pick the f-number for the light you have: a pixel reports only after enough photons arrive, so a wider aperture tightens the response and quiets noise events.

Turning events into images your tools accept

Most vision libraries expect an image, so you accumulate. Two reconstructions cover nearly everything: an event-count image — how many events each pixel produced inside the window — for presence and speed maps, and a last-polarity image — the most recent direction of change — for silhouettes. Both need a window Δt, and the blur budget sets it: Δt = one pixel ÷ pixel speed, which here is 86 μm ÷ 500,000 μm/s ≈ 172 μs. Tolerate two pixels of smear and double it; go much beyond that and separate objects merge.

You can also skip images entirely. The record stream answers timing questions — vibration frequency, arrival time, counts past a gate — with a time-slice query that no frame pipeline can match. Whichever path you take, pre-allocate and reuse buffers instead of allocating per burst; reusing image buffers instead of per-frame allocation shows the pattern.

A stopped scene, though, returns nothing at all.

One workaround is strobed illumination, which turns a static part into a brightness change on every flash.

Event camera versus a global-shutter area scan camera

For the wider question — which paradigm wins for fast motion — the companion piece on event-based vision versus frame cameras works the trade-off; this one stays on the data format itself.

How to choose, and the cameras for the conventional cases

Run the arithmetic of the worked example on your own line, then decide:

• Pixel speed under about 1,000 px/s — a blur budget of 1 ms or more — is ordinary territory for global-shutter frames, with standard tools and standard qualification.
• To measure a frequency you need at least two samples per cycle: any 120 fps capture caps measurable vibration near 60 Hz, while microsecond stamps resolve well past 5 kHz. kHz-scale vibration, or triggering that must react inside a millisecond, is event territory.
• If you also need appearance — the surface, the print, the color — take frames, or run both cameras on a shared clock. Global-shutter camera and IMU modules for fast-motion tracking covers the conventional side of that pairing.

Slow production motion is the common case, and a compact C-mount camera with a global shutter covers it. The MV-CU020-90GC is exactly that class of camera.

For machines where the camera bolts directly onto the frame, board-level cameras bring the same shutter behavior in a much smaller package. The LS-BCM-0003 is a 3.1 MP USB3 board-level camera with a 1/1.8" global-shutter sensor at 120 fps.

When you need detail as well as speed, high-resolution global-shutter sensors hold the middle ground. The MV-CH120-11UC is a 12 MP USB3 camera, high-speed version, with a 1.1" sensor, C-mount and global shutter.

Browse area scan cameras for housed models or board-level cameras to embed, filter everything in the camera finder, or start at the camera step of the system configurator.

Checks before you commit

• Estimate events per second at the worst moment — parts crossing together, strobe firing — and double it for margin before checking it against the interface.
• Read the SDK documentation for the record layout: field order, timestamp unit, coordinate origin, polarity encoding. Parse exactly what it documents, not what a tutorial implies.
• Plan clock sync before fusing event times with frames or an encoder: align the clocks, then measure the residual offset. Mapping camera timestamps to PC time for recorded frames shows the measurement.
• Trial the darkest and brightest surfaces at the real working distance; the change threshold, not the resolution, decides what you detect.
• Fix the accumulation window from the blur budget before tuning any tool that runs on top of it.
• If the timestamped records must land in a plant database, logging timestamped events to a SQL database shows the logging side of that pattern.

When the event answer is wrong

Static inspection is the big one: presence checks, defect finding and code reading need full frames of a part that is not moving, and a sensor that only reports change has nothing to say. Appearance measurement fails the same way — gray values never enter the record. A textureless surface sliding past fires only at its boundaries, and a drift slower than the threshold never fires at all. Do not choose events for cable bandwidth alone, either; most lines that feel fast still need only tens to a few hundred frames per second, which a global-shutter area scan camera delivers with far simpler tooling.

The decision, case by case

• Vibration above about 60 Hz, kHz-scale timing, or a reaction inside a millisecond: event camera.
• Sparse fast motion you only need to detect and time — parts in flight, sparks, droplets: event camera.
• Any task that must see appearance, color or gray levels: global-shutter frames.
• Pixel speed under roughly 1,000 px/s with an exposure budget of a millisecond or more: global-shutter frames; most production lines live here.
• Tight mounting space at those moderate speeds: a board-level global-shutter camera.

If your line sits between two of these cases, send the part speed, the field of view and the fastest event you must catch through the contact page; free expert support comes with every order.