Event camera bias values are not contrast thresholds

An event camera's tuning panel shows register values like bias_diff_on = 102 and bias_diff_off = 73, and the tempting reading is that a pixel fires only on a 102% brightness change. That reading is wrong, and it breaks every calculation built on it: on that logic, a pixel sitting above roughly half of full scale could never fire an ON event. The numbers are unitless DAC codes written to the sensor; the real quantity is a contrast threshold on the change in log intensity, close to 25% Weber contrast at default settings. You will leave with the formula the sensor actually applies, a worked example you can check, a calibration that measures your own threshold, and a decision rule for when an event camera is worth the effort at all.

What the bias register values actually set

An event camera pixel does not wait for a frame. Each pixel carries a circuit that tracks the logarithm of the light reaching it, and two comparators — ON and OFF — watch that signal for change. When the log signal moves by more than a comparator's threshold, the pixel emits one event carrying polarity, coordinates and a microsecond timestamp, then stays silent for a refractory period before it can fire again.

The thresholds are set by currents, and the currents are set by bias DACs. bias_diff_on positions the ON comparator and bias_diff_off the OFF one; bias_hpf sets the bandwidth of the change filter feeding them. The codes are plain integers on an arbitrary scale. Published pixel characterizations agree on each dial's direction: raising bias_diff_on raises the ON contrast threshold, raising bias_diff_off raises the OFF threshold, and the effective thresholds also move with bias_hpf, because bandwidth and threshold trade against each other inside one circuit.

Defaults can still look odd. Some sensors store their default biases as zero offsets from a base configuration while the panel displays the absolute codes those offsets resolve to, so a fresh unit shows non-zero numbers where you expected zeros. Both displays describe one configuration; neither is a percentage, and nothing in the register interface hands you one.

SDKs expose biases as typed parameters beside other register data — the same structured pattern that carries a camera temperature readout. What you read back is the code, never its physical meaning.

The threshold the sensor compares, in units you can use

The quantity under comparison is a change in log intensity, and two unit systems describe it: Weber contrast as a fraction of the starting intensity, and log units, which is what the circuit actually measures.

A datasheet contrast threshold (CT) near 25% therefore means θ_on ≈ ln(1.25) = 0.223. The scale runs: a 10% threshold is ln(1.10) = 0.095, a 30% threshold is ln(1.30) = 0.262, a 50% threshold is ln(1.50) = 0.405. In decades, 25% is log10(1.25) = 0.097, the unit some vendors print directly.

Because the comparison is a ratio, absolute brightness cancels. A pixel at any light level fires on the same relative step, so the fear that bright pixels can never produce ON events is an artifact of reading the register code as a percent of full scale — something the hardware never does. Defaults are chosen to land on the printed CT, so the datasheet figure and the shipped default describe the same operating point.

ΔI itself is made upstream of the sensor: lighting geometry — the camera, light and part positions — sets the contrast the pixel sees, and stray light quietly eats it. Both are tunable long before any bias is touched.

Worked example: does this brightness change fire an event?

Take a default-tuned pixel, θ_on ≈ 0.223, and a part that brightens when a light step is applied. Measure the two levels the way you would for any intensity measurement; suppose the meter reads I1 = 200 and I2 = 260 in its own counts.

• Weber contrast: C = (260 - 200) / 200 = 60 / 200 = 0.30, that is 30%.
• Log change: θ = ln(260 / 200) = ln(1.30) = 0.262.
• Decision: 0.262 ≥ 0.223, so the ON event fires.

Repeat with the weaker step I2 = 240: C = (240 - 200) / 200 = 0.20 (20%), θ = ln(1.20) = 0.182, and 0.182 < 0.223, so no event. The arithmetic answers what the panel cannot: a 20% step is invisible to a default-tuned pixel, a 30% step fires. Run it in reverse and it becomes a measurement — if your 20% steps fire reliably, the effective threshold is already below 20%, whatever the code says.

How to measure your own contrast threshold

You do not need the vendor's mapping table. Keep illumination and geometry fixed, and present intensity steps of known size — 5%, 10%, 15%, 20%, 25%, 30% of the base level — by swapping a reflectance target or stepping a light controller's output. For each bias_diff_on setting, record the smallest step that reliably fires ON events; that step, in Weber contrast, is the effective threshold. Sample three or four codes and the code-to-contrast curve for your unit is mapped. The mapping is monotonic, so a few points interpolate the rest.

