Graphics Tools for Linux
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 them
Creation - 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
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- LiveCode Ltd.'s LiveCode
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide