# openeb's upgrade path starts with sudo and a global file check

> This is the open-source half of a camera vendor's machine-vision stack, published so that researchers can experiment with event-based cameras and manufacturers can build their own plugins. The module design is a clean bottom-up ladder from a hardware abstraction layer to a viewer, and the machine-learning module includes bridges from events to ordinary video and back. What is worth knowing before you build on it is that the software installs into system directories, that an upgrade begins by uninstalling as root and then checking your library path by hand, and that the readme never states the licence.

**prophesee-ai/openeb** — Open source SDK to create applications leveraging event-based vision hardware equipment

- Repository: https://github.com/prophesee-ai/openeb
- Website: https://www.prophesee.ai/metavision-intelligence/
- Stars: 305 · Forks: 93
- Language: C++
- License: not declared
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/prophesee-ai-openeb

## Six modules stacked from the hardware up

The module list is the clearest statement of the design and it is a strict ladder. At the bottom is a hardware abstraction layer whose stated job is to operate any event-based vision device, which is the only part that knows about USB and cameras. Above it, a base module of foundations and common definitions, then a core module of generic algorithms for visualisation and event-stream manipulation. Then the module that matters most if you are doing machine learning: a core ML module carrying general learning functions plus explicit pipelines in both directions between events and ordinary video. Then a stream module, described as a high-level abstraction built on top of the hardware layer, which is the one place the list skips a rung in its own wording. Finally a UI module of viewers and display controllers. Separately, the repository ships the vendor's own camera plugins, which is what makes the abstraction layer useful to a competing manufacturer rather than merely tidy.

## The documented starting point is a tag, and the source archive needs choosing

Two instructions here will save you an afternoon. The first is that the clone command in the readme pins a release rather than the default branch, which is unusual for a project's own getting-started section and tells you the maintainers consider tags the stable artefact.

```bash
git clone https://github.com/prophesee-ai/openeb.git --branch 5.2.0
```

The second is a warning about GitHub's own download. If you fetch an archive instead of cloning, you are told to pick a full-source-code archive and explicitly not to use the automatically generated source archive, because it does not include a required submodule. The repository does carry a submodules file, so that is not a surprise, but the failure mode is: the automatic archive looks correct, unpacks correctly, and fails later at configure time. Either clone, or use the archive the maintainers assembled. Either way the readme asks you to treat the resulting directory as a named variable in the commands that follow, which is a small courtesy that also means every path in the guide is easy to check.

## The upgrade starts with an elevated uninstall and a manual audit

This is the section that tells you what kind of software this is. Before installing a new version you are told to remove any previously installed vendor software, and the removal is an elevated make target run from the build directory. Then comes a global check, and it is spelled out as four system directories and three environment variables: the library and include paths under the system root, and the executable path, the Python path and the dynamic linker path. The reason for that last one is structural. The build produces native libraries that are found through the linker search path rather than through a package manager, which is exactly what you would expect from a stack that installs itself with elevated privileges into system directories. The same paragraph also warns that some changes affect cameras and not just code: a firmware update might be necessary. So an upgrade here is a system operation with three possible moving parts, the code, the installed files, and the camera itself, and the readme tells you to read the release notes before starting.

## Two distributions, one architecture, and a graphics floor

The build requirements are stated as a tested matrix rather than a supported one, and the wording is careful. Compilation and execution were tested on one distribution family at two long-term-support releases, 64-bit, on one processor architecture, with a graphics card supporting at least version three of OpenGL. Everything else is explicitly not tested: alternative distributions, different versions of the same distribution, and other processor architectures, with the note that adjustments to the guide or to the code itself may be required. Read that as a containerisation problem rather than a compatibility promise. There is no ARM build, so a developer on an Apple-silicon machine or an ARM server is reading an untested path from the start, and the OpenGL floor means a build machine needs a real or virtualised graphics stack even for headless work. The test side is lighter: two optional packages for a C++ test framework, with a Python test configuration already at the repository root.

## The Python environment must see system packages, and that has a documented cost

The Python instructions contain the most subtle paragraph in the readme, and it is about a compromise rather than a feature. The virtual environment must be created with the option that exposes system site packages, and the reason given is that the SDK packages installed into system directories have to remain importable. The cost is stated immediately: that option also makes the local per-user site-packages directory visible, which quietly defeats the isolation you created the environment for. The documented mitigation is to set an environment variable that disables user site lookups, which is the correct fix and is the kind of thing most guides leave out. Two requirement files are then installed, one for the SDK and one for the CPU build of the learning framework, with a note to swap the second for its accelerator counterpart. The supported interpreter matrix is tied to the distribution release rather than floating, which is honest and also means a Python upgrade means changing your base image.

