Event Camera

An event camera has no frame clock. Each of its pixels watches the logarithm of the light falling on it and, whenever that value has changed by a set amount since the pixel last reported, sends out an event: the pixel’s address, a timestamp and one bit saying whether the light went up or down. A static scene viewed by a static camera produces almost nothing; a moving edge produces a stream of events along its path, timestamped with microsecond resolution. Gallego et al. (2022), whose survey is the main source for this article, describe the sensors as sampling light according to the scene’s dynamics rather than a clock unrelated to the scene, and list their attractions as high temporal resolution and low latency, very high dynamic range, low power and reduced motion blur. The price is an output that frame-based algorithms cannot use directly.

How a conventional pixel turns light into a number is the subject of image sensor, and how motion is estimated from frames that of optical flow estimation. This article covers the event pixel and its generation model, the sensor designs, the data and its representations, the noise and non-idealities, simulation, and the main ways of processing events. A worked example builds an exact event simulator for a moving edge and measures what a frame-sampled simulator gets wrong. Flying with event cameras is described in drone vision, and their place among robot sensors in robot perception.

How It Works

The event generation model

Gallego et al. (Section 2.4) state the idealized model. Each pixel responds to its log photocurrent, $L = \log I$, which the survey calls “brightness” (it notes that brightness is a perceived quantity and uses the word for log intensity for brevity; we follow it). An event $e_k = (\mathbf{x}_k, t_k, p_k)$ is triggered at pixel $\mathbf{x}_k$ and time $t_k$ as soon as the brightness increment since the last event at that pixel,

$$\Delta L(\mathbf{x}_k, t_k) = L(\mathbf{x}_k, t_k) - L(\mathbf{x}_k, t_k - \Delta t_k),$$

reaches a temporal contrast threshold $\pm C$:

$$\Delta L(\mathbf{x}_k, t_k) = p_k C,$$

with $C > 0$, $\Delta t_k$ the time since the pixel’s previous event, and polarity $p_k \in \{+1, -1\}$ the sign of the change: ON for an increase, OFF for a decrease. Each pixel memorizes the log intensity at its last event and keeps comparing the current value with it (survey, Section 2). In practice ON and OFF events may have different thresholds $C^+$ and $C^-$, set by the pixel’s bias currents. Gallego et al. report that typical sensors can set thresholds between 10% and 50% illumination change; the threshold in the model is a step in log intensity, so, in our reading, a threshold quoted as a 15% change is $C = \ln 1.15 \approx 0.14$, not 0.15. Polarity is $\pm 1$ in the survey; some file formats store it as 0 or 1.

Two readings of the model follow from a Taylor expansion (survey, Eqs. 3 and 4, read from the rendered page). For small $\Delta t_k$, an event says something about the temporal derivative of brightness,

$$\frac{\partial L}{\partial t}(\mathbf{x}_k, t_k) \approx \frac{p_k C}{\Delta t_k},$$

although the survey stresses that events are triggered by the size of the change, not by the derivative crossing a threshold. And under constant illumination and brightness constancy,

$$\Delta L \approx -\nabla L \cdot \mathbf{v}\,\Delta t,$$

so events are caused by brightness gradients moving with image velocity $\mathbf{v}$. As the dot product shows, motion parallel to an edge generates no events, and motion perpendicular to it generates them fastest. Only the velocity component along $\nabla L$, the normal flow of the aperture problem, changes the signal.

Working in log intensity has a consequence the survey points out: the light at a pixel is the product of illumination and reflectance, so when the illumination is roughly constant a change in log intensity signals a change of reflectance, and the events have a built-in invariance to the scene’s illumination level. Multiplying every intensity by a constant adds the same constant to every $L$ and leaves every difference unchanged.

The pixel’s bandwidth

The pixel is fast but not instantaneous. Gallego et al. (Section 2, Fig. 2) show the measured response of one pixel of the 128 × 128 DVS to a sinusoidally modulated LED: above a cut-off frequency the photoreceptor filters out the variation and the number of events per cycle falls. The cut-off rises with light intensity. Under the brighter illumination the bandwidth was about 3 kHz, which the survey equates to an exposure time of about 300 µs; at 1000 times lower intensity it fell to about 300 Hz, still ten times the 30 Hz Nyquist frequency of a 60 fps frame camera. Unlike the frame camera, the pixel does not alias frequencies above its bandwidth back into the baseband, because its response is continuous in time.

Readout

Events leave the pixel array on a shared digital bus, typically by address-event representation (AER) readout. Gallego et al. give readout rates from 2 MHz for the first DVS to 1200 MHz for a recent sensor, and note that the bus can saturate, which perturbs the times at which events are sent. Events are timestamped with microsecond resolution, from a 1 MHz clock (Section 2.2), and transmitted with sub-millisecond latency. The output is therefore data-driven: the faster the motion or the more texture moves, the more events per second.

Sensor Designs

The survey traces the idea to the “silicon retina” built by Mahowald and Mead at Caltech between 1986 and 1992, which had logarithmic pixels and sent spike events by the AER protocol but suffered from pixel mismatch, hand-tuned biases and large pixels. The survey presents three designs as the most common (Gallego et al., Section 2.1):

