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

## Getting the integrated equalizer to work, from Debian Jessie, KDE 4.

I happen to have an older laptop, which I name ‘Klystron’, that is running Debian 8 / Jessie, with KDE 4 as its desktop manager. Don’t ask me why, but I tend to leave older builds of Linux running on some of my computers, just because they seem to be running without any deficiencies.

That laptop has lousy speakers. I decided a few days ago, that it would benefit, if I could get the 14-band graphical equalizer to work, that is generally available on Linux computers which, like that laptop, use the ‘PulseAudio’ sound server. However, on this old version of Linux, achieving that was a bit harder than it’s supposed to be. Yet, because I succeeded, I felt that I should share with the community, what the steps were, needed to succeed.

First of all, this is what the equalizer looks like, which I can now open on that laptop:

And it works!

In order to get this sort of equalizer working with PulseAudio, eventually, the following two modules need to be loaded:

module-equalizer-sink

module-dbus-protocol

And, if I gave the command ‘load-module…’ naively from the command-line, as user, because under my builds of Linux, PulseAudio runs in user mode, both these modules seem to load fine, without my having to install any additional packages.

On more recent builds of Linux, one needs to install the package ‘pulseaudio-equalizer’ to obtain this feature, or some similarly-named package. But, because these two modules just loaded fine under Debian / Jessie, I guess the functionality once came integrated with PulseAudio.

But I soon started to run in to trouble with these modules, and discovered why, then, the equalizer function was not set up to run out-of-the-box…

(Updated 6/26/2020, 10h30… )

## Latest Debian Security Update Breaks Jessie (Resolved).

In addition to my Debian / Stretch computer, I still operate two Debian / Jessie computers. Those latter two computers were subscribed to the Debian Security repository, as well as to the standard Debian / Jessie repository. Unfortunately, the package manager on one of my Debian / Jessie computers had made me aware of a conflict which existed, due to an update which Debian Security is pushing, to a package and its related packages, all belonging to:

liqt4-dev

The version which Debian Security is trying to install is:

4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u2

But, the version which the rest of Debian / Jessie was using, was:

4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1

The problem was the fact that, if I told my package manager to go ahead with its suggested updates, doing so would have forced me to reject a long, long list of packages essential to my system, including many KDE-4-related packages. Now, I can just ignore that this problem exists, and rely on my package manager again not installing packages, that would break my system, on a daily basis. But this would turn into a very unsafe practice in the long run. And so, the only safe course of action for me currently seemed to be, to unsubscribe from Debian / Security instead.

(Update 17h55 : )

I have resubscribed to the Debian Security repository in question, and re-attempted the update, to find that this time, it worked. I can think of 2 possible reasons why it might not have worked the first time:

1. My unattended-upgrades script is configured to break up an update into smaller pieces, and because this update involves a large number (over 20) of Qt 4 packages, this in itself could have broken the ability to perform the update, or
2. Debian Security may not have put all the involved updates ‘out there’ on its servers, to be downloadable in one shot, even though every Qt 4 package needs to be updated, in order for any of the updates to succeed. But, only hours later, all the required packages may have become available (on the servers).

I rather think that it was due to reason (2) and not reason (1) above.

Dirk

## My system for switching between compilers needed an overhaul.

According to what I had written in earlier postings, I had co-installed a Debian Jessie / Security version of the GCC / CPP / C++ compiler system, which had version 4.9.2, alongside the official versions, which were 6.3, on the Debian / Stretch computer I name ‘Phosphene’. There was a problem in how I had done that. If next, the Package Maintainers had pushed through an update to their official compiler, the update would have broken my link groups – in a devastating way. And so what I needed to do was to rearrange those link-groups, to make them compatible with this scenario. The result is as follows:


dirk@Phosphene:~$su Password: root@Phosphene:/home/dirk# update-alternatives --config cc There are 2 choices for the alternative cc (providing /usr/bin/cc). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/bin/gcc 20 auto mode 1 /usr/bin/gcc 20 manual mode 2 /usr/bin/gcc-4.9 10 manual mode Press to keep the current choice[*], or type selection number: root@Phosphene:/home/dirk# update-alternatives --config cpp There are 2 choices for the alternative cpp (providing /lib/cpp). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/bin/cpp 20 auto mode 1 /usr/bin/cpp 20 manual mode 2 /usr/bin/cpp-4.9 10 manual mode Press to keep the current choice[*], or type selection number: root@Phosphene:/home/dirk# update-alternatives --config c++ There are 2 choices for the alternative c++ (providing /usr/bin/c++). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/bin/g++ 20 auto mode 1 /usr/bin/g++ 20 manual mode 2 /usr/bin/g++-4.9 10 manual mode Press to keep the current choice[*], or type selection number: root@Phosphene:/home/dirk# ls -l /usr/bin/gcc lrwxrwxrwx 1 root root 5 May 3 10:58 /usr/bin/gcc -> gcc-6 root@Phosphene:/home/dirk# ls -l /usr/bin/cpp lrwxrwxrwx 1 root root 5 May 3 11:01 /usr/bin/cpp -> cpp-6 root@Phosphene:/home/dirk# ls -l /usr/bin/g++ lrwxrwxrwx 1 root root 5 May 3 11:24 /usr/bin/g++ -> g++-6 root@Phosphene:/home/dirk# exit exit dirk@Phosphene:~$



Dirk Mittler