OpenCV Zoo: A Model Zoo Tuned for OpenCV DNN, With Per-Device Inference Benchmarks
Model Zoo For OpenCV DNN and Benchmarks.
At a glance
- What is it?
- OpenCV Zoo collects models converted for the OpenCV DNN module and publishes inference timings across x86-64, ARM and RISC-V boards. It is a compatibility and measurement project, not a training or serving framework, and the README now points users to Hugging Face for models and online demos.
- Who is it for?
- Adopt OpenCV Zoo if you already ship opencv-python and want models that are known to load through the DNN module, plus a benchmark harness you can rerun on your own board. Skip it if you need a training pipeline, a model server, or a support commitment: there is no homepage, the last release listed is 4.10.0 from June 2024, and the README's first line redirects to the Hugging Face OpenCV org for models and online demos.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 110 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What OpenCV Zoo Is For, and What It Is Not
OpenCV DNN is an inference module inside OpenCV. It reads a limited set of graph formats and runs them without a Python deep learning framework in the loop. That constraint is the whole reason this repository exists. A model that trains fine in PyTorch may fail to load, produce different outputs after conversion, or run slowly because a layer fell back to a default implementation. OpenCV Zoo is the curated answer: a set of models the maintainers describe as tuned for OpenCV DNN, each in its own directory under models/, each with a demo script.
The audience is narrow and practical. You are writing C++ or Python that already links OpenCV, you want face detection, pose estimation, segmentation or text detection without adding ONNX Runtime or LibTorch, and you want to know roughly what latency to expect on the board you are targeting. The repository serves that reader. It does not train anything, it does not serve HTTP, and it does not manage model versions for you.
The README's opening line is the most important sentence in it: the project is now hosted in Hugging Face, with a pointer to huggingface.co/opencv for models and online demos. Treat the GitHub tree as the source of demo scripts, benchmark configuration and the timing table, and treat Hugging Face as the distribution channel. Anyone cloning this expecting the canonical weight host should read that line first.
How Models and Benchmarks Are Organized in the Repo
The layout is one directory per task, named for the task and the model. The README lists examples such as models/face_detection_yunet, models/face_recognition_sface, models/human_segmentation_pphumanseg, models/image_segmentation_efficientsam, models/object_detection_nanodet, models/object_detection_yolox, models/object_tracking_vittrack, models/qrcode_wechatqrcode and models/text_detection_ppocr. MediaPipe-derived entries sit under palm_detection_mediapipe, handpose_estimation_mediapipe, person_detection_mediapipe and pose_estimation_mediapipe.
Each directory carries its own demo script and, per the README, example outputs under an example_outputs/ subdirectory. That is the data flow a user experiences: clone, pull weights through Git LFS, run the demo for the model you care about, then lift the preprocessing and postprocessing code into your own application. The demos are the documentation. There is no separate API reference in the material provided, so the script next to the weights is what you read.
Benchmarks live in a parallel tree. The README points to benchmark/README for instructions and to benchmark/config for per-model benchmarking details, and the results table is rendered from benchmark/color_table.svg. Keeping configuration separate from model directories means the same model can be measured under different settings without editing the model folder.
The result is a flat, predictable structure rather than a package with a plugin registry. If you want a model that is not in the tree, nothing here helps you add it beyond copying the shape of an existing directory.
Getting It Running: pip, Git LFS and the Benchmark Config
The README gives three steps. Install or upgrade the Python bindings:
python3 -m pip install opencv-python
or
python3 -m pip install --upgrade opencv-python
Then clone with Git LFS present, because the weights are large binary files:
git clone https://github.com/opencv/opencv_zoo && cd opencv_zoo git lfs install git lfs pull
Then, for timings on your own machine, the README directs you to benchmark/README.md and notes that benchmark/config holds the details for benchmarking different models. Those are the only configuration surfaces named in the material I have. I cannot tell you the exact keys inside a benchmark config file, because the README does not print one.
The order matters. Running git lfs pull after git lfs install is what fetches the actual model blobs; a plain clone without LFS leaves pointer files. And the pip step installs a binary wheel, which will not include the TIM-VX or CANN backends the ARM results depend on. The README links separate OpenCV wiki guides for building with those backends enabled, which tells you the published NPU numbers come from custom builds, not from the wheel you just installed.
The Benchmark Table: What the Numbers Actually Measure
The README is unusually explicit about methodology, which is worth quoting in substance. The data under each hardware column is the elapsed time of an inference covering preprocess, forward pass and postprocess. It is the mean of 10 runs after warmup runs. Batch size is 1 for all results. A dash means the model is not available to run on that device. The README also warns that different metrics may be applied to specific models.
That combination is honest but easy to misread. A single number that folds preprocessing into the measurement is useful for an embedded deployment decision, because preprocessing cost on a Cortex-A53 is real. It is less useful if you plan to batch, since batch size is fixed at 1. And a mean of 10 runs after warmup tells you nothing about tail latency, which is often what breaks a camera pipeline.
The hardware list spans three instruction sets. On x86-64 there is an Intel Core i7-12700K. On ARM the README names Khadas VIM3, VIM4 and Edge 2, Atlas 200 DK and Atlas 200I DK A2, NVIDIA Jetson Nano B01 and Jetson Orin Nano, Raspberry Pi 4B, Horizon Sunrise X3, MAIX-III AXera-Pi and Toybrick RV1126. On RISC-V there are StarFive VisionFive 2 and Allwinner Nezha D1.
One qualifier is buried in the ARM list: benchmarks there are done using per-tensor quantized models, and the VIM3 entry says to follow the TIM-VX wiki guide to build OpenCV with that backend. So the ARM column is not measuring the same artifact as the x86 column. Comparing an x86 float result against an ARM quantized result is comparing two different things.
Where the Coverage Thins Out
The RISC-V section is the clearest limitation. It lists two boards, and for the Allwinner Nezha D1 the README states plainly that YuNet is tested for now, with a link to a separate C++ repository for details. One model on one board is a demonstration that the port exists, not a coverage claim. If your target is RISC-V, plan on doing the conversion and measurement work yourself for anything other than face detection.
The dashes in the table are the second limitation, and they are structural rather than accidental. A model that cannot run on a device is usually blocked by an unsupported operator, a backend that lacks the layer, or a quantized variant that was never produced. The README's phrase is that the model is not available to run on the device. There is no per-cell explanation of which of those three applies, so a dash tells you the combination failed but not why.
A third gap is versioning. The recent releases listed are 4.10.0 from June 2024 and 4.9.0 from December 2023, while the repository itself shows a push in May 2026. The release tags and the tree are moving on different schedules. Nothing in the material states which OpenCV version a given model directory was validated against, so if you pin opencv-python to an older minor version you are testing that pairing yourself.
How This Differs From ONNX Runtime or a Full Inference Server
The obvious alternative is ONNX Runtime. The difference is not speed, it is dependency surface. ONNX Runtime is a dedicated inference engine with its own execution providers, its own graph optimizer and its own release cadence. OpenCV Zoo's premise is the opposite: you already have OpenCV in your binary for image I/O, geometry or video capture, and you want inference to come along for free rather than adding a second runtime and a second set of native libraries to your build.
That trade has a cost. OpenCV DNN supports a narrower operator set than a dedicated runtime, which is exactly why this repository exists as a curation layer: someone has already checked that each listed model loads and runs. With ONNX Runtime you can take an arbitrary exported graph and find out at runtime whether it works; with OpenCV Zoo you pick from a list that is known to work and accept that the list is shorter.
A second contrast is the benchmark posture. This project publishes timings on named consumer and embedded boards, including NPUs, with the methodology stated. A general-purpose runtime typically leaves that to you. If cross-device latency comparison is the thing you need, the table here is the deliverable, and the model files are almost a side effect.
Maintenance, Licensing and Upgrade Cost
The repository is Apache-2.0 and is not archived. That covers the repository's own code and scripts. It does not automatically cover the weights. Model directories are named after third-party models, and the README does not state a per-model licence in the material I have. Before shipping any of them, check the licence attached to that specific model directory or its Hugging Face counterpart, because Apache-2.0 on the zoo does not relicense someone else's trained weights. This is a factual observation about where the licence boundary sits, not legal advice.
Upgrade cost is dominated by the Git LFS payload rather than by code. Pulling the full set of weights means a large clone, and re-pulling after an upstream model change means transferring those blobs again. If you only need two models, cloning the whole zoo to get them is the expensive path.
On the release side, the tags listed are 4.10.0 and 4.9.0, roughly six months apart, with the tree pushed much later than either tag. There is no stated compatibility matrix tying a model directory to an OpenCV version. The practical consequence is that upgrading opencv-python and upgrading the zoo are two separate decisions, and the benchmark table will not tell you whether an older pairing still behaves the same way.
Who Should Take This Dependency
Take it if your application is already an OpenCV application. The value is the curation: models that load through the DNN module, a demo script per model showing the preprocessing and postprocessing, and a benchmark harness in benchmark/ with configuration in benchmark/config that you can point at your own board to replace the published numbers with yours.
Do not take it if you need training, fine-tuning, a serving layer, or a vendor support contract. None of those are in scope, and the README's own first line moves model distribution to Hugging Face, which means the GitHub repository is not where you should expect weight hosting to remain stable over time.
Two verifications come before any integration work. First, run git lfs pull and confirm the weight files in the model directory you intend to use are real binaries and not pointer stubs, since a missed LFS step produces a failure that looks like a corrupt model. Second, check whether your target hardware needs a custom OpenCV build: the README links TIM-VX and CANN build guides for the Khadas VIM3 and Atlas boards respectively, so if your device is in that list, the opencv-python wheel is not the artifact the published numbers were measured on.
Editorial conclusion
Adopt OpenCV Zoo if you already ship opencv-python and want models that are known to load through the DNN module, plus a benchmark harness you can rerun on your own board. Skip it if you need a training pipeline, a model server, or a support commitment: there is no homepage, the last release listed is 4.10.0 from June 2024, and the README's first line redirects to the Hugging Face OpenCV org for models and online demos. Before committing, verify two things on your own hardware: that git lfs pull actually materializes the weights you need, and that your OpenCV build has the backend enabled for your NPU, since the ARM numbers in the table depend on TIM-VX or CANN builds rather than stock opencv-python.
Community notes