• DVS (Dynamic Vision Sensor). The change-detecting pixel described above, introduced as a practical sensor by Lichtsteiner, Posch and Delbruck (2008). The survey dates commercial availability of event cameras from 2008, with that sensor.
• ATIS (Asynchronous Time-based Image Sensor), from Posch, Matolin and Wohlgenannt (2011). Each pixel has a change-detection subpixel that triggers a second, exposure-measurement subpixel; the intensity is sent as two further events whose time difference encodes it, brighter light giving a shorter interval. Only pixels that change report a new intensity. The survey gives the ATIS a static dynamic range above 120 dB, pixels at least twice the area of DVS pixels, and slow intensity readout in dark scenes.
• DAVIS (Dynamic and Active Pixel Vision Sensor), from Brandli et al. (2014). A conventional active pixel sensor (APS) shares each pixel’s photodiode with the DVS circuit, adding about 5% to the pixel area, so the camera delivers frames and events from the same pixels. The frames can be triggered at a constant rate or on demand, but their dynamic range is limited (55 dB, Section 2.1) and, like any frame, they repeat themselves when nothing changes.

Because ATIS and DAVIS both contain a DVS-type change detector, the survey uses “DVS” for the binary-polarity event output whichever design produced it.

Data It Produces

The raw output is a list of events $(x, y, t, p)$, ordered roughly by time, with a variable rate: none for a still scene, many for fast motion in texture. A DAVIS adds intensity frames, and some cameras an inertial measurement unit. A single event carries little information, so almost every method first gathers events into a representation. Gallego et al. (Section 3.1) list the common ones:

• Individual events, used by event-by-event filters and spiking neural networks, which keep a state built from past events.
• Event packets: a set of events in a space-time neighbourhood, processed together; the right packet size depends on the method’s assumptions.
• Event frames (2D histograms): events counted or polarities summed per pixel over a window. They are easy to feed to image algorithms, but they quantize timestamps and depend strongly on how many events are used.
• Time surfaces: a 2D map holding one time per pixel, for example the timestamp of its last event, so that the “intensity” is the motion history (classical vision calls these motion history images). An exponential kernel emphasizes recent events. Time surfaces compress heavily and degrade in textured scenes where pixels fire often.
• Voxel grids: a space-time histogram. Each event’s polarity goes to one voxel or is spread over the nearest ones with a kernel; the second, interpolated form keeps sub-bin timing. Rebecq et al. (2019) use 10 temporal bins and spread each polarity over the two nearest bins with a triangular kernel.
• 3D point sets $(x, y, t)$, for plane fitting or point-based networks, and motion-compensated event images, which warp events along a candidate motion so that they pile up into sharp edges (below).

Gehrig et al. (2019) cast these grid representations as kernels, quantization and projections of the event stream, all differentiable, and learn the kernel with a small network together with the task network; they report about 12% improvement on optical flow estimation and object recognition over the then state of the art.

Characteristics

Gallego et al. give the following figures. They note that their Table 1 values are approximate, because the sensors were not measured on a common testbed, and that event sensors would benefit from agreed standard specifications. The table entries below were read from the rendered page.

Sensor (year)	Resolution	Latency	Dynamic range	Min. contrast sensitivity	Pixel size
DVS128 (2008)	128 × 128	12 µs at 1 klux	120 dB	17%	40 × 40 µm
DAVIS240 (2014)	240 × 180	12 µs at 1 klux	120 dB	11%	18.5 × 18.5 µm
DAVIS346 (2017)	346 × 260	20 µs	120 dB	14.3–22.5%	18.5 × 18.5 µm
ATIS (2011)	304 × 240	3 µs	143 dB	13%	30 × 30 µm

The titles of the papers that introduced the DVS128 and DAVIS240 quote 15 µs and 3 µs latency, and 130 dB for the DAVIS240; the table’s figures differ, and we report them as printed.

• Temporal resolution and latency. Microsecond timestamps; latency about 10 µs on the lab bench and sub-millisecond in the real world (Section 2.2). The timestamp resolution and the latency are different quantities.
• Dynamic range. The survey is not consistent about this number. Its abstract and introduction give 140 dB against 60 dB for standard cameras, while Section 2.2 gives more than 120 dB against the 60 dB of high-quality frame cameras and attributes the range to the logarithmic photoreceptors and the independence of the pixels. HDR imaging cites the Section 2.2 figure, robot perception the abstract’s.
• Power. About 10 mW at the die level for most cameras, prototypes below 10 µW, and embedded systems (sensor plus processor) of 100 mW or less (Section 2.2).
• Resolution and pixel size. Pixels have been large: 40 µm (DVS128), 30 µm (ATIS), 18.5 µm (DAVIS240, DAVIS346). The smallest published DVS pixel was 4.86 µm, and the largest published array about 1 Mpixel (1280 × 960), against 2–4 µm for global-shutter industrial frame sensors (Section 2.5). Back-side illumination raises the fill factor but can add spurious “leak” events.
• Cost. Several thousand dollars per camera when the survey was written; ESIM’s authors gave $6,000 for a DAVIS346 in 2018. The survey also cites a consumer home-monitoring device containing an event sensor that sold for 100 dollars.
• Colour and sensitivity. The survey finds few publications of practical colour event cameras, which use colour filter arrays or splitter prisms; experimental pixels with extra gain reach thresholds near 1%, at the cost of dynamic range (Section 2.5).

