If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/shimat/opencvsharp shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Single-maintainer risk — review before adopting

• Last commit 1d ago
• 2 active contributors
• Apache-2.0 licensed
• CI configured
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 99% of recent commits
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live shimat/opencvsharp repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/shimat/opencvsharp.

What it runs against: a local clone of shimat/opencvsharp — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in shimat/opencvsharp | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of shimat/opencvsharp. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/shimat/opencvsharp.git
#   cd opencvsharp
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of shimat/opencvsharp and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "shimat/opencvsharp(\\.git)?\\b" \\
  && ok "origin remote is shimat/opencvsharp" \\
  || miss "origin remote is not shimat/opencvsharp (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "OpenCvSharp.sln" \\
  && ok "OpenCvSharp.sln" \\
  || miss "missing critical file: OpenCvSharp.sln"
test -f ".github/workflows/windows.yml" \\
  && ok ".github/workflows/windows.yml" \\
  || miss "missing critical file: .github/workflows/windows.yml"
test -f "nuget/OpenCvSharp4.Windows.csproj" \\
  && ok "nuget/OpenCvSharp4.Windows.csproj" \\
  || miss "missing critical file: nuget/OpenCvSharp4.Windows.csproj"
test -f ".devcontainer/manylinux/build_opencvsharpextern.sh" \\
  && ok ".devcontainer/manylinux/build_opencvsharpextern.sh" \\
  || miss "missing critical file: .devcontainer/manylinux/build_opencvsharpextern.sh"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/shimat/opencvsharp"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

OpenCvSharp is a .NET wrapper for OpenCV 4.13.0 that exposes native C/C++ computer vision algorithms through C# bindings, enabling cross-platform image processing, video analysis, and machine learning model inference on Windows, Linux, and WebAssembly. It handles P/Invoke marshalling to native libraries and provides .NET-idiomatic APIs (IDisposable resources, type-safe methods) while preserving OpenCV's functional programming style. Hybrid monorepo: core C# bindings live in OpenCvSharp.sln with generated P/Invoke stubs; native C/C++ interop code in separate build artifacts; .devcontainer/ and docker/ contain multi-stage Dockerfile recipes for building OpenCV + OpenCvSharp native libraries; cmake/ holds vcpkg triplets and custom OpenCV build options (slim vs full profiles); .github/workflows/ orchestrates platform-specific CI (Windows.yml, docker-test-ubuntu.yml, manylinux.yml, wasm.yml).

