The Artist’s Guide to GIMP Effects

I’m a little late getting this news out, but Ramon Miranda has published GIMP Paint Studio V1.4, a collection of presets, brushes, and other files for use with GIMP 2.6.  GPS reconfigures GIMP so that advanced users can achieve a more professional experience with GIMP, especially when combined with the use of a drawing tablet.  I use GPS for my day to day GIMP work.

GPS requires a manual installation to your .gimp-2.6 directories.  I wrote a simple Makefile for installation of v1.3.7 on Linux systems, though this may require updates to work with GPS 1.4. 

Related posts

• Using Drawing Tablets with the GIMP (0)
• Tutorials (0)
• The Artist’s Guide to GIMP Effects (2)
• Plugins (0)
• Open Forum (0)

This seems to come up fairly often.  Non-programmers often have a difficult time understanding what to do with scripts and plugins they download for use with GIMP.  It isn’t clear what the difference is between them.  What constitutes a script and what constitutes a plugin?  Aren’t python programs considered scripts?  Are they all just plugins?  What do you do with these programs in order to use them with GIMP?

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.

Related posts

• No related posts.

I was rereading Linux Format tutorial for issue 123 – making star fields – and realized it is missing an important step right up front.  In the printed article the following paragraph:

Add a new layer (Layer > New Layer) and name it Small Stars. Set the layer colour to the foreground colour, open the HSV Noise filter (Filters > Noise > HSV Noise) and set the Holdness to 3, the Hue to 20, the Saturation to 90 and the Value to 100. Apply this to the Small Stars layer by clicking the OK button. HSV Noise renders coloured noise, so we need to desaturate it. Go to Colours > Desaturate and use the Luminosity setting. Click OK to apply this to the layer.

Should read:

Add a new layer (Layer->New Layer) an name it Small Stars.  Drag the background color (white) into the layer, open the HSV Noise filter (Filters->Noise->HSV Noise) and set the Holdness to 3, the Hue to 20, the Saturation to 90 and the Value to 100.  Apply this to the Small Stars layer by clicking the OK button.  HSV Noise renders colored noise, so we need to desaturate it.  Go to Colours->Desaturate and use the Luminosity setting.  Click OK to apply this to the layer.  Invert the colors in the layer (Colors->Invert).

The two things to note that changed are that the new layer is first filled with white, not black, and after applying noise and desaturating the colors in the layer need to be inverted.  Now you have white dots on a black background.  In the original, you have nothing because the original layer color was black and applying noise to this was nearly invisible.

Later, there is a scaling issue.  Instead of scaling the Large Stars down by 40% it should be scaled down by 60%.  That would make the layer large than the original while 40% would be smaller than the original.

Finally, before moving to the Clustering step, change the Large Stars layer mode to Screen.  Do this before you start to paint in the layer masks for the Large and Small stars.  If you don’t do this it will be hard to see the results of masking out the stars.

Looks like I really munged this tutorial.  My apologies to both Linux Format and my readers.  I should do better than that.

Related posts

• Using Drawing Tablets with the GIMP (0)
• Tutorials (0)
• The Artist’s Guide to GIMP Effects (2)
• LXF releases PDFs of a bunch of my tutorials (0)
• Looking at 2.6 (4)

This very cool trick comes from Saul Goode, courtesy of the GIMP User Mailing list.  To create a zig zag pattern very quickly…

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:

Related posts

• No related posts.

It’s a good thing I check my blog stats otherwise I never would have known about this.  Linux Format has released, through TuxRadar, the PDFs for 18 of my GIMP tutorials from my column in their magazine.  Pretty cool.  I’d always hoped they’d get a wider net audience.  Too bad I can’t put them on my book site too.  Ah well, at least everyone can see them now.

Note that the downloads are by BitTorrent only at the moment.  So I can’t link to individual PDFs from here.

The tutorials include the following:

• Product Design For Geeks – How I made a T-Shirt design (which you can find on my CafePress site)
• Shattered Face – Fast and easy way to break an object into many pieces
• Leopard-style Icons – Icons like what you get on a Mac
• Sin City Style – A little artwork similar in style to the popular Sin City movie.
• Summer of Love – sun beams and a happy couple
• Travel to the Stars – making space images
• Going to Warp Speed – a warp effect like you might see on older Star Trek movies
• Create a Fire Goddess – burn baby burn
• Decay in the City – life after the apocalypse
• Enhance the Interface – introducing GIMP Paint Studio
• iPod Fun – guess what this is?
• Use other tools – GIMP with Scribus, Inkscape and OpenOffice
• Text Effects – making a wine bottle
• 3D effects in GIMP –
• Speedy Color Fixes – fixing colors in photos
• Printing and Color – GIMP, CUPS, and Gutenprint
• Know Your Selections – tips on using selections
• Creative Text wtih GIMP – Map an image onto text so that the entire image is nothing but colored text but still looks like the image

You can see some of the resulting artwork from these tutorials in my LXF gallery.

