OpenCV: Open Source Computer Vision Library

What OpenCV is

OpenCV, the Open Source Computer Vision Library, is a C++ library for image processing, classical computer vision and, increasingly, neural network inference. It ships official bindings for Python, Java and JavaScript, and it has been the default toolbox for camera pipelines, robotics, inspection systems and research prototypes for a long time: the licence-change proposal in the project wiki notes that OpenCV was released by Intel as an open-source library in 2000, and the GitHub repository itself was created on 19 July 2012. Today it has about 91,600 stars, and the copyright file lists Intel, Willow Garage, NVIDIA, AMD, Itseez, the OpenCV Foundation, Xperience AI, OpenCV AI and several universities among its contributors over the years.

The repository README is short. It points to the homepage at opencv.org, documentation at docs.opencv.org (with separate 4.x and 5.x trees), a Q&A forum at forum.opencv.org, the issue tracker, and the companion opencv_contrib repository for extra modules. The substance lives in the docs tree, the wiki and the per-module headers, which is where most of the facts on this page come from.

The audience is broad. A Python developer who needs to decode a JPEG, threshold it and count blobs uses the same library as a C++ team calibrating a multi-camera rig or running an ONNX detector on an ARM board. What changed in 2026 is that OpenCV 5 landed, with a reorganised module layout, a rewritten deep learning engine and a long list of removals, so the question of which version a project is on matters more than usual.

The 4.x and 5.x branches, as the sources state them

The default branch on GitHub is 5.x, and a 4.x branch also exists. The wiki page on branches spells out the policy. 5.x is "the major development branch for 5.x releases since 5.0.0" and contributors should "use it by default" for pull requests. 4.x "is switched to maintenance mode. No new features are accepted here." Changes from 4.x are merged into 5.x regularly (weekly or bi-weekly), but "there is no regular process for backporting patches from 5.x". Both branches must preserve API compatibility; neither promises ABI compatibility, and 4.x is asked to "avoid major breakages". The 3.4 branch went end-of-life in 2023 and 2.4 in 2020.

The OpenCV 5 summary page in the wiki frames it slightly differently: OpenCV "maintains two active development branches: the previous stable 4.x branch and 5.x branch (now also stable) where most of the latest functionality will be put to", and many performance, codec, SIMD and HAL improvements were developed in 4.x and backported to 5.x. Reading the two together, 4.x still gets releases and fixes, but new features go to 5.x.

The version headers confirm where each branch is heading. On 15 November 2026, modules/core/include/opencv2/core/version.hpp on 5.x defines 5.2.0 with status -dev, and the same file on 4.x defines 4.15.0-dev. The released versions, from the git tags and the change log, are:

Release	Tag date	Notes from the change log
5.1.0	5 November 2026	"First feature update for OpenCV 5.x"
4.14.0	18 July 2026	4.x maintenance release, listed as July 2026
5.0.0	5 June 2026	First 5.x release; summary and migration guide in the wiki
4.13.0	30 December 2025	"New Year update for OpenCV 4.x"

On PyPI the picture lags slightly. The newest uploads of opencv-python and opencv-python-headless are 5.0.0.93 (2 July 2026) and 4.14.0.94 (28 July 2026), and the PyPI JSON reports 5.0.0.93 as the current version. No 5.1.0 wheel was listed when this was checked, so pip users get 5.0 even though the C++ sources are at 5.1.0.

How OpenCV is organised

Modules

The library is split into modules, each a subdirectory of modules/. On the 5.x branch they are calib, core, dnn, features, flann, geometry, highgui, imgcodecs, imgproc, ml, objdetect, photo, ptcloud, stereo, stitching, video and videoio, plus binding and test infrastructure (java, js, objc, python, ts, world). The 4.x branch instead has calib3d, features2d and gapi. That difference is the visible part of the 5.0 restructuring:

calib3d was split into four modules. geometry holds classic 2D, 3D and nD geometry, calib camera calibration, stereo depth estimation from stereo correspondence, and ptcloud higher-level 3D work such as visual odometry and TSDF volume integration.
features2d became features. SIFT, ORB, FAST, GoodFeaturesToTrack and MSER stay in the main repository; obsolete detectors moved to contrib; deep learning local features (ALIKED, DISK) and the LightGlue matcher were added, and Annoy-based approximate nearest neighbour search arrived as a modern replacement for FLANN-based search.
G-API and the classic ML module moved to opencv_contrib. The wiki suggests scikit-learn for Python users who relied on cv2.ml.
Haar cascades and HOG moved to contrib (xobjdetect), with the DNN-based FaceDetectorYN recommended for new face detection code.

