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…

 

Cinepaint_1

 

Cinepaint_2

 

Cinepaint_3

 

Cinepaint_4

 

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!

 

Continue reading An Ode to Cinepaint

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