{{ message }}
Event camera simulation#3202
Merged
Merged
Conversation
zimmy87
suggested changes
Dec 15, 2020
zimmy87
left a comment
Contributor
There was a problem hiding this comment.
Most comments are style/debugging-related. Currently blocked from testing due to the last comment though.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

This PR introduces a simple event camera simulation in Python, using numba for performance.
The event simulator uses two consecutive RGB images (converted to grayscale), and computes "events" based on the change in log luminance between the images. These events are reported as a stream of bytes, following this format:
<x> <y> <timestamp> <pol>x and y are the pixel locations of the event firing, timestamp is the global timestamp in microseconds and pol is either +1/-1 depending on whether the brightness increased or decreased. Along with this bytestream, an accumulation of events over a 2D frame is also constructed, known as an 'event image' that visualizes +1 events as red and -1 as blue pixels.
There are quite a few parameters that can be tuned to achieve a level of visual fidelity/performance. The main factors would be the resolution of the camera and the log luminance threshold (TOL) that determines whether or not a detected change counts as an event. There is also currently a max limit on the number of events generated per pair of images, which can also be tuned.