If you have previous/other manually installed (= not installed via pip) version of OpenCV installed (e.g. cv2 module in the root of Python's site-packages), remove it before installation to avoid conflicts.
Make sure that your pip version is up-to-date (19.3 is the minimum supported version): pip install --upgrade pip. Check version with pip -V. For example Linux distributions ship usually with very old pip versions which cause a lot of unexpected problems especially with the manylinux format.
There are four different packages (see options 1, 2, 3 and 4 below) and you should SELECT ONLY ONE OF THEM. Do not install multiple different packages in the same environment. There is no plugin architecture: all the packages use the same namespace (cv2). If you installed multiple different packages in the same environment, uninstall them all with pip uninstall and reinstall only one package.
These packages are smaller than the two other packages above because they do not contain any GUI functionality (not compiled with Qt / other GUI components). This means that the packages avoid a heavy dependency chain to X11 libraries and you will have for example smaller Docker images as a result. You should always use these packages if you do not use cv2.imshow et al. or you are using some other package (such as PyQt) than OpenCV to create your GUI.
Since opencv-python version 4.3.0.*, manylinux1 wheels were replaced by manylinux2014 wheels. If your pip is too old, it will try to use the new source distribution introduced in 4.3.0.38 to manually build OpenCV because it does not know how to install manylinux2014 wheels. However, source build will also fail because of too old pip because it does not understand build dependencies in pyproject.toml. To use the new manylinux2014 pre-built wheels (or to build from source), your pip version must be >= 19.3. Please upgrade pip with pip install --upgrade pip.
A: If the import fails on Windows, make sure you have Visual C++ redistributable 2015 installed. If you are using older Windows version than Windows 10 and latest system updates are not installed, Universal C Runtime might be also required.
If you have Windows Server 2012+, media DLLs are probably missing too; please install the Feature called "Media Foundation" in the Server Manager. Beware, some posts advise to install "Windows Server Essentials Media Pack", but this one requires the "Windows Server Essentials Experience" role, and this role will deeply affect your Windows Server configuration (by enforcing active directory integration etc.); so just installing the "Media Foundation" should be a safer choice.
If you still encounter the error after you have checked all the previous solutions, download Dependencies and open the cv2.pyd (located usually at C:\Users\username\AppData\Local\Programs\Python\PythonXX\Lib\site-packages\cv2) file with it to debug missing DLL issues.
A: The repository contains only OpenCV-Python package build scripts, but not OpenCV itself. Python bindings for OpenCV are developed in official OpenCV repository and it's the best place to report issues. Also please check OpenCV wiki and the official OpenCV forum before file new bugs.
A: Non-free algorithms such as SURF are not included in these packages because they are patented / non-free and therefore cannot be distributed as built binaries. Note that SIFT is included in the builds due to patent expiration since OpenCV versions 4.3.0 and 3.4.10. See this issue for more info: -python/issues/126
A: It's easier for users to understand opencv-python than cv2 and it makes it easier to find the package with search engines. cv2 (old interface in old OpenCV versions was named as cv) is the name that OpenCV developers chose when they created the binding generators. This is kept as the import name to be consistent with different kind of tutorials around the internet. Changing the import name or behaviour would be also confusing to experienced users who are accustomed to the import cv2.
The project is structured like a normal Python package with a standard setup.py file.The build process for a single entry in the build matrices is as follows (see for example .github/workflows/build_wheels_linux.yml file):
Since OpenCV version 4.3.0, also source distributions are provided in PyPI. This means that if your system is not compatible with any of the wheels in PyPI, pip will attempt to build OpenCV from sources. If you need a OpenCV version which is not available in PyPI as a source distribution, please follow the manual build guidance above instead of this one.
If you need contrib modules or headless version, just change the package name (step 4 in the previous section is not needed). However, any additional CMake flags can be provided via environment variables as described in step 3 of the manual build section. If none are provided, OpenCV's CMake scripts will attempt to find and enable any suitable dependencies. Headless distributions have hard coded CMake flags which disable all possible GUI dependencies.
find_version.py script searches for the version information from OpenCV sources and appends also a revision number specific to this repository to the version string. It saves the version information to version.py file under cv2 in addition to some other flags.
A release is made and uploaded to PyPI when a new tag is pushed to master branch. These tags differentiate packages (this repo might have modifications but OpenCV version stays same) and should be incremented sequentially. In practice, release version numbers look like this:
Linux wheels are built using manylinux2014. These wheels should work out of the box for most of the distros (which use GNU C standard library) out there since they are built against an old version of glibc.
Just doing that got the API working on python-3.8.0 runtime. The libgl1 and such dependencies are for the GUI and GPU centric version that comes with opencv-python. So you can get away with opencv-python-headless or opencv-contrib-python-headless. The only buildpack you need is the heroku/python buildpack.
Python is quite fast as long as you use standard OpenCV or numpy functions. The problem is that it becomes extremely slow when you need to write your own functions, if they contain for loops like:
I agree with @kbarni. Would sum up that you should think about the deployment environment to make a better decision. A few examples: if you have a server application and python performance is good enough, you would be safe with python. On the other hand, IOT, mobile or even desktop apps would benefit the better performance of a fine tunned C++ compiled project. Also, I prefer to deliver C++ binaries to the end user, usually it will be faster, safer and more stable.
both for obfuscation and for optimization, you should look at Cython. it is a language and a compiler/translator. it is a derivative of Python that can be compiled to run as fast as C, if you add appropriate static types the compiler can optimize for. if you have to write your own pixel manipulation loops, use Cython.
C++ is leaking abstractions all over the place. it is high level assembly language. it is what other languages are written in. you should only write C++ if your time as a human being is worth very little or someone pays you for the pain and suffering.
Lol, I like that. Not that I know much about C++, or python, for that matter. But it reminds me of my days doing industrial controls. Once you learned to program Siemens PLCs in statement list (a very simple almost machine code like PLC language) you never wanted to see ladder logic again.
Another point I think has to be made: image processing and computer vision are fields where visualization is critical to every stage of the research and develppment. Using python in Jupyter-Notebooks will make your life much easier. When working with C++, there is a great Visual-Studio plugin called Image-Watch.
I've been developing a real-time augmented-reality type application in Python OpenCV, and had a rather nasty surprise when I switched from my Core i7 development machine to the Atom unit that we wanted to actually use. It turned out to be nowhere near fast enough, giving me 5-10 fps where it would easily keep up with 30 fps videos on the i7.
So my question is whether porting my application to C would help at all, or if it's just that OpenCV can't handle this kind of application. When I put my app through the Python profiler almost all of the time was being spent in cv calls, and waitKey was also taking forever. Should I just give up and look at something like Halcon?
Coding in C gives zero advantage over C++, but it may give a boost over Python. The profiler will tell you exactly how much you can gain. You will have a gain if some of the processing is done in python, bu custom code, but the OpenCV calls, as Alexander S. said, are the same.
Finally, the problem is not OpenCV, but the way you are using it. I've wrote complex processing that takes 3ms on a mobile processors, and saw others do the same - the price is a hard work in optimization. Take this post as an introduction to a more serious approach to optimization. On Intel chips you have SSE instructions instead of the NEON technology found on ARM devices.
It's always worth take a look at optimizations. Maybe in your case SSE or NEON is an overkill, but you may improve the algorithm by simple means - like reducing the image resolution before any other processing takes place.
All modern code in OpenCV library is written on C++, but there are light-weight wrappers for C and Python. So these languages are very similar from optimization point of view. So you should special optimization techniques for getting fast code. Try to use SSE instructions, add parallel code, ...
In other words, there is no sense in porting Python code to the C++. OpenCV doesn't work at Python level, it simply calls C++ function, and all the pixels processing happens on native level. And the amount of work on the native level is much larger than on the Python level, because we usually process millions of pixels. BTW, that's why you can program with OpenCV in Java on Android - because everything is calculated on the native level. Thus, if somebody wants to optimize the code, just find which C++ function consumes the most time, and optimize it. And finally you can call your optimized version from Python, because the call is cheap in comparison to processing time :)
7fc3f7cf58