Every user has a .gimp directory in their HOME directory.  The actual name is suffixed with the version you’re using, so the latest stable release uses a directory named .gimp-2.6.  Inside of the .gimp directory you’ll find a variety of files and directories.  Two of these directories are plug-ins and scripts.  The plug-ins is where you store python scripts and compiled plugins.  The scripts directory is where you store script-fu scripts.

Technically there is no functional difference between the files in either directory.  Python scripts, script-fu scripts and compiled plugins provide the same internal capabilities.  This means that a python script can call a script-fu script and vice-versa.  But non-developers don’t care about that.  So just remember that only script-fu scripts go in the scripts directory.  All other plugins go in the plug-ins directory.

Plugin developers who use python for their plugins might want to consider using the batch processing option of GIMP.  To pass a python script to GIMP through the batch interface you need to specify that the python interpreter should be used, as in:

–batch-interpreter python-fu-eval

Then any arguments passed to the -b option will be run through the python intepreter.

Select the top half of your layer, enter Quick Mask mode, and run  Filters->Distorts->Ripple with the Smear, Vertical, and Sawtooth  options (use the sliders to size your zigs and zags). Exit Quick Mask  mode.

Here’s an example result:

In the GIMP, look in Edit->Preferences, in the Environment options under Resource Consumption.  There is a field to set the number of processors to use.  I’ve set mine to 4 because I’ve got a quad-core AMD processor.

I asked Sven Neumann what processes this affects.  He pointed me to look at git grep pixel_regions_process_parallel which must be done under a git tree for the current GIMP source.  I ran this method through cscope to find every place it was called and came up with these functions:

apply_mask_to_region
combine_mask_and_region
combine_regions
gimp_channel_combine_mask
gimp_channel_real_invert
gimp_channel_real_sharpen
gimp_drawable_process
gimp_histogram_calculate
gimp_image_contiguous_region_by_color
initial_region
pixel_regions_process_parallel

So masks and channel operations can utilize multiple cores.  I’m not sure what the _region functions do but perhaps they’re related to tile handling.  This would imply canvas updates are parallelized too.

In summary, you’ll get some benefit from having multiple cores when using lots of masks.  This is good to know because masks are non-destructive changes to layers and you get the most benefit of using them if you have mulitple cores.

What I found interesting about this discussion was the tip from Milan Knizek, who showed how he checked the files for color profile information.  He used two commands:

exiftool -a -G -H _GOR3359.JPG | grep Color

Obviously the .JPG is the source image filename.  This command produced information that looked like this:

[File]               – Color Components                : 3
[EXIF]          0xa001 Color Space                     : Uncalibrated
[MakerNotes]    0×0037 Color Space                     : Adobe RGB

This is how he found that the color space specified in the file (Adobe RGB) was not actually specified in the EXIF fields.  The second command was exiv2:

exiv2 -pa _GOR3359.JPG | grep Color

This command produced information like so:

Exif.Pentax.ColorSpace                       Short       1  Adobe RGB
Exif.Pentax.ColorTemperature                 Short       1  0
Exif.Pentax.ColorInfo                        Undefined  18  32 131 31
100 31 125 32 156 33 72 32 246 31 51 31 10 0 0
Exif.Photo.ColorSpace

It’s unclear to me what this is telling us but it appears that the Pentax information is in a special area of the EXIF data in the file.  In any case, finding out what color space is specified in an image file, and most cameras do this now, is pretty easy with these two commands.  On Fedora, the exiv2 program is found in the exiv2 package while the exiftool program is found in the perl-Image-ExifTool package.  Having this information may make it a little easier to configure GIMP’s color management too.

But I’m a developer by trade so there should be no reason I cannot figure out.  So this blog entry is all about getting that done.

Required Packages

• BABL
• GEGL
  • Ruby (when building from the git repository)
  • lua-devel
  • OpenEXR-devel
  • librsvg2-devel
  • libopenraw-devel
  • graphviz
  • avformat
  • libspiro-devel
• GIMP
  • jasper library
  • libpoppler
  • libwmf
  • libexif

These are just the packages that were not found the first time I tried to build things on Fedora 11.  On other systems (including Windows and Macs) you’ll may have other requirements, especially if you don’t use GNOME on your desktop at all.  Fedora 11 didn’t seem to have a version of avformat so I skipped it.  I installed libpoppler (runtime and devel packages) but GIMP didn’t like that so the PDF support was built using the Postscript plug-in.

