One of the things I needed to do a few months ago, was a complete reinstall of software on a computer which was named ‘Phoenix’, but which had suffered from a hard-drive controller failure, so that it needed to be resurrected as the computer ‘Phosphene’. Both times that hardware had Debian / Stretch installed, even though the first time it was not an official Kanotix install. The second time it was.
When I need to reinstall the O/S, I also need to install much software again. And one piece of software which I’ve been focusing on somewhat in recent days, is “OpenCV“.
‘OpenCV’ is a library and a series of header files, and a set of Python modules, and a Java Interface, that specialize in Computer Vision, which could therefore be classified as a rudimentary AI, although it should be said that This form of AI is still of such a variety, that the computer is only performing remarkably complicated calculations, to be able to do things, which were not feasible only a few decades ago. It provides Image Recognition. Because of the way I am, I value having many computing resources installed, even if I rarely use them. OpenCV would be one such resource.
What tends to happen on Debian-based platforms, is that the version of OpenCV available from the package manager is a somewhat old version – in the case of Debian / Stretch, v2.4.9 – which is only important to install the library packages for, not the ‘-dev’ packages, and the former because the library packages are also dependencies of many other packages, which use OpenCV in the background, but not in any way that the user would want to write his own applications with.
What I additionally did, was to install v4.1 from the OpenCV Web-site, from source-code, and this seems like a good move because v4.1 is rumoured to be easier to write programs with, than v3.2 was, especially if the power-user does not want to end up shoulder-high in low-level code, to do many of the uninteresting parts of what his application needs to do, to be user-friendly.
But then, before writing our own applications with OpenCV, what we might also want is a demo program, that just shows users what the capabilities of this library and of this SDK are. And so the main program to do this with is called “OpenCV Demonstrator“. This could be a way to intrigue ourselves, as well to show off what our computers can do, maybe to friends?
But here I ran into a bit of a snag. ‘OpenCV Demonstrator’ has only been compiled, by its author, as an application that uses OpenCV 3.2, and according to examination of my blog entries from before the reinstall, was compatible with v3.4. It’s not compatible with v4.1, even though v4.1 is more powerful. Whenever there is a major version update, let’s say from 3 to 4, applications built against one version will no longer run, when compiled against the next version. But I wanted that Demonstration Program. And so the following is what I did:
From the OpenCV Web-site, I clicked all the way down, to a download of v3.2, even though v4.1 was already fully installed to my root file-system, to standard directories for libraries, data and header files. Then, with the source-code for v3.2 downloaded into a separate folder under my home folder, I took note of the fact that both v3.2 and v4.1 are based on the ‘CMake’ system of generating Makefiles – under Linux – but which will also generate other types of Project Files, for compilers that run under Windows or OS/X. I created a sub-directory of the v3.2 source-code directory, that I named ‘build_opt’, and pointed my ‘cmake-gui’ program to that pair of directories. Later, I changed the install path for this project to ‘/opt’ (it was ‘/usr/local’ by default). I also needed to disable ‘precompiled header files’. And then I compiled and installed v3.2 to this separate directory, still within the root file system, but to a place where the O/S will not find it innately.
After that, I edited the following file within the ‘OpenCV Demonstrator’ source tree:
~/Programs/opencv-demonstrator/libcutil/data/makefile-opencv320 OCVIPATH = /opt/include OCVLPATH = /opt/lib
The two variables in this file, that are shown above, instruct the OpenCV Demonstrator application to look for and link to the downgraded OpenCV version, which I just installed into the directory ‘/opt’. After editing that I was able to build the Demo app, and it runs just fine. But I also know that if I ever wanted to write my own application using OpenCV, I have a higher version of it, that promises to be more user-friendly, installed to the standard prefixes.
I should add that when I built OpenCV v4.1, within CMake-GUI, I enabled ‘BUILD_opencv_world’. What this option does is to create a very few shared libraries, differently named, explicitly under the prefix ‘/usr/local/lib’, instead of the long list of shared libraries that programmers would eventually need to link their applications to, and the names of which might unintentionally match those of the package-manager installed libraries. If the names of the libraries matched, then the libraries in this directory would override those under ‘/usr/lib’, creating incompatibilities and eventual error messages, from package-manager installed applications. The package-installed versions of OpenCV use the system of many separate shared libraries, for many separate capabilities, supplied by many separate (Debian) packages.
Because I did not install the (OpenCV) ‘-dev’ packages, there is also no ambiguity in which header files to compile against.
Additionally, because v3.2 installed its libraries to the prefix ‘/opt/lib’, my overall strategy should keep existing software stable.