[Previous]

[Find]

[Next]

Royal Frazier's

- MIRROR sites: closer, faster, non-English -

[Home] [Introduction] [Find] [Viewing] [Software] [How to make GIF Animations] [HTML] [Conservation] [Help] [Problems] [Technical] [Gallery] [About]

If you have a few minutes, please fill out the Visitor Survey. It will help in making this site better.

All About GIF89a

• Understanding GIF89a
• The Structure of a GIF89a file
• What are the benefits & limitations of GIF89a animations?
• The GIF89a Specification

Understanding GIF89A

First, a little legal mumbo-jumbo that has upset a lot of people. The GIF image format uses a built-in LZW compression algorithm. This compression algorithm is patented technology and currently owned by Unisys Corporation. As of 1995, Unisys decided that commercial vendors, whose products use the GIF LZW compression, must license its use from UNISYS. End users, online services, and non-profit organizations do not pay this royalty. Since it's inception GIF has been a royalty-free format. Only as of 1995, did Unisys decide to collect royalties. To avoid this royalty, vendors have developed an alternative to GIF that supports transparency and interlacing called PNG ("ping"), the Portable Network Graphic. PNG, however, does not support a multiple image data stream to my knowledge.

Now, to clean up some of the mess I've made. I still have to find specifications for GIF87a to be sure of everything, but this is how I understand it. GIF87a was released...guess when? 1987. GI87a allowed for the following features

• LZW compressed images
• multiple images encoded within a single files
• positioning of the images on a logical screen area (need to confirm this fact)
• interlacing (need to confirm this fact)

This means that nine years ago, it was possible to do simple animation with GIFs by encoding multiple images, what we will refer to as "frames", in a single file. GIF89a is an extension of the 87a spec. GIF89a added:

• how many 100ths of a second to wait before displaying the next frame
• wait for user input
• specify transparent color
• include unprintable comments
• display lines of text
• indicate how the frame should be removed after it has been displayed
• application-specific extensions encoded inside the file

Netscape Navigator is the only browser than comes close to full GIF89a compliance. The lines of text & user input are not currently supported in NEtscape Navigator 2.0, and the image removal doesn't support removal by previous image. Most browsers support single image GIF87a and will recognize the transparency flag of GIF89a and nothing else. I received numerous corrections stating that all transparent GIFs are GIF89a format. I realize this. Several people thought it confusing to call this GIF89a animation when GIF87a could accommodate some of these animations. I guess the technically accurate naming convention would be "mostly GIF89a-compliant animations which take advantage of some or all of the GIF89a-compliant features present in Netscape Navigator and hopefully other browsers, though some browsers technically support GIF87a animation with selective support of GIF89a transparency and everything else of GIF89a ignored." I will continue to call it GIF89a animation.

GIF89a is still a 256-color (maximum) format. GIF allows for any number of colors between 2 and 256. The fewer colors the less data and the smaller the graphic files. If your GIF only uses 4 colors, you can reduce the palette to only 2 bits (4 color) and decrease the file size by upwards of 75%.

The following software lets you set bits-per-pixel for GIFs: Abode Photoshop(Mac/Win), Boxtop's PhotoGIF PlugIn(MAC), GIFConvertor(Mac), and PhotoGIF(Mac), Picture Publisher(Win), Paint Shop Pro 3.0(Win), LVieWPro, WebImage from Group42, Graphic Convertor(Mac), Fractal Painter, Painter 2.0, PhotoStudio from ArcSoft, ImageMagick, ClarisPaintShop, PaintIt, ColorIt and ToolWorks 2.2(SGI Indy) all do. DeBabelizer 1.6.5 does but only for GIF87a images. If software NOT listed above can set the bits-per-color, please let me know.

The Structure of a GIF89a file

This is a little technical but it will give users a real understanding of how the GIF works, and what you need to do with it. GIFs are composed of Blocks and Extensions. Blocks can be classified into three groups:

• Control
• Graphic-Rendering
• Special Purpose

Control blocks, such as the Header, the Logical Screen Descriptor, the Graphic Control Extension and the Trailer, control how the graphic data is handled. Graphic-Rendering blocks such as the Image Descriptor and the Plain Text Extension contain data used to render a graphic . Special Purpose blocks such as the Comment Extension and the Application Extension are not used by GIF decoders at all. The Logical Screen Descriptor and the Global Color Table affect all the images in a single file. Each Control block will only affect a single Image block that immediately follows it.

