|
|
|
|
|
|
|
|
This first of a four-part series introduces us to the GIMP, a Linux power tool for the graphics artist. Mr. Hammel used the GIMP to design this month's cover.
by Michael J. Hammel
It has been a long time coming, but the wait is over: Linux has its first real end-user power tool. It's not for administrators. It's not for network hacks. It's not another developers tool. It's for artists. It's for media managers and graphics nuts. It's for fun. It's for real. It's the GIMP.
This article is the first of a four part series on the GIMP. This first part is a general introduction to the application including some definitions and system requirements. Future articles will cover basic functionality, an exploration of the Image Window including the use of layers and a detailed walk-through of the Toolbox.
The GIMP is the GNU Image Manipulation Program, a tool for manipulating graphics images that borrows its look and feel from the popular Macintosh and Windows program from Adobe called Photoshop. It is used for all varieties of image processing, photo retouching and image composition. Built-in features, such as scripting, make it very easy to create logos for web pages and magazine cover art, and the Plug-In API provides a convenient mechanism for extending the very rich standard feature set. Support for a large number of input and output file formats is provided, including support for reading Photoshop files which is under development at the time of this writing.
It is nearly impossible to discuss certain features of the GIMP without first introducing others, but one must begin somewhere. I will attempt to limit confusion by mentioning features before they are discussed. Also, it will be impossible to go into complete detail of all aspects of the GIMP even in four articles. Layers, in particular, will be difficult to discuss at length without compromising discussion of other aspects of the application. Perhaps, if there is enough interest, I can expand this series into a full sized published text. In the meantime, these articles will provide an introductory view of this wonderful new tool.
The first thing you want is the program itself. Binary versions of the latest release packaged in an RPM format will most likely be available from Red Hat, although at the time of this writing none of the latest developers releases were available in binary. The GIMP's web site will also have binaries available for some platforms, including Linux. Of course, the GIMP is also distributed with full source code as well. The source distribution can be retrieved from ftp://scam.xcf.berkeley.edu/pub/gimp/developers/. There are two files needed to build and install from the source: gimp-1.0.tar.gz and gimp-data-1.0.tar.gz. The former is the real source code and the latter is the standard set of brushes, palette and so forth that comes with the default source distribution. Note that the actual version and release numbers might be different, so just look for the latest releases on the FTP site. At the time of this writing the actual release number was 0.99.10.
Building from source should be a straightforward process:
This process is required for both the source code and the data files archives. If you intend to install in the default locations under /usr/local, you need to be the root user to do the last step. If you wish to install in some other location, you can instead type:
./configure --prefix=/There are a number of options available via the configure program. Check the INSTALL file first, and if you can't find what you need there try running:
./configure --helpAlso, as always, help is available from the GIMP Developer and GIMP user mailing lists (see the section at the end of this article for Resources on the Net).
Once the GIMP has been installed you're ready to start experimenting. Starting the program is simple: type gimp. If your system does not support the MIT-SHM extension (see below), you can type:
gimp --no-xshmWhen the GIMP starts, it first reads a configuration file located in the .gimp directory located in the user's $HOME directory. This directory is where user-configurable options, user-specific plug-ins, palettes, brushes and so forth are kept. A similar set of directories are kept in the system directories (by default under /usr/local/share and /usr/local/lib).
If the GIMP does not find the .gimp directory in the users $HOME directory, it will create and populate it for them. Since this process can potentially take longer than just a few moments, a window is displayed explaining what the program is doing. The user need not do anything during this time. When the initialization of the .gimp directory has completed, the program opens the main window, and the user can begin work. Future invocations of the application will not include the creation of the .gimp directory unless that directory is removed for some reason between GIMP sessions.
The configuration file, gimprc, contains the specifications for the directory in which the GIMP is to find all of its files. In this way a user can, if desired, use a locally installed version of the GIMP instead of the one installed in the system directories. The gimprc file also defines the default settings for many of the features for the application. Such items as the speed at which the ``marching ants'' (the moving dashed line that denotes a selected region of an image) move, the number of colors to use, the GIMP colormap option and the Gamma correction setting are defined in the gimprc file. This file is well commented so you shouldn't have too much trouble understanding what the various configurable parameters affect. You should probably take a look at this file at least once before starting the GIMP, although it may not be absolutely necessary for you to become familiar with it, especially if you are using a high-end system with a high-end graphics adapter.
The GIMP uses its own temporary and swap files for saving runtime data. Most temporary files get removed at the end of a GIMP session, however some of these files may remain after exiting. It is recommended that the temporary directory be a directory that is specific to the individual user. This directory should not be one that is cleaned up by the system automatically. The swap file is a file that can get very large due to the use of the tile-based memory scheme that the GIMP uses. Because of this it is recommended that the swap file directory be /tmp or some other directory on a file system with plenty of disk space. Defaults for both the temporary files directory and the swap file directory exist in the gimprc file. You should verify that these are appropriate for your use before doing any heavy, image-processing work.
One of the settings in the gimprc file that you might consider changing is the one that allows the GIMP to use its own colormap. If you have a system with 1MB of video memory (not system memory--there is a difference) and you wish to run in a high-resolution mode such as 800x600 or 1024x768, you may only be able to run with a maximum of 256 colors. In this case the GIMP (and many other applications, such as Netscape) will quickly run out of colors. In some cases, with smart applications, you'll get what's known as ``color flashing''--where the color of windows and the background changes depending on which window currently holds the focus for keyboard and mouse input. Although a bit annoying, color flashing is the result of a little trick provided in X Windows applications to help guarantee they have enough colors. They do this by installing their own colormap. The GIMP allows you to do this in the gimprc file. However, this option is not turned on by default. If you have a low-end video system and run using an 8-bit (256 color) display, you'll want to uncomment this option in the gimprc file before starting the GIMP. If the color flashing that occurs is bothersome, there is another option for setting the color cube. Changing the values here, however, is a little trickier and should probably only be done if you understand what ``dithering colors'' means.
As with nearly all X applications, the GIMP supports the ability to run on one machine and display on another. Most X applications accept, through the Xt toolkit, the -display command-line option to specify a remote host to display on. The GIMP accepts a similar command except that two dashes are required. Somewhere in the evolution of Linux there was a migration from one to two dashes for command-line options. I'm sure there is a valid reason for it--I just never figured out what it was. In any case, the command-line option for displaying on a remote system is:
--display <remote host>:<display number>.<screen>For most users, the display number and screen will both be 0 (zero).
The GIMP has been ported to many of the well known Unix platforms, including Solaris, SGI, FreeBSD and, of course, Linux. The software is not hardware specific since it makes use of the low-level X11 interface provided by Xlib (GIMP's toolkit, gtk+, does not rely on either the Xt toolkit or Motif). This allows the X server to handle the actual screen drawing and lets the GIMP provide the computational work of the display. Consequently, the GIMP works with all of the well known X servers for Linux (MetroLink, Xi Graphics and XFree86). As with any high-end graphics tool, you'll have better results with the high-end graphics adapters. I use a Matrox Mystique at 1152x900 with 4MB of video memory that allows up to 16 million colors. Be sure to check the server documentation or vendor's marketing material to find out if the video adapter you use is supported.
One extension to the X Window Protocols that many X servers support is the MIT Shared Memory Extension. This extension provides a method for an X application to make use of the shared memory resources of the operating system without having to go through the Xlib interprocess communication channel. For this reason, the processing of large images by the low-level X routines can be done much faster. The GIMP makes use of this feature to help provide speed enhancements. Unfortunately, not all X servers provide support for this extension. If it appears the GIMP is not behaving well, you can try starting it with the --no-xshm command-line option to disable the use of the MIT Shared Memory Extension. One common scenario which often needs this option is when a user starts the GIMP on one machine but has it display across the Net on another system.
Note that all three of the major X server vendors (MetroLink, Xi Graphics and the XFree86 Project) currently provide servers for Linux that support this extension. However, older versions of these servers may not. Some of the popular (but older) X terminals from NCD also do not support this extension. To find out if your server has this support, type:
xdpyinfo | grep MIT-SHMIf this command prints out ``MIT-SHM'', your server supports the extension. If it doesn't, you need to use the --no-xshm option. On the Xi Graphics AcceleratedX 3.1 server running with a Matrox Mystique video card, the shared memory extension appeared to function incorrectly and the GIMP had to be run without the use of the X shared-memory support. A small number of other cards had similar problems with this server. If you have few problems other than the windows which display images are being redrawn incorrectly (they appear to have overlapping tiles, for example), you should consider running with the X shared-memory option disabled. Note that Xi Graphics is currently working to resolve this problem, and the problem does not exist for all cards supported by their X server.
The GIMP uses a tile-based memory management system so that extremely large images can be worked on without exhausting physical memory. Even so, work like this benefits tremendously from additional system memory. I recommend you have at least 16MB of system memory to do simple web page graphics. If you intend to get into print media you'll be working on much larger images, with X/Y dimensions of 2000x2000 or more. In these cases you need at least 64MB of memory and probably more.
CPU speed is also important for doing high-end graphics work. You can use the GIMP on any Linux-based hardware platform, but you may get frustrated waiting for some pixel operations to complete on older systems. For example, operations like blurring, mosaics or adding sparkles to regions of images can be very CPU intensive. I used a 486/66DX2 (i.e., a speed doubled 486-33MHz) system with the original release of the GIMP well over a year ago. The new version benefits a great deal from the added power of the Cyrix P166 (133MHz) system I currently use. The equation for computer graphics is simple: faster CPU + more memory = reduced frustration.
The GIMP does not at the time of this writing have direct support for scanners, tablets or pen devices. Work is currently underway on a generic scanner interface (called SANE) which includes a plug-in for use with the GIMP. This plug-in is not part of the base distribution at this time. I expect that scanner support will be much more extensive for the GIMP by the time this article reaches the newsstand.
Support for Wacom tablets is also in the works. A number of contributors have the Wacom ArtZ working with XFree86, and a couple of individual projects were started to integrate the tablets with the GIMP using the X Input Extension. Recently (in June 1997), these projects began to merge. Again, by the time this article reaches the newsstand, this support should be much more extensive. It is interesting to note that Wacom is a commercial supporter of the XFree86 project. At the time of this writing based on information from their web sites, neither the MetroLink nor Xi Graphics X servers appear to support Wacom tablets.
The version of the GIMP that I use, the developers 0.99.10 release, requires approximately 19MB of disk space for the runtime files. This includes about 11MB for the binary, 5MB for the various plug-ins and about 2.5MB for the libraries and data files, such as patterns, brushes and so forth. The source code takes up approximately 11MB uncompiled.
Working with images is very disk space intensive--this means that you need to have a lot of disk space for all the images you will be creating or manipulating. You also need space for variations of images, photos from archives to use as starting points for creating your images and a number of copies of the same image in different formats. Managing all the files alone could be a full-time job (and in large media shops, it is a full-time job), so be aware that in the long run you may need to add hard disk space.
Now that you know a little about what the GIMP is, where to get it and what type of hardware and software requirements and support it has, you're ready to look at the application itself. Next month we'll discuss some basic features such as file I/O, dialog windows and cursors. Each of these topics could fill a chapter in a book, but we're going to try to cover them in one article. So hang on, we're just getting started.
Michael J. Hammel is an X Windows and applications software engineer for EMASS in Denver, CO. He is the author of the ``Graphics Muse'' column in the Linux Gazette, keeper of the Linux Graphics Mini-HOWTO and co-author of The Unix Web Server Book from Ventana. His interests outside of computers include 5K/10K races, Thai food and gardening. He suggests if you have any serious interest in finding out more about him, you visit his home pages at http://www.csn.net/~mjhammel. He can be reached via e-mail at mjhammel@csn.net.
