upvote

points

by Joel_Mckay5 hours ago |
comments
upvoteby markusMB3 hours ago|
next
[-]
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 ;-)

reply
upvoteby Joel_Mckay2 hours ago|
parent|
[-]
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

reply
upvoteby Sesse__3 hours ago|
prev|
next
[-]
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).
reply
upvoteby Joel_Mckay3 hours ago|
parent|
[-]
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

reply
upvoteby harrall4 hours ago|
prev|
next
[-]
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.

reply
upvoteby Joel_Mckay2 hours ago|
parent|
[-]
One can... and should report when stuff is broken, or the project becomes worthless to all but one persons passing interest. =3
reply
upvoteby ranit1 hours ago|
prev|
[-]
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?

reply
upvoteby zdkl1 hours ago|
parent|
[-]
Well I've deployed OpenCV based pipelines in academic contexts for site surveys and photogrammetry.
reply