Sindbad~EG File Manager
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<link rel="stylesheet" type="text/css" href="main.css">
<link rel="stylesheet" type="text/css" href="gif89a.css">
<script type="text/javascript" src="gif89a.js"></script>
<title>Graphics Interchange Format Version 89a</title>
</head>
<body><h1>Graphics Interchange Format Version 89a</h1>
<!-- source best viewed with tab width 4 -->
<div id="notes">
<p>The document below is a copy of <a
href="http://www.w3.org/Graphics/GIF/spec-gif89a.txt">http://www.w3.org/Graphics/GIF/spec-gif89a.txt</a>,
reformatted into HTML to make it easier to read and print.</p>
<p>Notable changes:</p>
<ul>
<li>moved chapter "Cover Sheet for the GIF89a Specification" from the
beginning to the end</li>
<li>removed page numbers</li>
<li>removed redundant rows from <a href="#quickreferencetable">Quick
Reference Table</a></li>
</ul>
You can also read <a href="gif89.txt">the original flat text.</a>
</div>
<hr>
<p>© 1987, 1988, 1989, 1990</p>
<p>Copyright<br>
CompuServe Incorporated<br>
Columbus, Ohio</p>
<p>Graphics Interchange Format Programming Reference</p>
<p>CompuServe Incorporated</p>
<p>Document Date: 31 July 1990</p>
<div class="togglevisall">
<span onclick="SetEveryVis(0);">hide all chapters</span> |
<span onclick="SetEveryVis(1);">show all chapters</span>
</div>
<h2>Table of Contents <span onclick="ToggleVis(0);">(hide/show)</span></h2>
<div id="p0">
<ol>
<li><a href="#disclaimer">Disclaimer</a>
</li><li><a href="#foreword">Foreword</a>
</li><li><a href="#licensing">Licensing</a>
</li><li><a href="#aboutthedocument">About the Document</a>
</li><li><a href="#generaldescription">General Description</a>
</li><li><a href="#versionnumbers">Version Numbers</a>
</li><li><a href="#encoder">The Encoder</a>
</li><li><a href="#decoder">The Decoder</a>
</li><li><a href="#compliance">Compliance</a>
</li><li><a href="#recommendations">About Recommendations</a>
</li><li><a href="#colortables">About Color Tables</a>
</li><li><a href="#blocksextensionsandscope">Blocks, Extensions and Scope</a>
</li><li><a href="#blocksizes">Block Sizes</a>
</li><li><a href="#embeddedprotocol">Using GIF as an embedded protocol</a>
</li><li><a href="#subblocks">Data Sub-blocks</a>
</li><li><a href="#blockterminator">Block Terminator</a>
</li><li><a href="#header">Header</a>
</li><li><a href="#logicalscreendescriptor">Logical Screen Descriptor</a>
</li><li><a href="#globalcolortable">Global Color Table</a>
</li><li><a href="#imagedescriptor">Image Descriptor</a>
</li><li><a href="#localcolortable">Local Color Table</a>
</li><li><a href="#tablebasedimagedata">Table Based Image Data</a>
</li><li><a href="#graphiccontrolextension">Graphic Control Extension</a>
</li><li><a href="#commentextension">Comment Extension</a>
</li><li><a href="#plaintextextension">Plain Text Extension</a>
</li><li><a href="#applicationextension">Application Extension</a>
</li><li><a href="#trailer">Trailer</a>
</li></ol>
<p>Appendices:</p>
<ol style="list-style-type:upper-latin;">
<li><a href="#quickreferencetable">Quick Reference Table</a>
</li><li><a href="#gifgrammar">GIF Grammar</a>
</li><li><a href="#glossary">Glossary</a>
</li><li><a href="#conventions">Conventions</a>
</li><li><a href="#interlacedimages">Interlaced Images</a>
</li><li><a href="#lzw">Variable-Length-Code LZW Compression</a>
</li><li><a href="#onlinecapabilities">On-line Capabilities Dialogue</a>
</li></ol>
<p>Other:</p>
<ul>
<li><a href="#coversheet">Cover Sheet for the GIF89a Specification</a>
</li></ul>
</div>
<h2 id="disclaimer">1. Disclaimer <span onclick="ToggleVis(1);">(hide/show)</span></h2>
<div id="p1">
<p>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.</p>
</div>
<h2 id="foreword">2. Foreword <span onclick="ToggleVis(2);">(hide/show)</span></h2>
<div id="p2">
<p>This document defines the Graphics Interchange Format℠. The
specification given here defines version 89a, which is an extension of version
87a.</p>
<p>The Graphics Interchange Format℠ 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.</p>
</div>
<h2 id="licensing">3. Licensing <span onclick="ToggleVis(3);">(hide/show)</span></h2>
<div id="p3">
<p>The Graphics Interchange Format© 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.</p>
<p>CompuServe Incorporated hereby grants a limited, non-exclusive, royalty-free
license for the use of the Graphics Interchange Format℠ in computer
software; computer software utilizing GIF℠ 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:</p>
<blockquote>
<p><i>The Graphics Interchange Format© is the Copyright property of
CompuServe Incorporated. GIF℠ is a Service Mark property of
CompuServe Incorporated.</i></p>
</blockquote>
<p>For further information, please contact:</p>
<blockquote>
<p>CompuServe Incorporated<br>
Graphics Technology Department<br>
5000 Arlington Center Boulevard<br>
Columbus, Ohio 43220<br>
U. S. A.</p>
</blockquote>
<p>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.</p>
</div>
<h2 id="aboutthedocument">4. About the Document <span onclick="ToggleVis(4);">(hide/show)</span></h2>
<div id="p4">
<p>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 <tt>"0x"</tt>. Bit fields
within a byte are described in order from most significant bits to least
significant bits.</p>
</div>
<h2 id="generaldescription">5. General Description <span onclick="ToggleVis(5);">(hide/show)</span></h2>
<div id="p5">
<p>The Graphics Interchange Format℠ 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.</p>
<p>The Graphics Interchange Format is defined in terms of blocks and
<a href="#subblocks">sub-blocks</a> 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.</p>
<p>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.</p>
<p>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.</p>
</div>
<h2 id="versionnumbers">6. Version Numbers <span onclick="ToggleVis(6);">(hide/show)</span></h2>
<div id="p6">
<p>The version number in the <a href="#header">Header</a> 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.</p>
</div>
<h2 id="encoder">7. The Encoder <span onclick="ToggleVis(7);">(hide/show)</span></h2>
<div id="p7">
<p>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.</p>
<p>The encoder has the following primary responsibilities.</p>
<ul>
<li>Include in the Data Stream all the necessary information to reproduce
the graphics.
</li><li>Insure that a Data Stream is labeled with the earliest possible Version
Number that will cover the definition of all the blocks in it; this is to
ensure that the largest number of decoders can process the Data Stream.
</li><li>Ensure encoding of the graphics in such a way that the decoding process
is optimized. Avoid redundant information as much as possible.
</li><li>To the extent possible, avoid grouping graphics which might require
resetting hardware parameters during the decoding process.
</li><li>Set to zero (off) each of the bits of each and every field designated
as reserved. Note that some fields in the Logical Screen Descriptor and the
<a href="#imagedescriptor">Image Descriptor</a> were reserved under Version
87a, but are used under version 89a.
</li></ul>
</div>
<h2 id="decoder">8. The Decoder <span onclick="ToggleVis(8);">(hide/show)</span></h2>
<div id="p8">
<p>The Decoder is the program used to process a GIF Data Stream. It processes
the Data Stream sequentially, parsing the various blocks and
<a href="#subblocks">sub-blocks</a>, using the control information to set
hardware and process parameters and interpreting the data to render the
graphics.</p>
<p>The decoder has the following primary responsibilities.</p>
<ul>
<li>Process each graphic in the Data Stream in sequence, without delays
other than those specified in the control information.
</li><li>Set its hardware parameters to fit, as closely as possible, the control
information contained in the Data Stream.
</li></ul>
</div>
<h2 id="compliance">9. Compliance <span onclick="ToggleVis(9);">(hide/show)</span></h2>
<div id="p9">
<p>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.</p>
</div>
<h2 id="recommendations">10. About Recommendations <span onclick="ToggleVis(10);">(hide/show)</span></h2>
<div id="p10">
<p>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.</p>
</div>
<h2 id="colortables">11. About Color Tables <span onclick="ToggleVis(11);">(hide/show)</span></h2>
<div id="p11">
<p>The GIF format utilizes color tables to render raster-based graphics. A
color table can have one of two different scopes: global or local.</p>
<p>A <a href="#globalcolortable">Global Color Table</a> is used by all those
graphics in the Data Stream which do not have a
<a href="#localcolortable">Local Color Table</a> associated with them. The
scope of the Global Color Table is the entire Data Stream.</p>
<p>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.</p>
<p>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.</p>
<p>The Definition of the GIF Format allows for a Data Stream to contain only
the <a href="#header">Header</a>, the
<a href="#logicalscreendescriptor">Logical Screen Descriptor</a>, a Global
Color Table and the <a href="#trailer">GIF Trailer</a>. 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.</p>
</div>
<h2 id="blocksextensionsandscope">12. Blocks, Extensions and Scope <span onclick="ToggleVis(12);">(hide/show)</span></h2>
<div id="p12">
<p>Blocks can be classified into three groups: Control, Graphic-Rendering and
Special Purpose.</p>
<p>Control blocks, such as the <a href="#header">Header</a>, the Logical Screen
Descriptor, the <a href="#graphiccontrolextension">Graphic Control
Extension</a> and the <a href="#trailer">Trailer</a>, contain information used
to control the process of the Data Stream or information used in setting
hardware parameters.</p>
<p>Graphic-Rendering blocks such as the <a href="#imagedescriptor">Image
Descriptor</a> and the <a href="#plaintextextension">Plain Text Extension</a>
contain information and data used to render a graphic on the display
device.</p>
<p>Special Purpose blocks such as the <a href="#commentextension">Comment
Extension</a> and the <a href="#applicationextension">Application Extension</a>
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.</p>
<p>With the exception of the <a href="#logicalscreendescriptor">Logical Screen
Descriptor</a> and the <a href="#globalcolortable">Global Color Table</a>,
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.</p>
<p>The labels used to identify labeled blocks fall into three ranges:</p>
<ul>
<li><tt>0x00</tt>–<tt>0x7F</tt> (0–127) are the Graphic
Rendering blocks, excluding the <a href="#trailer">Trailer</a>
(<tt>0x3B</tt>, 59)
</li><li><tt>0x80</tt>–<tt>0xF9</tt> (128–249) are the Control
blocks
</li><li><tt>0xFA</tt>–<tt>0xFF</tt> (250–255) are the Special
Purpose blocks
</li></ul>
<p>These ranges are defined so that decoders can handle block scope by
appropriately identifying block labels, even when the block itself cannot be
processed.</p>
</div>
<h2 id="blocksizes">13. Block Sizes <span onclick="ToggleVis(13);">(hide/show)</span></h2>
<div id="p13">
<p>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
<a href="#blockterminator">Block Terminator</a>, 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 <a href="#subblocks">sub-blocks</a> are
of variable length to accommodate the amount of data.</p>
</div>
<h2 id="embeddedprotocol">14. Using GIF as an embedded protocol <span onclick="ToggleVis(14);">(hide/show)</span></h2>
<div id="p14">
<p>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 <a href="#applicationextension">Application Extensions</a>, 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.</p>
</div>
<h2 id="subblocks">15. Data Sub-blocks <span onclick="ToggleVis(15);">(hide/show)</span></h2>
<div id="p15">
<h3>a. Description</h3>
<p>Data Sub-blocks are units containing data. They do not have a label, these
blocks are processed in the context of control blocks, wherever data blocks are
specified in the format. The first byte of the Data sub-block indicates the
number of data bytes to follow. A data sub-block may contain from 0 to 255 data
bytes. The size of the block does not account for the size byte itself,
therefore, the empty sub-block is one whose size field contains <tt>0x00</tt>
(0).</p>
<h3>b. Required Version</h3>
<p>87a.</p>
<h3>c. Syntax</h3>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">0
</td><td>Block Size
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">1
</td><td rowspan="5">Data Values
</td><td rowspan="5">Byte
</td></tr><tr>
<td style="text-align:center;">2
</td></tr><tr>
<td style="text-align:center;">3
</td></tr><tr>
<td style="text-align:center;">⋮
</td></tr><tr>
<td style="text-align:center;">up to 255
</td></tr></tbody></table>
<ol style="list-style-type:lower-roman;">
<li>Block Size:
<ul>
<li>Number of bytes in the Data Sub-block; the size must be within 0
and 255 bytes, inclusive.
</li></ul>
</li><li>Data Values:
<ul>
<li>Any 8-bit value. There must be exactly as many Data Values as
specified by the Block Size field.
</li></ul>
</li></ol>
<h3>d. Extensions and Scope</h3>
<p>This type of block always occurs as part of a larger unit. It does not have
a scope of itself.</p>
<h3>e. Recommendation</h3>
<p>None.</p>
</div>
<h2 id="blockterminator">16. Block Terminator <span onclick="ToggleVis(16);">(hide/show)</span></h2>
<div id="p16">
<h3>a. Description</h3>
<p>This zero-length <a href="#subblocks">Data Sub-block</a> is used to
terminate a sequence of Data Sub-blocks. It contains a single byte in the
position of the Block Size field and does not contain data.</p>
<h3>b. Required Version</h3>
<p>87a.</p>
<h3>c. Syntax</h3>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">0
</td><td>Block Size
</td><td>Byte
</td></tr></tbody></table>
<ol style="list-style-type:lower-roman;">
<li>Block Size:
<ul>
<li>Number of bytes in the Data Sub-block; this field contains the
fixed value <tt>0x00</tt> (0).
</li></ul>
</li><li>Data Values:
<ul>
<li>This block does not contain any data.
</li></ul>
</li></ol>
<h3>d. Extensions and Scope</h3>
<p>This block terminates the immediately preceding sequence of Data Sub-blocks.
This block cannot be modified by any extension.</p>
<h3>e. Recommendation</h3>
<p>None.</p>
</div>
<h2 id="header">17. Header <span onclick="ToggleVis(17);">(hide/show)</span></h2>
<div id="p17">
<h3>a. Description</h3>
<p>The Header identifies the GIF Data Stream in context. The Signature field
marks the beginning of the Data Stream, and the Version field identifies the
set of capabilities required of a decoder to fully process the Data Stream.
This block is <i>required</i>; exactly one Header must be present per Data
Stream.</p>
<h3>b. Required Version</h3>
<p>Not applicable. This block is not subject to a version number. This block
must appear at the beginning of every Data Stream.</p>
<h3>c. Syntax</h3>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">0
</td><td rowspan="3">Signature
</td><td rowspan="3">3 Bytes
</td></tr><tr>
<td style="text-align:center;">1
</td></tr><tr>
<td style="text-align:center;">2
</td></tr><tr>
<td style="text-align:center;">3
</td><td rowspan="3">Version
</td><td rowspan="3">3 Bytes
</td></tr><tr>
<td style="text-align:center;">4
</td></tr><tr>
<td style="text-align:center;">5
</td></tr></tbody></table>
<ol style="list-style-type:lower-roman;">
<li>Signature:
<ul>
<li>Identifies the GIF Data Stream. This field contains the fixed value
<tt>'GIF'</tt> (<tt>0x47 0x49 0x46</tt>).
</li></ul>
</li><li>Version:
<ul>
<li>Version number used to format the data stream. Identifies the
minimum set of capabilities necessary to a decoder to fully process the
contents of the Data Stream.
</li><li>Version Numbers as of 10 July 1990:
<ul>
<li><tt>"87a"</tt> (<tt>0x38 0x37 0x61</tt>) – May 1987
</li><li><tt>"89a"</tt> (<tt>0x38 0x39 0x61</tt>) – July 1989
</li></ul>
</li><li>Version numbers are ordered numerically increasing on the first two
digits starting with 87 (87, 88, …, 99, 00, …, 85, 86)
and alphabetically increasing on the third character (a, …, z).
</li></ul>
</li><li>Extensions and Scope:
<ul>
<li>The scope of this block is the entire Data Stream. This block
cannot be modified by any extension.
</li></ul>
</li></ol>
<h3>d. Recommendations</h3>
<ol style="list-style-type:lower-roman;">
<li>Signature:
<ul>
<li>This field identifies the beginning of the GIF Data Stream; it is
not intended to provide a unique signature for the identification of
the data. It is recommended that the GIF Data Stream be identified
externally by the application. (Refer to <a href="#online">Appendix
G</a> for on-line identification of the GIF Data Stream.)
</li></ul>
</li><li>Version:
<ul>
<li>Encoder: An encoder should use the earliest possible version number
that defines all the blocks used in the Data Stream. When two or more
Data Streams are combined, the latest of the individual version numbers
should be used for the resulting Data Stream.
</li><li>Decoder: A decoder should attempt to process the data stream to the
best of its ability; if it encounters a version number which it is not
capable of processing fully, it should nevertheless, attempt to process
the data stream to the best of its ability, perhaps after warning the
user that the data may be incomplete.
</li></ul>
</li></ol>
</div>
<h2 id="logicalscreendescriptor">18. Logical Screen Descriptor <span onclick="ToggleVis(18);">(hide/show)</span></h2>
<div id="p18">
<h3>a. Description</h3>
<p>The Logical Screen Descriptor contains the parameters necessary to define
the area of the display device within which the images will be rendered. The
coordinates in this block are given with respect to the top-left corner of the
virtual screen; they do not necessarily refer to absolute coordinates on the
display device. This implies that they could refer to window coordinates in a
window-based environment or printer coordinates when a printer is used.</p>
<p>This block is <i>required</i>; exactly one Logical Screen Descriptor must be
present per Data Stream.</p>
<h3>b. Required Version</h3>
<p>Not applicable. This block is not subject to a version number. This block
must appear immediately after the <a href="#header">Header</a>.</p>
<h3>c. Syntax</h3>
<table>
<tbody><tr>
<th rowspan="2">Byte #
</th><th colspan="8">Bits
</th><th rowspan="2">Field Name
</th><th rowspan="2">Type
</th></tr><tr>
<th>7
</th><th>6
</th><th>5
</th><th>4
</th><th>3
</th><th>2
</th><th>1
</th><th>0
</th></tr><tr>
<td style="text-align:center;">0
</td><td rowspan="2" colspan="8">
</td><td rowspan="2">Logical Screen Width
</td><td rowspan="2">Unsigned
</td></tr><tr>
<td style="text-align:center;">1
</td></tr><tr>
<td style="text-align:center;">2
</td><td rowspan="2" colspan="8">
</td><td rowspan="2">Logical Screen Height
</td><td rowspan="2">Unsigned
</td></tr><tr>
<td style="text-align:center;">3
</td></tr><tr>
<td style="text-align:center;">4
</td><td>
</td><td colspan="3">
</td><td>
</td><td colspan="3">
</td><td><Packed Fields>
</td><td>See below
</td></tr><tr>
<td style="text-align:center;">5
</td><td colspan="8">
</td><td>Background Color Index
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">6
</td><td colspan="8">
</td><td>Pixel Aspect Ratio
</td><td>Byte
</td></tr></tbody></table>
<p><Packed Fields> =</p>
<table>
<tbody><tr>
<td><a href="#globalcolortable">Global Color Table</a> Flag
</td><td>1 Bit
</td></tr><tr>
<td>Color Resolution
</td><td>3 Bits
</td></tr><tr>
<td>Sort Flag
</td><td>1 Bit
</td></tr><tr>
<td>Size of Global Color Table
</td><td>3 Bits
</td></tr></tbody></table>
<ol style="list-style-type:lower-roman;">
<li>Logical Screen Width:
<ul>
<li>Width, in pixels, of the Logical Screen where the images will be
rendered in the displaying device.
</li></ul>
</li><li>Logical Screen Height:
<ul>
<li>Height, in pixels, of the Logical Screen where the images will be
rendered in the displaying device.
</li></ul>
</li><li>Global Color Table Flag:
<ul>
<li>Flag indicating the presence of a Global Color Table; if the flag
is set, the Global Color Table will immediately follow the Logical
Screen Descriptor. This flag also selects the interpretation of the
Background Color Index; if the flag is set, the value of the Background
Color Index field should be used as the table index of the background
color. (This field is the most significant bit of the byte.)
</li><li>Values:
<ul>
<li>0: No Global Color Table follows, the Background Color Index
field is meaningless.
</li><li>1: A Global Color Table will immediately follow, the Background
Color Index field is meaningful.
</li></ul>
</li></ul>
</li><li>Color Resolution:
<ul>
<li>Number of bits per primary color available to the original image,
minus 1. This value represents the size of the entire palette from
which the colors in the graphic were selected, not the number of colors
actually used in the graphic. For example, if the value in this field
is 3, then the palette of the original image had 4 bits per primary
color available to create the image. This value should be set to
indicate the richness of the original palette, even if not every color
from the whole palette is available on the source machine.
</li></ul>
</li><li>Sort Flag:
<ul>
<li>Indicates whether the Global Color Table is sorted. If the flag is
set, the Global Color Table is sorted, in order of decreasing
importance. Typically, the order would be decreasing frequency, with
most frequent color first. This assists a decoder, with fewer available
colors, in choosing the best subset of colors; the decoder may use an
initial segment of the table to render the graphic.
</li><li>Values:
<ul>
<li>0: Not ordered.
</li><li>1: Ordered by decreasing importance, most important color
first.
</li></ul>
</li></ul>
</li><li>Size of Global Color Table:
<ul>
<li>If the Global Color Table Flag is set to 1, the value in this field
is used to calculate the number of bytes contained in the Global Color
Table. To determine that actual size of the color table, raise 2 to
[the value of the field + 1]. Even if there is no Global Color Table
specified, set this field according to the above formula so that
decoders can choose the best graphics mode to display the stream in.
(This field is made up of the 3 least significant bits of the byte.)
</li></ul>
</li><li>Background Color Index:
<ul>
<li>Index into the Global Color Table for the Background Color. The
Background Color is the color used for those pixels on the screen that
are not covered by an image. If the Global Color Table Flag is set to
(zero), this field should be zero and should be ignored.
</li></ul>
</li><li>Pixel Aspect Ratio:
<ul>
<li>Factor used to compute an approximation of the aspect ratio of the
pixel in the original image. If the value of the field is not 0, this
approximation of the aspect ratio is computed based on the formula:<br>
<img src="gif-aspectratio.png" alt="Aspect Ratio = (Pixel Aspect Ratio + 15) ÷ 64">
</li><li>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 <img src="gif-1over64.png" alt="1/64">.
</li><li>Values:
<ul>
<li>0: No aspect ratio information is given.
</li><li>1…255: Value used in the computation.
</li></ul>
</li></ul>
</li></ol>
<h3>d. Extensions and Scope</h3>
<p>The scope of this block is the entire Data Stream. This block cannot be
modified by any extension.</p>
<h3>e. Recommendations</h3>
<p>None.</p>
</div>
<h2 id="globalcolortable">19. Global Color Table <span onclick="ToggleVis(19);">(hide/show)</span></h2>
<div id="p19">
<h3>a. Description</h3>
<p>This block contains a color table, which is a sequence of bytes representing
<span class="rcomp">red</span>-<span class="gcomp">green</span>-<span class="bcomp">blue</span> color triplets. The Global Color Table is used by
images without a <a href="#localcolortable">Local Color Table</a> and by <a href="#plaintextextension">Plain Text Extensions</a>. Its presence is marked by
the Global Color Table Flag being set to 1 in the <a href="#logicalscreendescriptor">Logical Screen Descriptor</a>; if present, it
immediately follows the Logical Screen Descriptor and contains a number of
bytes equal to:</p>
<blockquote>
<p>3 × 2<sup>Size of Global Color Table + 1</sup></p>
</blockquote>
<p>This block is <i>optional</i>; at most one Global Color Table may be present
per Data Stream.</p>
<h3>b. Required Version</h3>
<p>87a.</p>
<h3>c. Syntax</h3>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">0
</td><td><span class="rcomp">Red</span> 0
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">1
</td><td><span class="gcomp">Green</span> 0
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">2
</td><td><span class="bcomp">Blue</span> 0
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">3
</td><td><span class="rcomp">Red</span> 1
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">4
</td><td><span class="gcomp">Green</span> 1
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">⋮
</td><td style="text-align:center;">⋮
</td><td style="text-align:center;">⋮
</td></tr><tr>
<td style="text-align:center;">766
</td><td><span class="gcomp">Green</span> 255
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">up to 767
</td><td><span class="bcomp">Blue</span> 255
</td><td>Byte
</td></tr></tbody></table>
<h3>d. Extensions and Scope</h3>
<p>The scope of this block is the entire Data Stream. This block cannot be
modified by any extension.</p>
<h3>e. Recommendation</h3>
<p>None.</p>
</div>
<h2 id="imagedescriptor">20. Image Descriptor <span onclick="ToggleVis(20);">(hide/show)</span></h2>
<div id="p20">
<h3>a. Description</h3>
<p>Each image in the Data Stream is composed of an Image Descriptor, an
optional <a href="#localcolortable">Local Color Table</a>, and the <a href="#tablebasedimagedata">image data</a>. Each image must fit within the
boundaries of the Logical Screen, as defined in the <a href="#logicalscreendescriptor">Logical Screen Descriptor</a>.</p>
<p>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 <a href="#graphiccontrolextension">Graphic Control Extension</a>, and may be
optionally followed by a Local Color Table; the Image Descriptor is always
followed by the image data.</p>
<p>This block is <i>required</i> 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.</p>
<h3>b. Required Version</h3>
<p>87a.</p>
<h3>c. Syntax</h3>
<table>
<tbody><tr>
<th rowspan="2">Byte #
</th><th colspan="8">Bits
</th><th rowspan="2">Field Name
</th><th rowspan="2">Type
</th></tr><tr>
<th>7
</th><th>6
</th><th>5
</th><th>4
</th><th>3
</th><th>2
</th><th>1
</th><th>0
</th></tr><tr>
<td style="text-align:center;">0
</td><td colspan="8">
</td><td>Image Separator
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">1
</td><td rowspan="2" colspan="8">
</td><td rowspan="2">Image Left Position
</td><td rowspan="2">Unsigned
</td></tr><tr>
<td style="text-align:center;">2
</td></tr><tr>
<td style="text-align:center;">3
</td><td rowspan="2" colspan="8">
</td><td rowspan="2">Image Top Position
</td><td rowspan="2">Unsigned
</td></tr><tr>
<td style="text-align:center;">4
</td></tr><tr>
<td style="text-align:center;">5
</td><td rowspan="2" colspan="8">
</td><td rowspan="2">Image Width
</td><td rowspan="2">Unsigned
</td></tr><tr>
<td style="text-align:center;">6
</td></tr><tr>
<td style="text-align:center;">7
</td><td rowspan="2" colspan="8">
</td><td rowspan="2">Image Height
</td><td rowspan="2">Unsigned
</td></tr><tr>
<td style="text-align:center;">8
</td></tr><tr>
<td style="text-align:center;">9
</td><td>
</td><td>
</td><td>
</td><td colspan="2">
</td><td colspan="3">
</td><td><Packed Fields>
</td><td>See below
</td></tr></tbody></table>
<p><Packed Fields> =</p>
<table>
<tbody><tr>
<td>Local Color Table Flag
</td><td>1 Bit
</td></tr><tr>
<td>Interlace Flag
</td><td>1 Bit
</td></tr><tr>
<td>Sort Flag
</td><td>1 Bit
</td></tr><tr>
<td>Reserved
</td><td>2 Bits
</td></tr><tr>
<td>Size of Local Color Table
</td><td>3 Bits
</td></tr></tbody></table>
<ol style="list-style-type:lower-roman;">
<li>Image Separator:
<ul>
<li>Identifies the beginning of an Image Descriptor. This field
contains the fixed value <tt>0x2C</tt> (44, <tt>','</tt>).
</li></ul>
</li><li>Image Left Position:
<ul>
<li>Column number, in pixels, of the left edge of the image, with
respect to the left edge of the Logical Screen. Leftmost column of the
Logical Screen is 0.
</li></ul>
</li><li>Image Top Position:
<ul>
<li>Row number, in pixels, of the top edge of the image with respect to
the top edge of the Logical Screen. Top row of the Logical Screen is 0.
</li></ul>
</li><li>Image Width:
<ul>
<li>Width of the image in pixels.
</li></ul>
</li><li>Image Height:
<ul>
<li>Height of the image in pixels.
</li></ul>
</li><li>Local Color Table Flag:
<ul>
<li>Indicates the presence of a Local Color Table immediately following
this Image Descriptor. (This field is the most significant bit of the
byte.)
</li><li>Values:
<ul>
<li>0: Local Color Table is not present. Use <a href="#globalcolortable">Global Color Table</a> if available.
</li><li>1: Local Color Table present, and to follow immediately after
this Image Descriptor.
</li></ul>
</li></ul>
</li><li>Interlace Flag:
<ul>
<li>Indicates if the image is interlaced. An image is interlaced in a
four-pass interlace pattern; see <a href="#interlacedimages">Appendix
E</a> for details.
</li><li>Values:
<ul>
<li>0: Image is not interlaced.
</li><li>1: Image is interlaced.
</li></ul>
</li></ul>
</li><li>Sort Flag:
<ul>
<li>Indicates whether the Local Color Table is sorted. If the flag is
set, the Local Color Table is sorted, in order of decreasing
importance. Typically, the order would be decreasing frequency, with
most frequent color first. This assists a decoder, with fewer available
colors, in choosing the best subset of colors; the decoder may use an
initial segment of the table to render the graphic.
</li><li>Values:
<ul>
<li>0: Not ordered.
</li><li>1: Ordered by decreasing importance, most important color
first.
</li></ul>
</li></ul>
</li><li>Size of Local Color Table:
<ul>
<li>If the Local Color Table Flag is set to 1, the value in this field
is used to calculate the number of bytes contained in the Local Color
Table. To determine that actual size of the color table, raise 2 to
[the value of the field + 1]. This value should be 0 if there is no
Local Color Table specified. (This field is made up of the 3 least
significant bits of the byte.)
</li></ul>
</li></ol>
<h3>d. Extensions and Scope</h3>
<p>The scope of this block is the Table-based Image Data Block that follows it.
This block may be modified by the Graphic Control Extension.</p>
<h3>e. Recommendation</h3>
<p>None.</p>
</div>
<h2 id="localcolortable">21. Local Color Table <span onclick="ToggleVis(21);">(hide/show)</span></h2>
<div id="p21">
<h3>a. Description</h3>
<p>This block contains a color table, which is a sequence of bytes representing
<span class="rcomp">red</span>-<span class="gcomp">green</span>-<span class="bcomp">blue</span> color triplets. The Local Color Table is used by the
image that immediately follows. Its presence is marked by the Local Color Table
Flag being set to 1 in the <a href="#imagedescriptor">Image Descriptor</a>; if
present, the Local Color Table immediately follows the Image Descriptor and
contains a number of bytes equal to:</p>
<blockquote>
<p>3 × 2<sup>Size of Local Color Table + 1</sup></p>
</blockquote>
<p>If present, this color table temporarily becomes the active color table and
the following image should be processed using it. This block is
<i>optional</i>; 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.</p>
<h3>b. Required Version</h3>
<p>87a.</p>
<h3>c. Syntax</h3>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">0
</td><td><span class="rcomp">Red</span> 0
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">1
</td><td><span class="gcomp">Green</span> 0
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">2
</td><td><span class="bcomp">Blue</span> 0
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">3
</td><td><span class="rcomp">Red</span> 1
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">4
</td><td><span class="gcomp">Green</span> 1
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">⋮
</td><td style="text-align:center;">⋮
</td><td style="text-align:center;">⋮
</td></tr><tr>
<td style="text-align:center;">766
</td><td><span class="gcomp">Green</span> 255
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">up to 767
</td><td><span class="bcomp">Blue</span> 255
</td><td>Byte
</td></tr></tbody></table>
<h3>d. Extensions and Scope</h3>
<p>The scope of this block is the Table-based Image Data Block that immediately
follows it. This block cannot be modified by any extension.</p>
<h3>e. Recommendations</h3>
<p>None.</p>
</div>
<h2 id="tablebasedimagedata">22. Table Based Image Data <span onclick="ToggleVis(22);">(hide/show)</span></h2>
<div id="p22">
<h3>a. Description</h3>
<p>The image data for a table based image consists of a sequence of <a href="#subblocks">sub-blocks</a>, of size at most 255 bytes each, containing an
index into the active color table, for each pixel in the image. Pixel indices
are in order of left to right and from top to bottom. Each index must be within
the range of the size of the active color table, starting at 0. The sequence of
indices is encoded using the LZW Algorithm with variable-length code, as
described in <a href="#lzw">Appendix F</a>.</p>
<h3>b. Required Version</h3>
<p>87a.</p>
<h3>c. Syntax</h3>
<p>The image data format is as follows:</p>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">0
</td><td>LZW Minimum Code Size
</td><td>Byte
</td></tr></tbody></table>
<p></p>
<table>
<tbody><tr>
<th>Field Name
</th><th>Type
</th></tr><tr>
<td>Image Data
</td><td>Data Sub-blocks
</td></tr></tbody></table>
<ol style="list-style-type:lower-roman;">
<li>LZW Minimum Code Size:
<ul>
<li>This byte determines the initial number of bits used for LZW codes
in the image data, as described in Appendix F.
</li></ul>
</li></ol>
<h3>d. Extensions and Scope</h3>
<p>This block has no scope, it contains raster data. Extensions intended to
modify a Table-based image must appear before the corresponding <a href="#imagedescriptor">Image Descriptor</a>.</p>
<h3>e. Recommendations</h3>
<p>None.</p>
</div>
<h2 id="graphiccontrolextension">23. Graphic Control Extension <span onclick="ToggleVis(23);">(hide/show)</span></h2>
<div id="p23">
<h3>a. Description</h3>
<p>The Graphic Control Extension contains parameters used when processing a
graphic rendering block. The scope of this extension is the first graphic
rendering block to follow. The extension contains only one <a href="#subblocks">data sub-block</a>.</p>
<p>This block is <i>optional</i>; 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.</p>
<h3>b. Required Version</h3>
<p>89a.</p>
<h3>c. Syntax</h3>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">0
</td><td>Extension Introducer
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">1
</td><td>Graphic Control Label
</td><td>Byte
</td></tr></tbody></table>
<p></p>
<table>
<tbody><tr>
<th rowspan="2">Byte #
</th><th colspan="8">Bits
</th><th rowspan="2">Field Name
</th><th rowspan="2">Type
</th></tr><tr>
<th>7
</th><th>6
</th><th>5
</th><th>4
</th><th>3
</th><th>2
</th><th>1
</th><th>0
</th></tr><tr>
<td style="text-align:center;">0
</td><td colspan="8">
</td><td>Block Size
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">1
</td><td colspan="3">
</td><td colspan="3">
</td><td>
</td><td>
</td><td><Packed Fields>
</td><td>See below
</td></tr><tr>
<td style="text-align:center;">2
</td><td rowspan="2" colspan="8">
</td><td rowspan="2">Delay Time
</td><td rowspan="2">Unsigned
</td></tr><tr>
<td style="text-align:center;">3
</td></tr><tr>
<td style="text-align:center;">4
</td><td colspan="8">
</td><td>Transparent Color Index
</td><td>Byte
</td></tr></tbody></table>
<p></p>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">0
</td><td><a href="#blockterminator">Block Terminator</a>
</td><td>Byte
</td></tr></tbody></table>
<p><Packed Fields> =</p>
<table>
<tbody><tr>
<td>Reserved
</td><td>3 Bits
</td></tr><tr>
<td>Disposal Method
</td><td>3 Bits
</td></tr><tr>
<td>User Input Flag
</td><td>1 Bit
</td></tr><tr>
<td>Transparent Color Flag
</td><td>1 Bit
</td></tr></tbody></table>
<ol style="list-style-type:lower-roman;">
<li>Extension Introducer:
<ul>
<li>Identifies the beginning of an extension block. This field contains
the fixed value <tt>0x21</tt> (33, <tt>'!'</tt>).
</li></ul>
</li><li>Graphic Control Label:
<ul>
<li>Identifies the current block as a Graphic Control Extension. This
field contains the fixed value <tt>0xF9</tt> (249).
</li></ul>
</li><li>Block Size:
<ul>
<li>Number of bytes in the block, after the Block Size field and up to
but not including the Block Terminator. This field contains the fixed
value <tt>0x04</tt> (4).
</li></ul>
</li><li>Disposal Method:
<ul>
<li>Indicates the way in which the graphic is to be treated after being
displayed.
</li><li>Values:
<ul>
<li>0: No disposal specified. The decoder is not required to take
any action.
</li><li>1: Do not dispose. The graphic is to be left in place.
</li><li>2: Restore to background color. The area used by the graphic
must be restored to the background color.
</li><li>3: Restore to previous. The decoder is required to restore the
area overwritten by the graphic with what was there prior to rendering the graphic.
</li><li>4–7: To be defined.
</li></ul>
</li></ul>
</li><li>User Input Flag:
<ul>
<li>Indicates whether or not user input is expected before continuing.
If the flag is set, processing will continue when user input is
entered. The nature of the User input is determined by the application
(Carriage Return, Mouse Button Click, etc.).
</li><li>Values:
<ul>
<li>0: User input is not expected.
</li><li>1: User input is expected.
</li></ul>
</li><li>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.
</li></ul>
</li><li>Transparency Flag:
<ul>
<li>Indicates whether a transparency index is given in the Transparent
Index field. (This field is the least significant bit of the byte.)
</li><li>Values:
<ul>
<li>0: Transparent Index is not given.
</li><li>1: Transparent Index is given.
</li></ul>
</li></ul>
</li><li>Delay Time:
<ul>
<li>If not 0, this field specifies the number of hundredths (<img src="gif-1over100.png" alt="1/100">) of a second to wait before
continuing with the processing of the Data Stream. The clock starts
ticking immediately after the graphic is rendered. This field may be
used in conjunction with the User Input Flag field.
</li></ul>
</li><li>Transparency Index:
<ul>
<li>The Transparency Index is such that when encountered, the
corresponding pixel of the display device is not modified and
processing goes on to the next pixel. The index is present if and only
if the Transparency Flag is set to 1.
</li></ul>
</li><li>Block Terminator:
<ul>
<li>This zero-length data block marks the end of the Graphic Control
Extension.
</li></ul>
</li></ol>
<h3>d. Extensions and Scope</h3>
<p>The scope of this Extension is the graphic rendering block that follows it;
it is possible for other extensions to be present between this block and its
target. This block can modify the <a href="#imagedescriptor">Image Descriptor
Block</a> and the <a href="#plaintextextension">Plain Text Extension</a>.</p>
<h3>e. Recommendations</h3>
<ol style="list-style-type:lower-roman;">
<li>Disposal Method:
<ul>
<li>The mode Restore To Previous is intended to be used in small
sections of the graphic; the use of this mode imposes severe demands on
the decoder to store the section of the graphic that needs to be saved.
For this reason, this mode should be used sparingly. This mode is not
intended to save an entire graphic or large areas of a graphic; when
this is the case, the encoder should make every attempt to make the
sections of the graphic to be restored be separate graphics in the data
stream. In the case where a decoder is not capable of saving an area of
a graphic marked as Restore To Previous, it is recommended that a
decoder restore to the background color.
</li></ul>
</li><li>User Input Flag:
<ul>
<li>When the flag is set, indicating that user input is expected, the
decoder may sound the bell (<tt>0x07</tt>, 7) to alert the user that
input is being expected. In the absence of a specified Delay Time, the
decoder should wait for user input indefinitely. It is recommended that
the encoder not set the User Input Flag without a Delay Time specified.
</li></ul>
</li></ol>
</div>
<h2 id="commentextension">24. Comment Extension <span onclick="ToggleVis(24);">(hide/show)</span></h2>
<div id="p24">
<h3>a. Description</h3>
<p>The Comment Extension contains textual information which is not part of the
actual graphics in the GIF Data Stream. It is suitable for including comments
about the graphics, credits, descriptions or any other type of non-control and
non-graphic data. The Comment Extension may be ignored by the decoder, or it
may be saved for later processing; under no circumstances should a Comment
Extension disrupt or interfere with the processing of the Data Stream.</p>
<p>This block is <i>optional</i>; any number of them may appear in the Data
Stream.</p>
<h3>b. Required Version</h3>
<p>89a.</p>
<h3>c. Syntax</h3>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">0
</td><td>Extension Introducer
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">1
</td><td>Comment Label
</td><td>Byte
</td></tr></tbody></table>
<p></p>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">N
</td><td>Comment Data
</td><td><a href="#subblocks">Data Sub-blocks</a>
</td></tr></tbody></table>
<p></p>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">0
</td><td><a href="#blockterminator">Block Terminator</a>
</td><td>Byte
</td></tr></tbody></table>
<ol style="list-style-type:lower-roman;">
<li>Extension Introducer:
<ul>
<li>Identifies the beginning of an extension block. This field contains
the fixed value <tt>0x21</tt> (33, <tt>'!'</tt>).
</li></ul>
</li><li>Comment Label:
<ul>
<li>Identifies the block as a Comment Extension. This field contains
the fixed value <tt>0xFE</tt> (254).
</li></ul>
</li><li>Comment Data:
<ul>
<li>Sequence of sub-blocks, each of size at most 255 bytes and at least
1 byte, with the size in a byte preceding the data. The end of the
sequence is marked by the <a href="#blockterminator">Block
Terminator</a>.
</li></ul>
</li><li>Block Terminator:
<ul>
<li>This zero-length data block marks the end of the Comment Extension.
</li></ul>
</li></ol>
<h3>d. Extensions and Scope</h3>
<p>This block does not have scope. This block cannot be modified by any
extension.</p>
<h3>e. Recommendations</h3>
<ol style="list-style-type:lower-roman;">
<li>Data:
<ul>
<li>This block is intended for humans. It should contain text using the
7-bit ASCII character set. This block should not be used to store
control information for custom processing.
</li></ul>
</li><li>Position:
<ul>
<li>This block may appear at any point in the Data Stream at which a
block can begin; however, it is recommended that Comment Extensions do
not interfere with Control or Data blocks; they should be located at
the beginning or at the end of the Data Stream to the extent possible.
</li></ul>
</li></ol>
</div>
<h2 id="plaintextextension">25. Plain Text Extension <span onclick="ToggleVis(25);">(hide/show)</span></h2>
<div id="p25">
<h3>a. Description</h3>
<p>The Plain Text Extension contains textual data and the parameters necessary
to render that data as a graphic, in a simple form. The textual data will be
encoded with the 7-bit printable ASCII characters. Text data are rendered using
a grid of character cells defined by the parameters in the block fields. Each
character is rendered in an individual cell. The textual data in this block is
to be rendered as mono-spaced characters, one character per cell, with a best
fitting font and size. For further information, see the section on
Recommendations below.</p>
<p>The data characters are taken sequentially from the data portion of the
block and rendered within a cell, starting with the upper left cell in the grid
and proceeding from left to right and from top to bottom. Text data is rendered
until the end of data is reached or the character grid is filled. The Character
Grid contains an integral number of cells; in the case that the cell dimensions
do not allow for an integral number, fractional cells must be discarded; an
encoder must be careful to specify the grid dimensions accurately so that this
does not happen.</p>
<p>This block requires a <a href="#globalcolortable">Global Color Table</a> to
be available; the colors used by this block reference the Global Color Table in
the Stream if there is one, or the Global Color Table from a previous Stream,
if one was saved.</p>
<p>This block is a graphic rendering block, therefore it may be modified by a
<a href="#graphiccontrolextension">Graphic Control Extension</a>.</p>
<p>This block is <i>optional</i>; any number of them may appear in the Data
Stream.</p>
<h3>b. Required Version</h3>
<p>89a.</p>
<h3>c. Syntax</h3>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">0
</td><td>Extension Introducer
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">1
</td><td>Plain Text Label
</td><td>Byte
</td></tr></tbody></table>
<p></p>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">0
</td><td>Block Size
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">1
</td><td rowspan="2">Text Grid Left Position
</td><td rowspan="2">Unsigned
</td></tr><tr>
<td style="text-align:center;">2
</td></tr><tr>
<td style="text-align:center;">3
</td><td rowspan="2">Text Grid Top Position
</td><td rowspan="2">Unsigned
</td></tr><tr>
<td style="text-align:center;">4
</td></tr><tr>
<td style="text-align:center;">5
</td><td rowspan="2">Text Grid Width
</td><td rowspan="2">Unsigned
</td></tr><tr>
<td style="text-align:center;">6
</td></tr><tr>
<td style="text-align:center;">7
</td><td rowspan="2">Text Grid Height
</td><td rowspan="2">Unsigned
</td></tr><tr>
<td style="text-align:center;">8
</td></tr><tr>
<td style="text-align:center;">9
</td><td>Character Cell Width
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">10
</td><td>Character Cell Height
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">11
</td><td>Text Foreground Color Index
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">12
</td><td>Text Background Color Index
</td><td>Byte
</td></tr></tbody></table>
<p></p>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">N
</td><td>Plain Text Data
</td><td>Data Sub-blocks
</td></tr></tbody></table>
<p></p>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">0
</td><td><a href="#blockterminator">Block Terminator</a>
</td><td>Byte
</td></tr></tbody></table>
<ol style="list-style-type:lower-roman;">
<li>Extension Introducer:
<ul>
<li>Identifies the beginning of an extension block. This field contains
the fixed value <tt>0x21</tt> (33, <tt>'!'</tt>).
</li></ul>
</li><li>Plain Text Label:
<ul>
<li>Identifies the current block as a Plain Text Extension. This field
contains the fixed value <tt>0x01</tt> (1).
</li></ul>
</li><li>Block Size:
<ul>
<li>Number of bytes in the extension, after the Block Size field and up
to but not including the beginning of the data portion. This field
contains the fixed value <tt>0x0C</tt> (12).
</li></ul>
</li><li>Text Grid Left Position:
<ul>
<li>Column number, in pixels, of the left edge of the text grid, with
respect to the left edge of the Logical Screen.
</li></ul>
</li><li>Text Grid Top Position:
<ul>
<li>Row number, in pixels, of the top edge of the text grid, with
respect to the top edge of the Logical Screen.
</li></ul>
</li><li>Image Grid Width:
<ul>
<li>Width of the text grid in pixels.
</li></ul>
</li><li>Image Grid Height:
<ul>
<li>Height of the text grid in pixels.
</li></ul>
</li><li>Character Cell Width:
<ul>
<li>Width, in pixels, of each cell in the grid.
</li></ul>
</li><li>Character Cell Height:
<ul>
<li>Height, in pixels, of each cell in the grid.
</li></ul>
</li><li>Text Foreground Color Index:
<ul>
<li>Index into the Global Color Table to be used to render the text
foreground.
</li></ul>
</li><li>Text Background Color Index:
<ul>
<li>Index into the Global Color Table to be used to render the text
background.
</li></ul>
</li><li>Plain Text Data:
<ul>
<li>Sequence of sub-blocks, each of size at most 255 bytes and at least
1 byte, with the size in a byte preceding the data. The end of the
sequence is marked by the Block Terminator.
</li></ul>
</li><li>Block Terminator:
<ul>
<li>This zero-length data block marks the end of the Plain Text Data
Blocks.
</li></ul>
</li></ol>
<h3>d. Extensions and Scope</h3>
<p>The scope of this block is the Plain Text Data Block contained in it. This
block may be modified by the Graphic Control Extension.</p>
<h3 id="p25e">e. Recommendations</h3>
<p>The data in the Plain Text Extension is assumed to be preformatted. The
selection of font and size is left to the discretion of the decoder. If
characters less than <tt>0x20</tt> (32) or greater than <tt>0xF7</tt> (247) are
encountered, it is recommended that the decoder display a Space character
(<tt>0x20</tt>, 32). The encoder should use grid and cell dimensions such that
an integral number of cells fit in the grid both horizontally as well as
vertically. For broadest compatibility, character cell dimensions should be
around 8×8 or 8×16 (width × height); consider an image for
unusual sized text.</p>
<p><i>Editor's (Kalle's) note: the upper limit for a printable character,
<tt>0xF7</tt>, seems odd. Maybe they meant <tt>0x7E</tt> (126, <tt>'~'</tt>,
the last printable 7-bit ASCII character)?</i></p>
</div>
<h2 id="applicationextension">26. Application Extension <span onclick="ToggleVis(26);">(hide/show)</span></h2>
<div id="p26">
<h3>a. Description</h3>
<p>The Application Extension contains application-specific information; it
conforms with the extension block syntax, as described below, and its block
label is <tt>0xFF</tt> (255).</p>
<h3>b. Required Version</h3>
<p>89a.</p>
<h3>c. Syntax</h3>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">0
</td><td>Extension Introducer
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">1
</td><td>Extension Label
</td><td>Byte
</td></tr></tbody></table>
<p></p>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">0
</td><td>Block Size
</td><td>Byte
</td></tr><tr>
<td style="text-align:center;">1…8
</td><td>Application Identifier
</td><td>8 Bytes
</td></tr><tr>
<td style="text-align:center;">9…11
</td><td>Application Authentication Code
</td><td>3 Bytes
</td></tr></tbody></table>
<p></p>
<table>
<tbody><tr>
<th>Field Name
</th><th>Type
</th></tr><tr>
<td>Application Data
</td><td><a href="#subblocks">Data Sub-blocks</a>
</td></tr></tbody></table>
<p></p>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">0
</td><td><a href="#blockterminator">Block Terminator</a>
</td><td>Byte
</td></tr></tbody></table>
<ol style="list-style-type:lower-roman;">
<li>Extension Introducer:
<ul>
<li>Defines this block as an extension. This field contains the fixed
value <tt>0x21</tt> (33, <tt>'!'</tt>).
</li></ul>
</li><li>Application Extension Label:
<ul>
<li>Identifies the block as an Application Extension. This field
contains the fixed value <tt>0xFF</tt> (255).
</li></ul>
</li><li>Block Size:
<ul>
<li>Number of bytes in this extension block, following the Block Size
field, up to but not including the beginning of the Application Data.
This field contains the fixed value <tt>0x0B</tt> (11).
</li></ul>
</li><li>Application Identifier:
<ul>
<li>Sequence of eight printable ASCII characters used to identify the
application owning the Application Extension.
</li></ul>
</li><li>Application Authentication Code:
<ul>
<li>Sequence of three bytes used to authenticate the Application
Identifier. An Application program may use an algorithm to compute a
binary code that uniquely identifies it as the application owning the
Application Extension.
</li></ul>
</li></ol>
<h3>d. Extensions and Scope</h3>
<p>This block does not have scope. This block cannot be modified by any extension.</p>
<h3>e. Recommendation</h3>
<p>None.</p>
</div>
<h2 id="trailer">27. Trailer <span onclick="ToggleVis(27);">(hide/show)</span></h2>
<div id="p27">
<h3>a. Description</h3>
<p>This block is a single-field block indicating the end of the GIF Data
Stream. It contains the fixed value <tt>0x3B</tt> (59, <tt>';'</tt>).</p>
<h3>b. Required Version</h3>
<p>87a.</p>
<h3>c. Syntax</h3>
<table>
<tbody><tr>
<th>Byte #
</th><th>Field Name
</th><th>Type
</th></tr><tr>
<td style="text-align:center;">0
</td><td>GIF Trailer
</td><td>Byte
</td></tr></tbody></table>
<h3>d. Extensions and Scope</h3>
<p>This block does not have scope, it terminates the GIF Data Stream. This
block may not be modified by any extension.</p>
<h3>e. Recommendations</h3>
<p>None.</p>
</div>
<h2 id="quickreferencetable">Appendix A. Quick Reference Table <span onclick="ToggleVis(28);">(hide/show)</span></h2>
<div id="p28">
<table>
<tbody><tr>
<th>Block Name
</th><th>Required?
</th><th>Label
</th><th>Extension
</th><th>Version
</th></tr><tr>
<th colspan="5">Unlabeled Blocks
</th></tr><tr>
<td><a href="#header">Header</a>
</td><td>required (one occurrence)
</td><td style="text-align:center;">none
</td><td style="text-align:center;">no
</td><td style="text-align:center;">N/A
</td></tr><tr>
<td><a href="#logicalscreendescriptor">Logical Screen Descriptor</a>
</td><td>required (one occurrence)
</td><td style="text-align:center;">none
</td><td style="text-align:center;">no
</td><td style="text-align:center;">87a (89a)
</td></tr><tr>
<td><a href="#globalcolortable">Global Color Table</a>
</td><td>optional (at most one occurrence)
</td><td style="text-align:center;">none
</td><td style="text-align:center;">no
</td><td style="text-align:center;">87a
</td></tr><tr>
<td><a href="#localcolortable">Local Color Table</a>
</td><td>optional (zero or more occurrences)
</td><td style="text-align:center;">none
</td><td style="text-align:center;">no
</td><td style="text-align:center;">87a
</td></tr><tr>
<th colspan="5">Graphic-Rendering Blocks
</th></tr><tr>
<td><a href="#plaintextextension">Plain Text Extension</a>
</td><td>optional (zero or more occurrences)
</td><td style="text-align:center;"><tt>0x01</tt> (1)
</td><td style="text-align:center;">yes
</td><td style="text-align:center;">89a
</td></tr><tr>
<td><a href="#imagedescriptor">Image Descriptor</a>
</td><td>optional (zero or more occurrences)
</td><td style="text-align:center;"><tt>0x2C</tt> (44, <tt>','</tt>)
</td><td style="text-align:center;">no
</td><td style="text-align:center;">87a (89a)
</td></tr><tr>
<th colspan="5">Control Blocks
</th></tr><tr>
<td><a href="#graphiccontrolextension">Graphic Control Extension</a>
</td><td>optional (zero or more occurrences)
</td><td style="text-align:center;"><tt>0xF9</tt> (249)
</td><td style="text-align:center;">yes
</td><td style="text-align:center;">89a
</td></tr><tr>
<th colspan="5">Special Purpose Blocks
</th></tr><tr>
<td><a href="#trailer">Trailer</a>
</td><td>required (one occurrence)
</td><td style="text-align:center;"><tt>0x3B</tt> (59, <tt>';'</tt>)
</td><td style="text-align:center;">no
</td><td style="text-align:center;">87a
</td></tr><tr>
<td><a href="#commentextension">Comment Extension</a>
</td><td>optional (zero or more occurrences)
</td><td style="text-align:center;"><tt>0xFE</tt> (254)
</td><td style="text-align:center;">yes
</td><td style="text-align:center;">89a
</td></tr><tr>
<td><a href="#applicationextension">Application Extension</a>
</td><td>optional (zero or more occurrences)
</td><td style="text-align:center;"><tt>0xFF</tt> (255)
</td><td style="text-align:center;">yes
</td><td style="text-align:center;">89a
</td></tr></tbody></table>
<p>Notes:</p>
<ul>
<li>The Header is not subject to Version Numbers.
</li><li>(89a) The Logical Screen Descriptor and the Image Descriptor retained
their syntax from version 87a to version 89a, but some fields reserved
under version 87a are used under version 89a.
</li></ul>
</div>
<h2 id="gifgrammar">Appendix B. GIF Grammar <span onclick="ToggleVis(29);">(hide/show)</span></h2>
<div id="p29">
<p>A Grammar is a form of notation to represent the sequence in which certain
objects form larger objects. A grammar is also used to represent the number of
objects that can occur at a given position. The grammar given here represents
the sequence of blocks that form the GIF Data Stream. A grammar is given by
listing its rules. Each rule consists of the left-hand side, followed by some
form of equals sign, followed by the right-hand side. In a rule, the right-hand
side describes how the left-hand side is defined. The right-hand side consists
of a sequence of entities, with the possible presence of special symbols. The
following legend defines the symbols used in this grammar for GIF.</p>
<p>Legend:</p>
<table>
<tbody><tr>
<td style="text-align:center;">< >
</td><td>grammar word
</td></tr><tr>
<td style="text-align:center;">::=
</td><td>defines symbol
</td></tr><tr>
<td style="text-align:center;">*
</td><td>zero or more occurrences
</td></tr><tr>
<td style="text-align:center;">+
</td><td>one or more occurrences
</td></tr><tr>
<td style="text-align:center;">|
</td><td>alternate element
</td></tr><tr>
<td style="text-align:center;">[ ]
</td><td>optional element
</td></tr></tbody></table>
<p>Example:</p>
<blockquote>
<p><GIF Data Stream> ::= <a href="#header">Header</a> <Logical
Screen> <Data>* <a href="#trailer">Trailer</a></p>
</blockquote>
<p>This rule defines the entity <GIF Data Stream> as follows. It must
begin with a Header. The Header is followed by an entity called Logical Screen,
which is defined below by another rule. The Logical Screen is followed by the
entity Data, which is also defined below by another rule. Finally, the entity
Data is followed by the Trailer. Since there is no rule defining the Header or
the Trailer, this means that these blocks are defined in the document. The
entity Data has a special symbol (*) following it which means that, at this
position, the entity Data may be repeated any number of times, including 0
times. For further reading on this subject, refer to a standard text on
Programming Languages.</p>
<h3>The Grammar</h3>
<table class="invisible">
<tbody><tr>
<td><GIF Data Stream>
</td><td>::=
</td><td>Header <Logical Screen> <Data>* Trailer
</td></tr><tr>
<td><Logical Screen>
</td><td>::=
</td><td><a href="#logicalscreendescriptor">Logical Screen Descriptor</a>
[<a href="#globalcolortable">Global Color Table</a>]
</td></tr><tr>
<td><Data>
</td><td>::=
</td><td><Graphic Block> | <Special-Purpose Block>
</td></tr><tr>
<td><Graphic Block>
</td><td>::=
</td><td>[<a href="#graphiccontrolextension">Graphic Control Extension</a>]
<Graphic-Rendering Block>
</td></tr><tr>
<td><Graphic-Rendering Block>
</td><td>::=
</td><td><Table-Based Image> | <a href="#plaintextextension">Plain
Text Extension</a>
</td></tr><tr>
<td><Table-Based Image>
</td><td>::=
</td><td><a href="#imagedescriptor">Image Descriptor</a> [<a href="#localcolortable">Local Color Table</a>] <a href="#tablebasedimagedata">Image Data</a>
</td></tr><tr>
<td><Special-Purpose Block>
</td><td>::=
</td><td><a href="#applicationextension">Application Extension</a> | <a href="#commentextension">Comment Extension</a>
</td></tr></tbody></table>
<p><i>Note:</i> The grammar indicates that it is possible for a GIF Data Stream
to contain the Header, the Logical Screen Descriptor, a Global Color Table and
the GIF Trailer. This special case is used to load a GIF decoder with a Global
Color Table, in preparation for subsequent Data Streams without color tables at
all.</p>
</div>
<h2 id="glossary">Appendix C. Glossary <span onclick="ToggleVis(30);">(hide/show)</span></h2>
<div id="p30">
<table>
<tbody><tr>
<td>Active Color Table
</td><td>Color table used to render the next graphic. If the next graphic is
an image which has a <a href="#localcolortable">Local Color Table</a>
associated with it, the active color table becomes the Local Color
Table associated with that image. If the next graphic is an image
without a Local Color Table, or a <a href="#plaintextextension">Plain
Text Extension</a>, the active color table is the <a href="#globalcolortable">Global Color Table</a> associated with the
Data Stream, if there is one; if there is no Global Color Table in the
Data Stream, the active color table is a color table saved from a
previous Data Stream, or one supplied by the decoder.
</td></tr><tr>
<td>Block
</td><td>Collection of bytes forming a protocol unit. In general, the term
includes labeled and unlabeled blocks, as well as Extensions.
</td></tr><tr>
<td>Data Stream
</td><td>The GIF Data Stream is composed of blocks and <a href="#subblocks">sub-blocks</a> representing images and graphics,
together with control information to render them on a display device.
All control and data blocks in the Data Stream must follow the <a href="#header">Header</a> and must precede the <a href="#trailer">Trailer</a>.
</td></tr><tr>
<td>Decoder
</td><td>A program capable of processing a GIF Data Stream to render the
images and graphics contained in it.
</td></tr><tr>
<td>Encoder
</td><td>A program capable of capturing and formatting image and graphic
raster data, following the definitions of the Graphics Interchange
Format.
</td></tr><tr>
<td>Extension
</td><td>A protocol block labeled by the Extension Introducer <tt>0x21</tt>
(33, <tt>'!'</tt>).
</td></tr><tr>
<td>Extension Introducer
</td><td>Label (<tt>0x21</tt>, 33, <tt>'!'</tt>) defining an Extension.
</td></tr><tr>
<td>Graphic
</td><td>Data which can be rendered on the screen by virtue of some
algorithm. The term graphic is more general than the term image; in
addition to images, the term graphic also includes data such as text,
which is rendered using character bit-maps.
</td></tr><tr>
<td>Image
</td><td>Data representing a picture or a drawing; an image is represented
by an array of pixels called the raster of the image.
</td></tr><tr>
<td>Raster
</td><td>Array of pixel values representing an image.
</td></tr></tbody></table>
</div>
<h2 id="conventions">Appendix D. Conventions <span onclick="ToggleVis(31);">(hide/show)</span></h2>
<div id="p31">
<table>
<tbody><tr>
<td>Animation
</td><td>The Graphics Interchange Format is not intended as a platform for
animation, even though it can be done in a limited way.
</td></tr><tr>
<td>Byte Ordering
</td><td>Unless otherwise stated, multi-byte numeric fields are ordered with
the Least Significant Byte first.
</td></tr><tr>
<td>Color Indices
</td><td>Color indices always refer to the active color table, either the <a href="#globalcolortable">Global Color Table</a> or the <a href="#localcolortable">Local Color Table</a>.
</td></tr><tr>
<td>Color Order
</td><td>Unless otherwise stated, all triple-component RGB color values are
specified in <span class="rcomp">Red</span>-<span class="gcomp">Green</span>-<span class="bcomp">Blue</span> order.
</td></tr><tr>
<td>Color Tables
</td><td>Both color tables, the Global and the Local, are optional; if
present, the Global Color Table is to be used with every image in the
Data Stream for which a Local Color Table is not given; if present, a
Local Color Table overrides the Global Color Table. However, if neither
color table is present, the application program is free to use an
arbitrary color table. If the graphics in several Data Streams are
related and all use the same color table, an encoder could place the
color table as the Global Color Table in the first Data Stream and
leave subsequent Data Streams without a Global Color Table or any Local
Color Tables; in this way, the overhead for the table is eliminated. It
is recommended that the decoder save the previous Global Color Table to
be used with the Data Stream that follows, in case it does not contain
either a Global Color Table or any Local Color Tables. In general, this
allows the application program to use past color tables, significantly
reducing transmission overhead.
</td></tr><tr>
<td>Extension Blocks
</td><td>Extensions are defined using the Extension Introducer code
(<tt>0x21</tt>, 33, <tt>'!'</tt>) to mark the beginning of the block,
followed by a block label, identifying the type of extension. Extension
Codes are numbers in the range from <tt>0x00</tt> (0) to <tt>0xFF</tt>
(255), inclusive. Special purpose extensions are transparent to the
decoder and may be omitted when transmitting the Data Stream on-line.
The GIF capabilities dialogue makes the provision for the receiver to
request the transmission of all blocks; the default state in this
regard is no transmission of Special purpose blocks.
</td></tr><tr>
<td>Reserved Fields
</td><td>All Reserved Fields are expected to have each bit set to zero
(off).
</td></tr></tbody></table>
</div>
<h2 id="interlacedimages">Appendix E. Interlaced Images <span onclick="ToggleVis(32);">(hide/show)</span></h2>
<div id="p32">
<p>The rows of an Interlaced images are arranged in the following order:</p>
<table>
<tbody><tr>
<td>Group 1
</td><td>Pass 1
</td><td>Every 8th row, starting with row 0
</td></tr><tr>
<td>Group 2
</td><td>Pass 2
</td><td>Every 8th row, starting with row 4
</td></tr><tr>
<td>Group 3
</td><td>Pass 3
</td><td>Every 4th row, starting with row 2
</td></tr><tr>
<td>Group 4
</td><td>Pass 4
</td><td>Every 2nd row, starting with row 1
</td></tr></tbody></table>
<p>The following example illustrates how the rows of an interlaced image are
ordered.</p>
<table id="interlace">
<tbody><tr>
<th>Row Number
</th><th colspan="4">Interlace Pass
</th></tr><tr>
<td>0
</td><td>1
</td><td>
</td><td>
</td><td>
</td></tr><tr>
<td>1
</td><td>
</td><td>
</td><td>
</td><td>4
</td></tr><tr>
<td>2
</td><td>
</td><td>
</td><td>3
</td><td>
</td></tr><tr>
<td>3
</td><td>
</td><td>
</td><td>
</td><td>4
</td></tr><tr>
<td>4
</td><td>
</td><td>2
</td><td>
</td><td>
</td></tr><tr>
<td>5
</td><td>
</td><td>
</td><td>
</td><td>4
</td></tr><tr>
<td>6
</td><td>
</td><td>
</td><td>3
</td><td>
</td></tr><tr>
<td>7
</td><td>
</td><td>
</td><td>
</td><td>4
</td></tr><tr>
<td>8
</td><td>1
</td><td>
</td><td>
</td><td>
</td></tr><tr>
<td>9
</td><td>
</td><td>
</td><td>
</td><td>4
</td></tr><tr>
<td>10
</td><td>
</td><td>
</td><td>3
</td><td>
</td></tr><tr>
<td>11
</td><td>
</td><td>
</td><td>
</td><td>4
</td></tr><tr>
<td>12
</td><td>
</td><td>2
</td><td>
</td><td>
</td></tr><tr>
<td>13
</td><td>
</td><td>
</td><td>
</td><td>4
</td></tr><tr>
<td>14
</td><td>
</td><td>
</td><td>3
</td><td>
</td></tr><tr>
<td>15
</td><td>
</td><td>
</td><td>
</td><td>4
</td></tr><tr>
<td>16
</td><td>1
</td><td>
</td><td>
</td><td>
</td></tr><tr>
<td>17
</td><td>
</td><td>
</td><td>
</td><td>4
</td></tr><tr>
<td>18
</td><td>
</td><td>
</td><td>3
</td><td>
</td></tr><tr>
<td>19
</td><td>
</td><td>
</td><td>
</td><td>4
</td></tr></tbody></table>
</div>
<h2 id="lzw">Appendix F. Variable-Length-Code LZW Compression <span onclick="ToggleVis(33);">(hide/show)</span></h2>
<div id="p33">
<p>The Variable-Length-Code LZW Compression is a variation of the Lempel-Ziv
Compression algorithm in which variable-length codes are used to replace
patterns detected in the original data. The algorithm uses a code or
translation table constructed from the patterns encountered in the original
data; each new pattern is entered into the table and its index is used to
replace it in the compressed stream.</p>
<p>The compressor takes the data from the input stream and builds a code or
translation table with the patterns as it encounters them; each new pattern is
entered into the code table and its index is added to the output stream; when a
pattern is encountered which had been detected since the last code table
refresh, its index from the code table is put on the output stream, thus
achieving the data compression. The expander takes input from the compressed
data stream and builds the code or translation table from it; as the compressed
data stream is processed, codes are used to index into the code table and the
corresponding data is put on the decompressed output stream, thus achieving
data decompression. The details of the algorithm are explained below. The
Variable-Length-Code aspect of the algorithm is based on an initial code size
(LZW-initial code size), which specifies the initial number of bits used for
the compression codes. When the number of patterns detected by the compressor
in the input stream exceeds the number of patterns encodable with the current
number of bits, the number of bits per LZW code is increased by one.</p>
<p>The Raster Data stream that represents the actual output image can be
represented as:</p>
<table>
<tbody><tr>
<th>Field name
</th></tr><tr>
<td>LZW code size
</td></tr></tbody></table>
<p></p>
<table>
<tbody><tr>
<th>Field name
</th><th>
</th></tr><tr>
<td>block size
</td><td rowspan="2">Repeated as many times as necessary.
</td></tr><tr>
<td>data bytes
</td></tr></tbody></table>
<p>(The code that terminates the LZW compressed data must appear before <a href="#blockterminator">Block Terminator</a>.)</p>
<table>
<tbody><tr>
<th>Field name
</th></tr><tr>
<td>Block Terminator (<tt>0x00</tt>, 0)
</td></tr></tbody></table>
<p>The conversion of the image from a series of pixel values to a transmitted
or stored character stream involves several steps. In brief these steps
are:</p>
<ol>
<li>Establish the Code Size – Define the number of bits needed to
represent the actual data.
</li><li>Compress the Data – Compress the series of image pixels to a
series of compression codes.
</li><li>Build a Series of Bytes – Take the set of compression codes and
convert to a string of 8-bit bytes.
</li><li>Package the Bytes – Package sets of bytes into blocks preceded by
character counts and output.
</li></ol>
<h3>1. Establish Code Size</h3>
<p>The first byte of the Compressed Data stream is a value indicating the
minimum number of bits required to represent the set of actual pixel values.
Normally this will be the same as the number of color bits. Because of some
algorithmic constraints however, black & white images which have one color
bit must be indicated as having a code size of 2. This code size value also
implies that the compression codes must start out one bit longer.</p>
<h3>2. Compression</h3>
<p>The LZW algorithm converts a series of data values into a series of codes
which may be raw values or a code designating a series of values. Using text
characters as an analogy, the output code consists of a character or a code
representing a string of characters.</p>
<p>The LZW algorithm used in GIF matches algorithmically with the standard LZW
algorithm with the following differences:</p>
<ol>
<li>A special Clear code is defined which resets all
compression/decompression parameters and tables to a start-up state. The
value of this code is 2<sup><code size></sup>. For example if the
code size indicated was 4 (image was 4 bits/pixel) the Clear code value
would be 16 (<tt>10000</tt> binary). The Clear code can appear at any point
in the image data stream and therefore requires the LZW algorithm to
process succeeding codes as if a new data stream was starting. Encoders
should output a Clear code as the first code of each image data stream.
</li><li>An End of Information code is defined that explicitly indicates the end
of the image data stream. LZW processing terminates when this code is
encountered. It must be the last code output by the encoder for an image.
The value of this code is <Clear code>+1.
</li><li>The first available compression code value is <Clear code> + 2.
</li><li>The output codes are of variable length, starting at <code size>
+ 1 bits per code, up to 12 bits per code. This defines a maximum code
value of 4095 (<tt>0xFFF</tt>). Whenever the LZW code value would exceed
the current code length, the code length is increased by one. The
packing/unpacking of these codes must then be altered to reflect the new
code length.
</li></ol>
<p><i>Editor's (Kalle's) note: see also the <a href="#coversheet">Cover
Sheet</a>.</i></p>
<h3>3. Build 8-bit Bytes</h3>
<p>Because the LZW compression used for GIF creates a series of variable length
codes, of between 3 and 12 bits each, these codes must be reformed into a
series of 8-bit bytes that will be the characters actually stored or
transmitted. This provides additional compression of the image. The codes are
formed into a stream of bits as if they were packed right to left and then
picked off 8 bits at a time to be output.</p>
<p>Assuming a character array of 8 bits per character and using 5 bit codes to
be packed, an example layout would be similar to:</p>
<table>
<tbody><tr>
<th>Byte #
</th><th>Bits
</th></tr><tr>
<td style="text-align:center;">0
</td><td><tt>bbbaaaaa</tt>
</td></tr><tr>
<td style="text-align:center;">1
</td><td><tt>dcccccbb</tt>
</td></tr><tr>
<td style="text-align:center;">2
</td><td><tt>eeeedddd</tt>
</td></tr><tr>
<td style="text-align:center;">3
</td><td><tt>ggfffffe</tt>
</td></tr><tr>
<td style="text-align:center;">4
</td><td><tt>hhhhhggg</tt>
</td></tr><tr>
<td style="text-align:center;">⋮
</td><td><tt></tt>
</td></tr><tr>
<td style="text-align:center;">N
</td><td>
</td></tr></tbody></table>
<p>Note that the physical packing arrangement will change as the number of bits
per compression code change but the concept remains the same.</p>
<h3>4. Package the Bytes</h3>
<p>Once the bytes have been created, they are grouped into blocks for output by
preceding each block of 0 to 255 bytes with a character count byte. A block
with a zero byte count terminates the Raster Data stream for a given image.
These blocks are what are actually output for the GIF image. This block format
has the side effect of allowing a decoding program the ability to read past the
actual image data if necessary by reading block counts and then skipping over
the data.</p>
<h3>Further Reading</h3>
<ol>
<li>Ziv, J. and Lempel, A.: <i>A Universal Algorithm for Sequential Data
Compression</i>, IEEE Transactions on Information Theory, May 1977
</li><li>Welch, T.: <i>A Technique for High-Performance Data Compression</i>,
Computer, June 1984
</li><li>Nelson, M.R.: <i>LZW Data Compression</i>, Dr. Dobb's Journal, October
1989
</li></ol>
<p><i>Editor's (Kalle's) note: see also <a href="https://web.archive.org/web/20160304075538/http://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch">Wikipedia –
Lempel–Ziv–Welch</a>.</i></p>
</div>
<h2 id="onlinecapabilities">Appendix G. On-line Capabilities Dialogue <span onclick="ToggleVis(34);">(hide/show)</span></h2>
<div id="p34">
<p><i>Note:</i> This section is currently (10 July 1990) under revision; the
information provided here should be used as general guidelines. Code written
based on this information should be designed in a flexible way to accommodate
any changes resulting from the revisions.</p>
<p>The following sequences are defined for use in mediating control between a
GIF sender and GIF receiver over an interactive communications line. These
sequences do not apply to applications that involve downloading of static GIF
files and are not considered part of a GIF file.</p>
<h3>GIF Capabilities Enquiry</h3>
<p>The GIF Capabilities Enquiry sequence is issued from a host and requests an
interactive GIF decoder to return a response message that defines the graphics
parameters for the decoder. This involves returning information about available
screen sizes, number of bits/color supported and the amount of color detail
supported. The escape sequence for the GIF Capabilities Enquiry is defined
as:</p>
<table>
<tbody><tr>
<td style="text-align:center;"><tt>ESC</tt>
</td><td style="text-align:center;"><tt>0x1B</tt> (27)
</td></tr><tr>
<td style="text-align:center;"><tt>[</tt>
</td><td style="text-align:center;"><tt>0x5B</tt> (91)
</td></tr><tr>
<td style="text-align:center;"><tt>></tt>
</td><td style="text-align:center;"><tt>0x3E</tt> (62)
</td></tr><tr>
<td style="text-align:center;"><tt>0</tt>
</td><td style="text-align:center;"><tt>0x30</tt> (48)
</td></tr><tr>
<td style="text-align:center;"><tt>g</tt>
</td><td style="text-align:center;"><tt>0x67</tt> (103)
</td></tr></tbody></table>
<h3>GIF Capabilities Response</h3>
<p>The GIF Capabilities Response message is returned by an interactive GIF
decoder and defines the decoder's display capabilities for all graphics modes
that are supported by the software. Note that this can also include graphics
printers as well as a monitor screen. The general format of this message
is:</p>
<p>#version;protocol{;dev, width, height, color-bits,
color-res}…<CR></p>
<table>
<tbody><tr>
<td><tt>'#'</tt>
</td><td>GIF Capabilities Response identifier character.
</td></tr><tr>
<td>version
</td><td>GIF format version number; initially <tt>'87a'</tt>.
</td></tr><tr>
<td>protocol=<tt>'0'</tt>
</td><td>No end-to-end protocol supported by decoder Transfer as direct
8-bit data stream.
</td></tr><tr>
<td>protocol=<tt>'1'</tt>
</td><td>Can use CIS B+ error correction protocol to transfer GIF data
interactively from the host directly to the display.
</td></tr><tr>
<td>dev=<tt>'0'</tt>
</td><td>Screen parameter set follows.
</td></tr><tr>
<td>dev=<tt>'1'</tt>
</td><td>Printer parameter set follows.
</td></tr><tr>
<td>width
</td><td>Maximum supported display width in pixels.
</td></tr><tr>
<td>height
</td><td>Maximum supported display height in pixels.
</td></tr><tr>
<td>color-bits
</td><td>Number of bits per pixel supported. The number of supported colors
is therefore 2<sup>color-bits</sup>.
</td></tr><tr>
<td>color-res
</td><td>Number of bits per color component supported in the hardware color
palette. If color-res is <tt>'0'</tt> then no hardware palette table is
available.
</td></tr></tbody></table>
<p>Note that all values in the GIF Capabilities Response are returned as ASCII
decimal numbers and the message is terminated by a Carriage Return character
(<tt>0x0D</tt>, 13).</p>
<p>The following GIF Capabilities Response message describes three standard IBM
PC <a href="https://web.archive.org/web/20160304075538/http://en.wikipedia.org/wiki/Enhanced_Graphics_Adapter">Enhanced
Graphics Adapter</a> configurations with no printer; the GIF data stream can be
processed within an error correcting protocol:</p>
<blockquote>
<p><tt>#87a;1;0,320,200,4,0;0,640,200,2,2;0,640,350,4,2<CR></tt></p>
</blockquote>
<h3>Enter GIF Graphics Mode</h3>
<p>Two sequences are currently defined to invoke an interactive GIF decoder
into action. The only difference between them is that different output media
are selected. These sequences are:</p>
<table>
<tbody><tr>
<td style="text-align:center;"><tt>ESC</tt>
</td><td style="text-align:center;"><tt>0x1B</tt> (27)
</td><td rowspan="5">Display GIF image on screen
</td></tr><tr>
<td style="text-align:center;"><tt>[</tt>
</td><td style="text-align:center;"><tt>0x5B</tt> (91)
</td></tr><tr>
<td style="text-align:center;"><tt>></tt>
</td><td style="text-align:center;"><tt>0x3E</tt> (62)
</td></tr><tr>
<td style="text-align:center;"><tt>1</tt>
</td><td style="text-align:center;"><tt>0x31</tt> (49)
</td></tr><tr>
<td style="text-align:center;"><tt>g</tt>
</td><td style="text-align:center;"><tt>0x67</tt> (103)
</td></tr></tbody></table>
<p></p>
<table>
<tbody><tr>
<td style="text-align:center;"><tt>ESC</tt>
</td><td style="text-align:center;"><tt>0x1B</tt> (27)
</td><td rowspan="5">Display image directly to an attached graphics printer.
The image may optionally be displayed on the screen as well.
</td></tr><tr>
<td style="text-align:center;"><tt>[</tt>
</td><td style="text-align:center;"><tt>0x5B</tt> (91)
</td></tr><tr>
<td style="text-align:center;"><tt>></tt>
</td><td style="text-align:center;"><tt>0x3E</tt> (62)
</td></tr><tr>
<td style="text-align:center;"><tt>2</tt>
</td><td style="text-align:center;"><tt>0x32</tt> (50)
</td></tr><tr>
<td style="text-align:center;"><tt>g</tt>
</td><td style="text-align:center;"><tt>0x67</tt> (103)
</td></tr></tbody></table>
<p>Note that the <tt>'g'</tt> character terminating each sequence is in
lowercase.</p>
<h3>Interactive Environment</h3>
<p>The assumed environment for the transmission of GIF image data from an
interactive application is a full 8-bit data stream from host to micro. All 256
character codes must be transferrable. The establishing of an 8-bit data path
for communications will normally be taken care of by the host application
programs. It is however up to the receiving communications programs supporting
GIF to be able to receive and pass on all 256 8-bit codes to the GIF decoder
software.</p>
</div>
<h2 id="coversheet">Cover Sheet for the GIF89a Specification <span onclick="ToggleVis(35);">(hide/show)</span></h2>
<div id="p35">
<h3>Deferred clear code in LZW compression</h3>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Because of a large base of decoders that do not handle the decompression in
this manner, we ask developers of GIF encoding software to <i>not</i> 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.</p>
<h3>Application Extension Block – Application Identifier</h3>
<p>There will be a Courtesy Directory file located on CompuServe in the PICS
forum. This directory will contain Application Identifiers for <a href="#applicationextension">Application Extension Blocks</a> 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.</p>
<p>E-Mail can be sent to Larry Wood (forum manager of PICS) indicating the
request for inclusion in this file with an identifier.</p>
</div>
<hr>
</body>
</html>
Sindbad File Manager Version 1.0, Coded By Sindbad EG ~ The Terrorists