The list of packages available from the GIT repository is available from the GIMP Developer web site.  This list does not list the prerequisites that are not part of the GIMP GIT repository.

Getting The Source

Git requires two steps to get the code.  The first is called a clone, which gets the source sufficient to build the tree.  The second step, checkout, actually checks out the source so that you can make modifications and check them back in.   A third step, config, allows configuration of general details such as your user name and email address.  Only the first step is required if all you want to do is built GIMP from the source tree in order to get all the latest features and bug fixes and are not intending to make source code changes to submit back to the project.  All of this information can be found on the GNOME GIT pages.

Compiling Order

Building the GIMP is easy at the moment because there are only two real dependencies that can’t be satisfied by just installing prebuilt development packages.  This won’t always be the case as development of the 2.7 version progresses.

For now, you can get away with building in the following order:

• BABL
• GEGL
• GIMP

Building Into a Development Directory

If you build all the prerequisites into a single directory it will make it easier to compile prerequisites and run programs later.  Therefore we choose a single directory: /usr/local/gimpgit.   To use this directory for the build we’re going to want to add some environment variable settings:

export PKG_CONFIG_PATH=/usr/local/gimpgit/lib/pkgconfig/:$PKG_CONFIG_PATH

export LD_LIBRARY_PATH=/usr/local/gimpgit/lib:$LD_LIBRARY_PATH

The first variable is used to find pkg-config configuration files for prerequisite libraries.  The second is used to find runtime libraries of prerequisite packages during the build.  In both cases we’re placing the location to look for file of interest from the build directory tree ahead of any other configurations we might have previously set such as in our .bashrc file.  In this way we’ll pick up the new builds first and then pick up the old versions later if the new versions haven’t been built yet.  This will cause the build of each prerequisite to behave in the expected fashion, informing us of missing requirements.

Build Process

The GIMP packages (BABL, GEGL and GIMP) are all built using the autogen.sh script.  This is a front end to the autoconf/automake/libtool configuration contained in the source tree that makes it easy to create the Makefiles throughout the tree.  The general format of the command is as follows:

./autogen.sh –prefix=/usr/local/gimpgit

Running autogen.sh in the gimp source tree the first time will print out the results of simple tests to verify that you have required build tools, such as autoconf and automake.  When autogen.sh is run it will also run the configure script it creates which in turn will do additional searches for required packages.  It is at this point that the build will detect if you have the proper prerequisite libraries installed such as BABL and GEGL.

In order to find out what prerequisites I was missing I just ran autogen.sh once in the GIMP tree.  It told me I was missing babl, which I then built and installed.  I then ran the same autogen.sh command but substituted configure for autogen.sh because the latter will rebuild everything while the former (configure) will just run the configuration processing.  In other words, autogen.sh is needed once to build the configure script. After that you can usually just run configure instead.

BABL

After running autogen.sh, run the following commands:

• make
• sudo make install

GEGL

After installing the myriad of prerequisites and running autogen.sh, run the following commands:

• make
• sudo make install

GIMP

Fortunately it doesn’t appear that you need to update GTK+ and its related libraries for GIMP.  At least not at this time and not with GIMP 2.7 out of the git repository.

After installing the myriad of prerequisites and running autogen.sh, run the following commands:

• make
• sudo make install

Running GIMP

Now that you have it all built you just need to make sure the the build directories are the first in your PATH environment variable.  The best way to do this without affecting the rest of you desktop experience is to write a little script and use it to launch the development version.

#!/bin/bash

export PATH=/usr/local/gimpgit/bin:$PATH

gimp-2.7

Note that the program name is not “gimp”.  You can now run the development version of GIMP.  This version will create a new runtime directory in the users home:  .gimp-2.7.  GIMP will import its settings from your old .gimp-2.6 directory or even your .gimp-2.4 directory if you skipped 2.6 altogether.

Update: 2011-01-27

To help out with this process, here are two scripts I use to download and build the components required to build GIMP from GIT (and described in this post).

• build.sh
• getIt.sh

build.sh is the script to run, and it calls getIt.sh for each component.  You should edit these scripts since they are not general purpose – make sure they fit your needs.  They are just the ones I used to do my builds from GIT and install them locally.

I mentioned some time ago that I was reading The Artist’s Guide to GIMP Effects, by michael j. hammel, and that over time I’d report on what I thought about it.  Ok, here’s what I think about it. WOW!

