What does this equation mean?

Commercial event sensors have reached production stacked-silicon form. The Sony-Prophesee IMX636 reports pixel latency under 100 microseconds at 1,000 lux, standby power of 5 milliwatts against a maximum of 205 milliwatts, and a peak event rate above one billion events per second across its 1,280-by-720 array [ 13 ] . Because a pixel only ever transmits when it individually crosses its change threshold, the sensor’s data rate scales with how much of the scene is actually changing, not with the pixel count or a fixed frame clock — the opposite dependency from a frame sensor’s fixed-rate readout: $R_{\mathrm{frame}} = N_{\mathrm{pixels}} \cdot f_{\mathrm{frame}} \cdot b, \qquad R_{\mathrm{event}}(t) \approx N_{\mathrm{active}}(t) \cdot b_{\mathrm{event}}$. where $N_{\mathrm{active}}(t)$ , the number of pixels crossing threshold at a given instant, is normally far smaller than the total pixel count $N_{\mathrm{pixels}}$ for a mostly-static scene. That scene-dependence is also the sensor’s clearest limitation rather than a free efficiency gain: because each pixel’s operating principle is defined by Gallego and colleagues as asynchronously measuring per-pixel brightness change and encoding “the time, location and sign” of that change [ 3 ] , a highly textured, fast-moving, or vibrating scene drives $N_{\mathrm{active}}(t)$ toward $N_{\mathrm{pixels}}$ , and the bandwidth and power advantage over a frame sensor narrows or disappears for exactly the scenes where an application often needs the most from its sensor. The advantage is real and large for a mostly-static scene with occasional motion; it is not a property of the device independent of what it is pointed at.