Event Cameras (Neuromorphic Vision): The Ultimate Guide

A standard camera measures brightness on a clock. Every 33 milliseconds it opens a shutter, integrates light across the whole sensor, and hands you a frame: millions of pixels, most of them identical to the frame before, all timestamped with the single moment the shutter closed. That model has run machine vision for fifty years, and it wastes almost everything. In a scene where one object is moving, you re-transmit the static background thousands of times. When the object moves fast, it smears across the exposure. When part of the scene is in shadow and part in sun, one exposure cannot hold both. And the fastest you ever learn that something changed is one frame period late.

An event camera throws out the clock. Each pixel runs its own independent circuit that watches the log of the light hitting it and fires a tiny message the instant that log-brightness crosses a threshold, then resets and waits for the next change. Nothing moves in front of a pixel, the pixel stays silent. An edge sweeps across it, the pixel fires within microseconds. There is no frame, no global shutter, no exposure time. The output is a sparse asynchronous stream of events, each one a tuple of pixel coordinate, timestamp, and the sign of the change. This is the Dynamic Vision Sensor (DVS), and the field around it goes by neuromorphic vision because the design borrows the spiking, change-driven behaviour of biological retinas.

This guide covers the sensor from the silicon up: how the DVS pixel actually works and the log-intensity math behind it, why the result gives you microsecond latency and 120+ dB of dynamic range with no motion blur, how the event-stream data model differs from a frame and what that does to every downstream algorithm, the algorithm landscape (event-based optical flow, feature tracking, visual-inertial odometry, and frame reconstruction), the real failure modes (noise, the new-paradigm tooling gap, threshold tuning), the applications where event cameras earn their place, and the two vendors, Prophesee and iniVation, that ship most of the hardware you can buy in 2026.

The take: an event camera is the right sensor when your problem is dominated by speed, dynamic range, or power, and it is the wrong sensor when you need absolute brightness, static-scene appearance, or a mature tooling stack. It measures temporal contrast, so it is blind to a still scene and brilliant at a fast one. Most disappointment with event cameras comes from treating the stream as a drop-in replacement for frames instead of rebuilding perception around asynchronous change.

Companion reading: machine vision, robot sensors, drone/UAV hardware, robot perception & pose estimation, and self-driving cars.

Table of contents

1. Key takeaways
2. Why the frame is the problem
3. How the DVS pixel works
4. The properties that fall out of the design
5. The event-stream data model
6. Sensor variants and a comparison
7. The specs that matter and how to read a datasheet
8. Noise, calibration, and error sources
9. The algorithm landscape
10. Integration, bandwidth, and compute
11. Applications
12. Selecting an event camera
13. Frequently asked questions

Why the frame is the problem

Start with what a conventional camera does, because the event camera is an answer to its specific limits. A frame sensor exposes every pixel over a shared window, reads the whole array out on a fixed clock, and delivers a dense grid of absolute intensities. Three costs are baked into that model.

The first is redundancy. Point a 1 megapixel camera at a scene where a single small object moves and you still transmit a million pixels every frame, nearly all of them unchanged from the previous one. The information rate of the scene might be a few kilobytes per second; the sensor's output rate is tens of megabytes per second. Everything downstream, the bus, the memory, the processor, pays for data that carries no new information.

The second is the exposure-latency trade. A short exposure freezes motion but starves the sensor of photons, so it is noisy in low light. A long exposure gathers light but smears anything moving across the frame. And whatever you pick, you learn that the world changed no sooner than the next readout, so a 30 fps camera has a floor of 33 ms of latency before any algorithm even starts. For a drone dodging a thrown object or a robot arm catching a part, 33 ms is a long time.

The third is dynamic range. One global exposure has to hold both the shadow and the highlight. A scene with 100,000:1 contrast (a car exiting a tunnel into sun) blows out the bright region or crushes the dark one, because a linear sensor with a 10-12 bit ADC covers only about 60-70 dB. High-dynamic-range tricks (multiple exposures, log pixels) help, at the cost of frame rate or noise.