For Python users the migration guide says the restructuring "is fully transparent": functions stay reachable as cv2.<funcname>(). C++ users need new includes such as opencv2/geometry.hpp and opencv2/calib.hpp.

opencv_contrib

The contrib README explains why it exists: new modules "quite often do not have stable API, and they are not well-tested", so they are developed separately and moved into the main repository once they mature, because the main library "maintains binary compatibility, and tries to provide decent performance and stability". Since 4.0 all CUDA-accelerated algorithm implementations live in contrib as well, according to the configuration reference.

Acceleration layers

Underneath the API sit several layers: universal intrinsics for SIMD (SSE/AVX on x86, NEON on ARM, VSX on PowerPC, RVV on RISC-V), a hardware abstraction layer (HAL) that vendor libraries such as Intel IPP, ArmPL and FastCV plug into, the OpenCL "Transparent API" that switches to GPU code when you pass cv::UMat objects, and a choice of threading backends. The configuration reference lists pthreads (default on Unix-like systems), Concurrency on Windows, GCD on Apple platforms, and optional TBB, OpenMP and HPX.

What OpenCV 5 changed

The OpenCV 5 wiki page and the 5.1.0 change log are long; these are the points most likely to affect a project:

C++17 and Python 3 only. C++17 is the minimum standard (GCC 8, Clang 9 or MSVC 2017 19.14 per the migration guide), Python 2 bindings are gone and Python 3.6 or later is required.
The C API is removed. cvCreateMat(), cvFindContours(), CvMat and friends are gone, though macros such as CV_8U remain.
New data types. 5.0 added CV_16BF (bfloat16), CV_32U, CV_64U, CV_64S and CV_Bool; 5.1.0 added FP8 depths CV_8F_E4M3FN and CV_8F_E4M3FNUZ. Arrays can now be genuinely 1D or 0D, so a NumPy array passed as an input becomes a 1D Mat rather than an N×1 matrix.
Behaviour changes that break pixel-exact baselines. Nearest-neighbour resize now follows the Pillow algorithm, and warpAffine, warpPerspective and remap dropped table-based interpolation, so bilinear and bicubic output "will differ slightly" from 4.x. The wiki claims warping speed-ups "from 10% to over 300%" depending on platform and flags.
Faster contours. findContours() uses the new TRUCO algorithm "whenever possible", which the wiki says is several times faster than the previous implementation.
Text rendering. 5.0 replaced the Hershey-only renderer with an STB TrueType engine and a built-in variable font; 5.1.0 switched to HarfBuzz, fixing complex scripts such as Arabic and Devanagari.
Video I/O. VideoCapture::get() now returns -1 instead of 0 for unsupported properties. 5.1.0 added camera enumeration, FFmpeg and GStreamer encoder controls (bitrate, CRF, preset, GOP size) and FFmpeg 9.0 support.
3D and calibration. USAC is the default robust estimator for homography, essential and fundamental matrices and PnP; there is a multi-view calibration pipeline for N cameras; 5.1.0 added an OpenGL 3D visualiser, 3D Gaussian Splatting loading, point-cloud processing and a first monocular visual odometry class.

The DNN module and ONNX

The dnn module is where OpenCV overlaps with dedicated inference runtimes, and it changed the most. OpenCV 5.0 introduced a new inference engine alongside the classic one. The wiki says it covers "over 64% of the ONNX specification", against "less than 13%" for 4.x, and handles dynamic shapes and subgraphs much better. readNet() and readNetFromONNX() gained an engine parameter defaulting to ENGINE_AUTO, which in 5.0 tries the new engine first and falls back to the classic one. The OPENCV_FORCE_DNN_ENGINE environment variable picks an engine without code changes, and value 4 routes inference through ONNX Runtime when OpenCV was built with it.

ONNX Runtime integration is a build option: WITH_ONNXRUNTIME and DOWNLOAD_ONNXRUNTIME (default version 1.25.1 per the configuration reference), with DOWNLOAD_ONNXRUNTIME_GPU for NVIDIA execution providers on Windows x64 and Linux x64. OpenCV uses its own ONNX parser to build the ORT graph, so only the ORT runtime library is needed. For GPU work in 5.0, the guidance is to force the classic engine (which has CUDA and OpenCL backends) or build with ORT plus NVIDIA providers, because the new engine was CPU-only at release.

