As with traditional vision systems, lighting is essential in event-based vision systems. Our technology relies on light changes at the pixel level for event generation. The more contrast, the more relevant objects will produce events. Therefore, contrast optimization is a must. For this, additional lighting can be used.

At this point, it is important to note that positive events tend to have shorter latency than negative ones. In practice, when an edge would reach a pixel, it would produce relatively few positive events, quite close timewise, while negative events would tend to be produce more events and more spread in time after the edge arrival. Therefore, positive event generation might be preferred when designing a product (this can be managed with material color, backlighting, etc.).

Also, the reflectance of the target object matters, as well as the background behind it. If the object has low reflectance, let’s say a black coin, it will be much more visible in front of a white background than a grey one. Textured backgrounds will also impact event generation (edges or textured objects will produce artefacts in the event stream). In the example below (see Background importance), the impact of a scene background (Prophesee offices with windows) is visible in the second image. Texture impact is highlighted on the sweater image, with a clear impact on the edges of the hand.

Finally, event-based applications are subject to noise similarly to classical frame-based sensors. Event-sensors will be less prone to produce noise in a high light scene. If your system is not constrained by ambient lighting, probably an additional (not flickering) lighting might improve your event data. Backlights can also be used in some cases (a light placed behind the object), by opposition to classical lighting next to the camera, or close to it.

As you can see above, a simple texure or non-uniform background will impact event generation, and might degrade your algorithms performance. It is very important to be aware of this and control the background scene.

In conclusion, for optimum results use a uniform background that contrasts with the object whenever possible. For instance a black piece passing in front of a white background, supplemented with additional lighting to boost contrast detection.

In the previous section, we detailed how to use additional lighting and the scene background to get an improved contrast. Light can also be filtered to select the relevant information.

A first example is spectrum selection. In the case of active markers for instance, Infra-Red (IR) LEDs can be used in addition to an IR filter before the sensor (either before or after the lens) to retrieve only events corresponding to variations in the IR spectrum.

Another example is light polarization. One might use an active light system producing polarized light and retrieving only events coming from this polarized light instead of the totality of events produced by the scene changes.

All-in-all, light filtering allows both to limit the information entering the sensor, and to select light sources dedicated to your use-case.

Even though Prophesee sensors allow pixelwise triggering, events are extracted line by line by the sensor readout process. The readout process produces vectors of events on the same line. If the edges are along this line, few vectors will be produced, and their filling rate will be high, but most importantly the readout line change is low. On the other hand, if the movement is along the columns of the sensor, then the readout will produce a lot of almost empty vectors, which might cause backpressure on the sensor to provide this quantity of vectors containing in fact very limited information, plus increased sensor consumption. On top of that, the readout line switch is quite time expensive in that case.

With the EVT3.0 event format, a compression operation is done to group event vectors on a same line in small data packets. This compression allows an efficient transfer from the sensor to the processing unit. In the case where few events occured on the same line (second part of the figure), the readout is highly used and might increase latency and data drop in worst cases (data buffer saturation).

In other words, sensor orientation is essential in case of main linear movements in the scene. In that case, the sensor should be placed so that edges are mostly along sensor rows.

For instance, here is a figure illustrating the evolution of sensor consumption along with the event rate for various patterns displayed in front of the sensor. It is very readable that a line pattern (event lines falling down in front of the sensor) cause much lower power consumption than columns moving to the right (for instance). The increased power consumption comes from increased readout consumption for vector generation.

Basically, the more events generated, the more efficient the vectorization, and therefore the more power efficient data transmission will be.

Static scene is the case where event-based cameras are naturally relevant, as they natively filter out static objects, leaving only moving or changing objects to be seen. However, in a lot of use-cases, the camera is moving. In that case, lots of events are produced by the movement, in addition to the moving elements in the scene. This implies a drastically increased event-rate, which might need to be controlled (by the ERC for instance). Bias tuning might help adjust the noise and sensitivity level to produce the best event stream to process. Vibrations will also impact event generation. If possible, place the camera or sensor on a non-vibrating surface. On the other hand, vibrations might help observe static objects by highlighting their edges.