BookNotesSlidesP-sets Syllabusdraft · v0.2.49.1
◀▲⌂▶
💬Comments welcome. To leave a note, select any text and click the note / highlight button that pops up — or open the panel with the tab at the top-right (‹). Notes are visible only inside our private review group.
💡 In a hurry? Jump to this chapter’s 1 big lesson ↓

34.7 Event sensors⧉

Almost every camera in this book is a clock-driven machine: on each tick of a shared shutter, every pixel reports its brightness, and the result is a frame. This is wasteful. Most of the scene usually isn't changing, so the sensor spends most of its data, power, and time re-transmitting a world that already sat still in the last frame, and anything that did move during the exposure is smeared into motion blur. The event sensor (or dynamic-vision sensor, DVS) throws the clock away. Each pixel runs independently and stays silent until the light it sees changes by a set amount; the instant it does, that one pixel fires a timestamped message, brighter here, now or darker here, now, and nothing else. A static scene produces near-silence; a moving edge sprays out a sparse stream of events with microsecond timing. There is no global frame exposure in a pure event stream, though the pixel circuit has finite bandwidth and response time. The sensor reports change, not state.

This inversion, asynchronous and differential rather than synchronous and absolute, defines the sensor. It buys a long list of advantages and exacts an equally structural price, and it forces nearly the entire downstream toolkit, built for dense synchronous arrays, to be rethought.

34.7.1 How it works: per-pixel change detection⧉

Each pixel of an event sensor continuously monitors the logarithm of the light falling on it. Working in log is the key design choice: a fixed log step is a fixed ratio of brightness, so the same threshold means "20% brighter" whether the pixel sits in deep shadow or bright sun, which gives the ratio-based sensitivity the eye has and the reason these sensors handle enormous dynamic range. The pixel remembers the log-intensity at which it last spoke. The moment the current log-intensity has risen by a threshold $\theta$ above that memory, the pixel emits an ON event (got brighter) and resets its memory to the new level; if it falls by $\theta$, it emits an OFF event (got darker). Each event is thus a tuple, pixel address, timestamp, polarity, and the pixel immediately re-arms to catch the next threshold crossing.

Because pixels fire independently and whenever they like, their events are read off the chip by an address-event representation (AER): a shared asynchronous bus over which each pixel announces its $(x, y)$ address and polarity the moment it fires, the time of arrival serving as the event's timestamp (Figure 34.7.1). There is no row-by-row scan, so there is no rolling shutter and no global frame time, just a single time-ordered stream of events from across the array, each marking one threshold crossing at one pixel at a timestamp resolution set by the device. Bus contention and circuit latency can delay or perturb that timestamp.

fig-event-pixel-log
Figure 34.7.1. One event pixel, and the stream it produces. The pixel tracks the log of incident light (top) and remembers the level at which it last fired. Each time that signal climbs by a threshold $\theta$ it emits an ON event (green) and resets its reference up; each time it drops by $\theta$ it emits an OFF event (red) and resets down (middle). The output is a train of timestamped, signed events, $(x,y,t,\text{polarity})$, rather than a brightness, read off a shared asynchronous bus by address-event representation (bottom): whichever pixel crosses threshold next puts its address on the bus, its arrival time serving as its timestamp. Working in log makes the threshold a fixed brightness ratio, which is why the sensor spans huge dynamic range. Schematic.

34.7.2 The upside: microseconds, dynamic range, no blur, little data⧉

The differential, asynchronous design wins on several axes at once, and they all trace to the same root.

💡 Big lesson (L34.3): report change, not state: the asynchronous pixel

A conventional sensor is synchronous and absolute: every pixel reports its brightness, on a shared clock, every frame, including most pixels that did not change, paying full data, power, and latency to re-send a static world, and smearing whatever moved into motion blur. An event sensor (and, in its own way, Chapter 34.5, Single-photon sensors (SPAD, avalanche, photon counting)) inverts this: each pixel is asynchronous and differential, staying silent until something happens and then firing a timestamped message the instant it does. The result is structural: microsecond latency, no motion blur, huge dynamic range, and data/power that scale with scene activity, not pixel count. The cost is equally structural: there is no frame and no absolute intensity, so the entire downstream toolkit, built on dense, synchronous arrays, must be rethought for a sparse, asynchronous stream.

fig-event-vs-frame
Figure 34.7.2. A spinning dot, seen by a frame camera and an event camera. The conventional camera (left) samples on a fixed clock: between frames the dot's motion is lost, and within each exposure it smears into motion blur. The event camera (right) is silent on the static background and fires a sparse stream of ON/OFF events that trace the moving edge continuously, with no blur and microsecond timing, but produces no grayscale picture, only change. The same scene as dense blurred frames versus a sparse crisp event stream. Schematic.

34.7.3 The downside: no picture, and a new kind of data⧉

Each advantage comes with a real cost. An event sensor does not produce an image. Its pixels report change in log-brightness, so a static image under constant illumination produces no ideal signal events, and there is no absolute intensity anywhere in its output; you cannot point it at a painting and get a photograph. This is why event cameras are frequently paired with a conventional sensor (or with a hybrid pixel that emits both events and occasional absolute frames, like the DAVIS sensor): the events supply the timing and the frames supply the appearance.

The deeper cost is to algorithms. The entire computer-vision and image-processing toolkit assumes a dense, synchronous array of intensities, with convolutions over a grid, frame differences, features computed on a picture. An event stream is none of those: it is a sparse, asynchronous point cloud in space-time, $(x, y, t, \text{polarity})$, with no frames to convolve and no fixed sampling rate. Working with it requires different machinery, such as accumulating events into time-surfaces or voxel grids, processing them event-by-event with recurrent or spiking networks, or fitting motion directly to the space-time event cloud, an active research area surveyed by Gallego et al. 2022.

fig-event-spacetime
Figure 34.7.3. Events live in space-time. Plotting each event at its $(x, y, t)$ with its polarity turns the output of the spinning dot into a helix in the space-time volume, a sparse point cloud, not a stack of images. There is no frame to convolve and no fixed time step; algorithms must work on the cloud itself (fitting motion to its geometry, or accumulating it into time-surfaces). The same data that looks impoverished as "no picture" is, in space-time, a clean continuous trace of motion. ON events green, OFF red, time along the vertical axis. Schematic.

34.7.4 Uses, lineage, and the contrast with single-photon⧉

This trade-off, strong on change detection and weak for static appearance, makes event sensors useful for the tasks frame cameras handle worst. High-speed tracking and robotics: catching a thrown ball or a fast gesture with microsecond latency rather than waiting a frame. Visual odometry and SLAM: estimating a drone's or car's motion robustly through fast movement and harsh lighting where a frame camera would blur or clip. Deblurring and high-speed reconstruction: the event stream constrains brightness changes during a long-exposure frame, so the two together can reconstruct a sharp, high-frame-rate video. Augmented reality and eye tracking: low-latency, low-power, always-on sensing of where a fast-moving eye or hand is, where a frame sensor's power and latency are prohibitive. These are usually done with the event camera alongside a conventional one: events for when and where it moved, frames for what it looks like.

The lineage runs back to neuromorphic engineering, Carver Mead's program of building circuits that compute the way nervous systems do, and the event pixel is a direct descendant of Mahowald and Mead's silicon retina, mimicking how the retina's ganglion cells fire on changes in light rather than reporting a steady image. The first practical imaging DVS was Lichtsteiner, Posch and Delbrück's 128×128 sensor in 2008 Lichtsteiner et al. 2008; they are now sold by iniVation and Prophesee, the latter in a high-definition stacked sensor co-developed with Sony.

Chapter 34.5, Single-photon sensors (SPAD, avalanche, photon counting) and the event sensor are siblings: both can produce discrete detections that require different processing. Timestamping SPADs are asynchronous, while counting SPAD arrays and QIS can also output synchronous frames. But they report different events. A SPAD fires on the arrival of a single photon; it measures light, at the ultimate sensitivity, and timestamps it for ranging. An event pixel fires on a change in brightness; it measures temporal contrast, which can come from motion or illumination change. One is the sensor for the darkest scene; the other is the sensor for the fastest one. Together with the velocity pixel of Chapter 34.6, Doppler / velocity imaging, they complete this part's argument: that the richest cameras are built by deciding, per pixel, to measure the specific quantity an ordinary frame does not measure: a photon's arrival, a surface's velocity, or a brightness change, and then rebuilding the algorithms to match.

Recap: big lessons of this chapter

💡 Big lesson (L34.3): report change, not state: the asynchronous pixel

A conventional sensor is synchronous and absolute: every pixel reports its brightness, on a shared clock, every frame, including most pixels that did not change, paying full data, power, and latency to re-send a static world, and smearing whatever moved into motion blur. An event sensor (and, in its own way, Chapter 34.5, Single-photon sensors (SPAD, avalanche, photon counting)) inverts this: each pixel is asynchronous and differential, staying silent until something happens and then firing a timestamped message the instant it does. The result is structural: microsecond latency, no motion blur, huge dynamic range, and data/power that scale with scene activity, not pixel count. The cost is equally structural: there is no frame and no absolute intensity, so the entire downstream toolkit, built on dense, synchronous arrays, must be rethought for a sparse, asynchronous stream.