Graphics Formats for Linux
If there is a single unifying feature of the computer world, it is non-conformity. In no place is this better illustrated than computer graphics. Literally dozens of different formats exist to do the same thing: store graphic images. Proprietary formats, independent free standards, and international standards all vie for attention. Fortunately, the computer community has settled on just a handful of formats. Some, like TIFF, are the jacks-of-all-trades and are widely used. Others, like GIF, have a niche that they dominate. But whatever the context, there is always more than one way to store images.
This article first provides a brief introduction to graphics on Linux, including format and type, compression, file structure, and various features. It then continues with descriptions of the common graphics formats found in the Linux world and programs with which to manipulate them.
Graphics formats come in two basic varieties: raster and vector. Raster formats store the entire image pixel by pixel and are the most commonly-used formats. Vector formats, also called descriptive formats, do not contain pixel image data; instead, they contain a series of commands telling a display program how to draw the image.
The most common use of vector formats is in computer aided drafting (CAD). Describing a line, for example, as a starting point, an ending point, and a color, as opposed to many colored points in a field of points, allows a program to manipulate the line as an object, making it easy to change color, length, and position. Another common use is in raytracing programs. These programs take geometric objects and trace the path of light rays to find shadows and highlights. Since the rendered objects are geometric shapes, it is much easier to store an image as “dodecahedron at (3,4,3) with size 2 and color 27” than as an array of pixel values, especially since the scene to be rendered is three-dimensional. Of course, once the scene is raytraced, the resulting image is stored in a raster format.
Images come in four basic types: monochrome (black and white), grayscale, color palette, and true color.
Grayscale and color palette images typically have 2, 4, or 8 bits per pixel. They use lookup tables that must be included in the image file; each entry in the color lookup table gives the red, green, and blue values for a color. Grayscale images have a similar lookup table for gray values. Each color or gray value is in a range of 0-3 for 2-bit images, 0-15 for 4-bit images, and 0-255 for 8-bit images. The actual image pixel data is a series of color or gray values corresponding to table entries which give the actual color of each pixel.
True color images are 24-bit images and are usually stored as 8 bits of red, 8 bits of green, and 8 bits of blue per pixel. Some formats may use different color models than RGB. The JPEG format, for example, uses a colorspace based on the luminance and two chrominance values (YCbCr). True color images do not need a color lookup table or palette.
Compression is integral to most graphics formats. An uncompressed 640x400x256 color image requires just over 256,000 bytes, while a true color image of the same size requires three-quarters of a megabyte. Although many compression schemes exist, only a few are common in graphics applications. LZW, LZ77, Huffman, and run-length encoding are lossless, meaning that the image is reproduced exactly when uncompressed. The cosine transform is the basis for the “lossy” JPEG format. We aren't concerned with the details of the compression schemes here.
JPEG gives by far the best compression, but at the expense of exact image reproduction and speed. Acceptable results are common with compression ratios of 25 to 1, that is, the compressed file is 25 times smaller than the original. Ratios of 100 to 1 may be possible if image quality is not a primary concern.
[FOOTNOTE:A better algorithm does exist, however: fractal image compression. This method gives good results at 100 to 1 and is finding many applications, though it has not yet been widely implemented as a general purpose graphics format.]
LZW and LZ77 are the best lossless schemes and produce similar results: usually around 2 to 1 compression. The modified LZ77 used in the PNG graphics format is slightly slower at compressing images than LZW, but it creates smaller files and is faster at decompressing. LZ77 is also used by the general purpose compression programs ZIP, GZIP, and PKZIP. Until recently, the use of LZW was much more common than LZ77. Its use is falling, however, because it is a patented algorithm, and UNISYS requires royalties for its use. Nonetheless, both GIF and TIFF, two of the three most common formats, use it.
Run length encoding (RLE) is the most common scheme and the least effective. It is, however, very fast compared to other compression algorithms. Its basic mechanism is very simple: when a string of pixels with the same value is encountered, RLE outputs the pixel value and the number of consecutive pixels with that value. Complex images do not compress well with this scheme, although monochrome images often compress very well.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
|Android Candy: Intercoms||Apr 23, 2015|
|"No Reboot" Kernel Patching - And Why You Should Care||Apr 22, 2015|
|Return of the Mac||Apr 20, 2015|
|DevOps: Better Than the Sum of Its Parts||Apr 20, 2015|
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
- Tips for Optimizing Linux Memory Usage
- "No Reboot" Kernel Patching - And Why You Should Care
- DevOps: Better Than the Sum of Its Parts
- Return of the Mac
- Android Candy: Intercoms
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Designing Foils with XFLR5
- Non-Linux FOSS: .NET?
- Play for Me, Jarvis