• Version 2.10 is a big deal: It’s the first one to use GPU acceleration for scaling and rotation, as well as deforming of different types. No more small previews, no more sluggish response to scaling. No need to scale down images for working, because it was too slow.
• The default theme (dark) is a joke. It’s elegant, but it’s difficult to see the differences between dark grey and lighter grey, which is the difference between a layer lock being enabled or not. I went for “system”, which got me Mint colors and nice icon spacing. Doesn’t look very elegant, but hey, I now know what I’m doing.
• The default icons are a joke as well. Very sleek, but the colors are gone. Once again, it’s elegance vs. functionality. There’s a “color” option for the icon. Looks like a children’s toolbox now, but it’s much easier to find the correct tool.

Linked layers

First and foremost: Layer groups is most likely the preferred solution. In particular, I used to link between a layer with a layer mask and its duplicate with the same layer mask applied in order to resize / rotate the layer along its layer mask. This isn’t necessary anymore: Just put the layer with a layer mask inside a group, and manipulate the group instead of the layer. This is quicker than this duplicate, apply and link method, but there’s one feature still lacking: The ability to crop the layer to which the mask has been applied, and manipulate a smaller area.

Linked layers doesn’t seem to work on 2.10.14 — this seems to be a bug: Say, when linking two layers and scaling / rotating one of them, nothing happens with the other.

Solution / workaround: There are two options I know of:

• Don’t use linked layers: Put the relevant layers in a layer group, and do the scaling / rotation on the group. But that doesn’t work well for manipulating a small layer in order to apply the changes on a larger one.
• Link between a layer group (possibly with one layer) and the layers that are affected by it. This really looks like a bug workaround: Linking layers to a layer group will make the changes to the layer group apply to all other layers. But only if the manipulations are made to the layer group. Which is more or less fine, because the normal way to work is to manipulate some specific layer, and the others follow. So put that layer in a group of its own, and link the others with the group.

Anyhow, there’s a little problem: The list gets very large after a while. Presets saved by name will most likely appear last, making them effectively unavailable.

The presets are stored as LISP code in a file called ~/.gimp-2.6/tool-options/gimp-curves-tool.settings (the tilde means “your home directory”). This is great news, because editing or clearing this file (possible deleting it) allows you to clean up this list.

But even better, it looks like these LISP expressions can be copied into a script, to repeat a Curves operation. I’ve discussed GIMP scripts here, so you may want to give it a try. I haven’t tried to adopt these curve settings in a script yet, because I haven’t had the need. If you’re successful with this, please leave a comment below.

The truth is that I don’t really understand why this works, but it fixed a nasty case of ugly skin texture in a low key photo. The trick was using the hard light layer mode, which is described in detail in the GIMP documentation. Unfortunately, the explanations and equations didn’t help me much in understanding why it happened as it happened.

So here’s the procedure, as I did it. If it doesn’t work for you, don’t blame me. I have no idea what I actually did.

Original image:

Original image

Duplicate the layer, and blur the upper layer strongly (Gaussinan blur, radius 40 in our case)

Stage two: Image blurred

Set upper layer’s mode as “Hard light”

Stage 3: Hard light applied

Merge down the upper layer, so they become one layer, and reduce the saturation:

Final result

This may not look like a significant change, but when zooming out, it is.

It looks like the GIMP developers found the Color Range Mapping plugin useless, as is apparent from their correspondence.  As Sven Neumann says over there, “Let’s remove those plug-ins then if the code sucks that much. Are they in anyway useful at all?”

Let me answer you, Sven. Yes, it’s very very useful. I don’t know if Photoshop has a similar feature, but color range mapping is extremely useful in photomontage. That’s when you need one exact color at one place, and another exact color at another.

When the absence of the relevant plugin was reported in a bug report, it was said that “Looking at it again, the plug-in really was so badly broken, I would prefer if we would not have to add it back.” Broken or not, I love this plugin.

To fix my own problem, I followed this post and fetched myself an x86-64 rpm of an old version of GIMP. Matching architecture is important, because the plugins are precompiled binaries.

I downloaded just the first RPM I could find of GIMP, which was of version 2.4 and compiled for x86_64, and then extracted the files in an empty directory with

rpm2cpio gimp-2.4.6-1.fc7.x86_64.rpm | cpio -idvm

And then, as root:

cp usr/lib64/gimp/2.0/plug-ins/mapcolor /usr/lib64/gimp/2.0/plug-ins/

and that’s all! Restarting GIMP I found my beloved plugin there. Happy, happy, joy, joy!

Update 14.7.21: In Gimp 2.10, there’s a separate directory for each plug-in, but all in all, it’s the same:

# cd /usr/lib/gimp/2.0/plug-ins/
# mkdir mapcolor
# cp /path/to/old/gimp/2.0/plug-ins/mapcolor mapcolor/

I use GIMP a lot. I store the images in the native file format, XCF. Now I’m stuck with a lot of files I can’t see outside GIMP, but I don’t want to save those files as anything else, because I’ll lose all the layer data. Solution: Batch conversion to JPEG as a simple bash script to run from the command line.

The idea is to make a JPEG copy of the image as it’s seen when it’s opened with GIMP. For that reason, I’ve chosen to flatten the image by visible layers only, and to crop it to image size.