An event camera attacks all three at once by changing the question the sensor asks. Instead of "what is the brightness everywhere, now," each pixel asks "has my brightness changed enough to be worth reporting, and if so, when." Redundancy vanishes because unchanged pixels stay silent. The latency floor vanishes because a pixel reports at the moment of change. Dynamic range explodes because each pixel adapts to its own light level in the log domain. The price is that you give up the frame, and with it the entire toolbox that assumes one. That trade is the whole subject of this guide.

How the DVS pixel works

The core idea, from Lichtsteiner, Posch, and Delbruck's 2008 DVS, is a per-pixel circuit that continuously tracks the logarithm of photocurrent and fires when it has moved by a fixed amount. Working in the log domain is the crucial choice: a fixed change in log-intensity is a fixed fractional (contrast) change in intensity, so the pixel responds to relative contrast regardless of absolute illumination, which is exactly what makes the dynamic range so wide.

The pixel signal chain

A DVS pixel has three stages in sequence. A logarithmic photoreceptor converts photocurrent to a voltage proportional to the log of light intensity. A differencing amplifier removes the DC level and amplifies changes since the last event, so the circuit is sensitive to change rather than absolute level. Two comparators then watch that amplified difference against an ON threshold and an OFF threshold. When the signal crosses one, the pixel emits an event of the corresponding polarity and resets the differencing stage to the current level, arming it for the next change.

Log-intensity state at a pixel:
  L(t) = log( I(t) )          I = photocurrent (proportional to brightness)

An event fires at pixel (x,y) at time t when:
  | L(x, y, t) - L(x, y, t_last) | >= C

  C        = contrast threshold (set by bias currents), a fixed log step
  t_last   = time of that pixel's previous event
  polarity = +1 if L increased by C  (ON event)
             -1 if L decreased by C   (OFF event)

After firing, the reference resets:  L(x, y, t_last) <- L(x, y, t)

Why the log domain gives contrast sensitivity

The threshold C is a step in log-brightness. Because d(log I) = dI / I, a fixed log step corresponds to a fixed ratio of intensity change:

  Delta L = C  ->  I_new / I_old = e^C

Example: C = 0.2 (a common ~20% contrast threshold)
  e^0.2 ~= 1.22   ->  a pixel fires on roughly a 22% brightness change,
  whether the local light level is a dim corridor or a sunlit wall.

That is the mechanism behind both the dynamic range and the invariance. A 22% contrast edge triggers the same event whether it sits in deep shade or full sun, so the sensor extracts scene structure (edges, texture in motion) across an intensity span no single-exposure frame sensor can hold.

Asynchronous readout

Each pixel decides on its own when to speak. When it does, an arbiter circuit on the sensor grants it the bus and reads out its address (this is the address-event representation, AER, that neuromorphic hardware has used since the 1990s). Pixels with nothing to report consume almost no bandwidth and little power. The consequence is that the sensor has no frame rate in the usual sense: its output rate is set by how much of the scene is changing and how fast.

Rule of thumb: think of a DVS as a million tiny independent light-change detectors sharing one output bus rather than a camera that reads out fast. The distinction drives every design decision downstream.

The properties that fall out of the design

Four headline properties come directly from the pixel design, and understanding them as consequences (rather than as marketing bullets) tells you when the sensor will and will not help.

Microsecond latency and temporal resolution. A pixel timestamps its event when the threshold is crossed, with a clock that resolves microseconds. Real end-to-end latency depends on bias settings, bus contention under heavy load, and the host interface, so in practice you see roughly 1 microsecond to a few hundred microseconds rather than the theoretical floor. Still, that is two to four orders of magnitude below a frame camera's period. For closed-loop control of fast motion, that latency is the whole point.