Noise and Non-Idealities

The model above is idealized. Gallego et al. (Section 2.4) describe the measured threshold of the DVS128 as roughly normally distributed around $C$, with a 1σ width of typically 2–4% temporal contrast. Fixed-pattern noise appears as pixel-to-pixel variation of the threshold: standard sensors reach a minimum $C$ of about ±15% with a standard deviation of about 2.5–4% between pixels. Setting $C$ too low produces “a storm of noise events”, starting from the pixels with the lowest thresholds. Other effects are the refractory period, during which a pixel ignores changes after firing (so fast objects produce fewer events), background events without a stimulus (Table 1 lists stationary noise from 0.03 to 0.2 events per pixel per second at 25 °C), and bus congestion, which delays timestamps. The survey states that a model predicting event-camera noise under arbitrary illumination and bias settings does not yet exist, and that noise filters mostly rely on real events being more correlated in space and time than noise.

Calibration

The survey gives two photometric calibration points. The threshold $C$ can be estimated from the bias currents that set it, and there have been attempts to measure pixelwise thresholds by comparing brightness changes signalled by events with differences of consecutive DAVIS frames (Section 2.4). For geometric calibration the readable sources here say little. In our reading, a DAVIS can use its frames, which come from the same photodiodes, with standard camera calibration, whereas a pure DVS sees a static calibration target only when something in the view changes, for example a moving or blinking pattern.

Processing the Data

Gallego et al. (Section 3) sort methods in two ways. Some update their estimate with every event, which gives minimum latency; others process packets or windows of events. Separately, methods are either model-based or learned. Three lines of work show the range.

Time surfaces and plane fitting. As an edge moves, its events lie on a surface in $(x, y, t)$, and the slopes of that surface encode the edge’s motion. Benosman et al. (2014), as the survey describes them, fit local planes to this surface and read the flow from the plane’s coefficients. The survey notes that the result is only normal flow, the velocity component perpendicular to the edge, and that the neighbourhood size matters. Too small a neighbourhood makes the fit arbitrary; too large a one breaks the planar approximation. The example below fits one global plane, our analogue of the local fits.

Contrast maximization. Gallego, Rebecq and Scaramuzza (2018) warp the events of a window to a reference time along candidate point trajectories, for optical flow $\mathbf{x}'_k = \mathbf{x}_k - (t_k - t_{\text{ref}})\boldsymbol{\theta}$, sum them into an image of warped events, and choose the motion parameters $\boldsymbol{\theta}$ that maximize that image’s variance (its contrast). The correct motion aligns events from the same edge and gives the sharpest image. The same framework handles depth and rotational motion, needs no appearance data, and produces motion-corrected edge images as a by-product.

Reconstructing video. Rebecq, Ranftl, Koltun and Scaramuzza (2019) take the opposite view: instead of new algorithms, turn events into intensity video and apply existing ones. Their E2VID network, a recurrent UNet, takes voxel grids of 25,000 events and is trained entirely on simulated events: MS-COCO images mapped onto a plane and viewed under random camera motion in the ESIM simulator. The positive and negative thresholds are drawn per scene from a normal distribution (mean 0.18, standard deviation 0.03), which they report stops the network from learning simply to integrate events. They report more than 20% better reconstruction quality than earlier methods, and better results from off-the-shelf classification and visual-inertial odometry on the reconstructed video than from methods designed for events.

Event cameras also feed visual odometry, visual-inertial odometry and feature tracking (survey, Section 4). The flight results with events, frames and inertial data are summarized in drone vision.

Simulating Events

Because sensors are costly and ground truth is hard to record, simulators matter (survey, Section 6.2). Rebecq, Gehrig and Scaramuzza (2018) built ESIM around one observation. Earlier simulators rendered frames at a fixed high rate and linearly interpolated each pixel’s brightness between them to emulate the pixel. That fails when the brightness varies faster than the chosen rate can follow. ESIM keeps the interpolation but chooses the rendering times adaptively, from the largest expected rate of brightness change or the largest image motion, so that between samples no pixel’s brightness is expected to change by more than the threshold or, in the second rule, no pixel moves too far; the authors used a factor $\lambda = 0.5$ in both rules. On their test sequence, the flow-based adaptive scheme needed on average 1,260 samples per second for a brightness RMSE of at most 0.01, where uniform sampling needed 2,060. ESIM also draws the threshold from a normal distribution and allows separate $C^+$ and $C^-$. To reproduce a real recording, its authors guessed $C^+ = 0.55$, $C^- = 0.41$ and $\sigma_C = 0.021$ from the event output. They list the refractory period, spatially and temporally varying thresholds and limited pixel bandwidth as effects ESIM does not model.

