{"id":4748,"date":"2025-07-30T12:15:39","date_gmt":"2025-07-30T16:15:39","guid":{"rendered":"https:\/\/www.1stvision.com\/machine-vision-solutions\/?p=4748"},"modified":"2025-09-04T15:42:11","modified_gmt":"2025-09-04T19:42:11","slug":"whitepaper-event-based-sensing-paradigm","status":"publish","type":"post","link":"https:\/\/www.1stvision.com\/machine-vision-solutions\/2025\/07\/whitepaper-event-based-sensing-paradigm.html","title":{"rendered":"Whitepaper: Event-based sensing paradigm"},"content":{"rendered":"\n

Except for sometimes compelling line-scan imaging, machine vision has been dominated by frame-based approaches. (Compare Area-scan vs. Line-scan<\/a>). With an area-scan camera, the entire two-dimensional sensor array of x pixels by y pixels is read out and transmitted over the digital interface<\/a> to the PC host. Whether USB3, GigE, CoaXPress, CameraLink, or any other interface, that’s a lot of image data to transport.<\/p>\n\n\n

\n
\"Download<\/a>
Event-based sensing as alternative to frame-based approach<\/figcaption><\/figure>\n<\/div>\n\n\n

If your application is about motion, why transmit the static pixels?<\/h2>\n\n\n\n

The question above is intentionally provocative, of course. One might ask, “do I have a choice?” With conventional sensors, one really doesn’t, as their pixels just convert light to electrons according to the physics of CMOS, and readout circuits move the array of charges on down the interface to the host PC, for algorithmic interpretation. There’s nothing wrong with that! Thousands of effective machine vision applications use precisely that frame-based paradigm. Or the line-scan approach, arguably a close cousin of the area-scan model.<\/p>\n\n\n\n

\"\"<\/figure>
\n

Consider the four-frame sequence to the left, relative to a candidate golf-swing analysis application. Per the legend, with post-processing markup the blue-tinged golfer, club, and ball are undersampled in the sense that there are unshown phases of the swing. <\/p>\n\n\n\n

Meanwhile the non-moving tree, grass, and sky are needlessly re-sampled in each frame.<\/p>\n\n\n\n

It takes an expensive high-frame-rate sensor and interface to significantly increase the sample rate. Plus storage capacity for each frame. And\/or processing capacity – for automated applications – to separate the motion segments from the static segments.<\/p>\n\n\n\n

With event-based sensing, introduced below, one can achieve the equivalent of 10k fps – by just transmitting the pixels whose values change.<\/p>\n\n\n\n

Images courtesy Prophesee Metavision.<\/p>\n<\/div><\/div>\n\n\n\n

Event-based sensing only<\/strong> transmits the pixels that changed<\/h2>\n\n\n\n

Unlike photography for social media or commercial advertising, where real-looking images are usually the goal, for machine vision it’s all about effective (automated) applications. In motion-oriented applications, we’re just trying to automatically control the robot arm, drive the car, monitor the secure perimeter, track the intruder(s), monitor the vibration, …<\/p>\n\n\n\n

We’re NOT worried about color rendering, pretty images, or the static portions in the field of view (FOV). With event-based sensing, “high temporal imaging” is possible, since one need only pay attention to the pixels whose values change.<\/p>\n\n\n\n

Consider the short video below. The left side shows a succession of frame-based images for a machine driven by an electric motor and belt. But the left hand image sequence is not a helpful basis for monitoring vibration with an eye to scheduling (or skipping) maintenance, or anticipating breakdowns.<\/p>\n\n\n\n

The right-hand sequence was obtained with an event-based vision sensor (EVS), and absolutely reveals components with both “medium” and “significant” vibration. Here those thresholds have triggered color-mapped pseudo-images, to aid comprehension. But an automated application could map the coordinates to take action, such as gracefully shutting down the machine, scheduling maintenance according to calculated risk, etc.<\/p>\n\n\n\n

\n