Three rules keep the sweep honest:

• Hold bias_hpf and the refractory-period bias fixed; both move the effective threshold as they change.
• Repeat each step. Pixel-to-pixel spread makes a single firing pixel ambiguous, so count events across the part and require the same decision on several repeats.
• Read the noise floor from the same recording: events per pixel per second on the static scene between steps. If it climbs while you lower the code, you are trading threshold for noise.

Background activity rate: datasheet ceiling versus measured sample

Background activity rate (BGR) is an event sensor's noise floor: events per pixel per second on a static scene, with no motion and no light change. Two published numbers for the same sensor can look irreconcilable until each claim is read for what it is.

The datasheet quotes a maximum: the worst rate the manufacturer commits to across all supported bias configurations. One sensor's datasheet allows at most 0.1 Hz per pixel at 1000 lx, rising to 10 Hz at 5 lx. An application note reports the rate measured on samples for one specific bias configuration; for that sensor it is 0.00005 Hz per pixel at 1000 lx, two thousand times under the ceiling. Both numbers are true — one is a guarantee, the other a sample. Datasheet conditions are stated in lux, and how lux relates to radiometric watts is its own unit comparison. Size event storage and your lowest usable threshold against the measured value; treat the ceiling as the worst case your tuning must survive.

When an event camera earns the tuning effort

Event sensing pays for itself in three regimes. Fast motion: a pixel reacts to a change within tens to hundreds of microseconds, against frame intervals of milliseconds. Dynamic range: the logarithmic response is commonly specified above 100 dB, while a 10-bit machine-vision sensor tops out near 20 × log10(1024) ≈ 60 dB, because the bit depth of the readout sets that bound. Sparse data: only changed pixels leave the chip, so a mostly static scene costs almost nothing to watch continuously. Moving-line inspection, latency-critical robot guidance and always-on monitoring are the fits.

If the scene is static between checks, or motion is slow enough that a frame every few milliseconds is plenty, the event sensor adds a bias panel and a calibration loop for data you would not have used.

When a frame camera is the simpler answer

For slow or staged inspection, a frame camera and lighting make the same threshold decision with arithmetic you already trust: exposure, gain and a fixed contrast rule. Motion you would otherwise chase with events still lands as sharp frames on the MV-CH120-11UC, a global-shutter sensor in 1.1-inch format behind a C-mount on USB3 and the high-speed version in its series.

Slower lines need less still. The LS-CMR-0166 reads 4000 × 3000 pixels at 30 fps over USB3.

At 30 fps the frame interval is 1 / 30 s = 33.3 ms, so a part traveling 300 mm/s moves 300 × 0.0333 = 10 mm between frames — fine for a pass/fail decision on a staged part, useless for tracking it. An event pixel watching the same line reports the change within tens of microseconds; over 20 µs the part moves 300 × 0.00002 = 0.006 mm. That gap of three orders of magnitude is the whole argument for event data. If your cycle does not need it, skip the bias tuning entirely. Readout and binning, not exposure alone, set the frame interval you actually get — sensor readout and binning versus frame rate covers that side.

If the question arrived as weak edges on a robot camera, that is frame-side contrast work, and the edge contrast troubleshooting steps for robot-integrated cameras walk that workflow.

Both camera families sit in the area scan cameras catalog. The camera finder filters by shutter, interface and resolution, and the camera configurator sizes lens and lighting around the part.

The decision, case by case

• The panel shows 102 and you need a number for an acceptance formula: the code carries no percent. Use the measured threshold, near 25% Weber contrast at defaults, and compute firing with θ = ln(1 + C).
• Faint edges miss events: lower bias_diff_on in calibrated steps, and stop when the background rate at your illuminance approaches the datasheet ceiling or your noise budget.
• Bright or dark pixels seem unable to fire: the comparison is a ratio, so absolute level never blocks an event. Suspect the formula, then the lighting — not the sensor.
• Two cameras disagree at identical codes: expected. Calibrate each unit; the code-to-contrast map is chip-specific.
• Motion is slow or staged: stay frame-based. Where the real requirement is depth rather than events, the 3D sensors category is the closer starting point.

Frame-based or event-based, the decision reduces to one measured quantity: the smallest intensity change your process must see, in Weber contrast, and the false-event rate you can afford. Size both from a recording rather than the register panel. If a live line needs a second opinion, talk it through with us, and the cameras topic page collects the sensor-side explainers that pair with this one.