Example: An Exact Event Simulator and a Frame-Sampled One

The example simulates the ideal pixel of the model above on a scene whose events are known in closed form, and measures what changes when the brightness is only known at frame times, as in a frame-sampled simulator. It uses NumPy 2.3.5 only, has no random element, and runs in about half a second; two runs gave identical output.

Scene and conventions. The grid has 64 × 64 pixels, sampled at their centres $(x, y)$ (integers; $x$ to the right, $y$ down), with no optics blur, area integration or noise. A straight edge has its unit normal at $\varphi = 30°$ from the $x$ axis; $s = x\cos\varphi + y\sin\varphi$ is a pixel’s position along the normal. The edge front moves as $p(t) = 10 + v_n t$ pixels, and behind it the natural log of the intensity rises from $\ln 0.1$ to $\ln 1.0$ along a raised-cosine ramp $S(u) = (1 - \cos \pi u)/2$ of width $w = 4$ px:

$$L(s, t) = \ln 0.1 + \ln 10 \cdot S\!\left(\operatorname{clip}\!\left(\frac{p(t) - s}{w}, 0, 1\right)\right).$$

Every pixel only brightens, so only ON events occur. The pixel is the ideal one of the event generation model, with $C^+ = C^- = C = 0.2$ in log units, and its reference level starts at $L(s, 0)$. The pixel has no noise, refractory period, threshold mismatch, bandwidth limit or timestamp quantization.

Two simulators. The exact simulator inverts the ramp: a pixel crosses the levels $L(s,0) + kC$ for $k = 1, \dots, \lfloor (L(s,T) - L(s,0))/C \rfloor$, at $u_k = \arccos(1 - 2(L(s,0) + kC - \ln 0.1)/\ln 10)/\pi$ and time $t_k = (s + w u_k - 10)/v_n$. The sampled simulator follows the interpolation scheme ESIM describes. It samples $L$ at uniform frame rates of 100 Hz and 1 kHz (the uniform rates of ESIM’s Fig. 5) and 10 kHz (the rate ESIM oversampled for its ground truth). It interpolates linearly between samples and fires an event each time the interpolant reaches $L_{\text{ref}} \pm C$, then moves the reference by $\pm C$. ESIM’s paper does not say where inside an interval it places the events; placing them where the interpolant crosses each level is our reading. ESIM’s adaptive sampling is not implemented here.

Conditions. The edge moves at $|\mathbf{v}| = 50$ px/s along its normal for 1 s (A), at 500 px/s along its normal for 0.1 s (B), at 500 px/s at 60° to its normal for 0.1 s (C, normal speed 250 px/s), and at 500 px/s along itself (D, normal speed 0). In A and B the front sweeps 50 px, in C 25 px.

Measures. Each pixel’s event count is compared with $\lfloor (L(s,T) - L(s,0))/C \rfloor$. Timestamp errors are the sampled times minus the exact ones, with events matched by level within each pixel. The time surface is the last event time per pixel, and a least-squares plane $t = a x + b y + c$ over the pixels the whole ramp has passed gives a normal speed $1/\sqrt{a^2 + b^2}$ and a direction $\operatorname{atan2}(b, a)$. Illumination scaling multiplies the 1 kHz intensity frames of B by $k = 0.25$ and $4$, with events taken from $\ln(kI)$ and, as our model of an additive offset such as a dark signal, from $\ln(kI + 0.02)$.

Checks and hypotheses. These were written in the plan before any simulator ran, together with the values that a correct implementation reaches, from a closed-form script (no simulator).

• C0 (data): the exact times reproduce their levels to within $10^{-12}$, every event is ON, the number of fully swept pixels matches the closed form, and pixels ahead of the front start at $\ln 0.1$.
• C1: every pixel’s count equals the floor formula in every condition and simulator. The script also prints the smallest distance of $\Delta L/C$ from an integer, so that rounding cannot decide the check.
• C2: D gives no events, and the totals fall from B to C to D.
• C3: without an offset, scaling leaves every count and polarity unchanged and moves no timestamp by more than $10^{-9}$ s.
• C4: with the offset, a fully swept pixel gives 8, 10 and 11 events for $k = 0.25, 1, 4$, and the totals rise with $k$.
• C5: the exact time surface returns the normal speed to a relative error of $10^{-9}$ and the direction to within $10^{-6}$ degrees.
• H1: RMS timestamp error falls from 100 Hz to 1 kHz to 10 kHz in A, B and C.
• H2: at each rate it is larger in B than in A.
• H3: the sampled time-surface speed error falls with rate and stays below 5% at 1 kHz and 10 kHz.
• H4: where the displacement per frame is far below the ramp width, the timestamp error scales as $v\,\Delta t^2$, so RMS(A, 1 kHz)/RMS(A, 10 kHz) lies in [50, 200] and RMS(B, 10 kHz)/RMS(A, 10 kHz) in [5, 20]. The derivation: linear interpolation errs by $\tfrac12 L''\tau(\Delta t - \tau)$ in $L$, dividing by $L'$ turns this into time, and with $L$ a function of $(p(t) - s)/w$, $L'' \propto v^2$ and $L' \propto v$, while $\tau(\Delta t - \tau)$ scales as $\Delta t^2$.

