Event Visualization

An event camera does not output "images"; it outputs a sequence of sparse asynchronous event points (x, y, p, t) that the eye cannot directly "see" as motion. This page covers the two ways to "turn events into a picture", and how the core parameter accumulation time works with the display frame rate. For the event principle see Fundamentals, and for event fields and file formats see Data Formats.

1. Two visualization approaches

Approach	How	What you see
XYT 3D space	Plot events in X-Y-time 3D coords	Spatiotemporal trajectory (continuous "tube")
2D frame generation	Accumulate events over a time window into one 2D image	A frame similar to a conventional camera

2. XYT 3D event space

Plot each event (x, y, t) into 3D coordinates: x and y are pixel coordinates, t is the time axis; ON events (brightening) and OFF events (darkening) are colored differently. Expanded along the time axis, a moving target forms a continuous "spatiotemporal trajectory" — a direct manifestation of the event camera's spatiotemporal continuity and zero motion blur: events closer to the observation end are newer, those farther away are older.

3. Generating 2D frames from events

At any single instant T (microsecond precision) there are usually very few events — not enough to form a picture. "Generating a frame" therefore requires accumulating events over the window [T-dt, T], where dt is the accumulation time:

Initialize a 768×608 frame with a background color (e.g. black) (dimensions from HV_EVS_WIDTH / HV_EVS_HEIGHT in Toolkit API);
For each event within [T-dt, T], color it by polarity — ON (p=1) one color (e.g. red), OFF (p=0) another (e.g. green);
Output this frame.

A complete implementation in C++ + OpenCV is in Programming Guide 05 — Display & Visualization.

4. Accumulation schemes: full / over / under

The relative relationship between the accumulation time dt and "how often a frame is generated" (frame period = 1 / frame rate) defines three typical schemes:

Scheme	Relationship	Effect	Suited for
full	`dt` = frame period	Each event appears in exactly one frame	Default, most common
over	`dt` > frame period	The same event appears in multiple frames (smear / slow-motion feel)	Slow-motion review, emphasize trajectory
under	`dt` < frame period	Most events are discarded; only events within `dt` before the frame are visible	Reduce compute, look only at the "latest" change

Example: display frame rate 30 FPS → frame period ≈ 33ms.

dt = 33ms → full, each event appears once;
dt still 33ms, but frame rate raised to 1000 FPS (frame period 1ms) → over, the same event spans multiple frames;
dt = 0.1ms → under, about 90% of events will not be displayed.

Automatic full accumulation

Our host software MultiVision Studio can set the accumulation time to "auto", so it follows the frame rate and automatically takes the full-accumulation value — no manual math needed. For MIPI modules, the frame-stacking parameter can also be tuned in evs_live_player on RDK X5.

5. How to pair accumulation time with frame rate

See fast targets clearly: raise the frame rate (shorten the frame period), and shorten the accumulation time in step to stay at full.
See motion trajectories / slow motion: keep a longer accumulation time and raise the display frame rate (over).
Compute-constrained: lower the frame rate, or use under to process only the latest events.
Pairing with bias: bias decides event density (whether to fire), accumulation decides how to "view" (how to stack); the two must be coordinated — see Bias & Tuning.

6. Recording ≠ visualization

Important: RAW recording is independent of accumulation time

The accumulation time is only a display / visualization parameter, similar to watching slow motion on a player. RAW / EVT2 files recorded with MultiVision Studio or evs_live_player store all the original events, independent of the accumulation time set during recording — the accumulation time can be freely reset on playback.