Oh and one note for TuxRadar:  it’s spelled “GIMP”, not “Gimp”. 

But thanks for posting those!

Related posts

• Using Drawing Tablets with the GIMP (0)
• The Artist’s Guide to GIMP Effects (2)
• Looking at 2.6 (4)
• Tutorials (0)
• Plugins (0)

This is pretty high end so not typically what I would refer readers to but if you need a high end colorimeter the Hubble from X-Rite now has an SDK available for Linux.  Apparently this was built for cineSpace, a Color management system for the film and television industries.  Unfortunately I don’t think this SDK is open source.

It would be interesting to see if this device generates profiles that GIMP can utilize.

Related posts

• The Artist’s Guide to GIMP Effects (2)
• GIMP and Linux in Hollywood (0)
• Working Production Edits for Section V (0)
• Using Drawing Tablets with the GIMP (0)
• Tutorials (0)

I wasn’t aware of this till recently but GIMP 2.6 has an option for setting the number of processors to use for certain processes. Multiple cores are like multiple CPUs except they all live in the same chip.  Most modern computers are being shipped with dual core or better though you can still purchase single core systems too.  I happen to have a number of dual and quad core systems though my laptop is an older single core.  The advantages of having multiple cores is that your computer can perform certain operations in parallel.  This makes certain operations must faster.  While you don’t get much benefit from multiple cores when working on an ordinary text document, you can definitely see the improvement in certain graphic and video operations.

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.

Related posts

• Update: LXF star field tutorial (0)
• Tutorials (0)
• GIMP 2.8 has a schedule, mostly (1)

There is an ongoing discussion on the GIMP User mailing list regarding color profiles.  One user was having problems with GIMP reading proper profile information from files produced by Pentax cameras.  It turns out that the camera was placing the information in custom fields so GIMP EXIF support never sees it.

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.

Related posts

• TWAIN for Linux: is there a new scanning solution on the horizon (2)
• Tips and Tricks and Resources (0)
• New User FAQ (0)
• Looking at 2.6 (4)
• Inexpensive tablets for Linux and GIMP? (5)

Martin Nordholts has published a tentative (and very fluid) schedule for GIMP 2.8.  The schedule currently calls for the first 2.8 release candidate on April 2, 2011.  Some of the items of interest that are under development for 2.8 include

• Resource tagging – allowing searches for brushes, for example, by tags similar to social networking tags
• Layer groups – allowing grouping of layers to make various layer and transform operations easier
• Single window mode – craved for by those who come from non-Unix environments

Along with this are a long list of bug fixes.  Obviously we can’t hold the developers to this schedule, but it’s a basic plan for 2.8 and it helps those outside the developer sphere to know what the current plans are for the next release.

Martin has calculated that the developer community combined provides 3 full work days (8 hours per day) each week to develope GIMP.  He’s also made estimates on the amount of 8 hour work days that are required for each task for 2.8.  Combined, these two items produce the date for the release candidate. We can only wonder how much the schedule could be sped up if the developers got a little more help.

I’ve never seen anyone publicly attempt this amount of scheduling for the GIMP project and I applaud Martin’s efforts in this area.  Managing a project schedule for GIMP is no simple task since no one can guarantee the number of developers available, how much they might accomplish nor the amount of time they’ll have to work on the project.   Still, it’s nice to know what they’re working on and their best guess as to when it might be available.  It’s sets public expectations in a positive manner.  At least I think so.

Martin includes a sheet in this document that starts the task list for GIMP 2.10/3.0.  It looks like there is a desire for a unified transform tool, apparently combining the rotate / perspective / scale / shear / flip tools into a single tool.  I suppose that would be a good idea.  I think a unified tool might require excessive configuration changes each time we change context, but maybe not.  We’ll just have to see what they come up with here.  There is also work schedulde for 2.10/3.0 on move drawing operations on the canvas to Cairo.  Cairo is a platform independent vector graphics library that is has been in use for GTK+ a nd a number of other projects for a number of years.  I’ve not seen the discussions on Cairo for GIMP so can’t say if this is specifically a performance benefit or a feature benefit or both.  In any case, Cairo is being used in many projects and its likely to be a big plus for GIMP too.

Related posts

• GIMP Paint Studio Collection (16)
• Tutorials (0)
• New User FAQ (0)
• Inexpensive tablets for Linux and GIMP? (5)
• GIMP and multicore processors (1)

I’m preparing to update my GIMP book and decided it would be best to work from the source repository.  A long time ago that repository was in CVS and you needed to download a bunch of GTK related packages as prerequisites.  This was actually pretty easy.  Then things moved to SVN and things were still pretty easy but you needed different repository tools.  Now things are in GIT and you need more packages unrelated to GTK, such as GEGL and BABL.  Things keep getting harder.  Sounds like GNOME development in general.

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.

Related posts

• New User FAQ (0)
• Developer release: GIMP 2.7.0 (0)
• Tips and Tricks and Resources (0)
• Looking at 2.6 (4)
• Inexpensive tablets for Linux and GIMP? (5)