C2 holds by construction: an infinite straight edge moving along itself leaves the image unchanged. It is an illustration of the dot product in the event generation model, not a test. C0, C1, C4 and C5 test the code against closed-form values that were computed before the pilot.

import os
for v in ("OMP_NUM_THREADS", "OPENBLAS_NUM_THREADS", "MKL_NUM_THREADS"):
    os.environ[v] = "1"                       # one BLAS thread, set before NumPy loads
import numpy as np

# Scene: 64 x 64 pixels, centres at integer (x, y), x right, y down, point sampling.
# A straight edge with unit normal at PHI = 30 deg; s = x cos(PHI) + y sin(PHI).
# Log intensity (natural log) rises from ln 0.1 to ln 1.0 across a raised-cosine ramp
# of width W behind the front p(t) = P0 + v_n t, so every pixel only brightens.
N, PHI, P0, W = 64, np.radians(30.0), 10.0, 4.0
I_LO, I_HI = 0.1, 1.0
L_LO, DL = np.log(I_LO), np.log(I_HI / I_LO)
C = 0.2                                        # contrast threshold, log units, C+ = C-
y, x = np.mgrid[0:N, 0:N].astype(float)
X, Y = x.ravel(), y.ravel()
s = X * np.cos(PHI) + Y * np.sin(PHI)
NPIX = s.size

def log_intensity(s_, t, vn):
    u = np.clip((P0 + vn * t - s_) / W, 0.0, 1.0)
    return L_LO + DL * (1 - np.cos(np.pi * u)) / 2

def simulate_exact(vn, T):
    """Ideal pixel, closed-form crossing times (valid here: L only rises)."""
    if vn == 0:
        return np.zeros(0, int), np.zeros(0), np.zeros(0, int)
    L0, LT = log_intensity(s, 0.0, vn), log_intensity(s, T, vn)
    n = np.floor((LT - L0) / C).astype(int)
    pix = np.repeat(np.arange(NPIX), n)
    k = np.concatenate([np.arange(1, m + 1) for m in n]).astype(float)
    level = L0[pix] + k * C
    u = np.arccos(1 - 2 * (level - L_LO) / DL) / np.pi
    t = (s[pix] + W * u - P0) / vn
    return pix, t, np.ones(pix.size, int)

def simulate_sampled(frame, times):
    """ESIM-style: log intensity sampled at `times`, interpolated linearly in between;
    an event each time the interpolant reaches L_ref +/- C, then L_ref moves by +/- C."""
    L_prev = frame(times[0])
    L_ref = L_prev.copy()
    P, T_, Q = [], [], []
    for t0, t1 in zip(times[:-1], times[1:]):
        L_cur = frame(t1)
        for pol in (1, -1):
            while True:
                target = L_ref + pol * C
                i = np.nonzero(pol * (L_cur - target) >= 0)[0]
                if i.size == 0:
                    break
                frac = (target[i] - L_prev[i]) / (L_cur[i] - L_prev[i])
                P.append(i); T_.append(t0 + frac * (t1 - t0)); Q.append(np.full(i.size, pol))
                L_ref[i] = target[i]
        L_prev = L_cur
    if not P:
        return np.zeros(0, int), np.zeros(0), np.zeros(0, int)
    return np.concatenate(P), np.concatenate(T_), np.concatenate(Q)

def by_pixel(ev):
    """Sort events by pixel, then time."""
    pix, t, p = ev
    o = np.lexsort((t, pix))
    return pix[o], t[o], p[o]

def counts(ev):
    return np.bincount(ev[0], minlength=NPIX)

def plane_speed(ev, mask):
    """Time surface (last ON timestamp per pixel), plane t = a x + b y + c over `mask`;
    normal speed 1/|grad t| and its direction."""
    ts = np.full(NPIX, -np.inf)
    np.maximum.at(ts, ev[0][ev[2] > 0], ev[1][ev[2] > 0])
    A = np.c_[X[mask], Y[mask], np.ones(mask.sum())]
    a, b, _ = np.linalg.lstsq(A, ts[mask], rcond=None)[0]
    return 1 / np.hypot(a, b), np.degrees(np.arctan2(b, a))

conds = {"A": (50.0, 0.0, 1.0), "B": (500.0, 0.0, 0.1),
         "C": (500.0, 60.0, 0.1), "D": (500.0, 90.0, 0.1)}   # |v| px/s, angle to normal, T s
rates = (100, 1000, 10000)
res = {}
print(f"pixels {NPIX}, C = {C}, edge normal {np.degrees(PHI):.0f} deg, ramp width {W:.0f} px, "
      f"events per fully swept pixel floor(ln10/C) = {int(np.floor(DL / C))}")
