OpenCV 2.x (please re-instate or provide a new opencv2 port)

[macports@…]

The opencv port was upgraded to 3.0.0 from 2.4.11 in Ticket #45203 in June this year (a week or so after the 3.0.0 release), removing the ability to build 2.4

I don't understand why the decision was made to replace/remove 2.4, because it looks like 3.x differs in ways that break some code/projects reliant on the 2.x API or libraries (tickets #48081 #48067 for example, see also ​http://docs.opencv.org/master/db/dfa/tutorial_transition_guide.html#gsc.tab=0).

Could we please have separate ports for 2.4 and 3.0 for those with projects that rely on one or the other? (even if they're incompatible with each other, *some* way of accessing the 2.x port would be helpful). It has only been a few months since the 3.0 release and I suspect many projects haven't had sufficient time to establish 3.0 compatibility (including one I work on but am not in a position to patch for OpenCV 3.x).

A quick check of the Portfiles mentioning opencv suggests it might be worth checking which version of the following ports are definitely compatible with 3.0, in case any more of them are broken by the change:

• aqua/nomacs
• gis/orfeotoolbox
• gnome/gstreamer010-gst-plugins-bad
• gnome/gstreamer1-gst-plugins-bad (comment in the Portfile suggests >= 2.0 and <= 2.5)
• graphics/objectmarker
• kde/digikam (issue #48081 says it won't build with 3.0)
• math/caffe
• multimedia/VLC
• multimedia/VLC-devel
• science/gerbil
• science/gmic
• x11/auto-multiple-choice

Note that #48067 requests updates to many of the above for the changed library names, but I think there are *also* be differences in API.

[mf2k (Frank Schima)]

In the future, please Cc the port maintainers (port info --maintainers opencv), if any.

[ryandesign (Ryan Carsten Schmidt)]

The need for an opencv2 port was reiterated in #50733.

[mascguy (Christopher Nielsen)]

Is there still a need for opencv2?

[mascguy (Christopher Nielsen)]

This will be fairly easy, as we can use the same strategy vis-a-vis OpenCV 4: Ensure everything is installed in subdirs, to allow peaceful coexistence.

I'll add this to my to-do list.

[mascguy (Christopher Nielsen)]

This change will necessitate moving OpenCV 3 headers and libs down a level, into ${prefix}/include/opencv3 and ${prefix}/lib/opencv3. And as part of this change, I'll be renaming port opencv to opencv3, to eliminate confusion. (There's an open ticket related to merging the opencv-related portfiles, and switching to subports. That will also be included in this effort.)

The handful of ports that depend on OpenCV 3, will be updated as appropriate.

None of this is a big deal, but just an FYI for anyone interested. Thoughts/comments welcome, as always.

[mascguy (Christopher Nielsen)]

FYI, progress is being made on this front. Details in ticket: issue:62011

[Christopher Nielsen <mascguy@…>]

In 1a1ad1dde0f1ed1a99f5bf431a30fa7eeaa269d0/macports-ports (master):

opencv3: new port to replace opencv, with opencv4-style isolation

See: #62011
See: #49670

[Christopher Nielsen <mascguy@…>]

In c5179d799bbe7a1154b5e2d82f927c24f6cbc404/macports-ports (master):

opencv3: migrate python bindings to subports; refine file layout, for consistency with opencv4

See: #62011
See: #49670

[Christopher Nielsen <mascguy@…>]

In 342f7793397fe4c31b2c032c2e82a23008e5106e/macports-ports (master):

opencv4: cleanup python subports; refine file layout, for consistency with opencv3

See: #62011
See: #49670

[mascguy (Christopher Nielsen)]

FYI, making progress on this. Using the last OpenCV 2 port as a starting point, and updating it to be segregated like opencv3 and opencv4, I have a near-working opencv2.

But there's one fly in the ointment: It depends on QTKit headers not available on newer MacOS releases. And thus far, I haven't found an acceptable workaround.

Grabbing those headers from an older MacOS SDK, and copying them into the port's source tree, fixes the problem. But that's not a great solution. (And could be problematic from a licensing perspective, though that's not confirmed.)

Regardless, for anyone interested, the work-in-progress is located here:

​https://github.com/mascguy/macports-ports/tree/mascguy-opencv2

[mascguy (Christopher Nielsen)]

But there's one fly in the ointment: It depends on QTKit headers not available on newer MacOS releases. And thus far, I haven't found an acceptable workaround.

Grabbing those headers from an older MacOS SDK, and copying them into the port's source tree, fixes the problem. But that's not a great solution. (And could be problematic from a licensing perspective, though that's not confirmed.)

I'm interested in folks' thoughts/guidance on this. In particular, can the QTKit headers be included in the port - perhaps via a compressed tar file - and used during the build phase?

I'm not asking from a technical perspective, as that's the easy part. Instead, I'm concerned about the legality of doing that. Can we include those with the port - and use them at build time - without issue?

[mascguy (Christopher Nielsen)]

Per @rjvb, relative to use of headers: comment:15:ticket:63741:

I'm pretty certain they're available for download from other places, aside from Apple's servers. Going out on a limb I'd say there are no problems as long as you include the proper licensing info, and use them only on Apple hardware to build software that will run on Apple hardware.

So it looks like header use/inclusion isn't an issue. Beautiful!

[RJVB (René Bertin)]

Just how hard and extensive is that dependency on QTKit on Mac? Evidently that SDK was never available on other platforms. And what if you were to provide a port:QTKit ... would it be functional on systems where it is no longer included?

(That last question should be answerable by checking if applications using QTKit still run on those newer systems.)

Have you looked if anyone wrote a QTKit replacement built on modern foundations? Back when the QT SDK was being deprecated (and I was still using it) I started looking into QtAV but for this you'd ideally want something built on AVFoundation I suppose.

CF: ​https://stackoverflow.com/questions/39735485/opencv-installation-failure-due-to-qtkit

[mascguy (Christopher Nielsen)]

Replying to RJVB:

Just how hard and extensive is that dependency on QTKit on Mac? Evidently that SDK was never available on other platforms. And what if you were to provide a port:QTKit ... would it be functional on systems where it is no longer included?

(That last question should be answerable by checking if applications using QTKit still run on those newer systems.)

Have you looked if anyone wrote a QTKit replacement built on modern foundations? Back when the QT SDK was being deprecated (and I was still using it) I started looking into QtAV but for this you'd ideally want something built on AVFoundation I suppose.

CF: ​https://stackoverflow.com/questions/39735485/opencv-installation-failure-due-to-qtkit

Based on my previous research, the vast majority of suggestions related to grabbing the headers from an older SDK, and building against those. So that was the approach I settled on, though I'm not married to it.

And while we could potentially add a 2nd port for the headers, I was hoping to avoid that. Particularly if Ryan creates ports for the various macOS SDKs, as then we could potentially depend on those (when needed).

The suggestion relative to QtAV is interesting, for sure. Though it looks a bit heavyweight, as we really just need the headers.

Does that make sense? Your thoughts?