High dynamic range, 120-140 dB. The logarithmic front end and per-pixel adaptation mean each pixel operates around its own light level. Datasheets quote 120 dB routinely and up to about 140 dB, against roughly 60-70 dB for a linear frame sensor. In scenes that murder a frame camera (headlights at night, a mouth of a tunnel, an arc weld) the event camera keeps producing usable edges.

No motion blur. Blur in a frame camera is the integration of a moving edge over the exposure window. A DVS has no exposure window, so a fast edge produces a clean sequence of events tracing its path in space-time. A propeller at 10,000 rpm, a bullet, a bouncing ball: each becomes a sharp trajectory of events rather than a smear.

Low power and low bandwidth in sparse scenes. Silent pixels cost almost nothing, so a mostly static scene yields a trickle of data and single-digit-milliwatt sensor power. This makes event cameras attractive for always-on, battery-powered, or space and payload-limited applications. The corollary bites too: a highly dynamic or noisy scene (rain, foliage in wind, a flickering light, camera shake) can flood the bus with events and spike both bandwidth and power. Scene activity sets the load.

War story: a team put an event camera on a quadrotor to exploit its latency for obstacle dodging, benchmarked it in a calm lab, and saw a beautifully sparse stream. Outdoors the first windy afternoon, sunlight flickering through moving leaves lit up half the array, the event rate jumped by two orders of magnitude, and the host could not keep up. The sensor was working exactly as designed. The fix was a hardware event-rate limiter plus a refractory-period bias to cap per-pixel firing, trading some responsiveness for a bounded data rate. Budget for the worst-case scene rather than the demo scene.

The event-stream data model

The single most important thing to internalize is what the output actually is: a stream of points in a three-dimensional space (x, y, t), each carrying a polarity bit. It has no frame and no absolute intensity. Everything awkward and everything powerful about event cameras comes from that.

What an event is

Event:      e_k = (x_k, y_k, t_k, p_k)

  x_k, y_k  pixel address (e.g. 0..1279, 0..719 for an HD sensor)
  t_k       timestamp, microsecond resolution, monotonically increasing
  p_k       polarity, +1 (brightness up) or -1 (brightness down)

A recording is an ordered list:  E = { e_1, e_2, ..., e_N },  t_1 <= t_2 <= ...

There is no third spatial channel, no colour by default (most DVS are monochrome), and no absolute intensity. You know that pixel (x, y) got about C log-units brighter or darker at time t. To recover anything resembling a picture you must accumulate or integrate events over some window, and the choice of that window is now yours to make per-task, at any timescale you like, rather than fixed at capture.

Representations you build from the stream

Because most existing algorithms and networks want a grid, practitioners convert the stream into one of several intermediate representations. Each is a lossy projection of the (x, y, t) point cloud onto a 2D or 3D tensor, and the choice trades latency against compatibility with frame tooling.

• Event frame / histogram. Accumulate all events in a fixed time window (say 10 ms) or a fixed event count into a 2D image, counting or summing polarity per pixel. Simple, frame-tool compatible, throws away fine timing.
• Time surface (SAE). For each pixel store the timestamp of its most recent event, optionally with exponential decay. A time surface encodes the local direction and speed of motion in a single 2D map, which is why it underpins many event-based flow and corner methods (the HOTS/HATS line of work).
• Voxel grid. Discretize time into a few bins and accumulate events into a 3D (x, y, t-bin) tensor. Preserves more temporal structure than a single frame and feeds 3D or recurrent networks.
• Raw event-by-event. Feed each event directly into an incremental filter or a spiking neural network with no accumulation at all. This preserves the full microsecond latency and is the only representation that truly exploits the sensor, at the cost of needing algorithms built for it.

The clock trade you are now making

A frame camera fixes the temporal window at capture (the exposure and frame rate). An event camera defers that choice to processing time. You can integrate 1 ms of events for a low-latency control loop and 50 ms of the same recording for a denser map, from one stream. That flexibility is real power, and it is also the source of the tooling gap: there is no canonical window, so every pipeline invents its own, and results are hard to compare across papers.