for name, (v, th, T) in conds.items():
    vn = v * np.cos(np.radians(th))
    vn = 0.0 if abs(vn) < 1e-9 else vn
    L0, LT = log_intensity(s, 0.0, vn), log_intensity(s, T, vn)
    ratio = (LT - L0) / C
    expect = np.floor(ratio).astype(int)
    ch = ratio > 0
    margin = np.min(np.abs(ratio[ch] - np.round(ratio[ch]))) if ch.any() else np.nan
    full = (s >= P0) & (s <= P0 + vn * T - W)
    ahead_ok = np.all(L0[s >= P0] == L_LO)
    ex = by_pixel(simulate_exact(vn, T))
    rt = np.max(np.abs(log_intensity(s[ex[0]], ex[1], vn) - (L0[ex[0]] +
             (np.arange(ex[0].size) - np.searchsorted(ex[0], ex[0]) + 1) * C))) if ex[0].size else 0.0
    print(f"\n{name}: |v| = {v:.0f} px/s at {th:.0f} deg to the normal, normal speed {vn:.0f} px/s, "
          f"T = {T} s; fully swept pixels {full.sum()}; L(0) = ln 0.1 ahead of the front: {ahead_ok}; "
          f"min distance of dL/C to an integer {margin:.2e}; exact round-trip error {rt:.1e}")
    print(f"  {'simulator':>9s} {'events':>7s} {'count mismatches':>16s} {'ON only':>7s} "
          f"{'RMS dt (us)':>12s} {'max dt (us)':>12s} {'speed (px/s)':>14s} {'rel. error':>10s} {'dir (deg)':>9s} {'dir error':>9s}")
    sims = [("exact", ex)]
    for r in rates:
        times = np.arange(int(round(r * T)) + 1) / r
        sims.append((f"{r} Hz", by_pixel(simulate_sampled(lambda t: log_intensity(s, t, vn), times))))
    for label, ev in sims:
        cnt = counts(ev)
        mism = int(np.sum(cnt != expect))
        on = bool(np.all(ev[2] == 1))
        if ev[0].size and np.array_equal(cnt, counts(ex)):
            dt = ev[1] - ex[1]
            rms, mx = np.sqrt(np.mean(dt ** 2)) * 1e6, np.max(np.abs(dt)) * 1e6
        else:
            rms = mx = np.nan
        if full.any():
            sp, d = plane_speed(ev, full)
            rel = abs(sp - vn) / vn
            print(f"  {label:>9s} {ev[0].size:7d} {mism:16d} {str(on):>7s} {rms:12.4g} {mx:12.4g} "
                  f"{sp:14.6f} {rel:10.3e} {d:9.4f} {abs(d - np.degrees(PHI)):9.3e}")
        else:
            print(f"  {label:>9s} {ev[0].size:7d} {mism:16d} {str(on):>7s} {rms:12.4g} {mx:12.4g} "
                  f"{'no events':>14s}")
        res[name, label] = (rms, sp if full.any() else np.nan)

print("\nScaling of the timestamp error (displacement per frame far below the ramp width):")
print(f"  RMS(A, 1 kHz) / RMS(A, 10 kHz) = {res['A', '1000 Hz'][0] / res['A', '10000 Hz'][0]:.3g}")
print(f"  RMS(B, 10 kHz) / RMS(A, 10 kHz) = {res['B', '10000 Hz'][0] / res['A', '10000 Hz'][0]:.3g}")

# Illumination: condition B, 1 kHz frames of intensity k * I, events from ln(k I) or ln(k I + eps).
v, th, T = conds["B"]
times = np.arange(int(round(1000 * T)) + 1) / 1000
full = (s >= P0) & (s <= P0 + v * T - W)
I = lambda t: np.exp(log_intensity(s, t, v))
ref = by_pixel(simulate_sampled(lambda t: np.log(I(t)), times))
print("\nIllumination scaling, condition B, 1 kHz:")
for k in (0.25, 4.0):
    ev = by_pixel(simulate_sampled(lambda t: np.log(k * I(t)), times))
    same = np.array_equal(counts(ev), counts(ref)) and np.array_equal(ev[2], ref[2])
    dt = np.max(np.abs(ev[1] - ref[1])) if same else np.nan
    print(f"  ln(kI), k = {k:4}: events {ev[0].size}, per-pixel counts and polarities identical to k = 1: "
          f"{same}, max |dt| {dt:.3g} s")
eps = 0.02
for k in (0.25, 1.0, 4.0):
    ev = simulate_sampled(lambda t: np.log(k * I(t) + eps), times)
    per = np.unique(counts(ev)[full])
    print(f"  ln(kI + {eps}), k = {k:4}: events {ev[0].size}, events per fully swept pixel {per}")

Output (NumPy 2.3.5):

pixels 4096, C = 0.2, edge normal 30 deg, ramp width 4 px, events per fully swept pixel floor(ln10/C) = 11

A: |v| = 50 px/s at 0 deg to the normal, normal speed 50 px/s, T = 1.0 s; fully swept pixels 2873; L(0) = ln 0.1 ahead of the front: True; min distance of dL/C to an integer 1.18e-05; exact round-trip error 8.9e-15
  simulator  events count mismatches ON only  RMS dt (us)  max dt (us)   speed (px/s) rel. error dir (deg) dir error
      exact   33523                0    True            0            0      50.000000  8.527e-16   30.0000 3.197e-14
     100 Hz   33523                0    True        357.7         3647      49.999229  1.543e-05   29.9996 4.239e-04
    1000 Hz   33523                0    True        3.478        79.07      49.999996  7.618e-08   30.0000 1.952e-06
   10000 Hz   33523                0    True      0.03525        0.983      50.000000  1.099e-09   30.0000 3.331e-08

