DEFERRED CLEAR CODE IN LZW COMPRESSION
There has been confusion about where clear codes can be found in the data stream. As the specification says, they may appear at anytime. There is not a requirement to send a clear code when the string table is full.
It is the encoder's decision as to when the table should be cleared. When the table is full, the encoder can chose to use the table as is, making no changes to it until the encoder chooses to clear it. The encoder during this time sends out codes that are of the maximum Code Size.
As we can see from the above, when the decoder's table is full, it must not change the table until a clear code is received. The Code Size is that of the maximum Code Size. Processing other than this is done normally.
Because of a large base of decoders that do not handle the decompression in this manner, we ask developers of GIF encoding software to NOT implement this feature until at least January 1991 and later if they see that their particular market is not ready for it. This will give developers of GIF decoding software time to implement this feature and to get it into the hands of their clients before the decoders start "breaking" on the new GIF's. It is not required that encoders change their software to take advantage of the deferred clear code, but it is for decoders.
APPLICATION EXTENSION BLOCK - APPLICATION IDENTIFIER
There will be a Courtesy Directory file located on CompuServe in the PICS forum. This directory will contain Application Identifiers for Application Extension Blocks that have been used by developers of GIF applications. This file is intended to help keep developers that wish to create Application Extension Blocks from using the same Application Identifiers. This is not an official directory; it is for voluntary participation only and does not guarantee that someone will not use the same identifier.
E-Mail can be sent to Larry Wood (forum manager of PICS) indicating the request for inclusion in this file with an identifier.
The information provided herein is subject to change without notice. In no event will CompuServe Incorporated be liable for damages, including any loss of revenue, loss of profits or other incidental or consequential damages arising out of the use or inability to use the information; CompuServe Incorporated makes no claim as to the suitability of the information.
This document defines the Graphics Interchange Format(sm). The specification given here defines version 89a, which is an extension of version 87a.
The Graphics Interchange Format(sm) as specified here should be considered complete; any deviation from it should be considered invalid, including but not limited to, the use of reserved or undefined fields within control or data blocks, the inclusion of extraneous data within or between blocks, the use of methods or algorithms not specifically listed as part of the format, etc. In general, any and all deviations, extensions or modifications not specified in this document should be considered to be in violation of the format and should be avoided.
The Graphics Interchange Format(c) is the copyright property of CompuServe Incorporated. Only CompuServe Incorporated is authorized to define, redefine, enhance, alter, modify or change in any way the definition of the format.
CompuServe Incorporated hereby grants a limited, non-exclusive, royalty-free license for the use of the Graphics Interchange Format(sm) in computer software; computer software utilizing GIF(sm) must acknowledge ownership of the Graphics Interchange Format and its Service Mark by CompuServe Incorporated, in User and Technical Documentation. Computer software utilizing GIF, which is distributed or may be distributed without User or Technical Documentation must display to the screen or printer a message acknowledging ownership of the Graphics Interchange Format and the Service Mark by CompuServe Incorporated; in this case, the acknowledgement may be displayed in an opening screen or leading banner, or a closing screen or trailing banner. A message such as the following may be used:
"The Graphics Interchange Format(c) is the Copyright property of
CompuServe Incorporated. GIF(sm) is a Service Mark property of
CompuServe Incorporated."
For further information, please contact :
CompuServe Incorporated
Graphics Technology Department
5000 Arlington Center Boulevard
Columbus, Ohio 43220
U. S. A.
CompuServe Incorporated maintains a mailing list with all those individuals and
organizations who wish to receive copies of this document when it is corrected
or revised. This service is offered free of charge; please provide us with your
mailing address.
This document describes in detail the definition of the Graphics Interchange Format. This document is intended as a programming reference; it is recommended that the entire document be read carefully before programming, because of the interdependence of the various parts. There is an individual section for each of the Format blocks. Within each section, the sub-section labeled Required Version refers to the version number that an encoder will have to use if the corresponding block is used in the Data Stream. Within each section, a diagram describes the individual fields in the block; the diagrams are drawn vertically; top bytes in the diagram appear first in the Data Stream. Bits within a byte are drawn most significant on the left end. Multi-byte numeric fields are ordered Least Significant Byte first. Numeric constants are represented as Hexadecimal numbers, preceded by "0x". Bit fields within a byte are described in order from most significant bits to least significant bits.
The Graphics Interchange Format(sm) defines a protocol intended for the on-line transmission and interchange of raster graphic data in a way that is independent of the hardware used in their creation or display.
The Graphics Interchange Format is defined in terms of blocks and sub-blocks which contain relevant parameters and data used in the reproduction of a graphic. A GIF Data Stream is a sequence of protocol blocks and sub-blocks representing a collection of graphics. In general, the graphics in a Data Stream are assumed to be related to some degree, and to share some control information; it is recommended that encoders attempt to group together related graphics in order to minimize hardware changes during processing and to minimize control information overhead. For the same reason, unrelated graphics or graphics which require resetting hardware parameters should be encoded separately to the extent possible.
A Data Stream may originate locally, as when read from a file, or it may originate remotely, as when transmitted over a data communications line. The Format is defined with the assumption that an error-free Transport Level Protocol is used for communications; the Format makes no provisions for error-detection and error-correction.
The GIF Data Stream must be interpreted in context, that is, the application program must rely on information external to the Data Stream to invoke the decoder process.
The version number in the Header of a Data Stream is intended to identify the minimum set of capabilities required of a decoder in order to fully process the Data Stream. An encoder should use the earliest possible version number that includes all the blocks used in the Data Stream. Within each block section in this document, there is an entry labeled Required Version which specifies the earliest version number that includes the corresponding block. The encoder should make every attempt to use the earliest version number covering all the blocks in the Data Stream; the unnecessary use of later version numbers will hinder processing by some decoders.
The Encoder is the program used to create a GIF Data Stream. From raster data and other information, the encoder produces the necessary control and data blocks needed for reproducing the original graphics.
The encoder has the following primary responsibilities.
The Decoder is the program used to process a GIF Data Stream. It processes the Data Stream sequentially, parsing the various blocks and sub-blocks, using the control information to set hardware and process parameters and interpreting the data to render the graphics.
The decoder has the following primary responsibilities.
An encoder or a decoder is said to comply with a given version of the Graphics Interchange Format if and only if it fully conforms with and correctly implements the definition of the standard associated with that version. An encoder or a decoder may be compliant with a given version number and not compliant with some subsequent version.
Each block section in this document contains an entry labeled Recommendation; this section lists a set of recommendations intended to guide and organize the use of the particular blocks. Such recommendations are geared towards making the functions of encoders and decoders more efficient, as well as making optimal use of the communications bandwidth. It is advised that these recommendations be followed.
The GIF format utilizes color tables to render raster-based graphics. A color table can have one of two different scopes: global or local. A Global Color Table is used by all those graphics in the Data Stream which do not have a Local Color Table associated with them. The scope of the Global Color Table is the entire Data Stream. A Local Color Table is always associated with the graphic that immediately follows it; the scope of a Local Color Table is limited to that single graphic. A Local Color Table supersedes a Global Color Table, that is, if a Data Stream contains a Global Color Table, and an image has a Local Color Table associated with it, the decoder must save the Global Color Table, use the Local Color Table to render the image, and then restore the Global Color Table. Both types of color tables are optional, making it possible for a Data Stream to contain numerous graphics without a color table at all. For this reason, it is recommended that the decoder save the last Global Color Table used until another Global Color Table is encountered. In this way, a Data Stream which does not contain either a Global Color Table or a Local Color Table may be processed using the last Global Color Table saved. If a Global Color Table from a previous Stream is used, that table becomes the Global Color Table of the present Stream. This is intended to reduce the overhead incurred by color tables. In particular, it is recommended that an encoder use only one Global Color Table if all the images in related Data Streams can be rendered with the same table. If no color table is available at all, the decoder is free to use a system color table or a table of its own. In that case, the decoder may use a color table with as many colors as its hardware is able to support; it is recommended that such a table have black and white as its first two entries, so that monochrome images can be rendered adequately.
The Definition of the GIF Format allows for a Data Stream to contain only the Header, the Logical Screen Descriptor, a Global Color Table and the GIF Trailer. Such a Data Stream would be used to load a decoder with a Global Color Table, in preparation for subsequent Data Streams without a color table at all.
Blocks can be classified into three groups : Control, Graphic-Rendering and Special Purpose. Control blocks, such as the Header, the Logical Screen Descriptor, the Graphic Control Extension and the Trailer, contain information used to control the process of the Data Stream or information used in setting hardware parameters. Graphic-Rendering blocks such as the Image Descriptor and the Plain Text Extension contain information and data used to render a graphic on the display device. Special Purpose blocks such as the Comment Extension and the Application Extension are neither used to control the process of the Data Stream nor do they contain information or data used to render a graphic on the display device. With the exception of the Logical Screen Descriptor and the Global Color Table, whose scope is the entire Data Stream, all other Control blocks have a limited scope, restricted to the Graphic-Rendering block that follows them. Special Purpose blocks do not delimit the scope of any Control blocks; Special Purpose blocks are transparent to the decoding process. Graphic-Rendering blocks and extensions are used as scope delimiters for Control blocks and extensions. The labels used to identify labeled blocks fall into three ranges : 0x00-0x7F (0-127) are the Graphic Rendering blocks, excluding the Trailer (0x3B); 0x80-0xF9 (128-249) are the Control blocks; 0xFA-0xFF (250-255) are the Special Purpose blocks. These ranges are defined so that decoders can handle block scope by appropriately identifying block labels, even when the block itself cannot be processed.
The Block Size field in a block, counts the number of bytes remaining in the block, not counting the Block Size field itself, and not counting the Block Terminator, if one is to follow. Blocks other than Data Blocks are intended to be of fixed length; the Block Size field is provided in order to facilitate skipping them, not to allow their size to change in the future. Data blocks and sub-blocks are of variable length to accommodate the amount of data.
As an embedded protocol, GIF may be part of larger application protocols, within which GIF is used to render graphics. In such a case, the application protocol could define a block within which the GIF Data Stream would be contained. The application program would then invoke a GIF decoder upon encountering a block of type GIF. This approach is recommended in favor of using Application Extensions, which become overhead for all other applications that do not process them. Because a GIF Data Stream must be processed in context, the application must rely on some means of identifying the GIF Data Stream outside of the Stream itself.
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Block Size Byte
+---------------+
1 | |
+- -+
2 | |
+- -+
3 | |
+- -+
| | Data Values Byte
+- -+
up | |
+- . . . . -+
to | |
+- -+
| |
+- -+
255 | |
+---------------+
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Block Size Byte
+---------------+
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Signature 3 Bytes
+- -+
1 | |
+- -+
2 | |
+---------------+
3 | | Version 3 Bytes
+- -+
4 | |
+- -+
5 | |
+---------------+
This block is REQUIRED; exactly one Logical Screen Descriptor must be present per Data Stream.
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Logical Screen Width Unsigned
+- -+
1 | |
+---------------+
2 | | Logical Screen Height Unsigned
+- -+
3 | |
+---------------+
4 | | | | | <Packed Fields> See below
+---------------+
5 | | Background Color Index Byte
+---------------+
6 | | Pixel Aspect Ratio Byte
+---------------+
<Packed Fields> = Global Color Table Flag 1 Bit
Color Resolution 3 Bits
Sort Flag 1 Bit
Size of Global Color Table 3 Bits
Aspect Ratio = (Pixel Aspect Ratio + 15) / 64
The Pixel Aspect Ratio is defined to be the quotient of the pixel's
width over its height. The value range in this field allows
specification of the widest pixel of 4:1 to the tallest pixel of
1:4 in increments of 1/64th.
This block is OPTIONAL; at most one Global Color Table may be present per Data Stream.
7 6 5 4 3 2 1 0 Field Name Type
+===============+
0 | | Red 0 Byte
+- -+
1 | | Green 0 Byte
+- -+
2 | | Blue 0 Byte
+- -+
3 | | Red 1 Byte
+- -+
| | Green 1 Byte
+- -+
up | |
+- . . . . -+ ...
to | |
+- -+
| | Green 255 Byte
+- -+
767 | | Blue 255 Byte
+===============+
The Image Descriptor contains the parameters necessary to process a table based image. The coordinates given in this block refer to coordinates within the Logical Screen, and are given in pixels. This block is a Graphic-Rendering Block, optionally preceded by one or more Control blocks such as the Graphic Control Extension, and may be optionally followed by a Local Color Table; the Image Descriptor is always followed by the image data.
This block is REQUIRED for an image. Exactly one Image Descriptor must be present per image in the Data Stream. An unlimited number of images may be present per Data Stream.
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Image Separator Byte
+---------------+
1 | | Image Left Position Unsigned
+- -+
2 | |
+---------------+
3 | | Image Top Position Unsigned
+- -+
4 | |
+---------------+
5 | | Image Width Unsigned
+- -+
6 | |
+---------------+
7 | | Image Height Unsigned
+- -+
8 | |
+---------------+
9 | | | | | | <Packed Fields> See below
+---------------+
<Packed Fields> = Local Color Table Flag 1 Bit
Interlace Flag 1 Bit
Sort Flag 1 Bit
Reserved 2 Bits
Size of Local Color Table 3 Bits
3x2^(Size of Local Color Table+1).
If present, this color table temporarily becomes the active color table
and the following image should be processed using it. This block is
OPTIONAL; at most one Local Color Table may be present per Image
Descriptor and its scope is the single image associated with the Image
Descriptor that precedes it.
7 6 5 4 3 2 1 0 Field Name Type
+===============+
0 | | Red 0 Byte
+- -+
1 | | Green 0 Byte
+- -+
2 | | Blue 0 Byte
+- -+
3 | | Red 1 Byte
+- -+
| | Green 1 Byte
+- -+
up | |
+- . . . . -+ ...
to | |
+- -+
| | Green 255 Byte
+- -+
767 | | Blue 255 Byte
+===============+
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
| | LZW Minimum Code Size Byte
+---------------+
+===============+
| |
/ / Image Data Data Sub-blocks
| |
+===============+
This block is OPTIONAL; at most one Graphic Control Extension may precede a graphic rendering block. This is the only limit to the number of Graphic Control Extensions that may be contained in a Data Stream.
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Extension Introducer Byte
+---------------+
1 | | Graphic Control Label Byte
+---------------+
+---------------+
0 | | Block Size Byte
+---------------+
1 | | | | | <Packed Fields> See below
+---------------+
2 | | Delay Time Unsigned
+- -+
3 | |
+---------------+
4 | | Transparent Color Index Byte
+---------------+
+---------------+
0 | | Block Terminator Byte
+---------------+
<Packed Fields> = Reserved 3 Bits
Disposal Method 3 Bits
User Input Flag 1 Bit
Transparent Color Flag 1 Bit
When a Delay Time is used and the User Input Flag is set, processing will continue when user input is received or when the delay time expires, whichever occurs first.
This block is OPTIONAL; any number of them may appear in the Data Stream.
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Extension Introducer Byte
+---------------+
1 | | Comment Label Byte
+---------------+
+===============+
| |
N | | Comment Data Data Sub-blocks
| |
+===============+
+---------------+
0 | | Block Terminator Byte
+---------------+
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Extension Introducer Byte
+---------------+
1 | | Plain Text Label Byte
+---------------+
+---------------+
0 | | Block Size Byte
+---------------+
1 | | Text Grid Left Position Unsigned
+- -+
2 | |
+---------------+
3 | | Text Grid Top Position Unsigned
+- -+
4 | |
+---------------+
5 | | Text Grid Width Unsigned
+- -+
6 | |
+---------------+
7 | | Text Grid Height Unsigned
+- -+
8 | |
+---------------+
9 | | Character Cell Width Byte
+---------------+
10 | | Character Cell Height Byte
+---------------+
11 | | Text Foreground Color Index Byte
+---------------+
12 | | Text Background Color Index Byte
+---------------+
+===============+
| |
N | | Plain Text Data Data Sub-blocks
| |
+===============+
+---------------+
0 | | Block Terminator Byte
+---------------+
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Extension Introducer Byte
+---------------+
1 | | Extension Label Byte
+---------------+
+---------------+
0 | | Block Size Byte
+---------------+
1 | |
+- -+
2 | |
+- -+
3 | | Application Identifier 8 Bytes
+- -+
4 | |
+- -+
5 | |
+- -+
6 | |
+- -+
7 | |
+- -+
8 | |
+---------------+
9 | |
+- -+
10 | | Appl. Authentication Code 3 Bytes
+- -+
11 | |
+---------------+
+===============+
| |
| | Application Data Data Sub-blocks
| |
| |
+===============+
+---------------+
0 | | Block Terminator Byte
+---------------+
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | GIF Trailer Byte
+---------------+
Block Name Required Label Ext. Vers. Application Extension Opt. (*) 0xFF (255) yes 89a Comment Extension Opt. (*) 0xFE (254) yes 89a Global Color Table Opt. (1) none no 87a Graphic Control Extension Opt. (*) 0xF9 (249) yes 89a Header Req. (1) none no N/A Image Descriptor Opt. (*) 0x2C (044) no 87a (89a) Local Color Table Opt. (*) none no 87a Logical Screen Descriptor Req. (1) none no 87a (89a) Plain Text Extension Opt. (*) 0x01 (001) yes 89a Trailer Req. (1) 0x3B (059) no 87a Unlabeled Blocks Header Req. (1) none no N/A Logical Screen Descriptor Req. (1) none no 87a (89a) Global Color Table Opt. (1) none no 87a Local Color Table Opt. (*) none no 87a Graphic-Rendering Blocks Plain Text Extension Opt. (*) 0x01 (001) yes 89a Image Descriptor Opt. (*) 0x2C (044) no 87a (89a) Control Blocks Graphic Control Extension Opt. (*) 0xF9 (249) yes 89a Special Purpose Blocks Trailer Req. (1) 0x3B (059) no 87a Comment Extension Opt. (*) 0xFE (254) yes 89a Application Extension >Transfer interrupted!