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!

 

 

This is a link, where one can still download the source-code for ‘lcms v1′:

https://sourceforge.net/projects/lcms/files/lcms/1.19/

And this is a link, where one can still download the source-code, for ‘Cinepaint 1.0-4′:

https://sourceforge.net/projects/cinepaint/files/CinePaint/CinePaint-1.0-4/

One does not want to build ‘Oyranos’.

Don’t get me wrong; before any of the source bundles above will compile, there is a host of ‘-dev’ packages which Debian users must install from their package managers, and a fundamental incompatibility with any version of ‘libpng’ later than v14. Debian 9 / Stretch uses ‘libpng v16′. Jessie still used v12. Also, this version of Cinepaint seems to be built on a mishmash of ‘Gtk2′ and ‘FLTK’ for its GUI. But eventually, the following is the result one is looking for, when running the configure script for Cinepaint:

 


dirk@Klystron:~$ cd ~/Programs/cinepaint-1.0-4
dirk@Klystron:~/Programs/cinepaint-1.0-4$ export LIBS='-lstdc++ -lm -lX11'
dirk@Klystron:~/Programs/cinepaint-1.0-4$ ./configure --enable-precision=u8,u16,half,float


(...)


=================================================================
              Configuration Results

GTK CinePaint Version 1.0-4


General dependencies:
   Gtk2 toolkit                 yes    2.24.25
   DnD support                  yes    X11/Xmu
   littleCMS                    yes    lcms 1.19
   Oyranos                      no

Plug-ins with external dependencies:
   Python plug-in:              no
   OpenEXR plug-in:             yes    OpenEXR 1.6.1
   Tiff plug-in:                yes
   PNG plug-in:                 yes    libpng 1.2.50
   Jpeg plug-in:                yes
   Print plug-in:               yes    Gutenprint 5.2.10
   FLTK dependent plug-ins:     yes    bracketing_to_hdr collect pdf
   Thread dependent plug-ins:   yes    icc_examin
   Flex dependent plug-ins:     yes    iol
=================================================================

Now type 'make' and 'make install' / 'make rpm' to build the package and 
install. The unix command is 'cinepaint'.
dirk@Klystron:~/Programs/cinepaint-1.0-4$ 

 

The snip above already reveals, what partS of Cinepaint will not work:

Python plug-in: no

The reason Cinepaint cannot be compiled with its Python-Fu working under Debian, is the fact that under Debian versions up to and including Stretch, there is no real package by the name of ‘gimp-python’. What Debian had been doing, and which they’ve only stopped doing with Debian 10 / Buster, is to bundle ‘PyGIMP’ as an integrated part of GIMP alone, while, as of Debian Buster, they’ve provided a standalone version of PyGIMP. That’s too late for Cinepaint!

Without the Python plug-in, certain features will not work, including all the scripts, and including the ability to work with preset patterns. I think that the ‘bucket-fill tool’ is supposed to have an option, to fill the selected region with a pattern, while all it can presently do is, to fill the selected region with one out of two solid colours, either the foreground colour, or the background colour. However, I’ve gotten all the Cinepaint plug-ins to work, except for the one called ‘script’…

 

Cinepaint_8

 

As the reader can see, I’ve even gotten ‘IOL’ to work, which stands for ‘Image Operation Language’. That’s a massive name for something that I don’t value, as it would represent yet-another language I’d need to learn, if I were to use it, and it’s not worth my while.

 

Cinepaint_5

Cinepaint_6

 

But all the basic functions of Cinepaint, as far as I can tell, work. This includes:

  • Assign ICC Profile,
  • Assign ICC Proof Profile,
  • Convert Using ICC Profile.

What is not included, is the executable “ICC Examin”, which was once a fun toy to play with, as it generated 3D views of selected colour profiles.

 

Dirk

 

Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>