gifenc 0.1.0

data/docs/Specification.md

@@ -0,0 +1,2477 @@
+```
+
+
+
+    Cover Sheet for the GIF89a Specification
+
+
+    DEFERRED CLEAR CODE IN LZW COMPRESSION
+
+    There has been confusion about where clear codes can be found in the
+    data stream.  As the specification says, they may appear at anytime.  There
+    is not a requirement to send a clear code when the string table is full.
+
+    It is the encoder's decision as to when the table should be cleared.  When
+    the table is full, the encoder can chose to use the table as is, making no
+    changes to it until the encoder chooses to clear it.  The encoder during
+    this time sends out codes that are of the maximum Code Size.
+
+    As we can see from the above, when the decoder's table is full, it must
+    not change the table until a clear code is received.  The Code Size is that
+    of the maximum Code Size.  Processing other than this is done normally.
+
+    Because of a large base of decoders that do not handle the decompression in
+    this manner, we ask developers of GIF encoding software to NOT implement
+    this feature until at least January 1991 and later if they see that their
+    particular market is not ready for it.  This will give developers of GIF
+    decoding software time to implement this feature and to get it into the
+    hands of their clients before the decoders start "breaking" on the new
+    GIF's.  It is not required that encoders change their software to take
+    advantage of the deferred clear code, but it is for decoders.
+
+    APPLICATION EXTENSION BLOCK - APPLICATION IDENTIFIER
+
+    There will be a Courtesy Directory file located on CompuServe in the PICS
+    forum.  This directory will contain Application Identifiers for Application
+    Extension Blocks that have been used by developers of GIF applications.
+    This file is intended to help keep developers that wish to create
+    Application Extension Blocks from using the same Application Identifiers.
+    This is not an official directory; it is for voluntary participation only
+    and does not guarantee that someone will not use the same identifier.
+
+    E-Mail can be sent to Larry Wood (forum manager of PICS) indicating the
+    request for inclusion in this file with an identifier.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                        GRAPHICS INTERCHANGE FORMAT(sm)
+
+                                  Version 89a
+
+                            (c)1987,1988,1989,1990
+
+                                   Copyright
+                            CompuServe Incorporated
+                                Columbus, Ohio
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+CompuServe Incorporated                           Graphics Interchange Format
+Document Date : 31 July 1990                            Programming Reference
+
+
+
+
+
+
+
+
+
+
+                               Table of Contents
+
+Disclaimer.................................................................  1
+
+Foreword...................................................................  1
+
+Licensing..................................................................  1
+
+About the Document.........................................................  2
+
+General Description........................................................  2
+
+Version Numbers............................................................  2
+
+The Encoder................................................................  3
+
+The Decoder................................................................  3
+
+Compliance.................................................................  3
+
+About Recommendations......................................................  4
+
+About Color Tables.........................................................  4
+
+Blocks, Extensions and Scope...............................................  4
+
+Block Sizes................................................................  5
+
+Using GIF as an embedded protocol..........................................  5
+
+Data Sub-blocks............................................................  5
+
+Block Terminator...........................................................  6
+
+Header.....................................................................  7
+
+Logical Screen Descriptor..................................................  8
+
+Global Color Table......................................................... 10
+
+Image Descriptor........................................................... 11
+
+Local Color Table.......................................................... 13
+
+Table Based Image Data..................................................... 14
+
+Graphic Control Extension.................................................. 15
+
+Comment Extension.......................................................... 17
+
+Plain Text Extension....................................................... 18
+
+Application Extension...................................................... 21
+
+Trailer.................................................................... 23
+
+
+
+
+
+
+
+
+
+
+
+Quick Reference Table...................................................... 24
+
+GIF Grammar................................................................ 25
+
+Glossary................................................................... 27
+
+Conventions................................................................ 28
+
+Interlaced Images.......................................................... 29
+
+Variable-Length-Code LZW Compression....................................... 30
+
+On-line Capabilities Dialogue.............................................. 33
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                         1
+
+
+1. Disclaimer.
+
+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.
+
+
+2. Foreword.
+
+This document defines the Graphics Interchange Format(sm). The specification
+given here defines version 89a, which is an extension of version 87a.
+
+The Graphics Interchange Format(sm) as specified here should be considered
+complete; any deviation from it should be considered invalid, including but not
+limited to, the use of reserved or undefined fields within control or data
+blocks, the inclusion of extraneous data within or between blocks, the use of
+methods or algorithms not specifically listed as part of the format, etc. In
+general, any and all deviations, extensions or modifications not specified in
+this document should be considered to be in violation of the format and should
+be avoided.
+
+
+3. Licensing.
+
+The Graphics Interchange Format(c) is the copyright property of CompuServe
+Incorporated. Only CompuServe Incorporated is authorized to define, redefine,
+enhance, alter, modify or change in any way the definition of the format.
+
+CompuServe Incorporated hereby grants a limited, non-exclusive, royalty-free
+license for the use of the Graphics Interchange Format(sm) in computer
+software; computer software utilizing GIF(sm) must acknowledge ownership of the
+Graphics Interchange Format and its Service Mark by CompuServe Incorporated, in
+User and Technical Documentation. Computer software utilizing GIF, which is
+distributed or may be distributed without User or Technical Documentation must
+display to the screen or printer a message acknowledging ownership of the
+Graphics Interchange Format and the Service Mark by CompuServe Incorporated; in
+this case, the acknowledgement may be displayed in an opening screen or leading
+banner, or a closing screen or trailing banner. A message such as the following
+may be used:
+
+      "The Graphics Interchange Format(c) is the Copyright property of
+      CompuServe Incorporated. GIF(sm) is a Service Mark property of
+      CompuServe Incorporated."
+
+For further information, please contact :
+
+      CompuServe Incorporated
+      Graphics Technology Department
+      5000 Arlington Center Boulevard
+      Columbus, Ohio  43220
+      U. S. A.
+
+CompuServe Incorporated maintains a mailing list with all those individuals and
+organizations who wish to receive copies of this document when it is corrected
+
+
+
+
+
+
+
+                                                                         2
+
+
+or revised. This service is offered free of charge; please provide us with your
+mailing address.
+
+
+4. About the Document.
+
+This document describes in detail the definition of the Graphics Interchange
+Format.  This document is intended as a programming reference; it is
+recommended that the entire document be read carefully before programming,
+because of the interdependence of the various parts. There is an individual
+section for each of the Format blocks. Within each section, the sub-section
+labeled Required Version refers to the version number that an encoder will have
+to use if the corresponding block is used in the Data Stream. Within each
+section, a diagram describes the individual fields in the block; the diagrams
+are drawn vertically; top bytes in the diagram appear first in the Data Stream.
+Bits within a byte are drawn most significant on the left end.  Multi-byte
+numeric fields are ordered Least Significant Byte first. Numeric constants are
+represented as Hexadecimal numbers, preceded by "0x".  Bit fields within a byte
+are described in order from most significant bits to least significant bits.
+
+
+5. General Description.
+
+The Graphics Interchange Format(sm) defines a protocol intended for the on-line
+transmission and interchange of raster graphic data in a way that is
+independent of the hardware used in their creation or display.
+
+The Graphics Interchange Format is defined in terms of blocks and sub-blocks
+which contain relevant parameters and data used in the reproduction of a
+graphic. A GIF Data Stream is a sequence of protocol blocks and sub-blocks
+representing a collection of graphics. In general, the graphics in a Data
+Stream are assumed to be related to some degree, and to share some control
+information; it is recommended that encoders attempt to group together related
+graphics in order to minimize hardware changes during processing and to
+minimize control information overhead. For the same reason, unrelated graphics
+or graphics which require resetting hardware parameters should be encoded
+separately to the extent possible.
+
+A Data Stream may originate locally, as when read from a file, or it may
+originate remotely, as when transmitted over a data communications line. The
+Format is defined with the assumption that an error-free Transport Level
+Protocol is used for communications; the Format makes no provisions for
+error-detection and error-correction.
+
+The GIF Data Stream must be interpreted in context, that is, the application
+program must rely on information external to the Data Stream to invoke the
+decoder process.
+
+
+6. Version Numbers.
+
+The version number in the Header of a Data Stream is intended to identify the
+minimum set of capabilities required of a decoder in order to fully process the
+Data Stream.  An encoder should use the earliest possible version number that
+includes all the blocks used in the Data Stream. Within each block section in
+this document, there is an entry labeled Required Version which specifies the
+
+
+
+
+
+
+
+                                                                         3
+
+
+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.
+
+
+7. The Encoder.
+
+The Encoder is the program used to create a GIF Data Stream. From raster data
+and other information, the encoder produces the necessary control and data
+blocks needed for reproducing the original graphics.
+
+The encoder has the following primary responsibilities.
+
+            - Include in the Data Stream all the necessary information to
+            reproduce  the graphics.
+
+            - 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.
+
+            - Ensure encoding of the graphics in such a way that the decoding
+            process is optimized. Avoid redundant information as much as
+            possible.
+
+            - To the extent possible, avoid grouping graphics which might
+            require resetting hardware parameters during the decoding process.
+
+            - 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 Image Descriptor were reserved under Version
+            87a, but are used under version 89a.
+
+
+8. The Decoder.
+
+The Decoder is the program used to process a GIF Data Stream. It processes the
+Data Stream sequentially, parsing the various blocks and sub-blocks, using the
+control information to set hardware and process parameters and interpreting the
+data to render the graphics.
+
+The decoder has the following primary responsibilities.
+
+            - Process each graphic in the Data Stream in sequence, without
+            delays other than those specified in the control information.
+
+            - Set its hardware parameters to fit, as closely as possible, the
+            control information contained in the Data Stream.
+
+
+9. Compliance.
+
+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
+
+
+
+
+
+
+
+                                                                         4
+
+
+encoder or a decoder may be compliant with a given version number and not
+compliant with some subsequent version.
+
+
+10. About Recommendations.
+
+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.
+
+
+11. About Color Tables.
+
+The GIF format utilizes color tables to render raster-based graphics. A color
+table can have one of two different scopes: global or local. A Global Color
+Table is used by all those graphics in the Data Stream which do not have a
+Local Color Table associated with them. The scope of the Global Color Table is
+the entire Data Stream. A Local Color Table is always associated with the
+graphic that immediately follows it; the scope of a Local Color Table is
+limited to that single graphic. A Local Color Table supersedes a Global Color
+Table, that is, if a Data Stream contains a Global Color Table, and an image
+has a Local Color Table associated with it, the decoder must save the Global
+Color Table, use the Local Color Table to render the image, and then restore
+the Global Color Table. Both types of color tables are optional, making it
+possible for a Data Stream to contain numerous graphics without a color table
+at all. For this reason, it is recommended that the decoder save the last
+Global Color Table used until another Global Color Table is encountered. In
+this way, a Data Stream which does not contain either a Global Color Table or
+a Local Color Table may be processed using the last Global Color Table saved.
+If a Global Color Table from a previous Stream is used, that table becomes the
+Global Color Table of the present Stream. This is intended to reduce the
+overhead incurred by color tables. In particular, it is recommended that an
+encoder use only one Global Color Table if all the images in related Data
+Streams can be rendered with the same table.  If no color table is available at
+all, the decoder is free to use a system color table or a table of its own. In
+that case, the decoder may use a color table with as many colors as its
+hardware is able to support; it is recommended that such a table have black and
+white as its first two entries, so that monochrome images can be rendered
+adequately.
+
+The Definition of the GIF Format allows for a Data Stream to contain only the
+Header, the Logical Screen Descriptor, a Global Color Table and the GIF
+Trailer. Such a Data Stream would be used to load a decoder with a Global Color
+Table, in preparation for subsequent Data Streams without a color table at all.
+
+
+12. Blocks, Extensions and Scope.
+
+Blocks can be classified into three groups : Control, Graphic-Rendering and
+Special Purpose.  Control blocks, such as the Header, the Logical Screen
+Descriptor, the Graphic Control Extension and the Trailer, contain information
+used to control the process of the Data Stream or information  used in setting
+hardware parameters.  Graphic-Rendering blocks such as the Image Descriptor and
+
+
+
+
+
+
+
+                                                                         5
+
+
+the Plain Text Extension contain information and data used to render a graphic
+on the display device. Special Purpose blocks such as the Comment Extension and
+the Application Extension are neither used to control the process of the Data
+Stream nor do they contain information or data used to render a graphic on the
+display device. With the exception of the Logical Screen Descriptor and the
+Global Color Table, whose scope is the entire Data Stream, all other Control
+blocks have a limited scope, restricted to the Graphic-Rendering block that
+follows them.  Special Purpose blocks do not delimit the scope of any Control
+blocks; Special Purpose blocks are transparent to the decoding process.
+Graphic-Rendering blocks and extensions are used as scope delimiters for
+Control blocks and extensions. The labels used to identify labeled blocks fall
+into three ranges : 0x00-0x7F (0-127) are the Graphic Rendering blocks,
+excluding the Trailer (0x3B); 0x80-0xF9 (128-249) are the Control blocks;
+0xFA-0xFF (250-255) are the Special Purpose blocks. These ranges are defined so
+that decoders can handle block scope by appropriately identifying block labels,
+even when the block itself cannot be processed.
+
+
+13. Block Sizes.
+
+The Block Size field in a block, counts the number of bytes remaining in the
+block, not counting the Block Size field itself, and not counting the Block
+Terminator, if one is to follow.  Blocks other than Data Blocks are intended to
+be of fixed length; the Block Size field is provided in order to facilitate
+skipping them, not to allow their size to change in the future.  Data blocks
+and sub-blocks are of variable length to accommodate the amount of data.
+
+
+14. Using GIF as an embedded protocol.
+
+As an embedded protocol, GIF may be part of larger application protocols,
+within which GIF is used to render graphics.  In such a case, the application
+protocol could define a block within which the GIF Data Stream would be
+contained. The application program would then invoke a GIF decoder upon
+encountering a block of type GIF.  This approach is recommended in favor of
+using Application Extensions, which become overhead for all other applications
+that do not process them. Because a GIF Data Stream must be processed in
+context, the application must rely on some means of identifying the GIF Data
+Stream outside of the Stream itself.
+
+
+15. Data Sub-blocks.
+
+      a. Description. 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 0x00.
+
+      b. Required Version.  87a.
+
+
+
+
+
+
+
+
+
+
+
+                                                                         6
+
+
+      c. Syntax.
+
+      7 6 5 4 3 2 1 0        Field Name                    Type
+     +---------------+
+  0  |               |       Block Size                    Byte
+     +---------------+
+  1  |               |
+     +-             -+
+  2  |               |
+     +-             -+
+  3  |               |
+     +-             -+
+     |               |       Data Values                   Byte
+     +-             -+
+ up  |               |
+     +-   . . . .   -+
+ to  |               |
+     +-             -+
+     |               |
+     +-             -+
+255  |               |
+     +---------------+
+
+            i) Block Size - Number of bytes in the Data Sub-block; the size
+            must be within 0 and 255 bytes, inclusive.
+
+            ii) Data Values - Any 8-bit value. There must be exactly as many
+            Data Values as specified by the Block Size field.
+
+      d. Extensions and Scope. This type of block always occurs as part of a
+      larger unit. It does not have a scope of itself.
+
+      e. Recommendation. None.
+
+
+16. Block Terminator.
+
+      a. Description. This zero-length Data Sub-block 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.
+
+      b. Required Version.  87a.
+
+      c. Syntax.
+
+      7 6 5 4 3 2 1 0        Field Name                    Type
+     +---------------+
+  0  |               |       Block Size                    Byte
+     +---------------+
+
+            i) Block Size - Number of bytes in the Data Sub-block; this field
+            contains the fixed value 0x00.
+
+            ii) Data Values - This block does not contain any data.
+
+
+
+
+
+
+
+
+
+                                                                         7
+
+
+      d. Extensions and Scope. This block terminates the immediately preceding
+      sequence of Data Sub-blocks. This block cannot be modified by any
+      extension.
+
+      e. Recommendation. None.
+
+
+17. Header.
+
+      a. Description. 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 REQUIRED; exactly one Header must
+      be present per Data Stream.
+
+      b. Required Version.  Not applicable. This block is not subject to a
+      version number. This block must appear at the beginning of every Data
+      Stream.
+
+      c. Syntax.
+
+
+      7 6 5 4 3 2 1 0        Field Name                    Type
+     +---------------+
+   0 |               |       Signature                     3 Bytes
+     +-             -+
+   1 |               |
+     +-             -+
+   2 |               |
+     +---------------+
+   3 |               |       Version                       3 Bytes
+     +-             -+
+   4 |               |
+     +-             -+
+   5 |               |
+     +---------------+
+
+            i) Signature - Identifies the GIF Data Stream. This field contains
+            the fixed value 'GIF'.
+
+            ii) Version - 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.
+
+            Version Numbers as of 10 July 1990 :       "87a" - May 1987
+                                                       "89a" - July 1989
+
+            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).
+
+            iii) Extensions and Scope. The scope of this block is the entire
+            Data Stream. This block cannot be modified by any extension.
+
+
+
+
+
+
+
+
+
+
+                                                                         8
+
+
+      d. Recommendations.
+
+            i) Signature - 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
+            Appendix G for on-line identification of the GIF Data Stream.)
+
+            ii) Version - 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. 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.
+
+
+18. Logical Screen Descriptor.
+
+      a. Description.  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.
+
+      This block is REQUIRED; exactly one Logical Screen Descriptor must be
+      present per Data Stream.
+
+      b. Required Version.  Not applicable. This block is not subject to a
+      version number. This block must appear immediately after the Header.
+
+      c. Syntax.
+
+      7 6 5 4 3 2 1 0        Field Name                    Type
+     +---------------+
+  0  |               |       Logical Screen Width          Unsigned
+     +-             -+
+  1  |               |
+     +---------------+
+  2  |               |       Logical Screen Height         Unsigned
+     +-             -+
+  3  |               |
+     +---------------+
+  4  | |     | |     |       <Packed Fields>               See below
+     +---------------+
+  5  |               |       Background Color Index        Byte
+     +---------------+
+  6  |               |       Pixel Aspect Ratio            Byte
+     +---------------+
+
+
+
+
+
+
+
+
+
+                                                                         9
+
+
+     <Packed Fields>  =      Global Color Table Flag       1 Bit
+                             Color Resolution              3 Bits
+                             Sort Flag                     1 Bit
+                             Size of Global Color Table    3 Bits
+
+            i) Logical Screen Width - Width, in pixels, of the Logical Screen
+            where the images will be rendered in the displaying device.
+
+            ii) Logical Screen Height - Height, in pixels, of the Logical
+            Screen where the images will be rendered in the displaying device.
+
+            iii) Global Color Table Flag - 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.)
+
+            Values :    0 -   No Global Color Table follows, the Background
+                              Color Index field is meaningless.
+                        1 -   A Global Color Table will immediately follow, the
+                              Background Color Index field is meaningful.
+
+            iv) Color Resolution - 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.
+
+            v) Sort Flag - 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.
+
+            Values :    0 -   Not ordered.
+                        1 -   Ordered by decreasing importance, most
+                              important color first.
+
+            vi) Size of Global Color Table - 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.)
+
+            vii) Background Color Index - Index into the Global Color Table for
+
+
+
+
+
+
+
+                                                                        10
+
+
+            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.
+
+            viii) Pixel Aspect Ratio - 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:
+
+            Aspect Ratio = (Pixel Aspect Ratio + 15) / 64
+
+            The Pixel Aspect Ratio is defined to be the quotient of the pixel's
+            width over its height.  The value range in this field allows
+            specification of the widest pixel of 4:1 to the tallest pixel of
+            1:4 in increments of 1/64th.
+
+            Values :        0 -   No aspect ratio information is given.
+                       1..255 -   Value used in the computation.
+
+      d. Extensions and Scope. The scope of this block is the entire Data
+      Stream. This block cannot be modified by any extension.
+
+      e. Recommendations. None.
+
+
+19. Global Color Table.
+
+      a. Description. This block contains a color table, which is a sequence of
+      bytes representing red-green-blue color triplets. The Global Color Table
+      is used by images without a Local Color Table and by Plain Text
+      Extensions. Its presence is marked by the Global Color Table Flag being
+      set to 1 in the Logical Screen Descriptor; if present, it immediately
+      follows the Logical Screen Descriptor and contains a number of bytes
+      equal to
+                    3 x 2^(Size of Global Color Table+1).
+
+      This block is OPTIONAL; at most one Global Color Table may be present
+      per Data Stream.
+
+      b. Required Version.  87a
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                        11
+
+
+      c. Syntax.
+
+      7 6 5 4 3 2 1 0        Field Name                    Type
+     +===============+
+  0  |               |       Red 0                         Byte
+     +-             -+
+  1  |               |       Green 0                       Byte
+     +-             -+
+  2  |               |       Blue 0                        Byte
+     +-             -+
+  3  |               |       Red 1                         Byte
+     +-             -+
+     |               |       Green 1                       Byte
+     +-             -+
+ up  |               |
+     +-   . . . .   -+       ...
+ to  |               |
+     +-             -+
+     |               |       Green 255                     Byte
+     +-             -+
+767  |               |       Blue 255                      Byte
+     +===============+
+
+
+      d. Extensions and Scope. The scope of this block is the entire Data
+      Stream. This block cannot be modified by any extension.
+
+      e. Recommendation. None.
+
+
+20. Image Descriptor.
+
+      a. Description. Each image in the Data Stream is composed of an Image
+      Descriptor, an optional Local Color Table, and the image data.  Each
+      image must fit within the boundaries of the Logical Screen, as defined
+      in the Logical Screen Descriptor.
+
+      The Image Descriptor contains the parameters necessary to process a table
+      based image. The coordinates given in this block refer to coordinates
+      within the Logical Screen, and are given in pixels. This block is a
+      Graphic-Rendering Block, optionally preceded by one or more Control
+      blocks such as the Graphic Control Extension, and may be optionally
+      followed by a Local Color Table; the Image Descriptor is always followed
+      by the image data.
+
+      This block is REQUIRED for an image.  Exactly one Image Descriptor must
+      be present per image in the Data Stream.  An unlimited number of images
+      may be present per Data Stream.
+
+      b. Required Version.  87a.
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                        12
+
+
+      c. Syntax.
+
+      7 6 5 4 3 2 1 0        Field Name                    Type
+     +---------------+
+  0  |               |       Image Separator               Byte
+     +---------------+
+  1  |               |       Image Left Position           Unsigned
+     +-             -+
+  2  |               |
+     +---------------+
+  3  |               |       Image Top Position            Unsigned
+     +-             -+
+  4  |               |
+     +---------------+
+  5  |               |       Image Width                   Unsigned
+     +-             -+
+  6  |               |
+     +---------------+
+  7  |               |       Image Height                  Unsigned
+     +-             -+
+  8  |               |
+     +---------------+
+  9  | | | |   |     |       <Packed Fields>               See below
+     +---------------+
+
+     <Packed Fields>  =      Local Color Table Flag        1 Bit
+                             Interlace Flag                1 Bit
+                             Sort Flag                     1 Bit
+                             Reserved                      2 Bits
+                             Size of Local Color Table     3 Bits
+
+           i) Image Separator - Identifies the beginning of an Image
+           Descriptor. This field contains the fixed value 0x2C.
+
+           ii) Image Left Position - 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.
+
+           iii) Image Top Position - 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.
+
+           iv) Image Width - Width of the image in pixels.
+
+           v) Image Height - Height of the image in pixels.
+
+           vi) Local Color Table Flag - Indicates the presence of a Local Color
+           Table immediately following this Image Descriptor. (This field is
+           the most significant bit of the byte.)
+
+
+           Values :    0 -   Local Color Table is not present. Use
+                             Global Color Table if available.
+                       1 -   Local Color Table present, and to follow
+                             immediately after this Image Descriptor.
+
+
+
+
+
+
+
+
+                                                                        13
+
+
+           vii) Interlace Flag - Indicates if the image is interlaced. An image
+           is interlaced in a four-pass interlace pattern; see Appendix E for
+           details.
+
+           Values :    0 - Image is not interlaced.
+                       1 - Image is interlaced.
+
+            viii) Sort Flag - 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.
+
+            Values :    0 -   Not ordered.
+                        1 -   Ordered by decreasing importance, most
+                              important color first.
+
+            ix) Size of Local Color Table - 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.)
+
+     d. Extensions and Scope. 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.
+
+     e. Recommendation. None.
+
+
+21. Local Color Table.
+
+     a. Description. This block contains a color table, which is a sequence of
+     bytes representing red-green-blue 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 Image Descriptor; if
+     present, the Local Color Table immediately follows the Image Descriptor
+     and contains a number of bytes equal to
+                          3x2^(Size of Local Color Table+1).
+     If present, this color table temporarily becomes the active color table
+     and the following image should be processed using it. This block is
+     OPTIONAL; at most one Local Color Table may be present per Image
+     Descriptor and its scope is the single image associated with the Image
+     Descriptor that precedes it.
+
+     b. Required Version.  87a.
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                        14
+
+
+     c. Syntax.
+
+      7 6 5 4 3 2 1 0        Field Name                    Type
+     +===============+
+  0  |               |       Red 0                         Byte
+     +-             -+
+  1  |               |       Green 0                       Byte
+     +-             -+
+  2  |               |       Blue 0                        Byte
+     +-             -+
+  3  |               |       Red 1                         Byte
+     +-             -+
+     |               |       Green 1                       Byte
+     +-             -+
+ up  |               |
+     +-   . . . .   -+       ...
+ to  |               |
+     +-             -+
+     |               |       Green 255                     Byte
+     +-             -+
+767  |               |       Blue 255                      Byte
+     +===============+
+
+
+     d. Extensions and Scope. The scope of this block is the Table-based Image
+     Data Block that immediately follows it. This block cannot be modified by
+     any extension.
+
+     e. Recommendations. None.
+
+
+22. Table Based Image Data.
+
+     a. Description. The image data for a table based image consists of a
+     sequence of sub-blocks, 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 Appendix F
+
+     b. Required Version.  87a.
+
+     c. Syntax. The image data format is as follows:
+
+      7 6 5 4 3 2 1 0        Field Name                    Type
+     +---------------+
+     |               |       LZW Minimum Code Size         Byte
+     +---------------+
+
+     +===============+
+     |               |
+     /               /       Image Data                    Data Sub-blocks
+     |               |
+     +===============+
+
+
+
+
+
+
+
+
+                                                                        15
+
+
+            i) LZW Minimum Code Size.  This byte determines the initial number
+            of bits used for LZW codes in the image data, as described in
+            Appendix F.
+
+     d. Extensions and Scope. This block has no scope, it contains raster
+     data. Extensions intended to modify a Table-based image must appear
+     before the corresponding Image Descriptor.
+
+     e. Recommendations. None.
+
+
+23. Graphic Control Extension.
+
+      a. Description. 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 data sub-block.
+
+      This block is OPTIONAL; at most one Graphic Control Extension may precede
+      a graphic rendering block. This is the only limit to the number of
+      Graphic Control Extensions that may be contained in a Data Stream.
+
+      b. Required Version.  89a.
+
+      c. Syntax.
+
+      7 6 5 4 3 2 1 0        Field Name                    Type
+     +---------------+
+  0  |               |       Extension Introducer          Byte
+     +---------------+
+  1  |               |       Graphic Control Label         Byte
+     +---------------+
+
+     +---------------+
+  0  |               |       Block Size                    Byte
+     +---------------+
+  1  |     |     | | |       <Packed Fields>               See below
+     +---------------+
+  2  |               |       Delay Time                    Unsigned
+     +-             -+
+  3  |               |
+     +---------------+
+  4  |               |       Transparent Color Index       Byte
+     +---------------+
+
+     +---------------+
+  0  |               |       Block Terminator              Byte
+     +---------------+
+
+
+      <Packed Fields>  =     Reserved                      3 Bits
+                             Disposal Method               3 Bits
+                             User Input Flag               1 Bit
+                             Transparent Color Flag        1 Bit
+
+            i) Extension Introducer - Identifies the beginning of an extension
+
+
+
+
+
+
+
+                                                                        16
+
+
+            block. This field contains the fixed value 0x21.
+
+            ii) Graphic Control Label - Identifies the current block as a
+            Graphic Control Extension. This field contains the fixed value
+            0xF9.
+
+            iii) Block Size - 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 4.
+
+            iv) Disposal Method - Indicates the way in which the graphic is to
+            be treated after being displayed.
+
+            Values :    0 -   No disposal specified. The decoder is
+                              not required to take any action.
+                        1 -   Do not dispose. The graphic is to be left
+                              in place.
+                        2 -   Restore to background color. The area used by the
+                              graphic must be restored to the background color.
+                        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.
+                     4-7 -    To be defined.
+
+            v) User Input Flag - 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.).
+
+            Values :    0 -   User input is not expected.
+                        1 -   User input is expected.
+
+            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.
+
+            vi) Transparency Flag - Indicates whether a transparency index is
+            given in the Transparent Index field. (This field is the least
+            significant bit of the byte.)
+
+            Values :    0 -   Transparent Index is not given.
+                        1 -   Transparent Index is given.
+
+            vii) Delay Time - If not 0, this field specifies the number of
+            hundredths (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.
+
+            viii) Transparency Index - 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.
+
+            ix) Block Terminator - This zero-length data block marks the end of
+
+
+
+
+
+
+
+                                                                        17
+
+            the Graphic Control Extension.
+
+      d. Extensions and Scope. 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
+      Image Descriptor Block and the Plain Text Extension.
+
+      e. Recommendations.
+
+            i) Disposal Method - 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.
+
+            ii) User Input Flag - When the flag is set, indicating that user
+            input is expected, the decoder may sound the bell (0x07) 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.
+
+
+24. Comment Extension.
+
+      a. Description. 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.
+
+      This block is OPTIONAL; any number of them may appear in the Data Stream.
+
+      b. Required Version.  89a.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                        18
+
+
+      c. Syntax.
+
+      7 6 5 4 3 2 1 0        Field Name                    Type
+     +---------------+
+  0  |               |       Extension Introducer          Byte
+     +---------------+
+  1  |               |       Comment Label                 Byte
+     +---------------+
+
+     +===============+
+     |               |
+  N  |               |       Comment Data                  Data Sub-blocks
+     |               |
+     +===============+
+
+     +---------------+
+  0  |               |       Block Terminator              Byte
+     +---------------+
+
+            i) Extension Introducer - Identifies the beginning of an extension
+            block. This field contains the fixed value 0x21.
+
+            ii) Comment Label - Identifies the block as a Comment Extension.
+            This field contains the fixed value 0xFE.
+
+            iii) Comment Data - 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.
+
+            iv) Block Terminator - This zero-length data block marks the end of
+            the Comment Extension.
+
+      d. Extensions and Scope. This block does not have scope. This block
+      cannot be modified by any extension.
+
+      e. Recommendations.
+
+            i) Data - 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.
+
+            ii) Position - 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.
+
+
+25. Plain Text Extension.
+
+      a. Description. 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
+
+
+
+
+
+
+
+
+                                                                        19
+
+
+      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. 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. This block requires a Global Color Table 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. This block is a graphic rendering block,
+      therefore it may be modified by a Graphic Control Extension.  This block
+      is OPTIONAL; any number of them may appear in the Data Stream.
+
+      b. Required Version.  89a.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                        20
+
+
+      c. Syntax.
+
+      7 6 5 4 3 2 1 0        Field Name                    Type
+     +---------------+
+  0  |               |       Extension Introducer          Byte
+     +---------------+
+  1  |               |       Plain Text Label              Byte
+     +---------------+
+
+     +---------------+
+  0  |               |       Block Size                    Byte
+     +---------------+
+  1  |               |       Text Grid Left Position       Unsigned
+     +-             -+
+  2  |               |
+     +---------------+
+  3  |               |       Text Grid Top Position        Unsigned
+     +-             -+
+  4  |               |
+     +---------------+
+  5  |               |       Text Grid Width               Unsigned
+     +-             -+
+  6  |               |
+     +---------------+
+  7  |               |       Text Grid Height              Unsigned
+     +-             -+
+  8  |               |
+     +---------------+
+  9  |               |       Character Cell Width          Byte
+     +---------------+
+ 10  |               |       Character Cell Height         Byte
+     +---------------+
+ 11  |               |       Text Foreground Color Index   Byte
+     +---------------+
+ 12  |               |       Text Background Color Index   Byte
+     +---------------+
+
+     +===============+
+     |               |
+  N  |               |       Plain Text Data               Data Sub-blocks
+     |               |
+     +===============+
+
+     +---------------+
+  0  |               |       Block Terminator              Byte
+     +---------------+
+
+            i) Extension Introducer - Identifies the beginning of an extension
+            block. This field contains the fixed value 0x21.
+
+            ii) Plain Text Label - Identifies the current block as a Plain Text
+            Extension. This field contains the fixed value 0x01.
+
+            iii) Block Size - 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 12.
+
+
+
+
+
+
+
+                                                                        21
+
+
+            iv) Text Grid Left Position - Column number, in pixels, of the left
+            edge of the text grid, with respect to the left edge of the Logical
+            Screen.
+
+            v) Text Grid Top Position - Row number, in pixels, of the top edge
+            of the text grid, with respect to the top edge of the Logical
+            Screen.
+
+            vi) Image Grid Width - Width of the text grid in pixels.
+
+            vii) Image Grid Height - Height of the text grid in pixels.
+
+            viii) Character Cell Width - Width, in pixels, of each cell in the
+            grid.
+
+            ix) Character Cell Height - Height, in pixels, of each cell in the
+            grid.
+
+            x) Text Foreground Color Index - Index into the Global Color Table
+            to be used to render the text foreground.
+
+            xi) Text Background Color Index - Index into the Global Color Table
+            to be used to render the text background.
+
+            xii) Plain Text Data - 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.
+
+            xiii) Block Terminator - This zero-length data block marks the end
+            of the Plain Text Data Blocks.
+
+      d. Extensions and Scope. The scope of this block is the Plain Text Data
+      Block contained in it. This block may be modified by the Graphic Control
+      Extension.
+
+      e. Recommendations. 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 0x20 or greater than 0xf7 are
+      encountered, it is recommended that the decoder display a Space character
+      (0x20). 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 8x8 or 8x16 (width x height); consider an image for unusual
+      sized text.
+
+
+26. Application Extension.
+
+      a. Description. The Application Extension contains application-specific
+      information; it conforms with the extension block syntax, as described
+      below, and its block label is 0xFF.
+
+      b. Required Version.  89a.
+
+
+
+
+
+
+
+
+
+                                                                        22
+
+
+      c. Syntax.
+
+      7 6 5 4 3 2 1 0        Field Name                    Type
+     +---------------+
+  0  |               |       Extension Introducer          Byte
+     +---------------+
+  1  |               |       Extension Label               Byte
+     +---------------+
+
+     +---------------+
+  0  |               |       Block Size                    Byte
+     +---------------+
+  1  |               |
+     +-             -+
+  2  |               |
+     +-             -+
+  3  |               |       Application Identifier        8 Bytes
+     +-             -+
+  4  |               |
+     +-             -+
+  5  |               |
+     +-             -+
+  6  |               |
+     +-             -+
+  7  |               |
+     +-             -+
+  8  |               |
+     +---------------+
+  9  |               |
+     +-             -+
+ 10  |               |       Appl. Authentication Code     3 Bytes
+     +-             -+
+ 11  |               |
+     +---------------+
+
+     +===============+
+     |               |
+     |               |       Application Data              Data Sub-blocks
+     |               |
+     |               |
+     +===============+
+
+     +---------------+
+  0  |               |       Block Terminator              Byte
+     +---------------+
+
+            i) Extension Introducer - Defines this block as an extension. This
+            field contains the fixed value 0x21.
+
+            ii) Application Extension Label - Identifies the block as an
+            Application Extension. This field contains the fixed value 0xFF.
+
+            iii) Block Size - 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 11.
+
+
+
+
+
+
+
+                                                                        23
+
+
+            iv) Application Identifier - Sequence of eight printable ASCII
+            characters used to identify the application owning the Application
+            Extension.
+
+            v) Application Authentication Code - 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.
+
+
+      d. Extensions and Scope. This block does not have scope. This block
+      cannot be modified by any extension.
+
+      e. Recommendation. None.
+
+
+27. Trailer.
+
+      a. Description. This block is a single-field block indicating the end of
+      the GIF Data Stream.  It contains the fixed value 0x3B.
+
+      b. Required Version.  87a.
+
+      c. Syntax.
+
+      7 6 5 4 3 2 1 0        Field Name                    Type
+     +---------------+
+  0  |               |       GIF Trailer                   Byte
+     +---------------+
+
+      d. Extensions and Scope. This block does not have scope, it terminates
+      the GIF Data Stream. This block may not be modified by any extension.
+
+      e. Recommendations. None.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                        24
+
+
+Appendix
+A. Quick Reference Table.
+
+Block Name                  Required   Label       Ext.   Vers.
+Application Extension       Opt. (*)   0xFF (255)  yes    89a
+Comment Extension           Opt. (*)   0xFE (254)  yes    89a
+Global Color Table          Opt. (1)   none        no     87a
+Graphic Control Extension   Opt. (*)   0xF9 (249)  yes    89a
+Header                      Req. (1)   none        no     N/A
+Image Descriptor            Opt. (*)   0x2C (044)  no     87a (89a)
+Local Color Table           Opt. (*)   none        no     87a
+Logical Screen Descriptor   Req. (1)   none        no     87a (89a)
+Plain Text Extension        Opt. (*)   0x01 (001)  yes    89a
+Trailer                     Req. (1)   0x3B (059)  no     87a
+
+Unlabeled Blocks
+Header                      Req. (1)   none        no     N/A
+Logical Screen Descriptor   Req. (1)   none        no     87a (89a)
+Global Color Table          Opt. (1)   none        no     87a
+Local Color Table           Opt. (*)   none        no     87a
+
+Graphic-Rendering Blocks
+Plain Text Extension        Opt. (*)   0x01 (001)  yes    89a
+Image Descriptor            Opt. (*)   0x2C (044)  no     87a (89a)
+
+Control Blocks
+Graphic Control Extension   Opt. (*)   0xF9 (249)  yes    89a
+
+Special Purpose Blocks
+Trailer                     Req. (1)   0x3B (059)  no     87a
+Comment Extension           Opt. (*)   0xFE (254)  yes    89a
+Application Extension       Opt. (*)   0xFF (255)  yes    89a
+
+legend:           (1)   if present, at most one occurrence
+                  (*)   zero or more occurrences
+                  (+)   one or more occurrences
+
+Notes : The Header is not subject to Version Numbers.
+(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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                        25
+
+
+Appendix
+B. GIF Grammar.
+
+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.
+
+Legend:           <>    grammar word
+                  ::=   defines symbol
+                  *     zero or more occurrences
+                  +     one or more occurrences
+                  |     alternate element
+                  []    optional element
+
+Example:
+
+<GIF Data Stream> ::= Header <Logical Screen> <Data>* Trailer
+
+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.
+
+
+The Grammar.
+
+<GIF Data Stream> ::=     Header <Logical Screen> <Data>* Trailer
+
+<Logical Screen> ::=      Logical Screen Descriptor [Global Color Table]
+
+<Data> ::=                <Graphic Block>  |
+                          <Special-Purpose Block>
+
+<Graphic Block> ::=       [Graphic Control Extension] <Graphic-Rendering Block>
+
+<Graphic-Rendering Block> ::=  <Table-Based Image>  |
+                               Plain Text Extension
+
+<Table-Based Image> ::=   Image Descriptor [Local Color Table] Image Data
+
+<Special-Purpose Block> ::=    Application Extension  |
+                               Comment Extension
+
+
+
+
+
+
+
+
+
+                                                                        26
+
+
+NOTE : 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                        27
+
+
+Appendix
+C. Glossary.
+
+Active Color Table - Color table used to render the next graphic. If the next
+graphic is an image which has a Local Color Table 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 Plain Text
+Extension, the active color table is the Global Color Table 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.
+
+Block - Collection of bytes forming a protocol unit. In general, the term
+includes labeled and unlabeled blocks, as well as Extensions.
+
+Data Stream - The GIF Data Stream is composed of blocks and sub-blocks
+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 Header and must precede the Trailer.
+
+Decoder - A program capable of processing a GIF Data Stream to render the
+images and graphics contained in it.
+
+Encoder - A program capable of capturing and formatting image and graphic
+raster data, following the definitions of the Graphics Interchange Format.
+
+Extension - A protocol block labeled by the Extension Introducer 0x21.
+
+Extension Introducer - Label (0x21) defining an Extension.
+
+Graphic - 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.
+
+Image - Data representing a picture or a drawing; an image is represented by an
+array of pixels called the raster of the image.
+
+Raster - Array of pixel values representing an image.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                        28
+
+
+Appendix
+D. Conventions.
+
+Animation - The Graphics Interchange Format is not intended as a platform for
+animation, even though it can be done in a limited way.
+
+Byte Ordering - Unless otherwise stated, multi-byte numeric fields are ordered
+with the Least Significant Byte first.
+
+Color Indices - Color indices always refer to the active color table, either
+the Global Color Table or the Local Color Table.
+
+Color Order - Unless otherwise stated, all triple-component RGB color values
+are specified in Red-Green-Blue order.
+
+Color Tables - 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.
+
+Extension Blocks - Extensions are defined using the Extension Introducer code
+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 0x00 to 0xFF,
+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.
+
+Reserved Fields - All Reserved Fields are expected to have each bit set to zero
+(off).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                        29
+
+
+Appendix
+E. Interlaced Images.
+
+The rows of an Interlaced images are arranged in the following order:
+
+      Group 1 : Every 8th. row, starting with row 0.              (Pass 1)
+      Group 2 : Every 8th. row, starting with row 4.              (Pass 2)
+      Group 3 : Every 4th. row, starting with row 2.              (Pass 3)
+      Group 4 : Every 2nd. row, starting with row 1.              (Pass 4)
+
+The Following example illustrates how the rows of an interlaced image are
+ordered.
+
+      Row Number                                        Interlace Pass
+
+ 0    -----------------------------------------       1
+ 1    -----------------------------------------                         4
+ 2    -----------------------------------------                   3
+ 3    -----------------------------------------                         4
+ 4    -----------------------------------------             2
+ 5    -----------------------------------------                         4
+ 6    -----------------------------------------                   3
+ 7    -----------------------------------------                         4
+ 8    -----------------------------------------       1
+ 9    -----------------------------------------                         4
+ 10   -----------------------------------------                   3
+ 11   -----------------------------------------                         4
+ 12   -----------------------------------------             2
+ 13   -----------------------------------------                         4
+ 14   -----------------------------------------                   3
+ 15   -----------------------------------------                         4
+ 16   -----------------------------------------       1
+ 17   -----------------------------------------                         4
+ 18   -----------------------------------------                   3
+ 19   -----------------------------------------                         4
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                        30
+
+
+Appendix
+F. Variable-Length-Code LZW Compression.
+
+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.
+
+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.
+
+The Raster Data stream that represents the actual output image can be
+represented as:
+
+         7 6 5 4 3 2 1 0
+        +---------------+
+        | LZW code size |
+        +---------------+
+
+        +---------------+ ----+
+        |  block size   |     |
+        +---------------+     |
+        |               |     +-- Repeated as many
+        |  data bytes   |     |   times as necessary.
+        |               |     |
+        +---------------+ ----+
+
+        . . .       . . . ------- The code that terminates the LZW
+                                  compressed data must appear before
+                                  Block Terminator.
+        +---------------+
+        |0 0 0 0 0 0 0 0|  Block Terminator
+        +---------------+
+
+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:
+
+1. Establish the Code Size - Define the number of bits needed to represent the
+actual data.
+
+2. Compress the Data - Compress the series of image pixels to a series of
+
+
+
+
+
+
+
+                                                                        31
+
+
+compression codes.
+
+3. Build a Series of Bytes - Take the set of compression codes and convert to a
+string of 8-bit bytes.
+
+4. Package the Bytes - Package sets of bytes into blocks preceded by character
+counts and output.
+
+ESTABLISH CODE SIZE
+
+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.
+
+COMPRESSION
+
+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.
+
+The LZW algorithm used in GIF matches algorithmically with the standard LZW
+algorithm with the following differences:
+
+1.  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**<code
+size>. For example if the code size indicated was 4 (image was 4 bits/pixel)
+the Clear code value would be 16 (10000 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.
+
+2. 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.
+
+3. The first available compression code value is <Clear code>+2.
+
+4. 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
+(0xFFF). 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.
+
+BUILD 8-BIT BYTES
+
+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
+
+
+
+
+
+
+
+                                                                        32
+
+
+picked off 8 bits at a time to be output.
+
+Assuming a character array of 8 bits per character and using 5 bit codes to be
+packed, an example layout would be similar to:
+
+
+     +---------------+
+  0  |               |    bbbaaaaa
+     +---------------+
+  1  |               |    dcccccbb
+     +---------------+
+  2  |               |    eeeedddd
+     +---------------+
+  3  |               |    ggfffffe
+     +---------------+
+  4  |               |    hhhhhggg
+     +---------------+
+           . . .
+     +---------------+
+  N  |               |
+     +---------------+
+
+
+Note that the physical packing arrangement will change as the number of bits
+per compression code change but the concept remains the same.
+
+PACKAGE THE BYTES
+
+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.
+
+
+
+FURTHER READING
+
+[1] Ziv, J. and Lempel, A. : "A Universal Algorithm for Sequential Data
+Compression", IEEE Transactions on Information Theory, May 1977.
+[2] Welch, T. : "A Technique for High-Performance Data Compression", Computer,
+June 1984.
+[3] Nelson, M.R. : "LZW Data Compression", Dr. Dobb's Journal, October 1989.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                        33
+
+
+Appendix
+G. On-line Capabilities Dialogue.
+
+NOTE : 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.
+
+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.
+
+GIF CAPABILITIES ENQUIRY
+
+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:
+
+ESC[>0g           0x1B 0x5B 0x3E 0x30 0x67
+
+GIF CAPABILITIES RESPONSE
+
+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:
+
+#version;protocol{;dev, width, height, color-bits, color-res}...<CR>
+
+
+'#'            GIF Capabilities Response identifier character.
+version        GIF format version number;  initially '87a'.
+protocol='0'   No end-to-end protocol supported by decoder Transfer as direct
+               8-bit data stream.
+protocol='1'   Can use CIS B+ error correction protocol to transfer GIF data
+               interactively from the host directly to the display.
+dev = '0'      Screen parameter set follows.
+dev = '1'      Printer parameter set follows.
+width          Maximum supported display width in pixels.
+height         Maximum supported display height in pixels.
+color-bits     Number of bits per pixel supported. The number of supported
+               colors is therefore 2**color-bits.
+color-res      Number of bits per color component supported in the hardware
+               color palette. If color-res is '0' then no hardware palette
+               table is available.
+
+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.
+
+The following GIF Capabilities Response message describes three standard IBM PC
+Enhanced Graphics Adapter configurations with no printer; the GIF data stream
+
+
+
+
+
+
+
+
+
+                                                                        34
+
+
+can be processed within an error correcting protocol:
+
+#87a;1;0,320,200,4,0;0,640,200,2,2;0,640,350,4,2<CR>
+
+ENTER GIF GRAPHICS MODE
+
+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:
+
+ESC[>1g     Display GIF image on screen
+
+                  0x1B 0x5B 0x3E 0x31 0x67
+
+ESC[>2g   Display image directly to an attached graphics printer. The image may
+optionally be displayed on the screen as well.
+
+                  0x1B 0x5B 0x3E 0x32 0x67
+
+Note that the 'g' character terminating each sequence is in lowercase.
+
+INTERACTIVE ENVIRONMENT
+
+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.
+.
+```