Rule of thumb: if your representation collapses events into fixed frames before processing, you have spent the sensor's latency advantage to buy compatibility with frame tools. That can be the right call; just know you made it.

Sensor variants and a comparison

The commercial landscape narrows to a few architectures and two main vendors. The distinctions that matter are whether the sensor also gives you intensity frames, its resolution and pixel pitch, and how it manages the event rate.

Pure DVS. Events only. The original iniVation DVS128 (128x128) and the DVXplorer line (VGA, 640x480) are pure event sensors. Small, fast, low power, but you get no absolute-intensity image at all.

DAVIS (events plus frames). iniVation's DAVIS sensors put a conventional active-pixel-sensor (APS) readout and a DVS in the same pixel, so you get a normal grayscale frame stream and a synchronized event stream from one aligned array. The DAVIS346 (346x260) is the workhorse research sensor. This is uniquely convenient: the frames anchor absolute appearance and calibration while the events carry the fast changes, with no parallax between them.

ATIS. Prophesee's earlier asynchronous time-based image sensor pairs each change detector with an exposure-measurement circuit that reports absolute intensity only for pixels that changed, encoded as a time interval. Elegant, but a dark static region never updates its intensity.

Sony-Prophesee stacked HD. The current commercial frontier. Prophesee's Metavision sensors, co-developed and manufactured with Sony on a stacked back-illuminated process (the IMX636 is the well-known part), reach HD (1280x720) at roughly a 4.86 micron pixel pitch with on-chip event-rate control, anti-flicker, and noise filtering. This is what most new industrial and automotive designs build on.

Sensor / family	Vendor	Resolution	Frames too?	Notable trait
DVS128	iniVation	128x128	No	The original DVS; tiny, historic
DAVIS346	iniVation	346x260	Yes (APS)	Frames + events in the same pixel; research standard
DVXplorer	iniVation	640x480	No	VGA pure event, higher event throughput
Gen4 / IMX636 (Metavision HD)	Prophesee + Sony	1280x720	No	Stacked BSI, HD, on-chip filtering, industrial/automotive
ATIS	Prophesee	304x240 (QVGA)	Per-pixel intensity	Change + async exposure per pixel

A few practical notes on the table. Higher resolution is not free: an HD event sensor in a busy scene can emit hundreds of millions of events per second, so the on-chip event-rate control and filtering on the Sony-Prophesee parts are as important as the resolution. Colour event sensors exist but are rare; assume monochrome. And the DAVIS frame-plus-event capability, while lower resolution, remains the easiest on-ramp because you can fall back to familiar frame algorithms while you learn the event side.

The specs that matter and how to read a datasheet

Event-camera datasheets do not line up cleanly with frame-camera ones, so here is the practitioner's checklist of what actually decides whether a sensor fits, and the traps in each.

Resolution and pixel pitch. Spatial resolution (128x128 up to HD 1280x720) sets how finely you resolve moving structure. Pixel pitch matters more than on a frame sensor because a DVS pixel is circuit-heavy: early sensors had large pitches (18-40 microns) that limited resolution, and the Sony stacked process shrinking pitch to about 4.86 microns is what made HD event sensors practical.

Contrast sensitivity / threshold. The minimum log-contrast that triggers an event, often quoted as a percentage (10-25% typical, tunable via bias). Lower thresholds see fainter texture but fire more (more noise, more data). This is a tunable knob whose setting dominates behaviour.

Latency. Two figures hide here: the per-pixel latency (how fast a pixel reports a change, microseconds) and the readout latency under load (how long an event waits for the bus when many pixels fire at once). The first is the headline; the second is what actually limits you in busy scenes.

Dynamic range. 120 dB is common, up to ~140 dB. Confirm the illumination conditions and threshold at which it is measured, because the two interact.

Maximum event rate / bandwidth. The ceiling on events per second the sensor and interface can sustain, from tens of millions to over a billion events per second on HD parts. Compare it against your worst-case scene rather than a nominal one, because saturating it drops events silently.