5.1.0 moved further. Its change log says the classic engine is removed, EngineType becomes ENGINE_AUTO, ENGINE_OPENCV and ENGINE_ORT, the TensorFlow importer is removed (ONNX and TFLite remain), and a CUDA backend with cuDNN support was added to the new engine. The migration note is explicit: code passing ENGINE_CLASSIC or ENGINE_NEW must switch. The 5.0.0.93 wheel tested below still exposes ENGINE_AUTO, ENGINE_CLASSIC, ENGINE_NEW and ENGINE_ORT, so code written against the PyPI wheel today will need a small change when 5.1 wheels arrive. Darknet and Caffe parsers were already removed in 5.0; the YOLO tutorial lists YOLOX, YOLO-NAS and YOLOv4 through YOLOv10 as supported and says YOLO v1 to v3 no longer are.

Performance numbers come with the usual caveat. The wiki publishes tables where the new engine is close to or ahead of ONNX Runtime 1.25.1 on several CPUs, for example YOLOv8 at 12.42 ms against 12.98 ms on an Intel i9 and MobileNetv2 at 1.35 ms against 1.06 ms. These are the project's own benchmarks; they were not reproduced here. The 5.1.0 log also adds KV-cache support, attention layers and tokenizers aimed at running vision-language models end to end, with an experimental VLM sample in samples/dnn.

Getting started

Python from PyPI

The Python setup tutorial calls PyPI the recommended route and notes that the OpenCV team maintains only the PyPI packages; Conda and vendor builds are community builds. There are four variants, and the opencv-python README says to install exactly one per environment because they all share the cv2 namespace:

pip install opencv-python
pip install opencv-contrib-python
pip install opencv-python-headless
pip install opencv-contrib-python-headless

The headless packages are the ones documented for "servers/containers/CI": they are built without Qt or other GUI components, which avoids the X11 dependency chain and gives smaller Docker images. Use them unless the code calls cv2.imshow or similar. The wheels are "pre-built CPU-only"; enabling CUDA means a manual build. The README also asks for pip 19.3 or newer, because older pip versions cannot install manylinux2014 wheels and fall back to a source build that also fails.

Building from source on Linux

The Linux install tutorial's quick start for the 5.x branch, taken from samples/install/linux_quick_install.sh:

sudo apt update && sudo apt install -y cmake g++ wget unzip ninja-build
wget -O opencv.zip https://github.com/opencv/opencv/archive/5.x.zip
unzip opencv.zip
mkdir -p build && cd build
cmake -GNinja  ../opencv-5.x
cmake --build .

To include contrib modules, the companion script downloads both archives and passes the extra modules path:

wget -O opencv_contrib.zip https://github.com/opencv/opencv_contrib/archive/5.x.zip
cmake -GNinja -DOPENCV_EXTRA_MODULES_PATH=../opencv_contrib-5.x/modules ../opencv-5.x

The configuration reference covers the useful knobs: BUILD_LIST to build only selected modules and their dependencies, CPU_BASELINE and CPU_DISPATCH for instruction sets (SSE3 is the x86_64 default baseline), WITH_CUDA, WITH_OPENCL, WITH_TBB and WITH_OPENVINO. A default install goes under /usr/local with headers in include/opencv5, and the tutorial does not recommend system-wide installation for regular users because of conflicts with distribution packages. Configure can download dependencies from the internet, and a failed download silently turns the related feature off, so check the summary.

Running an ONNX model

The migration guide's minimal DNN call, which it says is unchanged between 4.x and 5.x for most ONNX models:

net = cv2.dnn.readNet("model.onnx")
blob = cv2.dnn.blobFromImage(image, 1/255.0, (640, 640))
net.setInput(blob)
outputs = net.forward()

Hands-on: opencv-python-headless 5.0.0.93 on a 2-vCPU VM

This was run on 15 November 2026 on a Linux x86_64 cloud VM (Ubuntu 24.04, 2 vCPUs, Python 3.13, no GPU). pip install opencv-python-headless pulled opencv-python-headless-5.0.0.93 and numpy-2.5.4, and PyPI lists the Linux x86_64 headless wheels for that version at 56.6 MB (manylinux2014) and 61.2 MB (manylinux_2_28); the installed cv2 package directory is 72 MB. A short script then printed version and build information and ran real operations on a synthetic 1920×1080 image (three filled shapes, twelve circles and a line of text).

What the wheel is built with

Check	Output
`cv2.__version__`	`5.0.0`
`cv2.getNumThreads()`	`2` (matches the VM's vCPUs)
Parallel framework	`pthreads`
Modules to be built	`calib core dnn features flann geometry highgui imgcodecs imgproc objdetect photo ptcloud python3 stereo stitching video videoio`
CPU baseline / dispatch	`SSE SSE2 SSE3` / `SSE4_1 SSE4_2 AVX FP16 AVX2 AVX512_SKX`
Video I/O	`FFMPEG: YES` (avcodec 62.28.101), `GStreamer: NO`, `v4l/v4l2: YES`
GUI	`NONE`
Codecs	libjpeg-turbo 3.1.2, libpng 1.6.58, WebP, AVIF 1.4.2
Other	Intel IPP 2026.0.0, OpenBLAS Lapack, `OpenCL: YES`, `ONNX Runtime: NO`, C++ standard 17

Operations on the synthetic image

Operation	Result
`Canny(gray, 50, 150)`	10,489 edge pixels; about 2.8 ms per call
`threshold` + `findContours(RETR_EXTERNAL)`	23 external contours; largest areas 200,000, 157,525, 125,064 and 7,684 px (rectangle, circle, quadrilateral, one small circle)
`resize` to 640×360	about 0.5 ms with `INTER_LINEAR`, 2.4 ms with `INTER_AREA`
`GaussianBlur` 7×7	about 4.3 ms per call
`imencode` (6,220,800 raw bytes)	PNG 41,775 bytes; JPEG q90 84,340 bytes; WebP q90 25,978 bytes; JPEG round-trip PSNR 39.94 dB
`ORB_create(nfeatures=500)`	501 keypoints, descriptors shaped (501, 32); about 13 to 14 ms per detect-and-compute
ORB + `BFMatcher` against a 15° rotated copy	319 cross-checked matches; `findHomography` RANSAC kept 285 inliers but implied about 16.0°; `estimateAffinePartial2D` recovered 15.01° at scale 1.001 with 269 inliers

Timings are averages over 20 to 100 calls on a shared cloud VM and only indicate order of magnitude. The contour count includes the letter shapes from the text, which is why it is higher than the fifteen drawn shapes. The rotation test is a small lesson in itself: a full homography has eight degrees of freedom and drifted by about a degree on this synthetic scene, while the four-parameter similarity model matched the true transform almost exactly.

The 5.0 removals are real in the wheel

hasattr(cv2, "CascadeClassifier") and hasattr(cv2, "HOGDescriptor") both returned False, and hasattr(cv2, "ml") returned False. FaceDetectorYN was present.
The opencv-python README (on both its 4.x and 5.x branches) still says "All packages contain Haar cascade files" and shows a cv2.CascadeClassifier(...) example. On this 5.0.0.93 headless wheel that example failed with AttributeError: module 'cv2' has no attribute 'CascadeClassifier', and the cv2/data directory contained no XML files. Tutorials written for 4.x will hit the same error.
cv2.dnn.readNetFromONNX exists, and the engine constants were ENGINE_AUTO, ENGINE_CLASSIC, ENGINE_NEW and ENGINE_ORT, matching 5.0 rather than 5.1.

Use cases

Image pre- and post-processing around a model. Decoding, colour conversion, resizing and letterboxing before inference, then non-maximum suppression, drawing and encoding afterwards. Even teams that run detectors elsewhere, such as the models covered on the YOLOE and YOLOv10 page, often use OpenCV for this glue.
Lightweight ONNX inference without another runtime. When a model is in ONNX and the deployment is CPU-bound, the dnn module can load it directly, and the 5.x build can delegate to ONNX Runtime when compiled with it.
Video ingestion. VideoCapture over FFmpeg, V4L2 or GStreamer reads files, cameras and streams frame by frame, for example to sample frames for a document or OCR pipeline before handing them to a tool such as Docling.
Classical vision where deep learning is overkill. Thresholding, contours, morphology and template matching remain the fastest path for industrial inspection, barcode and QR work, ArUco markers and measurement.
Geometry and calibration. Single and multi-camera calibration, stereo depth, homographies and PnP for robotics, AR and photogrammetry.
Feature matching and retrieval. ORB, SIFT and the newer learned features produce descriptors for image alignment and stitching; large-scale similarity search over embeddings is usually handed to a dedicated index such as Faiss.

How OpenCV compares

OpenCV is a broad library, so comparisons are about overlap rather than replacement. The table sticks to what the sources read for this page support; details of the other projects are hedged and should be checked on their own pages.

	OpenCV	ONNX Runtime	YOLOE / YOLOv10
Primary job	General computer vision library: image I/O, processing, geometry, video, plus a DNN module	Model inference runtime for ONNX graphs	Specific object detection model families
Image and video I/O	Built in (imgcodecs, videoio)	Not its focus; typically paired with an image library	Relies on surrounding tooling
Running ONNX models	Yes, via `readNetFromONNX`; can also delegate to ONNX Runtime when built with `WITH_ONNXRUNTIME`	Yes, its core purpose	Models can be exported to ONNX; the OpenCV YOLO tutorial lists YOLOv10 as supported in the DNN module
GPU inference	5.0 new engine CPU-only; 5.1.0 adds a CUDA backend; or via ORT GPU providers	Through execution providers	Depends on the runtime used
Licence	Apache-2.0	See its page	See its page

In the Python image stack, Pillow and scikit-image are the usual alternatives for pure image manipulation. OpenCV's own migration guide treats Pillow as a reference point: 5.0's nearest-neighbour resize was changed to match Pillow output pixel for pixel. Pillow is lighter for format conversion and thumbnails; scikit-image leans on NumPy and SciPy and suits research code. OpenCV is the one that also covers video capture, camera calibration, real-time feature matching and model inference in one package, at the cost of a large wheel (roughly 35 to 74 MB for 5.0.0.93, depending on platform and variant, per PyPI). For tabular analysis of results produced by OpenCV pipelines, pandas is the natural next step. OpenCV's VLM work is experimental and is not a substitute for dedicated language model servers such as llama.cpp or vLLM.

Limits, trade-offs and when not to use it

The 5.0 migration is not free. C API removal, new module includes, 1D array semantics, the VideoCapture::get() return value change and slightly different warp and nearest-neighbour resize output can all break code or pixel-exact test baselines. Haar and HOG detectors and cv2.ml need contrib builds.
5.0 to 5.1 also moves the DNN API. ENGINE_CLASSIC and ENGINE_NEW exist in 5.0 and are gone in 5.1.0, and readNetFromTensorflow() was removed. Pin versions if you depend on the DNN module.
PyPI wheels are CPU-only. CUDA, OpenVINO or ONNX Runtime integration means building from source or using an opencv-python manual build with custom CMake flags, which the README says can take "anything from 5 minutes to over 2 hours".
One package per environment. Installing opencv-python and opencv-python-headless together causes conflicts because both provide cv2; a transitive dependency pulling the GUI variant into a server image is a common trap.
Not a training framework. The DNN module is for inference. Training stays in PyTorch or similar, and models move over via ONNX.
Overkill for simple jobs. If all you need is resizing uploads or converting formats, a smaller image library is easier to ship.
Non-free algorithms are excluded from wheels. The opencv-python FAQ says patented algorithms such as SURF are not included in the binaries; SIFT has been included since its patent expired (4.3.0 and 3.4.10).
Security of parsers. The 5.1.0 change log contains many fixes for malformed FileStorage, ONNX and TFLite inputs found by fuzzing. Treat untrusted model and image files with care and keep up with releases; vulnerabilities go to [email protected], with a PGP key in SECURITY.md.

Licensing and packaging details

The repository's LICENSE is the Apache License 2.0 on both 5.x and 4.x. The change log for 4.5.0 records that "Starting from OpenCV 4.5.0, all the future OpenCV 4.x and OpenCV 5.x releases will be distributed under Apache 2 license. OpenCV 3.x will keep using BSD." The evolution proposal behind it (OE-32) gives the reason: BSD "says nothing about the patents", and Apache 2's patent grant offers users some protection.

The Python wheels add layers on top. The opencv-python build scripts are MIT-licensed, OpenCV itself is Apache 2, all wheels ship FFmpeg under LGPLv2.1, and non-headless Linux wheels ship Qt 5 under LGPLv3, with the full list in LICENSE-3RD-PARTY.txt. Anyone redistributing the wheels in a product should review those LGPL components; the headless variants avoid Qt but still include FFmpeg. Linux wheels target manylinux2014 (with manylinux_2_28 builds also on PyPI for 5.0.0.93), and the README lists Python 3.7 to 3.14 as supported, using a single abi3 wheel per platform.

Project activity

Checked 15 November 2026: latest release 5.1.0 (5 November 2026, from the git tag and the change log), Apache-2.0, about 91,600 stars on the opencv/opencv repository. The latest 4.x release is 4.14.0 (18 July 2026), and the newest Python wheels on PyPI are 5.0.0.93 and 4.14.0.94. Both branches received commits on 15 November 2026, with the 5.x branch at 5.2.0-dev and 4.x at 4.15.0-dev. The 5.1.0 change log credits 174 contributors to the main repository since 5.0.0. The project is written mainly in C++, development happens on GitHub with pull requests targeted at 5.x by default, questions go to forum.opencv.org, and the documentation lives at docs.opencv.org.