Continuing my exploration of image processing, I found opencv. The examples given there are impressive. So, I decided to install opencv.
Im running 64-bit Windows7, and since I’m a grumpy old man, I don’t run Visual Studio, Eclipse or any other sissy IDE – I run barebones, cygwin shell, gcc & emacs, like any old real programmer (Vi is also OK).
However, as far as I can tell (and I could be wrong, but this is my impression after having spent 7(!) hours in getting opencv finally up & running on my environment) the instructions I’ve been able to find on how to get opencv running on my setup have not been exactly comprehensive: I’ve learned a few useful tidbits of info from here and there, e.g. here and here, but frankly, it was a pain in the butt to get opencv running in my environment. But now, I’m finally able to hack c++, calling opencv functions. I’m still not able to do what I really wanted to do, that is, call opencv functions from Python, but I’ll leave that for some other day….
Anyways, I thought I’d document what I did to get opencv to run on my environment – perhaps these few lines of info can spare a hacker pal out there from hours of trial&error….:
1) after downloading the binary distribution, I couldn’t find any way to get things to work, so I decided to build opencv from the sources.
2) starting cmake-gui from cygwin shell, after selecting the source and target dir’s, I used the default config, i.e. the one where cmake figures out what compiler etc I have running.
3) cmake reported a lot of problems (in red), but I didn’t care, pressed ‘configuration’ (or whatever it is called).
4) in a cygwin shell, going to the target dir, I hit make. The build started running
5) after 14%, the build failed, because the compiler reported that the file system.cpp in modules/core/src had a call to an unknown function close(fd). Giving a quick look at the call, I decided to comment out the call (probably not a good thing, but anyway), and rebuilding. If I’d been seriously interested, I’d have spent some time figuring out why the compiler didn’t accept the close() call.
6) the build now continued to some 50%.
7) then, there were two files, one of them calibfilter.cpp (the other I’ve forgotten, but look at your compiler error msg), where the compiler reported that ‘quad’ was undefined. Indeed it was, with a #undef quad. Commenting away that preprocessor directive made the build to go on. Again, probably not a safe move, but it made the build to proceed.
8) the build now stopped at the file imagestorage.h, because ‘datatype FILE’ was undefined. I added includes to <stdio.h> and <stdlib.h> and the build continued.
9) after building the opencv libs, and successfully running most of the included test.exe’s, I wanted to try a cpp program of my own exercising opencv. It failed immediately. First, because missing headers. It took me a while to figure out what -I directive to include in the g++ command, turned out it was not to the <include> directory in the target (build) area, but instead in the area where I ‘unzipped’ the opencv download… i
n my case, the -I path was : /cygdrive/c/User/Downloads/opencv/build/include, that is, the directory where I downloaded the distribution.
10) Now, compiling with g++ -c, i.e just compiling, no linking, of my test app, succeeded. But trying to build an executable still failed.
11) After some increasingly desperate hacking, and googling, I somehow found these settings to make building the test executable succeed:
g++ obj_detect.cpp -I /cygdrive/c/Users/Downloads/opencv/build/include -L/cygdrive/c/Users/Downloads/opencv/build/x64/vc12/lib -L/cygdrive/c/NEW/opencv/lib -lopencv_core -lopencv_highgui -lopencv_objdetect -lopencv_imgproc -o objdetect
That is, by explicitly adding all the necessary dll’s, specified by the -l directives, residing in the libraries specified by the -L directives, I managed to build my own test-app (objdetect).
12) now, with an opencv test hack finally successfully built, I’m trying to execute the generated executable, ‘objdetect’, only to get the message
cannot open shared object file: No such file or directory
After some head-scratching, I add the location of the opensv target bin directory to my PATH env variable, and voila’ – all of sudden my test program works!
So, after 7 hours of intense trial & error I’m now able to hack C++ calling opencv services. I’m still not able to do what I really wanted to do, calling opencv from Python, but I’ll have a deeper look at that later.
Now, it’s almost 20 years since I spent any serious, professional time on configuring computer environments over and above what is necessary for getting a new laptop to work, but still, I like to think I know a thing or two about computers, configurations and build error messages. If it takes me 7 hours of intense hacking to get a software package running on a fairly typical configuration, such as Windows 7/Cygwin 64, I’m worried that a lot of people interested in using the package (opencv, in this case), will give up, long before they’ve figured out how to get the package operational.
Now, I don’t want to throw any crap at all on the developer’s of opencv – on the contrary: those guys have produced an impressive library of very advanced functionality, all cudos to them. But my point is that it’s far from easy to get that great functionality to execute, unless you are running on a ‘vanilla’ installation. Perhaps my installation was a mess, I don’t know. But still, comparing to the ease of Python’s pip install, or Apple’s appstore, getting opencv to run on my environment was a pain.