Temporal resolution. The timestamp clock granularity, typically 1 microsecond. This is the resolution of the t field, distinct from latency.

Background activity / noise rate. How many spurious events per pixel per second the sensor emits with no scene change (dark noise), a function of temperature and bias. A high background rate wastes bandwidth and forces heavier filtering.

Power. Sensor power ranges from a few milliwatts in sparse scenes to hundreds of milliwatts under heavy activity. Quote it for your scene, because it is activity-dependent by design.

Rough worst-case bandwidth (HD sensor, heavy scene):
  event rate      ~ 300,000,000 events/s   (saturating a busy HD scene)
  bytes/event     ~ 8 bytes  (packed x, y, t, p; format-dependent)
  raw rate        ~ 2.4 GB/s  before any on-chip filtering

Same sensor, sparse indoor scene:
  event rate      ~ 100,000 events/s
  raw rate        ~ 0.8 MB/s

That four-orders-of-magnitude spread between sparse and saturated is the defining sizing problem of an event-camera system. Everything about your interface, buffers, and compute must survive the top of that range while the average sits near the bottom.

Rule of thumb: size the interface and compute for the worst-case event rate your scene can produce, and use the on-chip event-rate controller as a hard ceiling. Average-case sizing is how event pipelines fall over in the field.

Noise, calibration, and error sources

Event cameras have their own catalogue of artefacts, distinct from a frame camera's read noise and fixed-pattern noise, and knowing them is most of what separates a working pipeline from a frustrating one.

Background activity noise. Even with no scene change, thermal and junction-leakage effects make pixels fire spuriously, more at higher temperature and with more sensitive (lower-threshold) biases. These noise events are typically isolated in space and time, which is exactly how you filter them: a nearest-neighbour filter drops any event with no supporting event nearby in a short spatio-temporal window, because real edges produce spatially coherent bursts and noise does not.

Threshold mismatch and fixed-pattern effects. The ON and OFF thresholds are set by analog bias currents and vary pixel to pixel due to transistor mismatch, so the effective contrast threshold is not uniform across the array. Some pixels are "hot" (fire too easily) and need masking. This is the DVS analogue of fixed-pattern noise and is why per-pixel or per-sensor calibration of biases matters.

Refractory period and saturation. After firing, a pixel is briefly dead (the refractory period). Under very fast local change a pixel cannot report every crossing, and under global heavy activity the shared readout saturates and events queue or drop. Both distort the stream in ways that look like the scene slowed down.

Latency and timestamp jitter under load. The clean microsecond timestamp degrades when many pixels contend for the bus; events can be stamped at readout rather than at generation, introducing jitter precisely when the scene is busiest.

Geometric calibration. A DVS still has a lens, so it has the usual intrinsics and distortion. Calibrating them is harder because you cannot photograph a static checkerboard (a still target produces no events). The standard trick is to blink or move the pattern so its edges generate events, or, on a DAVIS, to calibrate using the built-in frames and reuse the intrinsics for the aligned event pixels.

No absolute reference. Because the sensor reports change, slow gradual illumination drift below the threshold produces nothing, and there is no ground-truth intensity to correct against. Any absolute-brightness task needs a companion frame sensor or a DAVIS.

War story: an eye-tracking prototype drifted in accuracy over a session and the team suspected the algorithm. The real cause was thermal: as the enclosure warmed, background activity climbed, a few pixels went hot, and the extra noise events biased the pupil centroid. A temperature-aware bias setting and a nearest-neighbour noise filter fixed it. On event cameras, check the noise floor and the sensor temperature before you debug the math.

The algorithm landscape

The asynchronous stream demands its own methods. Broadly, there are two camps: process events natively (event-by-event or in small groups, preserving latency) and convert to frames and reuse deep learning (giving up some latency for a mature toolbox). Most production systems mix them. Here are the core problems.

Event-based optical flow