Also, I’ll show an example of how to massively fix images with a GIMP script.

2022 update: This post is really old. Nowadays ImageMagick supports XCF, so it’s possible to just go

$ convert this.xcf this.jpg

But this post can still be of use for more sophisticated tasks with GIMP.

The script

It looks like LISP and it looks like bash. In fact, they’re mixed.

#!/bin/bash
{
cat <<EOF
(define (convert-xcf-to-jpeg filename outfile)
  (let* (
	 (image (car (gimp-file-load RUN-NONINTERACTIVE filename filename)))
	 (drawable (car (gimp-image-merge-visible-layers image CLIP-TO-IMAGE)))
	 )
    (file-jpeg-save RUN-NONINTERACTIVE image drawable outfile outfile .9 0 0 0 " " 0 1 0 1)
    (gimp-image-delete image) ; ... or the memory will explode
    )
  )

(gimp-message-set-handler 1) ; Messages to standard output
EOF

for i in *.xcf; do
  echo "(gimp-message \"$i\")"
  echo "(convert-xcf-to-jpeg \"$i\" \"${i%%.xcf}.jpg\")"
done

echo "(gimp-quit 0)"
} | gimp -i -b -

To try it out, simply execute the script from a directory containing several .xcf files. Be sure not have any .jpg files you care about in the same directory, because the outputs are with the same file names, just with the .jpg extension (old files are overwritten with no warning).

You will get kind-of-warning messages while the script is iterating, indicating which file is being processed. This is normal.

The concept of this script is simple. An ad-hoc LISP script is generated in the Bash block, which is enclosed by curly brackets. First we define the function, which converts one file. The bash script then creates calls to this function, by means of the (Bash) for-loop. All this is then fed into GIMP through standard input (piping).

Some LISP notes

I’m not really into LISP. So I ran into some trouble. These are my notes, so I won’t go through it again:

First, there’s the Script-Fu console, which was, well, sort-of helpful. The internal functions’ API can be found there as well.

As a LISP novice, I didn’t know the difference between “let” and “let*”. It turns out, that let* allows the use of previous assignments in the following ones, so this is what you get in the Script-Fu console:

> (let ( (x 2) (y x)) y)
Error: eval: unbound variable: x 

> (let* ( (x 2) (y x)) y)
2

It’s also worth to note, that the GIMP interpreter does not remember functions across different -b command-line arguments:

# First statement succeeds, second fails.
gimp -i -b '(define (myfun x y) (- x y))' -b '(myfun 2 3)'

# This works, because it's two statements in one execution (yuck!)
gimp -i -b '(define (myfun x y) (- x y)) (myfun 2 3)'

Mass processing of frames

As the title implies, I needed this to make adjustments on a video clip. It’s true that many video editors (Cinelerra included) have filters for that, but running a sequence of GIMP commands is probably stronger than any possible video editor.

So here’s a little script which runs some operations on a list of frames. This was useful, mainly because I wanted to run curves on a clip (and Cinelerra doesn’t have that operation. I wonder which video editor has).

#!/bin/bash
{
cat <<EOF

(define (do-retouch filename outfile)
 (let* (
 (image (car (gimp-file-load RUN-NONINTERACTIVE filename filename)))
 (drawable (car (gimp-image-merge-visible-layers image CLIP-TO-IMAGE)))
 )
 (gimp-colorize drawable 10 50 0)
 (gimp-curves-spline drawable HISTOGRAM-VALUE 6 #(0 0 147 44 255 122 ) )
 (gimp-hue-saturation drawable ALL-HUES 0 0 20)
 (plug-in-gauss RUN-NONINTERACTIVE image drawable 10 10 1)
 (file-png-save2 RUN-NONINTERACTIVE image drawable outfile outfile 0 9 0 0 0 0 0 0 1 )
 (gimp-image-delete image) ; ... or the memory will explode
 )
 )

(gimp-message-set-handler 1) ; Messages to standard output
EOF

for i in frame*.png; do
 echo "(gimp-message \"$i\")"
 echo "(do-retouch \"$i\" \"fixed/x_${i%%.png}.png\")"
done

echo "(gimp-quit 0)"
} | gimp -i -b

The script-Fu console was helpful in finding the function’s names, which are pretty obvious. I’ll only mention that running gimp-image-merge-visible-layers in this case is probably not necessary, but I suppose GIMP won’t waste too much time on merging a layer with itself.

As for the curves operation (gimp-curves-spline), I first tried to use curves traces which are saved by GIMP as they are being used in the GUI, but that turned out to be pretty complicated. So I went for the simple approach: Open the GUI, find the X-Y points on the graph, and copy them manually. The “6″ says that there are 6 numbers ahead (3 X-Y pairs), and then we have X0, Y0, X1, Y1, etc. The values go from 0 to 255. So it’s pretty trivial, and does exactly the same as the GUI.

Importing the frames to Cinelerra

Not that it’s directly relevant, but to import a bunch of frames into Cinelerra, use the mkframelist command line utility and load it like any file. For example,

$ ls *.png | mkframelist -r 30 > framelist

For 30 fps, and then load “framelist” to Cinelerra. Note that the paths in the list are absolute, so you can’t just move around the files.