However, it has a few issues:
1. Patented algorithms that are effectively impossible to license in a commercial setting.
2. Permuted API that change how identically named functions behave over versions.
3. Hardware CUDA version coupling deprecating support every major release.
4. Inconsistent and contradictory documentation in the constant subtle permutations. Downstream projects tend to version lock the lib for really practical reasons.
5. A shift away from core C libraries like ImageMagick & V4l, and into C++ abstractions with legacy Swig wrapper libraries in Java or Python.
6. Perpetual-Beta culture means the library will unlikely ever really fully stabilize.
It is a fun library, until people actually try to deploy something serious. As users will often simply suggest using an old version release if there is a bug.
Everything from Build flags to the API documentation has never fully stabilized. ymmv =3
But I can’t really complain because it’s open source and added to by contributors.
To enable Intel TBB, CUDA, and CPU specific compiler optimizations... one will almost certainly need to re-build the library, and customize your application build.
Some tasks degrade in performance on a GPU, and others are 740 times faster... ymmv. =3
Individual image processing operations are often very low arithmetic intensity. If you don't combine them into much larger subroutines—which are necessarily less generic and orthogonal—you spend all your time waiting on memory between every little op.
Our problem domains must obviously differ. Good luck =3
- OpenCV is Apache license. Yes, it used to be more complicated.
- The only patented algorithm I am aware of, SIFT, used to be part of opencv_contrib. And the README in opencv_contrib would greet you with a warning, that the code may not be fit commercial use for various reasons. Only when the patent expired, it was moved into OpenCV core.
- Same observation for Aruco marker detection, which was in contrib for a long time because the options to choose from were either not-well-maintained or GPL-licensed code. It is now in core OpenCV (and Apache).
- Despite its age, I think that OpenCV is still more than relevant today. And being part of modern languages like C++, Swig, Java and Python (and for years already) is part of that. Still I was surprised how long they maintained OpenCV 2 and 3.
- Over the past releases and few years, my impression was actually that core API was very much stable(izing). Cant say what happened in contrib – or what it feels like when you treat core and contribute as one and a feature progressed from contributing to core.
- I do agree, that I usually I would check that a MINOR releases wasnt actually a MAJOR release, breaking some API or behavior I was relying on. I am hoping that Version 5 is pulling the ambitions for making things differently away from Version 4. So v4 can be used stably ;-)
Indeed, if your library dependency constellation works, some will static link to stabilize/freeze their project for more than a few months.
It wasn't that v3 was particularly good, but rather v4 was a mess. I predict v5 inherited that mess, and improved it... lol =3
> 1. Patented algorithms that are effectively impossible to license in a commercial setting.
then does anyone know how "OpenCV has been the foundation of countless production systems" is possible, as the OP article claims?
I discovered that while porting it to a Pi ARM platform years ago (yes it was slow... lol.) Forgot when the IP becomes public domain, but you might want to check that out. If I recall it was unrelated to the COLMAP project design. =3
https://github.com/openMVG/openMVG/blob/develop/COPYRIGHT.md
https://github.com/cdcseacave/openMVS/blob/master/COPYRIGHT....
Personally, I recommend COLMAP + CloudCompare + MeshLab, but the Mozilla Public License 2.0 should address IP license issues if the author is also the rights holder. Keep in mind all work done by University Students and Staff is often property of the institution unless otherwise stated. It is a delicate subject.
Best of luck =3
https://github.com/alicevision/AliceVision https://github.com/alicevision/Meshroom
No affiliation, just an excellent tool
However, until each code area turns 17/21 no one knows for sure. It just looks normal at first, and $12k cheaper than MatLab server host licenses. =3
In all honesty, opencv has stood the test of time and I’m certain newer LLMs will likely not attempt to rewrite it from scratch.
P.S. I’ve been a user since the IplImage days, circa 2007, and I’d still consider using it over most CV libraries today.
Sooner or later a Rust developer will try.
But not for saving video. That fourcc pile of crap doesn't open up in QuickTime player, the default Ubuntu video player, or anything anybody actually uses. I've always had to add a os.system("ffmpeg [ask llm to generate the command for you]") afterwards to fix anything that OpenCV generates.