qourex/opencv5sharp
LibraryLive in productionHigh-performance, cross-platform .NET wrapper for OpenCV 5 with CUDA and cuDNN GPU acceleration.
High-performance, cross-platform .NET wrapper for OpenCV 5 with CUDA and cuDNN GPU acceleration. Supports modern C# (IDisposable-safe) on Windows, Linux, macOS, Android, and iOS.
qourex.github.io/opencv5sharp/
- C++80.4%
- C#6.0%
- Python5.0%
- C3.0%
- Java2.1%
- CMake2.0%
- Objective-C++0.7%
- HTML0.7%
1 Review
OpenCV5Sharp is a substantial binding project with a clear three-layer design: generated C# wrappers, a flat native C++ bridge, and OpenCV 5. The managed layer uses typed SafeHandle classes, disposal checks, native exception translation, platform guards, nullable annotations, and deterministic builds. That is the right foundation for an API crossing a large unmanaged boundary. Coverage extends across core image processing, DNN, feature detection, video, geometry, stitching, CUDA, and other OpenCV modules. The repository also includes numerous runnable samples, extensive generated API documentation, build scripts, release automation, SourceLink symbols, modular CPU, mobile, and GPU packages, plus strong legal notices for OpenCV, FFmpeg, CUDA, and bundled libraries.
The test suite is broader than most wrapper projects. It exercises ABI exports, data layouts, algorithms, invalid input, memory handling, concurrent disposal, finalization, DNN models, and optional CUDA hardware. CI enforces formatting, checksum validation, compilation, tests, coverage collection, and package creation. However, routine build and pull-request jobs run only on Windows, and tests target .NET 8 and 9 even though the library also targets .NET 10. Release jobs compile Linux, macOS, Android, and iOS binaries, but they do not run platform-specific smoke tests against those artifacts. For a project presented as production-ready and cross-platform, each supported runtime should load its native library and execute a small matrix operation before publication. The generator also produces about 97 percent of the code, yet CI does not appear to regenerate bindings and fail when committed output differs.
The largest improvement area is release consistency and supply-chain verification. The release workflow downloads precompiled GPU archives and publishes their contents without checking a pinned SHA-256 value. Existing checksums cover only three Windows CPU binaries, not every packaged native library. A signed manifest covering CPU, GPU, mobile, models, and FFmpeg artifacts would strengthen trust. Documentation also disagrees on CUDA, cuDNN, and OpenCV binary versions, including references to both opencv_world500 and opencv_world510, while package metadata still describes the main package as Windows-only. The checked-in opencv_prebuilt tree adds more than 8,000 files and significant repository weight. Moving reproducible native artifacts to versioned releases or Git LFS would make normal clones easier to manage. These gaps do not erase the engineering depth, but tightening platform validation, generated-code checks, and artifact provenance would better support the project’s production claims.
