Also, performance is generally pretty low; I've been on projects where we rewrote OpenCV code into more-or-less obvious hand-rolled code and won 5x perf. The abstractions are generally a bit too thick and oriented around single pixels (which also makes the API a bit too verbose for my taste).

Machine vision has always been resource intensive... and if you are doing trained ML projects the hardware choices are actually very limited.

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

It's not that you need to turn on some extra library backends and rebuild, it's that the abstractions themselves are fundamentally at odds with hitting peak performance on many things so you have to rewrite your code.

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.

> It's not that you need to turn on some extra library backends and rebuild

Our problem domains must obviously differ. Good luck =3

Agree with this too. OpenCV is functionality great but its constituent parts are written by many different people who all kind of do things a little differently and it shows.

But I can’t really complain because it’s open source and added to by contributors.

One can... and should report when stuff is broken, or the project becomes worthless to all but one persons passing interest. =3

Done a few projects with OpenCV myself, and your list of issues reads as if you throw OpenCV and opencv_contrib into the same bucket. Which you shouldnt. And maybe your assessment is outdated here and there and it is time to look again.

- 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 ;-)

My point was the release numbers are meaningless, as there is always something subtly broken even in the packaged versions. One can't just use the library beyond basic functionality without becoming involved in the code base.

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

If this is a fact:

> 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?

Well I've deployed OpenCV based pipelines in academic contexts for site surveys and photogrammetry.

There is a CLI photogrammetry OSS project with rather litigious faculty members behind the code. However, at least that group was upfront about what was expected of the library users, and didn't do something dodgy like quietly merge it into another community library like OpenCV.

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

They wouldn't happen to be french cartography would they?

These should help narrow down the search, but ibfs commercial restrictions are now 404... and the original IP warnings seem missing/expired.

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

Thank you for the recommendations, I'll return one myself:

https://github.com/alicevision/AliceVision https://github.com/alicevision/Meshroom

No affiliation, just an excellent tool

One can legally use/static-link OpenCV in most commercial projects, and there were only a few legal landmines people still try to document when possible.

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

Software patents aren't a thing in most of the world

Yup, it's basically the ROS of computer-vision.

vision_opencv has been part of ROS for a long time. Mind you many popular projects get integrated into ROS eventually. =3