# OpenCV's default branch is still 4.x, and its own docs link points at 5.x > OpenCV is a C++ computer vision library with bindings for Python, Java and others, and the repository is best understood by its directory layout: modules/ for the algorithms, hal/ for hardware acceleration, samples/ for the build targets it supports. Its README is 180 words of links, so the useful facts live in the branch names and the file tree. **opencv/opencv** — OpenCV provides image processing, video analysis, object detection, camera calibration, and machine-learning algorithms through C++, Python, Java, and other language bindings. - Repository: https://github.com/opencv/opencv - Website: https://opencv.org - Stars: 91,011 · Forks: 57,045 - Language: C++ - License: Apache-2.0 - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/opencv-opencv ## The default branch is 4.x while 5.0.0 has been out since June 2026 The repository's default branch is `4.x`. Releases tell a different story: 4.13.0 on 2025-12-31, 5.0.0 on 2026-06-06, and 4.14.0 on 2026-07-19. So a major version shipped in the middle of that sequence and the 4.x line kept receiving releases afterwards, which is why the default branch is still 4.x rather than 5.x. That matters more than it first appears, because the documentation link in the README points somewhere else entirely. The docs URL is `https://docs.opencv.org/5.x/`, so the reference you are told to read describes 5.x while the code you get from a plain clone is 4.x. The project is not confused about this: one of its stated contribution rules is to choose the right base branch, which only makes sense if several are live and in use. The consequence for an adopter is that you cannot let the defaults decide. Decide the major version first, then read the matching reference, because a function signature that moved between 4.x and 5.x will look correct in one set of docs and fail against the other. The last push to the repository was on 2026-09-29, so both lines are being worked on. ## opencv_contrib is a separate repository, so a clone is not the whole library One line in the README does more to shape expectations than any amount of prose could: additional OpenCV functionality lives at `github.com/opencv/opencv_contrib`. The main repository is the core, and a meaningful set of modules is maintained somewhere else. The consequence is practical and immediate. A clone of `opencv/opencv` does not contain everything people mean by OpenCV, so a tutorial that uses a contrib module will fail to build against a core checkout with an include error rather than a helpful message. You also inherit two release histories instead of one, and the version numbers of the two repositories are not a single coordinated number, so "upgrade OpenCV" is ambiguous about which of them you are upgrading. Whether to depend on contrib at all is a judgement worth making deliberately. It is the place to look for the newer and less settled algorithms, and the place where your build is most likely to change under you between releases. If your work only needs the core, staying inside the Apache-2.0 core repository keeps your dependency surface smaller and your upgrade decisions simpler. ## hal/ sits beside modules/, which makes acceleration a build decision The top-level layout separates concerns that other libraries interleave. `modules/` holds the algorithms, `include/` the public headers, `hal/` a hardware acceleration layer as a directory in its own right, `3rdparty/` the bundled third-party code, `cmake/` the build system, `platforms/` the platform-specific pieces, `apps/` ready-made applications and `data/` for the data files the algorithms load. `hal/` having its own top-level entry is the informative part. Acceleration is not sprinkled through the algorithm code, it is a layer the build can be pointed at, which is what lets the same module run on a CPU, a GPU or a vendor device depending on configuration. The sample tree backs this up, since it contains both `samples/gpu/` and `samples/hal/` alongside vendor-specific paths such as `samples/va_intel/` and `samples/sycl/`. The consequence for a user is that performance is chosen at configure time rather than at runtime, and the repository does not document which backends are available on which host. You find that out by building and reading the configuration output, not by reading a support matrix. If you are deploying to constrained hardware, budget time for that discovery, because the layer exists precisely to give you options and the README does not enumerate them. ## samples/ enumerates the build targets more honestly than any feature list The `samples/` directory is the closest thing the repository has to a capability list, and it is more informative than the project description because it is what is actually wired into the build. Directories cover `android/`, `cpp/`, `directx/`, `dnn/`, `gdb/`, `gpu/`, `hal/`, `java/`, `opencl/`, `opengl/`, `openvx/`, `python/`, `semihosting/`, `swift/`, `sycl/`, `tapi/`, `va_intel/` and `winrt/`, with `install/`, `data/` and the build glue alongside them. Read that as a statement about the range of the build rather than about the library. The presence of a `sycl/` and a `va_intel/` path says the acceleration layer has more than one vendor story, the presence of `dnn/` says the deep learning inference side is a first-class sample target, and the four mobile and desktop UI paths say the same tree has to serve Android, iOS, Windows and the web. The consequence is that the supported-target question is answerable from the tree, while the "which target works on my host" question is not. The samples also carry their own build files, `samples/CMakeLists.txt` and `samples/samples_utils.cmake`, plus Windows helper scripts, which is where to look when you want a working example rather than an API signature. ## The README is 180 words of links, and there is no install command in it Worth saying directly, because it shapes how you should approach the project: the README is a short list of URLs. It points to the homepage at opencv.org, to courses, to the documentation, to the Q&A forum, to issue tracking, to the contrib repository and to a donation page. It contains no build instructions, no installation command, no package names and no API overview. So if you arrived looking for the one command that installs OpenCV, the repository will not give it to you, and the honest answer is to go to the sources it names rather than to guess. The documentation site carries the API reference for the version you care about, the homepage is the entry point for the official distribution channels, and the forum at forum.opencv.org is where questions get answered. There is a second-order consequence worth planning for. Because the reference is versioned by URL, a search result or a copied snippet can easily point at a different major version than the one you built, and nothing in the snippet tells you which. Treat every fragment you find as version-relative and check the URL before you trust it. ## The old Q&A archive is frozen, so old answers describe versions long gone The README lists two forums. The current one is at forum.opencv.org. The previous one, at answers.opencv.org, is marked as read only. Both are still linked, which is generous for anyone with a decade of saved links, and it creates a specific hazard. A read-only archive is frozen at whatever version was current when it was retired. Answers there were written against 3.x and early 4.x code, and a question that reads as settled may be settled for an API that has since moved or been replaced. Because the archive is still indexed and still linked from the current README, search results mix the two freely, and nothing on the page itself tells you how old the answer is. The consequence is that forum answers are a good way to find the right question and a poor way to find the right code. Take the problem statement from either archive, then confirm the signature against the documentation for the branch you actually built. For anything load-bearing, the issue tracker on GitHub is the place where the answer is tied to the code that exists. ## One pull request per issue, with tests and documentation included The contribution guidelines are summarised in the README, and the summary is short enough to quote in full: one pull request per issue, choose the right base branch, include tests and documentation, clean up oops commits before submitting, and follow the coding style guide. The wiki pages for how to contribute and for coding style are where the detail lives. For a user this is mostly governance trivia, with one exception that matters. Requiring tests and documentation in the same change is what keeps a twenty-year-old C++ library's reference documentation honest, and it is why the docs site can be treated as authoritative for a given version. It also means a change you want has to clear a bar, so the timeline from issue to release is longer than a project without that rule. The base branch rule is the one to keep in mind when you open an issue or a patch. With 4.x and 5.x both receiving releases, a patch opened against the wrong line can be correct and still be unusable, so name the branch you built from when you file it. The repository also carries a `SECURITY.md` and a `CONTRIBUTING.md` at the top level, alongside the Apache-2.0 `LICENSE` and a `COPYRIGHT` file. ## Conclusion OpenCV is worth learning if you want the algorithms and the acceleration layer in one place and you are willing to read the API reference rather than a tutorial, because the project ships bindings, courses, a forum and a per-language sample tree but no narrative documentation in the repository itself. Two things decide whether it fits: whether you can pin a major version deliberately, since the default branch is 4.x while the documentation link is 5.x, and whether you accept that substantial functionality lives in the separate opencv_contrib repository. Check the branch you are about to build and the module list before you commit to it. ## FAQ ### Is OpenCV still relevant? The repository is not dormant: the last push was on 2026-09-29, and releases include OpenCV 4.14.0 from 2026-07-19, OpenCV 5.0.0 from 2026-06-06 and OpenCV 4.13.0 from 2025-12-31. The project describes coverage of image processing, video analysis, object detection, camera calibration and machine-learning algorithms through C++, Python, Java and other language bindings. ### Is OpenCV worth learning? That depends on what you need it for. The project ships per-language sample trees for C++, Python, Java, Swift and Android, a hardware acceleration layer under hal/, and it publishes courses and a Q&A forum. Note that substantial additional functionality lives in the separate opencv_contrib repository, and that the default branch is 4.x while the documentation link is 5.x. ### How do I install OpenCV for Python? The repository does not include an installation command. Its README is a list of links that points to the homepage at opencv.org, the documentation at docs.opencv.org/5.x/, the Q&A forum and the issue tracker, and the build system lives in the CMakeLists.txt and cmake/ directory at the top level of the source tree. ### How do I use OpenCV? Start from the versioned documentation at docs.opencv.org/5.x/ for the API reference, and from samples/ in the repository for working examples, which are split into cpp/, python/, java/, dnn/, gpu/, hal/ and vendor paths such as sycl/ and va_intel/. The public headers are under include/ and the algorithms under modules/. ### Which is better, YOLO or OpenCV? The repository does not document a comparison with YOLO. What it records about itself is that object detection and machine-learning algorithms are part of its scope, that there is a dnn/ sample target, and that additional functionality is maintained in the separate opencv_contrib repository, which is where a detector that is not in the core would be looked for. ## Sources - [Official documentation](https://opencv.org) - [Official README](https://github.com/opencv/opencv#readme) - [Project repository](https://github.com/opencv/opencv) - [Release notes](https://github.com/opencv/opencv/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/opencv-opencv