Strike that last. The name of the library being searched is libippicv.a, and that name only exists under opencv's 3rdparty directory tree, so link-line library ordering isnt the problem.

Mine is:

IPPICV_INSTALL_PATH:INTERNAL=/home/dan/testoc3/opencv-3.1.0/testinstall/share/OpenCV/3rdparty/lib/libippicv.a
IPPICV_LOCATION_PATH:INTERNAL=/home/dan/testoc3/opencv-3.1.0/3rdparty/ippicv/unpack/ippicv_lnx/lib/intel64/libippicv.a

which is where the ippicv stuff was put when it unzip'd.

Could this problem have something to do with the fact that I had IPP installed already, and those libraries are in my LIBRARY_PATH. Perhaps the system libraries are being found before the OpenCV supplied libraries during link?

Steven,

Thanks for the feedback. The length of my post was to provide all the details I thought might be pertinent to my issue, and also to show that I made some attempt to solve the problem myself. Because of its length I tried to separate it into summary/details sections.

As far as config goes, I dont know the totality of what you might want. I'm using:

• gcc/g++ 4.8.5 20150623
• CentOS 7 (though as I mentioned in my, admittedly long, post I dont think this plays)
• cmake 2.8.11
• uname -a returns:
  3.10.0-327.3.1.el7.x86_64 #1 SMP Wed Dec 9 14:09:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
• Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz, 64GB RAM

Do you need my version_string.temp, or anything else?

I tried both the version of OpenCV off the website and from git. If the website version isn't valid/recommended, then it should be removed.

Here's my commands (after unziping opencv from git repository):

• mkdir testbuild
• mkdir testinstall
• cd testbuild
• cmake -DCMAKE_BUILD_TYPE=RELEASE -DCMAKE_INSTALL_PREFIX=/home/dan/testoc3/opencv-3.1.0/testinstall ..
• make -j8 (though just make fails too)

Result: [ 45%] Building CXX object modules/features2d/CMakeFiles/opencv_features2d.dir/src/fast_score.cpp.o ../../lib/libopencv_core.a(matrix.cpp.o): In function reduceMinC32f(cv::Mat const&, cv::Mat&)': matrix.cpp:(.text._ZL13reduceMinC32fRKN2cv3MatERS0_+0x33d): undefined reference toippiMin_32f_C1R' ../../lib/libopencv_core.a(matrix.cpp.o): In function reduceMinC16s(cv::Mat const&, cv::Mat&)': matrix.cpp:(.text._ZL13reduceMinC16sRKN2cv3MatERS0_+0x45b): undefined reference toippiMin_16s_C1R' ../../lib/libopencv_core.a(matrix.cpp.o): In function reduceMinC16u(cv::Mat const&, cv::Mat&)': matrix.cpp:(.text._ZL13reduceMinC16uRKN2cv3MatERS0_+0x45b): undefined reference toippiMin_16u_C1R' ../../lib/libopencv_core.a(matrix.cpp.o): In function reduceMinC8u(cv::Mat const&, cv::Mat&)': matrix.cpp:(.text._ZL12reduceMinC8uRKN2cv3MatERS0_+0x65b): undefined reference toippiMin_8u_C1R' ../../lib/libopencv_core.a(matrix.cpp.o): In function reduceMaxC32f(cv::Mat const&, cv::Mat&)': matrix.cpp:(.text._ZL13reduceMaxC32fRKN2cv3MatERS0_+0x33d): undefined reference toippiMax_32f_C1R'

and tons more errors like them.

A google search on this issue gets very few hits, but the ones I could find appear to me to be either unsanswered or suggesting turning IPP off

Neither seemed right to me.

I had purchased the intel compiler, and have IPP from that. The rest of the post was what I had to do to get opencv3 to build with a pre-installed version of IPP.

If you need further information from me, please let me know.

I see differences in the Dual TVL1 optical flow algorithm between v2.4.11 and v.3.1. I was wondering if anyone has noticed the same problem, and had an explanation.

I've slightly modified the example code in samples/gpu/optical_flow.cpp. Specifically, I've replaced the hardcoded images to be compared (basketball1.png, pasketball2.png) with the ability to provide a video source file, and a frame # within that file (then consecutive frames are used as input).

I have visually inspected 2.4.11's modules/gpu/src/tvl1flow.cpp and 3.1's modules/cudaoptflow/src/tvl1flow.cpp and I dont see anything different (this is NOT the CUDA code).

I have noticed that in 2.4.11, the TVL1 and Brox outputs are almost indistinguishable, but in 3.1 they are very different. Also in 2.4.11 TVL1 and Brox runtimes are very close (on my machine ~.3s and .35s respectively), but in 3.1 they are a good deal different (~1.8s and .35s). The Bronx runtime remains the between opencv versions, but TVL1 is ~6x longer.

Might it be that in 2.4.11 the TVL1 was really running the Brox algorithm "under the covers"???

Source Images:

TVL1 Difference. Left is 2.4.11, right is 3.1. Left looks just like Brox, and for these images appears to be more accurate (subjectively)