|
|
|
|
|
|
|
|
You can do professional graphic art on Linux systems. The tools are available, the documentation is growing, and the user communities offer a wealth of information and help.
by Michael J. Hammel
Ever since I wrote my first basic program to peek and poke my way through a series of animated block graphics on a TRS-80 Model 1, I have been intrigued by the use of computers for graphics. I learned every new language by modifying a graphics program I had written in some other language. In high school and my early days of college these programs were simple games---later I learned of the Mandelbrot and Julia fractal algorithms. These algorithms were relatively simple to program and so became my tool for learning new languages, environments and, more importantly, graphics systems.
Over the years this fascination would wax and wane. Not surprisingly, my interest would peak when some new movie with the latest, greatest special effects was released. Star Wars came out when I got my hands on the TRS-80, so naturally I had X-Wing fighters evading a simulated crosshair radar written in BASIC, albeit by the time the radar locked, the pilot of the X Wing had probably died from old age.
Late in 1995, a co-worker and I began to work on our company's web pages. I had done my own pages, but they lacked good graphics. He was convinced he could do the graphics while I did the HTML. His enthusiasm became annoying when he began to laud the merits of MS-Windows-based graphic tools like Adobe Photoshop, and went on about how Linux, and Unix in general, lacked any such tools. Since I knew most of the special effects I was seeing in movies were coming from Silicon Graphics or other Unix systems, I knew comparable tools must be available for Linux.
And then came Toy Story. I was fascinated. I was enthralled. I was completely hooked. I set out to find Linux tools that I could use to update my web pages and to show the world what could be done on a Linux box.
This article introduces the tools I found, tells how the information I gathered grew into the Linux Graphics mini-HOWTO (see Resources box), and explores how the graphics arena is evolving on Linux. I assume the reader is a graphics beginner, and I focus on tools currently available. I touch only briefly on the programming environments and libraries available to do graphics, since these require a more in-depth discussion; however, I also don't want to rehash the Linux Graphics mini-HOWTO. After reading this article, you can check out the mini-HOWTO to get more details.
When you get right down to it, there are really only four types of tools available for graphics on Linux:
Viewing - tools which display images but don't change themCreation - tools which create images
Manipulation - tools which change existing images
Conversion - tools which convert images to new formats
Various tools are available for each of these types. Many tools fit into more than one category. The dividing line between categories is not always clear, but the use of categories helped in organizing the Graphics mini-HOWTO.
Creation tools also provide one of two basic functions: they draw or they render images. Drawing tools provide the ability to interactively create shapes, called primitives, such as boxes, circles, cones or torii. Creation tools also include paint programs. Rendering tools build images based on model information, i.e., information that describes the shapes of primitives and their relationships in a scene. The simplest way to distinguish between the two is that drawing programs generally deal with 2D images, and rendering tools deal with 3D images. This is an oversimplification but it will suffice for this article.
Images are pictures, basically, which come in a number of formats. GIF, JPEG, PNG and TGA are some of the more common static image formats, but there are literally hundreds of others. No one format is the standard, so there isn't one format that every tool supports. GIF and JPEG are the most widely supported formats for web browsers, but you can expect to see PNG support in many browsers and other tools soon. Which format you use depends on the tools you use and the way you intend to use the images. For example, GIF isn't good for large posters, because it lacks support for more than 256 colors per image. TGA, on the other hand, provides a large range of colors but isn't supported by web browsers.
Static images, like photographs, are single, independent pictures. Animated images can be strings of static images or images created on the fly by programs written using special languages or programming libraries. A lot of interest in computer graphics has been generated by the use of animated images; however, it is important for new users to understand static images before moving into animation. For that reason, animation tools are not discussed in this article.
A number of programming libraries are available for use in supporting the various graphics formats and certain types of primitives, functions and algorithms. Libraries already exist for TIFF, JPEG, PNG, and many other image formats, so programmers don't have to reinvent the wheel with each new program they write. Also available are a number of languages and programming interfaces for creating 2D and 3D graphics and runtime animation, including VRML, OpenGL and PHIGS.
Figure 1. AC3D Screen with Imported DXF Model for a Sailplane
Figure 2. GIMP Windows
In my early days on Compuserve, GIF files were abundant and were viewed with programs like picem, which had few capabilities beyond displaying the image. The majority of tools available for Linux today do much more than view images.
A few tools are still around that do little more than view images. xwud (X Window Undump) is a program delivered with the base set of X11 clients for displaying files in the X-Windows Dump format created with a companion tool called xwd (X Window Dump). However, neither of these tools is feature-rich, and I use them only when I have no other way to do a window screen capture under X.
Most of the graphics tools available for Linux fall into the category of creation tools and allow you to draw or render images, interactively or through some form of scene description language. One of the most widely known of these is XPaint, a tool similar in style to the old MacPaint or MS Paint without as many features. Recent updates to the program have helped by providing additional options, but the rapid growth of tools like Photoshop have made the XPaint style tools less attractive. XPaint does provide some basic functions useful for creating texture maps for other tools. For example, one nice feature of XPaint is the ability to edit individual bits in an image.
A disadvantage to XPaint and similar tools is that it is not designed to deal with pixels as groups or to allow the modification of pixels by hue, saturation or intensity. Thus, XPaint gives you a canvas on which to paint, but not the ability to mix your colors before you paint or to blend colors (or shades of gray) on the canvas itself.
The first tool I discovered after seeing Toy Story was POV-Ray, the Persistence of Vision Raytracer. POV-Ray, another form of creation tool, is a 3D photorealistic renderer (not a drawing program). It works by reading in a text file that describes the scene to render. The scene describes objects made up of primitives (boxes, cones, torii, triangles and/or combinations of these and other shapes), descriptions of the textures to place on these objects, the lighting in and around the scene and the point of view of the ``camera''. Programs that do raytracing use one particular method for determining how light acts on the objects, and thus, how the objects will look to the viewer. This method traces the path of light beams through the scene; how this is done is really unimportant to all but the most experienced raytracing artist. Other methods for computing the way light behaves in a scene are radiosity and the REYES algorithm, the method used in making Toy Story. Tools using these methods are discussed in the Linux Graphics mini-HOWTO.
The disadvantage to tools like POV-Ray is the lack of user interaction. POV-Ray is a sort of batch processor---it processes a file and produces output. No feature of POV-Ray allows you to create input files. Input files must be created either by hand or by the use of a modeller. Modellers, like CAD systems, use wireframe representations of the objects in their scenes. The use of wireframes helps to visualize the scene from various points of view without the overhead of adding the textures (which generally take a long time to compute, even on fairly fast systems).
There are three modellers available for Linux: SCED, Midnight Modeller, and AC3D. SCED, available as source, is portable across multiple Unix platforms and makes use of the Athena widget set. I found its interface a little difficult to use, but the ability to group objects, called CSG (Constructive Solid Geometry), was very nice. Midnight Modeller is a tool ported from the MS-Windows environment. The author does not release source code, so the program is available only in binary format. The interface is very CAD-like, but the colors tend to be harsh, making the program difficult to use. The window features, such as menus and dialog boxes, are very DOS-like, which I find a distraction on an X-Window system. Neither of these is the quality of some of the better modellers for MS-Windows.
AC3D is a new tool with a very nice 3D (Motif-like) interface that uses front and side view windows and can do some real-time rendering. I came across this tool just as I was finishing this article, so I haven't had time to give it a proper review. Of the three, it appears to be the most user-friendly with the most intuitive interface. AC3D is shareware for Linux (about $15 US) and comes in binary format only at this time.
When I first started gathering information about graphics tools, I was primarily using POV-Ray, as I had found the POV-Ray web site with its large collection of tools. However, the tools were mostly DOS/Windows binaries or written by DOS/Windows users and included the C source. Since I wasn't running DOS or Windows and there was little information on which tools would work on Unix, I started the Unix Graphics Utilities web page (this page is not exclusively for Linux). I used the information I gathered as the basis for and the incentive to write the Linux Graphics mini-HOWTO, since all my testing was done using Linux systems.
Many other tools can fit into the creation category. For example:
Again, you can get more detail on these tools from the Linux Graphics mini-HOWTO, including where to obtain the tools.
Figure 3. The POV-Ray Home Page
A manipulation tool that has gained a rather large following in a fairly short time is the GIMP, Generalized Image Manipulation Program. The GIMP is being developed primarily by Peter Mattis and Spencer Kimball at UC Berkeley. This tool, designed as a Unix-based counterpart to the Photoshop-caliber tools available on other operating systems, has a limited set of base features at this time; however, the design includes the ability to add plug-ins which expand the features of the program. The result of this design philosophy has been a very large collection of plug-ins from a growing developer base. I've added my own plug-in, the Sparkle plug-in based on John Beale's Sparkle utility. There are tutorials and tips and tricks web pages (see the Resources box) as well as a relatively strong effort to organize the registration, format and distribution of the plug-ins.
The GIMP provides both user interaction and the ability to combine images through various blending techniques (nearly all of which are done with plug-ins). By combining two images, say by subtracting one from the other, it is possible to take 2D black and white text and turn it into a full-color 3D image resembling anything from a plasma field to a glowing, tube-shaped jelly. The GIMP is a major step beyond the basic box, circle and fill capabilities of XPaint.
Combining images is done through what is known as ``Channel Operations'' (commonly referred to as channel ops). These are operations on individual pixels based on the intensities (brightness) or color of the pixel and/or surrounding pixels. In short, a channel operation is the blending of colors in one or more images. Channel ops are what make the GIMP a more attractive tool than XPaint to the graphics artist. (Note that the basic capabilities of XPaint are not all implemented in the GIMP, so XPaint is still useful.)
The disadvantages of the GIMP are twofold: it is in early development, and its GUI base is in the process of changing. The reliance on Motif is being removed and a new toolkit, gtk (the GIMP Toolkit), has been developed. This toolkit is in the early stages of testing. The base GIMP features and most of the plug-ins lack any detailed documentation. However, these problems are relatively minor and are being addressed. The GIMP's advantages are that, at this time, it is the only freely available program of this caliber, and it has a large support base from the plug-in development and user communities.
XV is another tool with wide audience appeal. XV, by John Bradley, is a shareware program that supports a large number of file formats for reading (displaying) and writing. A large printed document is available to those who register their copy of the software. Although the number of algorithms for manipulating images that XV supports is smaller than the plug-in base for the GIMP, the ability to control the images' colors is much greater in XV. You can control the hue, saturation and RGB (red, green and blue) levels interactively in more ways than the GIMP provides (although there is at least one GIMP plug-in that allows this control to some degree).
From my point of view, the main difference between the GIMP and XV is that the latter is designed for scientific image processing and the former for artists. I'm sure there are a few people who would argue, But I've seen television interviews of JPL and NASA employees who were using XV to display planetary images.
Figure 4. Image Produced Using GIMP Plug-ins
A couple of animation tools are worth mentioning. The first is mpeg_play, a tool for viewing MPEG-formated animation files. Its companion, mpeg_encode, creates MPEG files. It can also display XING files, which uses a variation of MPEG encoding. However, mpeg_play doesn't manipulate the image in a way that can be saved back to file---it modifies only the displayed image.
Xanim is similar to mpeg_play, but supports a much wider set of input file types and capabilities for resizing images on the fly.
One of the problems you'll encounter when working with graphics tools is support for specific image file formats. For example, while working with the GIMP, you may want to work with TGA images, since TGA provides as many as 24 bits of color while GIF formats only provide 8 bits of color. Having a greater range of colors gives a very smooth blending of colors when you add, subtract, blur or otherwise manipulate the images with the GIMP. However, if the image you are creating is destined for a web page, you need to convert it to GIF or JPEG format. If the GIMP didn't provide a way of doing this (which it does, but this is just an example), you would need a tool for converting the image formats.
PBMPlus and NetPBM are a set of tools for converting images between various formats. PBMPlus tools, originally written by Jef Poskanzer, take one image file of a particular format as input and convert it to an intermediate format called PPM (Portable Pixmap). Another PBMPlus tool is then used to convert the PPM format to the target format. For example, to go from TGA to GIF you might use
tgatoppm input.tga | ppmquant 256 | \
ppmtogif -interlace > output.gif
The ppmquant is another type of tool in PBMPlus used not to convert the file to another format, but to alter the image in the same way. In the case of ppmquant, the input image is quantified down from some large number of colors to 256. Doing so makes it possible to reduce the size of the data file, and depending on the image, may not alter the appearance so much as to make it unusable. You may choose to reduce the number of colors because computers can record more subtleties of color than the human eye can distinguish, and on a web page, small data files make for faster loading.
PBMPlus tools work by processing data from standard input and writing to standard output, which allows the user to string a collection of tools together in a series of pipes (as in the above example). All the tools are meant for command line use, i.e., no graphical interface is available for these tools.
NetPBM is a later incarnation of PBMPlus, after Jef stopped working on it and development was picked up by another team of developers. However, I believe Jef has once again returned to working on PBMPlus.
Another conversion tool is ImageMagick. This set of tools has a graphical front end, but they can also be used as command line tools, similar to the PBMPlus tools. I haven't used these tools much, but I know they have a number of supporters.
Programming interfaces aren't really end-user tools, but I'd like to mention a few, since these interfaces are likely to be the basis of the next generation of end-user tools.
One of the most popular and widespread programming interfaces is OpenGL, from Silicon Graphics. OpenGL is a hardware-independent programming interface that provides commands and operations to produce 3D, interactive applications. This technology is fairly new and requires support in your X server to make use of hardware accelerations provided by video adapters. Although the hardware support is not required in order to use OpenGL, without it or a relatively fast computer, OpenGL applications will run a bit sluggishly. A freely available version of OpenGL, known as MesaGL, implements most (if not all) of the OpenGL command set. Also, OpenGL has a very low level interface, much like Xlib is to X-Windows; therefore, higher level toolkits, such as GLUT or aux, are more appropriate for writing applications. [For more information on OpenGL/Mesa, see Linux Goes 3D elsewhere in this issue---ED.]
VRML is the Virtual Reality Modeling Language, designed to provide a 3D interface using a markup language similar to HTML. The current VRML 2.0 specification is based on Silicon Graphics Moving Worlds specification. Only a few VRML-capable browsers are available; however, there is strong industry interest in this language, and I expect many browsers will be supporting it in the near future. A recent report by C|Net cited both Netscape 3.0 and MS Internet Explorer as supporting VRML to some degree.
Java is not specifically graphics-oriented; its real purpose is to provide a platform-independent programming language. Java has gained its early reputation by virtue of a set of graphics applications and toolkits available via the World Wide Web. My own web pages make use of a scripting language known as JavaScript (from Netscape).
A number of other programming libraries have been announced on the comp.os.linux.announce newsgroup:
As I mentioned earlier in this article, web browsers support the GIF image format, and some JPEG; most now support both formats. In choosing one of these formats, you should consider the following:
The answers to these questions help determine which image format to use. JPEG will usually compress images without losing too much of the information and appearance of the image, than GIF. Therefore, if your images take up a lot of disk space (a problem since my ISP doesn't provide much disk space for private web pages), or you don't want to force your readers to download large images, JPEG images would probably be better. However, if your image has a background you do not want displayed but you do want the background image or color of the page to show through, you need to use GIF-formatted images, as JPEG does not provide transparency in images.
If you want your images to fade into view as the text around it is displayed, you need to use GIF images. This trick is called interlacing, and JPEG does not support it. If you have large images (not necessarily in bytes, but ones that take up a lot of screen space), it is more user-friendly to use interlaced GIF images.
Once you've decided on the type of images you'll use, you can start creating them. There are many tricks and tips, but for starters I suggest you get hold of the following tools:
You can use these tools, along with a CD-ROM of images (readily available from computer software stores) to create your own little web world. When you get adventurous, you might try adding some complex 3D images using POV-Ray. If you're interested in using special fonts with the GIMP, I suggest looking for packages containing Adobe Type 1 fonts. Once you have these you should check out the typ1inst package, which will allow you to install the fonts for use with your X server.
As you can see, there is really too much information about graphics tools to cover in a single article. Nearly all these tools are still evolving, adding new features and capabilities through the combined efforts of many people. Tools based on the more powerful programming languages, such as Java and OpenGL, are not far off, and it is only a matter of time before commercial versions begin to appear. Support for live video capture is available for some X servers and support for hardware accelerations and video capture boards is forthcoming. I intend to cover all of these in the Linux Graphics mini-HOWTO as they evolve.
You can do professional graphic art on Linux systems. The tools are available, the documentation is growing, and the user communities offer a wealth of information and help. And what's best of all---you can now find the tools you need using a single reference: The Linux Graphics mini-HOWTO.
Michael J. Hammel (mjhammel@csn.net) is a transient software engineer with a background in everything from data communications to GUI development to Interactive Cable systems---all based in Unix. His interests outside of computers include 5K/10K races, skiing, 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. You'll find out more there than you really wanted to know. He also requests that any commercial vendors of graphics systems contact him, as he'd like to include these in the mini-HOWTO in the future.