Here's what a GIF looks like inside:

GIF89a File Structure

• GIF89a HEADER
• LOGICAL SCREEN DESCRIPTOR BLOCK
  • may include an optional GLOBAL COLOR TABLE (99.5% of the time this will be present)
• optional NETSCAPE APPLICATION EXTENSION BLOCK(:-> surprise)
• a stream of graphics (each graphic being composed of the following)
  • an optional GRAPHIC CONTROL BLOCK (one preceding each IMAGE)
  • a single IMAGE DESCRIPTOR or PLAIN TEXT BLOCK
    • which can include an optional LOCAL COLOR TABLE for an image
    • and the actual IMAGE or TEXT data table
• GIF TRAILER ends the series of images

COMMENT BLOCKS may appear anywhere as they are ignored. (Do NOT place them before the Netscape Looping Extension!!)

BLOCK DEFINITIONS:

HEADER

The HEADER block is a small 6-byte (6-character) block. It is the first block in every file and contains the GIF version of the file (i.e either GIF87a or GIF89a). GIF image decoders use this information to determine the version of the file.

LOGICAL SCREEN DESCRIPTOR

The LOGICAL SCREEN DESCRIPTOR is always the second block in a file. It defines an area of pixels which you can think of as a screen (like a projector screen). The dimensions of this area define the size of your GIF on screen. This information determines how much space is reserved on-screen in your browser to display the image. If your logical screen is larger than your image, you will have space around the image when displayed.

The logical screen area should be large enough to display all of your individual frames in it. If an image in the GIF file is larger than the logical screen or, by its positioning, extends beyond the screen, the portion that is off-screen will not be displayed. Think of it the way a movie that is too big would not fit on a projector screen. More importantly, Netscape Beta4 (possibly more) will GPF (General Protection Fault) in Windows 3.x on an image larger than the Logical Screen Header. Do not assume all of your images are the same size. Read through their sizes and set the logical screen to the largest width & height included in the file.

The Logical Screen Block also chooses one of the colors in the Global Color Table to be the Background color of the screen. This color selection is ignored by Netscape Navigator. If a GIF's background area shows through, Navigator displays the color set in the BGCOLOR of the page's body or, if none is specified, the background color set in the menus under OPTIONS/GENERAL PREFERENCES/COLORS. Now, of course, the question arises; how do I get it to be transparent? Well, this SHOULDN'T work, but it does. Apparently, if Netscape's decoder finds a Control block (it must be first, before any images) with Transparency turned on (any color) the background of the GIF will be transparent. This will allows background GIFs to fill in the logical screen background.

A GIF file contains a global palette of common colors for all the images in its file to work from. (NOTE: It is technically possible for a GIF NOT to have a global palette, but this would be extremely rare.) This palette can have 2, 4, 8, 16, 32, 64, 128 , or 256 defined colors. Palettes are very important. Every color displayed in your GIF must come from a palette. The fewer colors used, the easier it will be for systems to display your images. The global palette is applied to all images in a GIF file. If an individual images differs greatly from that global palette, it may have a local palette that affects its color ONLY. However, no image can every reference more than one palette, so 256 colors per image is the max. Having a bunch of local palettes with wildly varied colors can sometimes cause color shifts in your display. (it also probably indicates a gaudy mix of colors)

The Logical Screen Header can also contain the aspect ratio of the image. This can sometimes account for GIFs appearing stretched out or scrunched. I will leave this to other who have use of this.

APPLICATION EXTENSIONS

Usually a discussion on APPLICATION EXTENSIONS would be left to last. However, this is an important issue, and is fitting to discuss at this point. Application Extensions allow for blocks of data to be inserted in the GIF for specific programs to act upon. It can be for any purpose. For this reason, only special programs will do anything with them. The January '95 release of GIF Construction Set 1.0G for Windows will insert the Netscape-specific loop-block into a GIF. With these blocks, programs could specify special effects or instructions on how to handle the image data. Typically, only the programs that define these application blocks will understand them.

OKAY...HERE IT IS...LOOPING!

Netscape Navigator has an Application Extension Block that tells Navigator to loop the entire GIF file. The Netscape block MUST APPEAR IMMEDIATELY AFTER THE GLOBAL COLOR TABLE OF THE LOGICAL SCREEN DESCRIPTOR. Only Navigator 2.0 Beta4 or better will recognize this Extension block. The block is 19 bytes long composed of: (note: hexadecimal equivalent supplied for programmers)

byte   1       : 33 (hex 0x21) GIF Extension code
byte   2       : 255 (hex 0xFF) Application Extension Label
byte   3       : 11 (hex (0x0B) Length of Application Block 
                 (eleven bytes of data to follow)
bytes  4 to 11 : "NETSCAPE"
bytes 12 to 14 : "2.0"
byte  15       : 3 (hex 0x03) Length of Data Sub-Block 
                 (three bytes of data to follow)
byte  16       : 1 (hex 0x01)
bytes 17 to 18 : 0 to 65535, an unsigned integer in 
                 lo-hi byte format. This indicate the 
                 number of iterations the loop should 
                 be executed.
bytes 19       : 0 (hex 0x00) a Data Sub-block Terminator. 

As of Beta5, the iteration count is ignored and the loop is infinite (an iteration count of zero indicates infinite). I strongly suggest you code the count to be accurate, so that when iterations begin working your GIF will not need to be modified. Technically that is all that needs to be done with this block. More about looping later in the tutorial.

CONTROL BLOCKS

A CONTROL BLOCK controls certain optional aspects of how an image is displayed. A Control block only affect the image immediately following it. For this reason, you should never include any block between a control block and the next image descriptor block. This Graphic Control Extension defines:

• if this image has a local palette of its own
• if one of the colors in this image is transparent
• if a user input is requested before proceeding
• if a timed delay in 1/100ths of a second should be used before displaying THIS image.
• what should be done with the image after it has been displayed (removal controls)

You should avoid using a local palette as it increases the likelihood of a confused video display. If a local palette doesn't exist, the global one is used. One of these color is designated as transparent in the control block.

User input and timing work together. When an image is described, it is immediately rendered on screen. Then, if a timed delay is set, it will wait for x/100ths of a second before removal and proceeding onto the next image. If a User Input is specified, the image waits until the user strikes a key, clicks a mouse or whatever. What is considered user input is determined by the program displaying the GIF. If both options are elected, the image remains until the delay expires or a user input occurs, whichever comes first.

Just before preceding to the next image, the removal options are performed. You may remove the image by:

• nothing: perform no action
• leave as is: leave the image on screen, should be same as nothing in most cases
• previous image: replace it with what was there before; this is difficult to implement and is the most powerful choice.
• background: replace with the logical screen background color. (note: If Navigator detected transparency, as written above, this will be replaced by the HTML specified background)

IMAGE BLOCK

An IMAGE BLOCK contain (tada!) an actual image. This image can be any size and have a palette of any size. You can have a mix of 16-color, 2-color, 256color, etc images in a single GIF. In addition to the actual image table data you have the following:

• the picture's size in pixels
• the position of the image on the logical screen
• whether it is interlaced
• an optional local palette for this image

The image's size in pixels cannot be modified. It is determined by the data of the image. Changing this would cause data corruption.

The top and left position of the images are within the defined logical screen. With this a small bitmap of an object could be placed anywhere within the screen area, rather than create an entire image with the object positioned within it. More on this in the tutorial.

Interlacing is a way of saving and displaying the image data. For interlacing to occur, the image must be set to save interlaced. Interlacing is not turned by the browser. It may be ignored by the browser. Interlacing saves alternate rows, producing a venetian blind or blocky-focusing effect, depending upon how the browser handles interlacing. Interlacing stores the rows of the image in the following order:

      Pass 1 : Every 8th. row, starting with row 0.
      Pass 2 : Every 8th. row, starting with row 4.
      Pass 3 : Every 4th. row, starting with row 2.
      Pass 4 : Every 2nd. row, starting with row 1.

COMMENT BLOCK

You can include comments in your GIF. These can be markers for long animation sequences or statements of ownership. I strongly suggest that you place your name, email, and home address in the GIF so people can contact you regarding your work. These comments DO NOT appear on screen.

PLAIN TEXT BLOCKS

In addition to images you can also render text on screen with a GIF. Unfortunately many programs don't recognize the text. Netscape does not. If you would like to learn more about the Plain Text Blocks read the GIF89a Specification Sheet.

TRAILER

The Trailer is simple. It indicates the end of the GIF file. It is unmodifiable and cannot be accessed in anyway.

Here is an example of the structure of a typical animation file:

GIF89A HEADER

LOGICAL SCREEN DESCRIPTOR

GLOBAL PALETTE

LOOP : Netscape 2.0 Loop

COMMENT "Created By..."

COMMENT "Star at 0 degrees"

CONTROL for IMAGE #1

IMAGE #1

COMMENT "Star at 15 degrees"

CONTROL for IMAGE #2

IMAGE#2

COMMENT "Star at 30 degrees"

CONTROL for IMAGE #3

IMAGE #3

TRAILER

What are the benefits & limitations of GIF89a animations?

Benefits

• All the benefits of GIF: transparency, compression, interlacing, 2,4,8,16,32,64,128 & 256 color palettes for optimum size and compression.
• Supported by the basic Netscape 2.0 product. No Plug-ins or additional software. Tested on Win 3.1x, Win95, MAC, Unix, Sun, Linux, & Irix.
• Web designer does not need access to internet provider's web server, server-side includes (SSI), or CGI/PERL scripting. If you have a program that can make multi-image 89a GIFs, you can make this animation.
• The animation is repeatable and reusable. You can place the same image on a page multiple times. It performs a single download for all and loops all from the cache.
• The animation only loads once, so your modem doesn't keep downloading constantly. It is faster than server-reliant methods. Check out the RACE!
• The animations are surprisingly compact. The static image of a construction sign above is 4,471 bytes, while the animated version is only 7,080 bytes. The rolling stars (all of them :->) are 7,635 bytes.
• ANYONE can use them on their page. Anyone with a web page can include this animation. IN FACT, if you save any of the animated GIFs to your hard drive, you will have the entire animation to put in your own pages. Please contact the creator for usage.
• Works like any other GIF. Include on your page in an IMG or FIG tag, even anchor it. Works invisibly.

Limitations

• All the limitations of GIFs: max of 256 colors, photographs are better compressed by JPEG
• Only plays in Netscape 2.0 or better, but DOES work with many platforms (Windows, MAC, Unix, etc)
• Will play once or continuously. Refresh will not play the image again, but RELOAD or resizing the windows will. If the viewer returns BACK to the page from elsewhere, the image will play, EVEN if cached! Later revisions of Navigator may support finite iterations of the animations.
• It cannot be used as a background GIF. Only the first frame will display.
• Netscape does not fully support GIF89a.
  • Ignores user input.
  • Does not handle previous image for image removal controls.
  • Plain text is not displayed
  • Bug in Windows version prevents timed displays of lower than 1/3 of a second between images.
• The animation can be slowed down or interrupted by other images being downloaded and other playing animations.
• Animation can be "borrowed" as easily as any GIF
• Non-supporting browsers either display the first image (Win 3.x: Cello, Internet Explorer, Netcruiser 2.1, Netscape before 2.0, NCSA Mosaic 2.0, Quarterdeck Mosaic, Spry Mosaic 3.0A, Video Online; Unix: NCSA Mosaic 2.7, Netscape before 2.0) or the last image (Win 3.x: AOL2.5(12-95); Unix: SUN's HotJava). It is safe to say any earlier versions of the browsers listed would behave similarly. If you have tested an unlisted browser please email me the results.

The GIF89a Specification

Compuserve released the technical specification for GIF89a in July of 1989. The technical specification is an exact breakdown of the byte-for-byte structure and rules for interpreting and building this format. If you are interested in a more technical explanation of the format, you can read the specifications as published by Compuserve. This is the perfect documentation for anyone considering writing code to deal with GIFs. The GIF87a Specifications are also available.

Any ideas, suggestions,utilities, or examples, please mail them over for inclusion in this page.

Royal Frazier

(Go to the TOP of PAGE for MENUS)

LinkExchange Member

Copyright 1996,1997 Royal E. Frazier Jr.

Last Updated: March 1997