Optical flow (the per-pixel motion field) is a natural fit because events are literally triggered by moving edges. The dominant approach fits a local plane to the surface of active events in (x, y, t): a moving edge sweeps a slanted plane through that space, and the plane's gradient gives the flow direction and speed (Benosman's local-plane-fitting line of work). Contrast-maximization methods instead search for the motion parameters that, when used to warp events, produce the sharpest accumulated edge image, on the principle that correct motion compensation makes moving edges align. Flow is available at microsecond timescales and never blurs, which is the appeal.

Feature detection and tracking

Corner and feature detectors adapted to events (event-based Harris, eFAST, and Arc*) run on time surfaces to find and follow features asynchronously, updating a track the moment a relevant event arrives rather than once per frame. Because there is no frame period, a tracked feature can be updated thousands of times per "frame-equivalent," which is what lets event trackers survive very fast motion that would smear a frame-based KLT tracker into failure.

Event-based visual-inertial odometry (VIO)

Fusing an event stream with an IMU gives a pose estimator that shines exactly where frame VIO struggles: high-speed motion and high dynamic range. Systems such as EVIO and Ultimate SLAM (Vidal et al., 2018) combine events, frames (on a DAVIS), and IMU, using events to hold tracking through fast rotation and low light where frames blur or underexpose. The IMU anchors metric scale and bridges the moments when the event stream alone is ambiguous, mirroring the role it plays in frame-based VIO covered in the robot perception and pose estimation guide.

Frame / intensity reconstruction

You can recover a grayscale video from events alone, because integrating polarity over time reconstructs relative log-intensity, and learned models do it well. E2VID (Rebecq et al., 2019) uses a recurrent network to turn an event stream into high-frame-rate, high-dynamic-range video, effectively synthesizing thousands of frames per second with no motion blur from a sensor that never captured a frame. This is powerful for visualization and for feeding legacy frame algorithms, though it reintroduces latency and can hallucinate detail, so it is a bridge rather than a free lunch.

Learning on events

Two families dominate. Spiking neural networks (SNNs) consume events natively as spikes and, on neuromorphic processors (Intel Loihi, SynSense), promise very low power and latency, though training them is still less mature than backprop on dense nets. The pragmatic mainstream converts events to voxel grids or event frames and runs standard CNNs or transformers, accepting the conversion cost to inherit the deep-learning ecosystem. The research frontier is closing the gap so that native, low-latency processing matches the accuracy of the frame-converted route. See the broader treatment in the machine vision guide.

Rule of thumb: choose your representation by your binding constraint. Latency-critical control loop, stay event-native or time-surface. Accuracy-critical perception with slack latency, convert to voxel grids and use a trained network. Do not force one representation to do both jobs.

Integration, bandwidth, and compute

Getting an event camera into a robot is mostly a data-and-timing problem. The sensor is easy; the stream is not.

Interfaces. Sensors ship over USB 3 (the common research path, iniVation and Prophesee eval kits) or MIPI CSI-2 for embedded integration into a compute module. The interface's sustained throughput must survive the worst-case event rate, and USB in particular can become the bottleneck under a saturating scene even when the sensor could produce more.

On-chip filtering is not optional on HD parts. The Sony-Prophesee sensors include hardware event-rate control, anti-flicker (to reject the 100/120 Hz flicker of mains lighting that would otherwise flood the stream), and spatio-temporal noise filtering. Enabling these at the sensor is far cheaper than filtering a billion events per second on the host.

Software stacks. Prophesee ships the Metavision SDK; iniVation ships DV and the dv-processing library; the open ecosystem centres on the event_camera_msgs and metavision/dvxplorer ROS 2 drivers, plus research datasets and tools around the AER/AEDAT and the newer standard formats. Tooling is real but thinner and less standardized than the frame world, which is a genuine cost you pay in engineering time. There is no single canonical event format the way there is for images, and pipelines still differ on the accumulation window, so expect to write glue.