B: |v| = 500 px/s at 0 deg to the normal, normal speed 500 px/s, T = 0.1 s; fully swept pixels 2873; L(0) = ln 0.1 ahead of the front: True; min distance of dL/C to an integer 1.18e-05; exact round-trip error 8.9e-15
  simulator  events count mismatches ON only  RMS dt (us)  max dt (us)   speed (px/s) rel. error dir (deg) dir error
      exact   33523                0    True            0            0     500.000000  1.023e-15   30.0000 1.066e-14
     100 Hz   33523                0    True         2777         7907     500.067541  1.351e-04   30.0079 7.930e-03
    1000 Hz   33523                0    True        35.77        364.7     499.992287  1.543e-05   29.9996 4.239e-04
   10000 Hz   33523                0    True       0.3478        7.907     499.999962  7.618e-08   30.0000 1.952e-06

C: |v| = 500 px/s at 60 deg to the normal, normal speed 250 px/s, T = 0.1 s; fully swept pixels 1028; L(0) = ln 0.1 ahead of the front: True; min distance of dL/C to an integer 1.64e-04; exact round-trip error 4.0e-15
  simulator  events count mismatches ON only  RMS dt (us)  max dt (us)   speed (px/s) rel. error dir (deg) dir error
      exact   13337                0    True            0            0     250.000000  1.478e-15   30.0000 7.816e-14
     100 Hz   13337                0    True         1861         7808     249.378075  2.488e-03   29.9929 7.063e-03
    1000 Hz   13337                0    True         18.1          490     249.998649  5.406e-06   30.0002 1.512e-04
   10000 Hz   13337                0    True       0.1792         4.07     249.999999  4.956e-09   30.0000 6.551e-07

D: |v| = 500 px/s at 90 deg to the normal, normal speed 0 px/s, T = 0.1 s; fully swept pixels 0; L(0) = ln 0.1 ahead of the front: True; min distance of dL/C to an integer nan; exact round-trip error 0.0e+00
  simulator  events count mismatches ON only  RMS dt (us)  max dt (us)   speed (px/s) rel. error dir (deg) dir error
      exact       0                0    True          nan          nan      no events
     100 Hz       0                0    True          nan          nan      no events
    1000 Hz       0                0    True          nan          nan      no events
   10000 Hz       0                0    True          nan          nan      no events

Scaling of the timestamp error (displacement per frame far below the ramp width):
  RMS(A, 1 kHz) / RMS(A, 10 kHz) = 98.7
  RMS(B, 10 kHz) / RMS(A, 10 kHz) = 9.87

Illumination scaling, condition B, 1 kHz:
  ln(kI), k = 0.25: events 33523, per-pixel counts and polarities identical to k = 1: True, max |dt| 3.12e-17 s
  ln(kI), k =  4.0: events 33523, per-pixel counts and polarities identical to k = 1: True, max |dt| 1.82e-17 s
  ln(kI + 0.02), k = 0.25: events 24380, events per fully swept pixel [8]
  ln(kI + 0.02), k =  1.0: events 30478, events per fully swept pixel [10]
  ln(kI + 0.02), k =  4.0: events 33480, events per fully swept pixel [11]

Counts are exact; timing is not. Every pixel in every condition and simulator fired exactly $\lfloor \Delta L/C \rfloor$ events (C1 held; the smallest margin from an integer, 1.18e-05, is far above rounding error). The data checks C0 held. A frame-sampled simulator therefore gets the number of events right here, but this follows from the design: each pixel’s brightness only rises, and the last sample falls at $T$. A linear interpolant through the samples of a monotone signal is itself monotone and passes through the true end values, so it crosses the same levels. The timestamps are another matter. At 100 Hz the RMS error is 0.36 ms for the slow edge and 2.8 ms for the fast one, with errors up to about 8 ms, comparable to the 10 ms frame interval and three orders of magnitude coarser than the microsecond timestamps of a real sensor. The errors fall steeply with the frame rate, and at a given rate they are larger for the faster edge. H1 and H2 held in every printed case. H4 held: the ratios 98.7 and 9.87 are close to the 100 and 10 the $v\,\Delta t^2$ law predicts. Condition B at a given rate is condition A at a tenth of the rate with time divided by ten, since only the displacement per frame matters. That is why B at 1 kHz repeats A’s 100 Hz relative speed error (1.543e-05), and why B’s RMS timestamp error at 1 kHz and at 10 kHz is a tenth of A’s at a tenth of that rate (35.77 µs at 1 kHz against 357.7 µs at 100 Hz). The $v\,\Delta t^2$ law gives the same factor, ten times the speed and a hundredth of $\Delta t^2$, but the time scaling makes it exact, outside the small-displacement regime too. ESIM’s flow-based sampling rule bounds the same quantity, the displacement between samples. The monotone edge hides a failure that, in our reading, appears with a thin bar or texture finer than the displacement per frame: there a coarse simulator can step over a brightness peak and lose events altogether, which this example does not test.

