Opened 9 years ago

Last modified 2 years ago

#49670 assigned enhancement

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

Reported by: macports@… Owned by: mascguy (Christopher Nielsen)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: cooljeanius (Eric Gallager)
Port: opencv

Description

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.

Change History (16)

comment:1 Changed 9 years ago by mf2k (Frank Schima)

Owner: changed from macports-tickets@… to stromnov@…
Type: defectenhancement
Version: 2.3.4

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

comment:2 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

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

comment:3 Changed 4 years ago by mascguy (Christopher Nielsen)

Is there still a need for opencv2?

comment:4 Changed 4 years ago by mf2k (Frank Schima)

Owner: changed from stromnov to mascguy
Status: newassigned

comment:5 Changed 4 years ago by 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.

comment:6 Changed 4 years ago by 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.

Last edited 4 years ago by mascguy (Christopher Nielsen) (previous) (diff)

comment:7 Changed 4 years ago by mascguy (Christopher Nielsen)

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

comment:8 Changed 4 years ago by Christopher Nielsen <mascguy@…>

In 1a1ad1dde0f1ed1a99f5bf431a30fa7eeaa269d0/macports-ports (master):

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

See: #62011
See: #49670

comment:9 Changed 4 years ago by 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

comment:10 Changed 4 years ago by Christopher Nielsen <mascguy@…>

In 342f7793397fe4c31b2c032c2e82a23008e5106e/macports-ports (master):

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

See: #62011
See: #49670

comment:11 Changed 3 years ago by 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

comment:12 in reply to:  11 Changed 3 years ago by 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?

Last edited 3 years ago by mascguy (Christopher Nielsen) (previous) (diff)

comment:13 Changed 3 years ago by 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!

comment:14 Changed 3 years ago by 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

comment:15 in reply to:  14 Changed 3 years ago by 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?

comment:16 Changed 2 years ago by cooljeanius (Eric Gallager)

Cc: cooljeanius added
Note: See TracTickets for help on using tickets.