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 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:
COMMENT BLOCKS may appear anywhere as they are ignored. (Do NOT place them before the Netscape Looping Extension!!)
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.
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.
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.
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:
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:
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 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.
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.
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.
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
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.