## The Python bindings are one pinned version and are optional

The bindings between the C++ interface and Python are built with pybind11 at a version stated exactly rather than as a range, and that pin is the sort of thing that usually signals a workaround for a specific compiler or platform issue. Then the useful part: the bindings are only needed if you want them, and you can switch them off at configure time with a single build argument, in which case the binding layer is not created and pybind11 is not a dependency of your build. For a project whose primary language is C++ but whose tutorials exist in both languages, that is the right default: a C++ user should not have to satisfy a Python binding toolchain to read a recording. The readme also points at online tutorials, samples and a module description, none of which are in this repository, so the repository you clone is the library and not the documentation.

## The dependency list tells you what the stack actually does

Read the three package-install lines as a specification rather than a shopping list, because they describe the whole system. An image library for frame processing. A general-purpose C++ library set. The USB development headers, which is how the cameras are reached. Protocol Buffers plus its compiler, which is how records and messages are structured. An HDF5 development package and its tools, which is the recording format. Two OpenGL-related packages, the extension loader and the windowing library, which is the viewer. A desktop audio module, which is how the device makes a sound. And a video encoder. Add the build tools, a package-manager front end, a downloader, an archiver, a version-control client and the build system itself. So this is a USB camera stack that records into a columnar binary format, renders through OpenGL, and pipes video out through ffmpeg, and the dependency list is consistent with exactly that.

## The licence is the one thing the readme does not state

Everything else in this repository is documented with unusual care: which platform combinations were tested and which were not, what the archive naming means, which environment variables to check after an uninstall, why a virtual environment flag is needed and what that flag costs. The licence is not. The repository metadata reports no licence it can identify, and there is a directory in the tree whose name is licensing, so the terms plainly exist somewhere. The readme never mentions them. For a library whose stated purpose includes letting camera manufacturers build their own plugins against its abstraction layer, that omission is the first thing to resolve, because the answer determines whether you can ship a product built on it, whether you can only use it internally, and whether your plugin has to be published. It also determines how you should read the plugin source that ships here for the vendor's own two cameras, which is the one part of this repository you will run on hardware you did not write.

## Conclusion

This project fits a researcher who owns one of the two supported evaluation cameras and wants to read, record and analyse event streams in C++ or Python, and a manufacturer who needs to expose their own hardware through the vendor's abstraction layer. It does not fit anyone who needs a portable install, because the supported build platforms are two long-term-support releases of one distribution on one architecture with a graphics floor, and the software installs into system directories. Before you start, resolve the licensing question yourself, since the repository reports no licence and the readme does not state terms, and decide whether an upgrade that requires elevated removal and a manual library-path audit is acceptable in your environment. If you only need the Python API, note that the bindings are optional at configure time.

## FAQ

### What is OpenEB?

It is the open source project associated with a commercial machine-vision SDK for event-based cameras. It is built from six modules, from a hardware abstraction layer through core algorithms and machine-learning functions to a viewer, and it includes the vendor's own camera plugins for streaming live data and reading recordings.

### Which cameras does OpenEB support?

Two evaluation camera models from the vendor, one offered at VGA, 320 and HD resolutions and the other at HD. The repository ships the source of the plugins for both, which is also the reference for anyone writing a plugin for their own hardware.

### What platforms can OpenEB be compiled on?

Compilation and execution were tested on 64-bit versions of one Linux distribution at two long-term-support releases, on the amd64 architecture, with a graphics card supporting at least OpenGL 3.0. The readme states explicitly that other distributions, other versions and other architectures such as ARM were not tested and may need adjustments to the guide or the code.

### How do I upgrade OpenEB without breaking an existing install?

Review the release notes first, because some changes affect the API and some may require a camera firmware update. Then remove the previously installed files with the elevated uninstall target run from the build directory, and check the system library and include directories plus the executable, Python and dynamic linker path environment variables for leftovers.

### Do I need the Python bindings to use OpenEB?

No. The bindings are built with pybind11 at a pinned version and are only needed if you want the Python interface, and you can skip creating them entirely with a build argument at configure time. The Python environment does need to expose system site packages so the installed SDK stays importable, with a documented mitigation for the user site directory that option also exposes.

## Sources

- [Issues](https://github.com/prophesee-ai/openeb/issues)
- [Project website](https://www.prophesee.ai/metavision-intelligence/)
- [prophesee-ai/openeb on GitHub](https://github.com/prophesee-ai/openeb)
- [README](https://github.com/prophesee-ai/openeb/blob/main/README.md)
- [Releases](https://github.com/prophesee-ai/openeb/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/prophesee-ai-openeb