Compute placement. You can process on a host CPU/GPU (easiest, but the USB link and host scheduling add latency), on an embedded GPU or FPGA close to the sensor (better latency, more work), or on a neuromorphic processor for SNN workloads (lowest power, most specialized). The right answer follows your latency and power budget. See the robot perception and pose estimation guide for where this sits in a perception stack.

Time synchronization. As with any multi-sensor rig, the event timestamps must share a clock with the IMU and any frame camera, or fusion degrades in ways that look like sensor noise. The microsecond event clock makes precise sync both more valuable and less forgiving: a millisecond of clock skew that a frame system tolerates can dominate an event-VIO error budget.

Rule of thumb: budget more engineering time for the data path (interface throughput, on-chip filtering config, timestamps, and the immature tooling) than for choosing the sensor. The hardware is the easy part.

Applications

Event cameras earn their place wherever speed, dynamic range, or power dominate, and struggle where absolute appearance or mature tooling matter more. The concrete wins in 2026:

High-speed drones and agile robots. Microsecond latency and no motion blur make event cameras compelling for aggressive flight, dynamic obstacle avoidance (dodging a thrown object), and catching or juggling. Research platforms use event-based flow and VIO to close control loops far faster than a frame camera allows, which is why the drone/UAV hardware guide treats them as an emerging perception option for fast platforms.

Automotive and ADAS. The high dynamic range handles tunnel exits, oncoming headlights, and deep shadow that blind frame cameras, and the low latency helps with fast cross-traffic and near-field detection. The Sony-Prophesee HD sensors were built with this market in mind, typically as a complement to frame cameras and radar rather than a replacement. See the self-driving cars guide.

Industrial monitoring and inspection. Vibration analysis, high-speed counting, spark and particle detection, and monitoring fast rotating machinery all exploit the blur-free high-temporal-resolution stream. Because a static line produces little data, an event camera watching for a fast fault is efficient and always-on.

Eye tracking and AR/VR. Fast, sparse, low-power gaze tracking is a strong fit: the eye moves in quick saccades an event sensor catches at microsecond resolution while sipping power, which suits battery-limited headsets.

Scientific and space imaging. High-speed phenomena (fluid dynamics, combustion, particle tracking) and the low-data, high-dynamic-range profile that suits space and other bandwidth-limited platforms.

Always-on low-power sensing. Presence and motion triggers that sleep at microwatts until something moves, waking heavier sensors only when needed.

Where event cameras do not fit: static-scene inspection needing absolute intensity or colour (read a label, grade a surface), tasks needing a conventional dense image out of the box, and projects without the engineering budget to build event-native perception. For those, the frame camera in the machine vision guide remains the right tool, and a DAVIS-style frames-plus-events sensor is the sensible hedge when you are unsure.

Selecting an event camera

Work through these in order; each narrows the field before the next.

1. Is your problem actually speed, dynamic range, or power? If none of those bind, and you need absolute appearance or static-scene detail, an event camera is the wrong tool. Be honest here; this eliminates most misfits.
2. Do you need intensity frames too? If you want a fallback to conventional algorithms or absolute appearance alongside events, a DAVIS (frames plus events, same pixel) is the safe choice despite its lower resolution. Pure DVS only when you are committed to event-native processing.
3. Resolution. Match spatial resolution to the smallest moving feature at your range. Research and prototyping often start at VGA (DVXplorer) or the DAVIS346; industrial and automotive designs use the HD Sony-Prophesee parts.
4. Event-rate ceiling and interface. Estimate your worst-case scene's event rate and confirm the sensor's max rate, on-chip filtering, and interface throughput can survive it. This is where naive selections fail.
5. Ecosystem and support. Prophesee's Metavision SDK and iniVation's DV are the two mature stacks. Pick the one your algorithms and ROS 2 integration are best supported on, because tooling maturity is worth more here than a spec-sheet edge.
6. Neuromorphic compute? Only if you are committed to SNNs and a Loihi-class processor for extreme power/latency. For most robots, a conventional CPU/GPU/FPGA host is the pragmatic path.

