At the beginning of this chapter, I posed five questions about the GIF file format. Well, before we delve into the inner workings of the GIF format, here are some answers:
Why isn’t a GIF with 129 colors smaller than one with 256 colors?
This is because the number of entries in the color table is not directly stored within the GIF file; it is actually calculated from the number of bits used to represent each index in the table. The total number of entries in the color table is calculated by raising 2 to the power of the number of bits per entry; thus if the number of bits used per index is 8, there are a maximum of 256 entries in the table (28). A 129-color palette requires 8 bits per entry (because 27 = 128), which means that a 256-color palette will be allocated, even if only 129 colors are actually used.
Can a multi-image GIF have more than one transparent color?
Yes, each image in a multi-image sequence may have its own local palette, which may contain its own transparent color index. The transparent index for a color table is defined in the Graphics Control Extension (described later). According to a strict interpretation of the GIF specification, only one graphic control block is allowed per image, so each image can have its own unique transparent color.
What is the maximum color depth of a GIF?
The maximum color depth of a GIF is 256 colors, because each pixel is represented as a single byte, which can be an index to at most 28 = 256 colors.
How does a decoder program know that a file is a GIF?
The first 3 bytes of the GIF file are always the hexadecimal string “0x47 0x49 0x46” which is the string “GIF” in ASCII characters. Bytes 4-6 are either the hex string “0x38 0x37 0x61” or “0x38 0x39 0x61,” which is either “87a” or “89a” in ASCII, depending on the version of encoding used. Unfortunately, some applications (such as certain web browsers) determine the content of the file solely by the extension used on the filename.
How can I make the smallest possible multi-image file?
This is a loaded question, but one way would be to make sure that your image manipulation software is using global palettes when color tables can be shared by more than one image. Each image may have its own local palette, which (for a 256-color palette) can add 768 bytes per palette. That’s actually not that much, but every bit counts. Also, the GIF format allows you to provide an offset (and to choose a “disposal” method) for each image in a file; the size of the file may be reduced by removing redundant data (either by creating a bounding box around the changed area and cropping away the rest, or by analyzing the image on a pixel-by-pixel basis and setting unchanged pixels to transparent) and allowing underlying frames to show through. An example is given in Chapter 9, and the Gimp (described in Chapter 7) provides an Animation Optimizer that automates this technique.
The GIF file format is pretty easy to decode. The specification is not the best general purpose file format description. For instance, the format of each type of block is inconsistent, which makes it a bit harder to parse. The standard unit for the fields in a GIF file is the byte, though in a couple of cases GIF uses a packed byte structure to store multiple fields within a single byte. Because of these structural decisions GIF does not have much room to grow as a file format. It is, however, a perfectly fine, robust specification as it is. In fact, CompuServe has recognized PNG as the official successor to GIF, so there won’t be any more official GIF revisions, at least not from CompuServe.
A GIF file always starts with the three-byte signature “GIF” and ends with the byte (in hex) “3B,” which indicates the end of the data stream. There is no built-in error-checking for determining whether the data in the file has been corrupted or not. The signature is part of the header block of information.
The header block of the GIF file contains a signature that identifies it as a GIF of version 87a or 89a, and a Logical Screen Descriptor block, which contains information about the minimum requirements of the device needed to display the image as intended by the creator. The header also contains information about the global color table included in the file, if any. The header is 13 bytes in length, consisting of the following fields:
- Signature (3 bytes)
Always GIF.
- Version (3 bytes)
Always 87a or 89a.
- Screen Width and Screen Height (2 bytes each)
The minimum screen dimensions required on the display device to properly render the image without scaling to fit the screen. These fields are often set to for general purpose images.
- Color Table Information (1 byte)
The next byte describes attributes of the global color table. The eight bits in this byte contain the following fields:
- Bits 0-2
The number of bits used for each color table entry minus one; if the color table has 256 entries, each entry would require an 8-bit index, so this field would contain 7 (111 in binary). This number is used to calculate the number of entries in the color table.
- Bit 3
This bit is set to 1 if the elements in the table are sorted in order of decreasing occurrence in the image.
- Bits 4-6
A number from to 7, indicating the significant bits per sample of each color in the table, minus one.
- Bit 7
The Global Color Table flag, which is 1 if the file contains a global color table.
- Background Color (1 byte)
A byte that contains an index for the color in the Global Color Table to be used as the border and background colors of the file.
A GIF file may optionally contain a global color table. If it does, the table will immediately follow the header in the data stream (that is, it will start on byte 14). This color table will contain 2, 4, 8, 16, 32, 64, 128, or 256 entries and will take up from 6 to 768 bytes. Each element of the color table consists of three bytes: one for each of the red, green, and blue components of the color.
Each Image block (described later) can also contain its own local color table, which would take precedence over the global color table. If every image block has its own local color table, the file does not need a global color table. If a file does not have a global color table and does not have local color tables, the image will be rendered using the application’s default color table, with unpredictable results. Local color tables have the same form as the global color table.
The GIF specification suggests that the first two elements of a color table be black (0) and white (1), but this is not necessarily always the case.
A GIF file can contain an unlimited number of images. Each image is stored in its own block, which consists of two or three parts: the Local Image Descriptor, an optional Local Color Table, and the compressed Image Data.
The Local Image Descriptor always consists of 10 bytes that contain the dimensions of the image and information on which color table to use and how the image data is stored. The fields of the Local Image Descriptor block are:
- Separator (1 byte)
Always the hex value 2C, which identifies this as a Local Image Descriptor block.
- Left, Top (2 bytes each)
Each of these is a number in the range to 65,535, which indicate the x, y coordinate within the image frame at which the upper-left corner of the image should be offset when it is displayed. See the bouncing ball example in Chapter 9 to see how these fields may be used effectively to reduce the size of a multi-image GIF.
- Width, Height (2 bytes each)
These fields provide the width and height of the image, in pixels.
- Color Information (1 byte)
The last byte of the Local Image Descriptor contains 8 bits describing the following fields (starting with the least significant bit):
- Bit 0
This bit is set to 1 if the Image Block contains a Local Color Table that should be used when rendering the image.
- Bit 1
This bit is set to 1 if the image data is stored in an interlaced format.
- Bit 2
This bit is set to 1 if the local color table is sorted in order of decreasing occurrence.
- Bits 3-4
These bits are reserved for use by future versions of GIF.
- Bits 5-7
The number of bits used for each entry in the Local Color Table.
The Local Color Table is in the same form as the Global Color Table—i.e., between 2 and 256 entries of one-byte triplets for each RGB value. If bit of the Local Image Descriptor is set to 0, there is not a local color table, and the Image Data will immediately follow the Descriptor block.
The Image Data for each image is always stored in the LZW compressed format. It is not stored as a continuous stream of LZW encoded data, but rather as an arbitrary number of shorter sub-blocks from 1 to 255 bytes in length. These sub-blocks each start with a count byte that is the number of bytes in the sub-block, which is followed by the encoded data. Each of the sub-blocks must be sent to the LZW decoder individually before they are assembled to form the decoded image data. A count byte of indicates the end of the image data block.
Once the sub-blocks have been read and decoded, we must know whether the pixels of the resulting block of image data are stored in an interlaced or noninterlaced form. Each pixel value is stored as a single byte in the decoded data block, regardless of the size of the color table. If the data is stored in a non-interlaced form, it may be read in linearly, with each scanline read consecutively after the previous. If the data is interlaced, it must be read according to the interlacing algorithm described earlier in the chapter.
The GIF89a specification adds four extension blocks to the original GIF87a format. Two of these extension blocks are used to implement common features of web graphics such as transparency and animated loops. The four extension blocks are the Graphics Control, Application, Comment, and Plain Text Extensions. Of these we will cover the Graphics Control Extension and the Application Extension, which are used in web graphics. The Plain Text Extension is not used in web graphics applications. The Comment Extension is often used to store copyright information for the image, but it is generally ignored by web clients.
An extension block may appear anywhere in a GIF file between the Global Color Table (if there is one) and the trailer. All extensions begin with an identifier byte which is always 0x21 to identify the block as an extension block. This is followed by an extension type byte, which indicates the type of extension. The codes for the Graphics Control and Application extensions are 0xF9 and 0xFF, respectively.
The Graphics Control Extension contains information that can tell an application how to deal with transparency in the image and how to dispose of images when displaying a multi-image GIF. It is 8 bytes long and contains seven fields:
- Introducer (1 byte)
This byte is always 0x21, indicating an extension block.
- Extension Label (1 byte)
this byte is always 0xF9, indicating a Graphics Control Extension.
- Block Size (1 byte)
This is always 0x04, because there are four more bytes of information before the extension block terminator.
- Control Information (1 byte)
This packed byte consists of the following three fields:
- Bit 0
Transparent color flag. This is 1 if the images referred to by this block are to contain a transparent color.
- Bit 1
User Input Enabled. This flag is not implemented by web browsers.
- Bits 2-4
Disposal method. This is a number from 0-4 that indicates the way the application should display the next image in a multi-image file:
- 0
Not specified
- 1
Do not dispose between frames
- 2
Overwrite frame with background color from header
- 3
Overwrite with previous frame
- Bits 5-7
Reserved.
- Delay Time (2 bytes)
This field contains the number of hundreths of a second the display client should wait before displaying the next image in a multi-image sequence. This allows very fine control of the delay time, which can be from to 655.35 seconds.
- Transparent Color Index (1 byte)
If the transparency bit is set, the color with this index should be made transparent when the image is rendered (i.e., it should not be drawn). This index applies to the current color table. It will continue to be the transparent index for every image until another Graphics Control Extension turns transparency off or changes the index.
- Extension Terminator (1 byte)
This is always 0.
The Application Extension Block allows GIF files to be customized for particular applications. Netscape took advantage of this feature to supplement the graphics control block with an application extension block that would tell a web browser how many times to display a sequence of images in an animated GIF before stopping. This became known as the Netscape Looping Extension, and it may as well be part of the GIF specification (though it isn’t). This is ironic because the GIF specification specifically notes that GIF was not intended as a platform for the delivery of animations, yet Netscape’s modification made GIF the de facto animation standard on the Web.
A Netscape looping extension follows the format of a generic application extension and looks like this:
- Introducer (1 byte)
This byte is always 0x21, indicating an extension block.
- Extension Label (1 byte)
This byte is always 0xFF, indicating an Application Extension.
- Block Size (1 byte)
This is always 0x0B, because there are eleven more fields of information before the extension block terminator.
- Identifier (8 bytes)
This is a human-readable 8-character string. For the Netscape looping extension, this field is always “NETSCAPE.”
- Application Authentication Code (3 bytes)
This field contains a 3-byte code that may be used to uniquely identify the application that created the file. In this case, the field will be “2.0.”
- Application Data (4 bytes)
In general, an application data field can contain a variable number of subblocks, the first of which is the number of bytes of sub-blocks remaining in the Data field. For a looping extension this number is always 3, of which only the second two are used to represent the number of times the animation should loop. Because it is 2 bytes (16 bits) long the possible range of values is to 65,535. A value of indicates that the animation should loop forever. Absence of a looping extension is generally interpreted as a value of 1.
- Extension Terminator (1 byte)
Get Programming Web Graphics with Perl and GNU Softwar now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
