## Getting FreeFem++ to display impressive visuals under Linux.

One of my Computing habits is, to acquire many frameworks, for performing Scientific or Analytical Computing, even though, in all honesty, I have little practical use for them, most of the time. They are usually of some Academic curiosity to me.

Some of the examples familiar to me are, ‘wxMaxima‘ (which can also be installed under Linux, directly from the package manager), ‘Euler Math Toolbox‘ (which, under Linux, is best run using Wine), and ‘SageMath‘ (which IMHO, is best installed under Linux, as a lengthy collection of packages, from the standard repositories, using the package manager, that include certain ‘Jupyter’ packages). In addition to that, I’d say that ‘Python‘ can also be a bit of a numerical toolbox, beyond what most programming languages can be, such as C++, yet, a programming language primarily, which under Linux, is best installed as a lengthy collection of packages through the package manager. And a single important reason is the fact that a Python script can perform arbitrary-precision integer arithmetic natively, and, with a small package named ‘python3-gmpy2′, can also perform arbitrary-precision floating-point arithmetic easily. If a Linux user wanted to do the same, using C, he or she would need to learn the library ‘GMP’ first, and that’s not an easy library to use. Also, there exists IPython, although I don’t know how to use that well. AFAICT, this consists mainly of an alternative shell, for interacting with Python, which makes it available through the Web-interface called “Jupyter”. Under Debian Linux, it is best installed as the packages ‘ipython3′, ‘python3-ipython-genutils’, ‘python3-ipykernel’, ‘python3-nbconvert’, and ‘python3-notebook’, although simply installing those packages, does not provide a truly complete installation… Just as one would want a ‘regular’ Python installation to have many additional packages, one would want ‘IPython’ to benefit from many additional packages as well.

But then, that previous paragraph also touches on an important issue. Each Scientific Computing platform I learn, represents yet-another scripting language I’d need to learn, and if I had to learn 50 scripting languages, ultimately, my brain capacity would become diluted, so that I’d master none of them. So, too much of a good thing can actually become a bad thing.

As a counter-balance to that, it can attract me to a given Scientific Computing platform, if it can be made to output good graphics. And, another Math platform which can, is called “FreeFem“. What is it? It’s a platform for solving Partial Differential Equations. Those equations need to be distinguished from simple derivatives, in that they are generally equations, in which a derivative of a variable is being stated on one side (the “left, bilinear side”), but in which a non-derivative function of the same variable is being stated on the other (the “right side”). What this does, is to make the equation a kind of recursive problem, the complexity of which really exceeds that of simple integrals. (:2)  Partial Differential Equations, or ‘PDE’s, are to multi-variable Calculus, as Ordinary Differential Equations, or ‘ODE’s, are to single-variable Calculus. Their being “partial” derives from their derivatives being “partial derivatives”.

In truth, Calculus at any level should first be studied at a University, before computers should be used as a simplified way of solving its equations.

FreeFem is a computing package, that solves PDEs using the “Finite Element Method”. This is a fancy way of saying, that the software foregoes finding an exact analytical solution-set, instead providing an approximation, in return for which, it will guarantee some sort of solution, in situations, where an exact, analytical solution-set could not even be found. There are several good applications. (:1)

But I just found myself following a false idea tonight. In search of getting FreeFem to output its results graphically, instead of just running in text mode, I next wasted a lot of my time, custom-compiling FreeFem, with linkage to my many libraries. In truth, such custom-compilation is only useful under Linux, if the results are also going to be installed to the root file-system, where the libraries of the custom-compile are also going to be linked to at run-time. Otherwise, a lot of similar custom-compiled software simply won’t run.

What needs to be understood about FreeFem++ – the executable and not the libraries – is, that it’s a compiler. It’s not an application with a GUI, from which features could be explored and evoked. And this means that a script, which FreeFem can execute, is written much like a C++ program, except that it has no ‘main()‘ function, and isn’t entirely procedural in its semantics.

And, all that a FreeFem++ script needs, to produce a good 2D plot, is the use of the ‘plot()‘ function! The example below shows what I mean:

I was able to use an IDE, which I’d normally use to write my C++ programs, and which is named “Geany”, to produce this – admittedly, plagiarized – visual. The only thing I needed to change in my GUI was, the command that should be used, to execute the program, without compiling it first. I simply changed that command to ‘FreeFem++ "./%f"‘.

Of course, if the reader wants in-depth documentation on how to use this – additional – scripting language, then This would be a good link to find that at, provided by the developers of FreeFem themselves. Such in-depth information will be needed, before FreeFem will solve any PDEs which may come up within the course of the reader’s life.

But, what is not really needed would be, to compile FreeFem with support for many back-ends, or to display itself as a GUI-based application. In fact, the standard Debian version was compiled by its package maintainers, to have as few dependencies as possible (‘X11′), and thus, only to offer a minimal back-end.

(Updated 7/14/2021, 21h45… )

## An Ode to Cinepaint

People who are knowledgeable about Linux, and up-to-date, will explain, that Cinepaint bit the dust of bit-rot several years ago, and is effectively uninstallable on modern Linux computers. I have to accept that. It has no future. The latest Debian version it’s still installable on in theory, is Debian 8, which is also called ‘Debian Jessie’. But there is a tiny niche of tasks which it can perform, which virtually no other open-source graphics application can, and that consists of, being given a sequence of numbered images that make up a video stream, and to perform frame-by-frame edits on those images. Mind you, Cinepaint will not even stream a video file, into such a set of numbered images – I think the best tool to do that is ‘ffmpeg’ – but, once given such a set of images, Cinepaint will allow them to be added to its ‘Flipbook’ quickly, from which they can be processed manually, yet efficiently. I suppose that this is a task which users don’t often have, and if they do, they’re probably also in a position to purchase software that will carry it out.

But, another big advantage which Cinepaint has over ‘GIMP’ is, that Cinepaint will process High Dynamic-Range images, such as, ones that have half-precision, 16-bit floating-point numbers for each of their colour channels. And wouldn’t the reader have guessed it, I still happen to have a Debian / Jessie laptop that’s fully functional! So, honouring glory that once was, I decided to custom-compile Cinepaint one more time, on that laptop, which I named ‘Klystron’. I was still successful today, with the exception that there is a key functionality of the application which I cannot evoke from it, and which I will mention below. First, here are some screen-shots, of what Cinepaint was once able to do…

That fourth screen-shot is what one obtains, when one chooses ‘Bracketing to HDR’ is the method to import an image, and if the person then specifies no images, because that person never uses the bracketed shooting mode of his DSLR (me).

One of the tasks which would be futile is, to try to work with images seriously, that have more than 8 bits per channel, without also working with ‘Colour Profiles’, aka ‘Colour Spaces’. Therefore, Cinepaint has as a required feature, that it work with version 1, not version 2, of the ‘Little Colour Management System’, aka, ‘lcms v1.19′. Here begin the hurdles in getting this to compile. A legitimate concern that the reader could already have is that Debian Jessie had transitioned to ‘lcms v2′. In certain cases, custom-compiling an older version of this, while the correct version is already installed from the package-manager, could pose a risk to the computer. And so, before proceeding, I verified that the library names, and the names of the header files, of the package-installed ‘lcms v2′, have the major version number appended to their file-names. What this means is, that when ‘lcms v1.19′ is installed under ‘/usr/local/lib’ and ‘/usr/local/include’, there is no danger that a future linkage of code, could actually link to the wrong development bundle. There is only the danger that some future custom-compile could actually detect the presence of the wrong development bundle. And this will be true, as long as one is only installing the libraries, and not executables!

## 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?

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:

## 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.

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