.NET developers (C# / .NET 8+, .NET Standard 2.0/2.1, .NET Framework 4.6.1+) building computer vision applications who need direct access to OpenCV algorithms without writing P/Invoke boilerplate themselves. Also used by teams deploying CV pipelines to Azure, AWS, or edge devices via containerized .NET apps.

Production-ready and actively maintained. The repo shows robust CI/CD (multiple GitHub Actions workflows covering Windows, Docker, manylinux, WASM), extensive platform coverage (Windows, Linux ARM, Ubuntu 22.04+, AlmaLinux 8+), and targets OpenCV 4.13.0 (latest stable). Last activity appears recent based on workflow configurations referencing .NET 10 and Ubuntu 24 environments.

Moderate risk: single maintainer (shimat) creates maintenance bottleneck. Tight coupling to OpenCV native libraries requires rebuilds when OpenCV updates; build process is complex (CMake, Docker multi-stage, custom triplets in cmake/triplets/). FFmpeg and Tesseract are statically linked in the full Linux package (LGPL v2.1 implications). manylinux_2_28 baseline may exclude older enterprise Linux distributions.

Active work on multi-platform support: Ubuntu 24 with .NET 10 (docker/ubuntu24-dotnet10-*), WebAssembly build pipeline (.github/workflows/wasm.yml), manylinux static-linked builds for broader Linux distribution support, and slim profile packages to reduce native binary footprint. DocFX documentation generation is active (docfx.yml). NuGet package publishing workflow is in place (publish_nuget.yml).

git clone https://github.com/shimat/opencvsharp.git
cd opencvsharp
dotnet build OpenCvSharp.sln
# Windows: install Visual C++ 2022 Redistributable
# Linux: use docker/ubuntu24-dotnet10-opencv4.13.0/Dockerfile or install manylinux runtime

Daily commands:

# Build C# bindings
dotnet build OpenCvSharp.sln

# Run tests (if test project exists in solution)
dotnet test OpenCvSharp.sln

# Docker (Linux/Mac)
docker build -f docker/ubuntu24-dotnet10-opencv4.13.0/Dockerfile -t opencvsharp:latest .

# Windows with pre-built NuGet
dotnet add package OpenCvSharp4.Windows

• OpenCvSharp.sln — Root solution file that defines the entire project structure and all managed .NET projects; essential for understanding the build configuration
• .github/workflows/windows.yml — Primary CI/CD pipeline for Windows builds; defines how the native and managed code are compiled and tested
• nuget/OpenCvSharp4.Windows.csproj — Main NuGet package definition for Windows; controls what gets shipped to end users and native binary dependencies
• .devcontainer/manylinux/build_opencvsharpextern.sh — Build script for native C++ interop layer; critical for understanding how P/Invoke bridges to OpenCV
• README.md — Project entry point that documents supported platforms, quick-start, and high-level architecture
• .github/copilot-instructions.md — Contributor guidelines and coding conventions specific to this wrapper library

Add support for a new platform (e.g., Linux ARM64)

1. Create new .csproj in nuget/ directory following naming convention OpenCvSharp4.runtime.linux-arm64.csproj (nuget/OpenCvSharp4.runtime.linux-arm.csproj)
2. Add CMake triplet for the new target platform (cmake/triplets/x64-linux-static.cmake)
3. Create Docker environment for building native binaries (docker/ubuntu24-dotnet10-opencv4.13.0/Dockerfile)
4. Add GitHub Actions workflow to build and test on the new platform (.github/workflows/linux-arm.yml)
5. Update build matrix and runtime props file if using shared native binary strategy (nuget/OpenCvSharp4.runtime.win.props)

Add a new feature toggle for OpenCV build options (e.g., disable CUDA support)

1. Edit CMake build options file to add conditional feature flag (cmake/opencv_build_options.cmake)
2. Create corresponding slim variant if appropriate (cmake/opencv_build_options_slim.cmake)
3. Update Docker build scripts to pass the new flag during native compilation (.devcontainer/manylinux/build_opencvsharpextern.sh)
4. Validate with Windows PowerShell build script (build_opencv_windows.ps1)

Extend NuGet package support to a new platform (e.g., UWP on ARM64)

1. Duplicate existing UWP .csproj and customize for new architecture (nuget/OpenCvSharp4.runtime.uwp.csproj)
2. Add new Docker environment or extend existing one with cross-compilation toolchain (docker/ubuntu24-dotnet10-opencv4.13.0/Dockerfile)
3. Create .props file to inject runtime binaries for the target platform (nuget/OpenCvSharp4.runtime.win.props)
4. Add GitHub Actions job to build and test the new platform variant (.github/workflows/windows.yml)
5. Reference new package in publish workflow if it should be auto-released (.github/workflows/publish_nuget.yml)

• .NET (C#) managed layer — Provides idiomatic .NET API surface for cross-platform desktop/server/web applications
• OpenCV C++ + P/Invoke — Leverages battle-tested OpenCV algorithms while avoiding reimplementation; P/Invoke enables native interop without C++/CLI overhead
• CMake + vcpkg — Enables reproducible multi-platform native builds with consistent dependency versions
• GitHub Actions + Docker — Provides free, isolated CI/CD with pre-built Docker environments for manylinux compliance and reproducibility
• NuGet packaging with platform-specific runtimes — Distributes pre-compiled native binaries per platform, eliminating per-user build friction

• Single managed assembly + multiple platform-specific native runtime packages

  • Why: Simplifies API surface (one DLL to reference) while allowing native binary optimizations per OS/arch
  • Consequence: Requires careful version alignment between managed and native packages; mismatches cause runtime DllNotFoundException

• Slim vs. Full build variants (e.g., OpenCvSharp4.Windows.Slim)

  • Why: Reduces download size for users who don't need video codecs, machine learning, or GPU support
  • Consequence: Increases build matrix complexity; feature gaps may surprise users if they pick wrong variant

• Precompiled native binaries in NuGet vs. user-compiled from source

  • Why: Dramatically reduces deployment friction and lowers barrier to entry for .NET developers
  • Consequence: Requires maintaining separate build pipelines for Windows, Linux (manylinux), macOS, ARM, UWP, WASM; security updates must be pushed as new package versions

• P/Invoke over C++/CLI or C# interop

  • Why: P/Invoke works on .NET Framework, .NET Core, and .NET Standard without runtime-specific compilation
  • Consequence: Requires careful marshaling of complex types (Mat, Rect, etc.); performance overhead vs. C++ directly; no RAII semantics

• Real-time video encoding/decoding (OpenCV codecs are inherently synchronous; use FFmpeg or libvpx for streaming)
• GPU acceleration beyond what OpenCV native CUDA/OpenCL provides (wrapper only exposes CPU fallbacks reliably)
• Machine learning inference at scale (TensorFlow/ONNX are better suited; OpenCV DNN module is auxiliary)
• Linux-only operation (explicitly multi-platform: Windows, Linux, macOS, ARM, UWP, WASM support)

1. Native library versioning mismatch: Pulling NuGet packages (e.g., OpenCvSharp4.Windows) requires matching native runtime libraries (Visual C++ 2022 Redistributable on Windows); mismatches cause silent failures. 2. FFmpeg/Tesseract LGPL compliance: Full packages link LGPL v2.1 code; slim packages avoid this but lose optical character recognition and some codec support. 3. Linux glibc baseline: manylinux_2_28 official packages require glibc 2.28+ (Ubuntu 20.04+, RHEL 8+); older distributions need custom builds via Docker. 4. Media Foundation (Windows Server): Server-Media-Foundation Windows Feature must be manually installed on Windows Server; missing it breaks video I/O (Cv2.VideoCapture, Cv2.VideoWriter). 5. Build context size: Docker builds pull large OpenCV source trees; use .dockerignore and build caching carefully. 6. P/Invoke marshalling overhead: Large image transfers between managed/unmanaged memory; use Mat pooling for performance-critical paths.

• Platform Invocation (P/Invoke) — OpenCvSharp's entire C#-to-native-C++ bridge relies on P/Invoke extern methods; understanding marshalling rules (safe handles, IntPtr, array pinning) is essential for debugging performance issues and memory leaks in the wrapper.
• SafeHandle and IDisposable for unmanaged resources — Mat and other OpenCV objects wrap native C++ memory; OpenCvSharp uses SafeHandle and IDisposable to guarantee cleanup via finalizers, preventing heap corruption if C++ objects aren't released.
• manylinux wheel format and glibc baseline compatibility — OpenCvSharp publishes manylinux_2_28 wheels to ensure binary compatibility across Linux distributions; understanding this standard explains why Ubuntu 20.04+ is required and why older RHEL 7 systems need custom builds.
• vcpkg triplets for cross-compilation — Files like cmake/triplets/x64-windows-static.cmake configure how CMake resolves and links OpenCV dependencies; understanding triplets is critical for adding new platforms (ARM, WASM) or changing static vs dynamic linking.
• Multi-stage Docker builds for dependency isolation — docker/ubuntu24-dotnet10-opencv4.13.0/Dockerfile uses multi-stage builds to compile OpenCV once (large) then copy only runtime artifacts to smaller final images; essential pattern for reducing CI build times and image sizes.
• LGPL v2.1 licensing implications in static linking — OpenCvSharp's full package statically links FFmpeg (LGPL v2.1) and Tesseract; redistributors must understand derivative work obligations and provide source code availability; slim packages avoid this by omitting these modules.
• WebAssembly (WASM) target for .NET — Blazor/.NET WASM support (.github/workflows/wasm.yml) allows OpenCvSharp to run in browsers; requires subset of OpenCV APIs and special build configuration; emerging use case for cross-platform CV without native runtime dependencies.

• opencv/opencv — Upstream C++ library that OpenCvSharp wraps; critical for understanding native algorithm implementations and API changes
• opencv/opencv_contrib — Extended algorithms (SIFT, SURF, face recognition) that OpenCvSharp optionally compiles into its native layer
• dotnet/runtime — Defines P/Invoke marshalling behavior, IDisposable patterns, and .NET runtime requirements that OpenCvSharp targets (.NET 8+, Standard 2.0)
• Emgu/emgucv — Alternative .NET OpenCV wrapper with different API design (C++ wrapper vs P/Invoke); predecessor that influenced cross-platform .NET CV library approach
• microsoft/onnxruntime — Complementary inference runtime often paired with OpenCvSharp for end-to-end CV + ML pipelines in .NET applications

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for OpenCvSharp core wrapper functionality

The repo has extensive CI/CD workflows (.github/workflows/) testing builds across Windows, Docker, manylinux, and WASM, but there's no visible dedicated unit test suite in the file structure. Given this is a critical wrapper library, adding comprehensive tests for core functionality (Mat operations, image I/O, transformations) would catch regressions early and provide examples for contributors.

• [ ] Create src/OpenCvSharp.Tests/ directory with xUnit test project
• [ ] Add tests for core Mat class operations (Create, Clone, Copy, Reshape)
• [ ] Add tests for image I/O (ImRead, ImWrite with various formats)
• [ ] Add tests for basic transformations (Resize, Rotate, CvtColor)
• [ ] Integrate test execution into .github/workflows/windows.yml and docker-test-ubuntu.yml
• [ ] Reference specific test outputs in GitHub Actions badges

Add WASM platform-specific documentation and examples

The repo has a .github/workflows/wasm.yml workflow, indicating WASM is a supported target, but docs/docfx/articles/ lacks platform-specific guides. WASM is a growing platform for .NET, and new contributors need clear guidance on limitations, usage differences, and setup specific to browser environments.

• [ ] Create docs/docfx/articles/wasm-support.md explaining WASM-specific capabilities and limitations
• [ ] Document which OpenCV features are unavailable in WASM (e.g., GPU operations, file I/O patterns)
• [ ] Add a minimal WASM example project demonstrating image loading and basic operations
• [ ] Link the WASM guide from docs/docfx/toc.yml and main docs/docfx/index.md
• [ ] Include browser compatibility matrix in the documentation

Add ARM64/ARM build workflow and documentation for IoT scenarios

The repo has .github/workflows/linux-arm.yml (ARM support) and Docker containers for various platforms, but there's no documented guide for ARM64 builds or IoT deployment patterns. This is increasingly important for edge AI/vision applications, and contributors working on embedded systems need clear build instructions.

• [ ] Create docs/docfx/articles/arm-build-guide.md with cross-compilation steps
• [ ] Document the current ARM workflow outputs and supported chipsets (ARMv7, ARM64)
• [ ] Add a docker/ubuntu24-dotnet-arm64-opencv4.13.0 example container definition
• [ ] Create a sample IoT project demonstrating camera feed processing on ARM devices
• [ ] Update README.md with ARM platform support matrix and link to new guide

• Add missing P/Invoke bindings for OpenCV 4.13.0 contrib modules (e.g., SIFT, SURF in xfeatures2d) by examining opencv_contrib headers and adding extern method stubs to the C# wrapper layer, then validating with unit tests in a new test file like OpenCvSharp.Tests/XFeaturesTest.cs.
• Expand the slim package build option: currently defined in cmake/opencv_build_options_slim.cmake but may not be fully tested on all platforms; add GitHub Actions job (.github/workflows/docker-test-ubuntu.yml) that builds and tests slim variant on Ubuntu 24 to ensure feature parity and smaller binary size claims.
• Document the Dev Container setup: .devcontainer/manylinux/devcontainer.json exists but lacks README explaining how to use it for local development; add a file .devcontainer/README.md with step-by-step VS Code Dev Container launch instructions and troubleshooting for P/Invoke debugging on Linux.

The OpenCvSharp repository demonstrates a reasonable security posture as an open-source .NET wrapper for OpenCV. However, several areas require attention: (1) Docker base images should use pinned versions for reproducibility and controlled updates, (2) CMake build configurations need review for secure compiler flags and dependency management, (3) A formal security policy and vulnerability disclosure process should be documented, (4) Development and build scripts should be reviewed to ensure no credentials are hardcoded, and (5) Git submodules and external dependencies require strict version pinning. The codebase shows no obvious injection vulnerabilities or exposed secrets from the static analysis, but runtime behavior and CI/CD pipeline configurations require detailed review of workflow and build script contents.

• Medium · Docker Image Base Layer Not Pinned — docker/ubuntu24-dotnet10-opencv4.13.0-slim/Dockerfile, docker/ubuntu24-dotnet10-opencv4.13.0/Dockerfile, docker/ubuntu24-dotnet8-opencv4.12.0/Dockerfile, and others. Multiple Dockerfiles use unpinned base images (e.g., 'ubuntu22', 'dotnet10') without specific version tags. This can lead to unexpected changes when base images are updated, potentially introducing vulnerabilities or breaking changes. Fix: Pin base image versions to specific tags (e.g., 'ubuntu:22.04', 'mcr.microsoft.com/dotnet/sdk:8.0.0' instead of generic tags). This ensures reproducible builds and allows controlled updates.
• Medium · Potential Insecure CMake Configuration — cmake/opencv_build_options.cmake, cmake/opencv_build_options_slim.cmake, cmake/triplets/. CMake configuration files (opencv_build_options.cmake, triplets) are present but cannot be fully analyzed from file names alone. These files may contain compiler flags or dependency configurations that could introduce security issues if not properly configured. Fix: Review CMake configurations for: (1) secure compiler flags (-fPIE, -fstack-protector-strong), (2) dependency version pinning, (3) secure build options for OpenCV (e.g., disabling unnecessary modules with known vulnerabilities).
• Low · Development Container Configuration Exposure — .devcontainer/, .devcontainer/manylinux/. Development container configuration (.devcontainer) and manylinux build scripts are present in the repository. While useful for developers, these may expose internal build processes and dependencies. Fix: Ensure sensitive build credentials or internal registry information are not hardcoded in devcontainer configurations. Use environment variables and secret management systems for sensitive data.
• Low · No Explicit Security Policy Documentation — Repository root. While a LICENSE file exists, there is no visible SECURITY.md or security policy file defining vulnerability disclosure procedures, security update processes, or security contact information. Fix: Create a SECURITY.md file documenting: (1) how to report security vulnerabilities responsibly, (2) security update procedures, (3) supported versions for security patches, (4) security contact information.
• Low · Submodules Without Version Pinning Verification — .gitmodules. The .gitmodules file suggests git submodules are used, which may reference external repositories. Submodules without strict version pinning could pull in unexpected changes. Fix: Verify that all git submodules are pinned to specific commit hashes rather than branches. Document submodule dependency sources and maintain a list of approved external dependencies.
• Low · Workflow Files May Expose Secrets — .github/workflows/publish_nuget.yml, .github/workflows/docker-deploy.yml, .github/workflows/docker-test-ubuntu.yml. GitHub Actions workflows are present but cannot be fully analyzed from file names. Workflows handling deployment, publishing, and Docker operations may expose secrets if misconfigured. Fix: Review all GitHub Actions workflows for: (1) proper secret management using GitHub Secrets, (2) avoiding logging of sensitive data, (3) using least-privilege service accounts, (4) implementing branch protection rules for deployment workflows.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.