I still have a long way to go to absorb everything in here, but in a few weeks I’ve gone from someone who’s messed around with Gimp for a few years but still felt lost, to someone who knows the principles behind using it as a tool.

Many of the questions people ask here seem obvious after reading and working with it for awhile.

He does a great job of teaching you the basic principles that let you solve problems.  You start thinking about what you want, instead of looking at what Gimp can do.

If you need to combine pictures, fix problems, do commercial graphics, web work, original art–this book is for you.  I’m astonished.

I’ll report back some more after spending a few more weeks with it.

It doesn’t cover 2.6, but it hasn’t been an issue using it with 2.6.  If you want to be a GIMP master, check it out!

Update: I’ve also rewritten this translation back into OpenOffice and PDF formats and improved upon the format and grammer slightly.

Enjoy!

The site also has a tutorials section that is primarily aimed at Photoshop users.  Experienced users should always consider tutorials of this type when trying to come up with techniques in GIMP.  Most of the things you can do in Photoshop you can do in GIMP, though you may have to perform them in a different way.

The texture downloads are limited to 15MB per day per user.  A random sample of the available images showed that most come at least 3 sizes with the largest size usually under 3MB and often under 1MB.  Larger images are available to members of the site, if you’re interested in signing up.

Also included in this collection are new sessionrc and toolrc files which, when used with the collection of tool-option presets, will change the default configuration of your GIMP session.  The new configurations make navigating GIMP easier while showing the power of our favorite editor.   Topping off this release is an extremely useful PDF document explaining the details and how to make the most out of the new brushes and palettes.

There are some minor downsides to this collection.  First, the PDF document is in Spanish and there are currently no translations available.  However this is a minor issue and doesn’t affect actual use of GPS. If the source to the document is released I suspect that the translations will follow in short order.

More importantly the updated configuration files will present a layout that will not fit on most desktops smaller than 1280×1024.   While the width of the windows fit on my 1280×800 laptop, the height of the windows did not and I was unable to get the window manager controls to resize the dock windows.  This, too, should not be a huge problem as you can drag the docks off from those windows and rearrange them to fit your needs, or simply don’t install the sessionrc or the toolrc.

Finally, the documentation refers to a number of brushes which I suspect are to be used with specific tools.  However, the brush names in the document do not match the brush names in the Brush dialog nor do they match the names of the brush files.

No license file accompanied the release though if my spanish is good enough it appears the page does refer to free software.

The collection is packaged in the 7z format, a zip like format available on Windows but which is not commonly used on Linux or Unix systems.  Fortunately a Linux port of an unpacking tool is available.  On Fedora systems look for the p7zip package and install with yum.  If you can’t find the package for your Linux distribution you can try grabbing the source code from its sourceforge page.  To unpack the package use the following command:

7za x gps_v1.0.7z

One of the features you won’t notice without deciphering the documentation is that most of the Tools now have a number of tool option presets.  To use these, click on the “Reset options from…” button at the bottom of the Tool Options dialog and select one of the new presets installed with GPS.  The presets for the Smudge tool are particularly interesting.

GPS adds additional presets to most Tool Options.

Examples of Ramón’s work with GPS can be found on his blog.

Update: 2009-03-07

I was browsing Ramon Miranda’s blog and found that someone has translated the PDF documentation into English.  The package is the complete GPS including all the original files (sans PDF) and the translation is in HTML. It uses the images from the original PDF so they don’t display well, though this could probably be fixed up a little with some CSS.  Anyway, You can at least get some idea of what the PDF is saying now.

It shouldn’t be hard to convert the PDF to english now, using the same format as the original.  I may try this if I can find a night to do all the cut/paste work.

Update: 2009-03-08

I’ve rewritten the english translation that was in HTML format into both OpenOffice and PDF formats using the same basic layout as Ramon’s original PDF documentation.  I’ve also cleaned up the grammer and made the document (IMHO) a bit easier to read.  I also added a small section on using the palettes, a title page and a table of contents.  Hopefully this will help those english readers who would like to understand how to use this very well done improvement to GIMP.

Update: 2009-03-10

I’ve noticed that I missed cleaning up the grammer in the sections describing each preset.  I’llupdate those after I finish my (currently due)  column for Linux Format later this week.

Update: 2009-06-08

Ramon pointed out I’ve been calling this by the wrong name:  it’s GIMP Paint Studio, not GIMP Paint Shop.  Mea culpa.

The slides aren’t not visually exciting.  It was only for a short 15-20 minute presentation at a local open source users meeting.