Representative 2026 hardware, always confirm against the current datasheet:

Product	Vendor	Resolution	Frames?	Best for
DAVIS346	iniVation	346x260	Yes	Research, event+frame VIO, easiest on-ramp
DVXplorer	iniVation	640x480	No	Higher-throughput pure-event prototyping
EVK4 (IMX636 / Metavision HD)	Prophesee + Sony	1280x720	No	Industrial, automotive, HD event vision
Metavision embedded modules	Prophesee	up to HD	No	Embedded MIPI integration into a product

Rule of thumb: for a first event-camera project, start with a DAVIS or a Prophesee eval kit and the vendor SDK, prototype your worst-case scene early to measure the real event rate, and only then commit to an embedded sensor and a compute target. The event rate you measure will surprise you.

Frequently asked questions

Is an event camera just a very fast frame camera? No. A frame camera reports absolute brightness for every pixel on a clock; an event camera reports only per-pixel changes in log-brightness, asynchronously, with no frame. It is blind to a static scene and produces no image without post-processing. The two measure fundamentally different quantities, which is why event data needs its own algorithms.

Why does my event camera output nothing when the scene is still? That is correct behaviour. A DVS pixel fires only on brightness change, so a perfectly static scene with a static camera produces almost no events (just noise). To get data off a static scene you must introduce motion (move the camera, or the object) or accept that the sensor is telling you nothing changed.

Can I get a normal image out of an event camera? Only indirectly. You can reconstruct grayscale video from events with learned models like E2VID, or use a DAVIS/ATIS sensor that also outputs intensity. Pure DVS sensors give you no absolute-intensity image; if you need one, choose a frames-plus-events sensor or add a separate frame camera.

What is the contrast threshold and why does it matter so much? It is the log-brightness change C a pixel must see before it fires, set by analog bias currents and often expressed as a percentage (10-25%). Lower it and the sensor sees fainter texture but fires far more (more noise, more data, more power); raise it and the stream is cleaner but misses low-contrast edges. It is the single most influential tuning knob on the sensor.

How do event cameras achieve 120+ dB of dynamic range? Each pixel works in the logarithmic domain and adapts to its own local light level, so it responds to relative (contrast) change rather than absolute intensity. That removes the single-global-exposure ceiling of a frame sensor and lets one pixel in shadow and another in sun both report edges at once, spanning an intensity range no single exposure could hold.

Do event cameras see colour? Almost all commercial event sensors are monochrome. Colour event sensors exist in research and a few niche parts, but assume monochrome unless a datasheet says otherwise. If colour appearance matters, pair the event camera with a frame camera or pick a different sensor.

How much data does an event camera produce? It depends entirely on scene activity. A sparse indoor scene might be under a megabyte per second; a busy HD scene can hit hundreds of millions of events per second and gigabytes per second before filtering. Size your interface, buffers, and compute for the worst case, and use on-chip event-rate control as a hard ceiling.

What algorithms do I run on the events? Either process natively (event-by-event filters, time surfaces, plane-fitting flow, spiking networks) to keep microsecond latency, or accumulate events into event frames or voxel grids and run standard CNNs and VIO, trading some latency for mature tooling. Most systems mix both. Match the representation to whether latency or accuracy binds.

Who makes event cameras I can actually buy? Two vendors dominate: Prophesee (with Sony, the Metavision line, HD IMX636-based sensors and eval kits) and iniVation (the DAVIS frames-plus-events sensors and the DVXplorer pure-event line). Both ship SDKs and ROS 2 support. Neuromorphic compute for events comes from Intel (Loihi) and startups like SynSense.

When should I not use an event camera? When your task needs absolute brightness or colour appearance, a conventional dense image out of the box, static-scene detail (reading a label, grading a surface), or when you lack the engineering budget to build event-native perception. For those, a frame camera from the machine vision guide is the right choice, and a DAVIS is the sensible hedge when unsure.