OpenCV Reinstalled on Computer Phosphene

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?

 

Screenshot_20190610_082145

 

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:

Continue reading OpenCV Reinstalled on Computer Phosphene

I’ve just custom-compiled OpenCV.

One trend in computing is AI, and a subject related to AI, is Computer Image Recognition, which could also be called ‘Computer Vision’. And there exists an Open-Source library for that, called ‘OpenCV‘. While I tend to think of it mainly as a Linux thing, it’s also possible to download and install OpenCV on Windows.

The version of OpenCV which Linux users obtain from the package manager, tends to be an outdated version, which under Debian / Stretch, is version 2.4.9 . I have a Debian / Stretch, Debian 9 computer I name ‘Plato’, and its hardware is decently strong. But one thing I just wanted to do, was to install a more up-to-date version of OpenCV on it, that being version 3.4.2 . The way to do this under Linux, is to custom-compile. And so doing that was an overnight project this morning.

One drawback to using OpenCV remains, that it does not seem to have many working applications out-of-the-box. It offers an API, and one needs to be a very good C++ programmer, to make any use of that API. But interestingly enough, there is a demonstration application these days, called “OpenCV Demonstrator“. If one has the appropriate version of OpenCV installed, one can also custom-compile the Demonstrator.

screenshot_20180826_055750

I made some observations about these two projects the hard way this morning.

Continue reading I’ve just custom-compiled OpenCV.

About how I won’t be doing any ‘ASL’ computing soon.

There exists an Open-Source code library named ‘ASL’, which stands for “Advanced Simulation Library“. Its purpose is to allow application-designers who don’t have to be deep experts at writing C++ code, to perform fluid simulations, but with the volume-based simulations running on the GPU of the computer, instead of on the CPU. This can also lead people to say, that ‘ASL’ is hardware-accelerated.

Last night I figured, that ‘ASL’ should run nicely on the Debian / Stretch computer I name ‘Plato’, because that computer has a GeForce GTX460 graphics card, which was considered state-of-the-art in 2011. But unfortunately for me, ‘ASL’ will only run its simulations correctly, if the GPU delivers ‘OpenCL’, version 1.2 or greater. The GeForce 460 graphics card is only capable of OpenCL 1.1, and is therefore no longer state-of-the-art by far.

Last night, I worked until exhausted, trying various solutions, in hopes that maybe the library had not been compiled correctly – I custom-compiled it, after finding out that the simulations were not running correctly. I also looked in to the possibility, that maybe I had just not been executing the sample experiments correctly. But alas, the problem was my ‘weak’ graphics card, that is nevertheless OpenGL 4 -capable.

As an alternative to using ‘ASL’, Linux users can use the Open-Source program-set called ‘Elmer‘. They run on the CPU.

Further, there is an associated GUI-application called ‘ParaView‘, the purpose of which is to take as input, volume-based geometries and arbitrary values – i.e., fluid states – and to render those with some amount of graphics finesse. I.e., ‘ParaView’ can be used to post-process the simulations that were created with ‘ASL’ or with ‘Elmer’, into a presentable visual. The version of ‘ParaView’ that installs from the package-manager under Debian / Stretch, ‘5.1.x’ , works fine. But for a while last night, I did not know whether problems that I was running in to were actually due to ‘ASL’ or to ‘ParaView’ misbehaving. And so what I also did, was to custom-compile ‘ParaView’, to version 5.5.2 . And if one does this, then the next problem one has, is that ParaView v5.5.2 requires VTK v7, while under Debian / Stretch, all we have is VTK v6.3 . And so on my platform, version 5.5.2 of ParaView encounters problems, in addition to ‘ASL’ encountering problems. And so for a while I had difficulty, identifying what the root causes of these bugs were.

Finally, the development branch, custom-compiled version of ‘Elmer’ and package-manager-installed ‘ParaView’ v5.1.x will serve me fine.

Dirk

 

I have now custom-compiled ‘gimp-gap’ on my laptop, Klystron.

Now that the laptop I name ‘Klystron’ has Linux on it, it is also a part of my ritual, that this machine is to receive all the software which I feel a posh Linux system should have. One piece of software in that category is ‘gimp‘, which has the plugin ‘gimp-gap‘.

But then we find that from the package manager, ‘gimp-gap‘ is missing several animation output options. And as I did recall, the solution to that problem is to custom-compile gimp-gap v2.6, to work with gimp v2.8. This requires may dependencies. It also requires the options


export LIBS='-lm'
./configure --prefix=/usr

The former ‘-lm’, linker option needs to be given on 64-bit Debian, in order to overcome the peculiar error message:


//lib/x86_64-linux-gnu/libm.so.6 error adding symbols dso missing from command line

Dirk