Illumination. Multiplying the intensity by 0.25 or 4 changed no count or polarity and moved timestamps by at most 3.1e-17 s, rounding error (C3 held). With the additive offset the invariance is gone: the per-pixel count goes 8, 10, 11 as the light goes from 0.25 to 4, and the total rises from 24,380 to 33,480 (C4 held). By construction, the offset compresses the dark end of the logarithm, so a dimmer scene gives smaller log steps and fewer events, while at $k = 4$ a fully swept pixel again gives the offset-free 11.

Motion along an edge, and normal flow. The edge moving along itself produced no events in any simulator (C2 held). At 60° the stream has 13,337 events against B’s 33,523, and the exact time surface returns 250.000000 px/s with direction error 7.816e-14 degrees: the normal speed $|\mathbf{v}|\cos 60°$, not the true 500 px/s (C5 held for speed and direction in A, B and C, with relative speed errors of at most 1.478e-15 and direction errors of at most 7.816e-14 degrees). The event stream of a straight edge cannot reveal motion along it, the aperture problem in event form, and the plane fit measures only normal flow, as the survey says of Benosman et al.‘s method. The sampled simulators’ plane fits stayed within 0.25% of the normal speed even at 100 Hz (2.488e-03 in C). Their errors fell with rate and were at most 1.543e-05 at 1 kHz and 10 kHz (H3 held in A, B and C). In our reading, the fit over thousands of pixels averages out much of the per-event timing error, which is why the error in velocity is far smaller than the error in time.

Disclosure of the planning and run history, from the drafting log:

• Before the plan’s checksum was recorded, two closed-form planning scripts ran (no simulator): the reachable-value script at 21:15:39, and at 21:15:53 a diagnostic of how close $\Delta L/C$ comes to an integer, after the first script’s four-decimal print showed 0.0000. The diagnostic found the smallest distance and set the precision with which C1’s margin is printed.
• The pilot then ran the planned script. In the pilot, C5’s direction part could not be decided, because the direction was printed only to four decimals against a tolerance of $10^{-6}$ degrees.
• Before the first run, the editor approved one print-format repair: the column of direction errors. The first run is the pilot script with that column added. Every other printed value is identical between pilot and first run, and no outcome differs except that C5’s direction part, undecided in the pilot, held in the first run.

Strengths

• Timing. Microsecond timestamps and latency of the order of 10 µs on the bench (survey) let events follow motion between the frames of a conventional camera; the example shows how coarse frame-time sampling is by comparison.
• Dynamic range. Logarithmic, independent pixels give a range quoted as more than 120 dB, or 140 dB, by the survey; see dynamic range for what such figures measure.
• Little motion blur, little redundancy. The survey describes event cameras capturing very fast motion without the motion blur of frame cameras (Section 2.2), although the pixel’s finite bandwidth acts like a short exposure (above); a static scene costs almost nothing in data and power.
• Illumination invariance. Events depend only on differences of log intensity, so a moving edge gives the same events at any constant illumination level; under constant illumination, events signal reflectance edges in motion. A change of illumination over time does produce events.

Limitations

• New algorithms. Events are asynchronous, sparse and carry one bit of photometric information; frame-based algorithms do not apply directly (survey, Section 2.3).
• Motion-dependent output. What a scene produces depends on its motion: no motion, no events, and motion along an edge gives none either. Polarity depends on motion direction, a nuisance for recognition (Section 3.1).
• Noise. Threshold mismatch, background events, refractory periods and bus saturation are only partly characterized (Section 2.4).
• Resolution, cost and pixel size. Arrays are small and pixels large compared with frame sensors, and cameras have been expensive (Section 2.5).
• No absolute intensity from a pure DVS; ATIS and DAVIS add it at a cost in pixel area or dynamic range.

Typical Applications

Gallego et al. (Section 1) list object tracking, surveillance and monitoring, object and gesture recognition, depth estimation, structured-light 3D scanning, optical flow, HDR image reconstruction and SLAM, and expect deblurring and star tracking to follow. In robotics, event cameras have been flown on quadrotors for state estimation (see drone vision), and they have been suggested for reducing perception latency in fast obstacle avoidance.

Comparison with Other Sensors

Property	Frame camera	Event camera (DVS)	DAVIS
Output	Full frames at a fixed rate	Events $(x, y, t, p)$, asynchronous	Events plus frames from the same pixels
Time resolution	Frame interval and exposure	Microsecond timestamps	Both
Dynamic range (survey)	About 60 dB	Over 120 dB (Section 2.2)	Events as DVS; frames 55 dB
Static scene	Repeats the same frame	Almost no output	Frames only
Absolute intensity	Yes	No	From the frames

A digital camera samples intensity on a grid at fixed times; an event camera samples changes of log intensity at times set by the scene. Active depth sensors such as LiDAR measure distance directly, which neither does.