gif87a.doc

Delphi direct support for GIF files

   compression  utilities.   The  CompuServe  adaptation  of LZW for GIF is

   described in Appendix C.

Graphics Interchange Format (GIF)                                   Page 10

Appendix B - Interactive Sequences

           GIF Sequence Exchanges for an Interactive Environment

        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 GCE 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 GCE is defined as:

        ESC [ > 0 g     (g is lower case, spaces inserted for clarity)

                         (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>

   '#'          - GCR identifier character (Number Sign)

   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 an 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  GCR  are  returned  as  ASCII  decimal

   numbers and the message is terminated by a Carriage Return character.

Graphics Interchange Format (GIF)                                   Page 11

Appendix B - Interactive Sequences

        The  following   GCR   message   describes   three   standard   EGA

   configurations  with  no  printer;  the GIF data stream 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 [ > 1 g   Display GIF image on screen

                   (0x1B 0x5B 0x3E 0x31 0x67)

     ESC [ > 2 g   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  lower

   case.

 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.

Graphics Interchange Format (GIF)                                   Page 12

Appendix C - Image Packaging & Compression

        The Raster Data stream that represents the actual output image  can

   be represented as:

         7 6 5 4 3 2 1 0

        +---------------+

        |   code size   | 

        +---------------+     ---+

        |blok byte count|        |

        +---------------+        |

        :               :        +-- Repeated as many times as necessary

        |  data bytes   |        |

        :               :        |

        +---------------+     ---+

        . . .       . . .

        +---------------+

        |0 0 0 0 0 0 0 0|       zero byte count (terminates data stream)

        +---------------+

        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 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  preceeded  by

       character counts and output.

ESTABLISH CODE SIZE

        The first byte of the GIF Raster 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.

Graphics Interchange Format (GIF)                                   Page 13

Appendix C - Image Packaging & Compression

        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 (hex FFF).  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 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:

         byte n       byte 5   byte 4   byte 3   byte 2   byte 1

        +-.....-----+--------+--------+--------+--------+--------+

        | and so on |hhhhhggg|ggfffffe|eeeedddd|dcccccbb|bbbaaaaa|

        +-.....-----+--------+--------+--------+--------+--------+

        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 preceeding 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

Graphics Interchange Format (GIF)                                   Page 14

Appendix C - Image Packaging & Compression

   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.

Graphics Interchange Format (GIF)                                   Page 15

Appendix D - Multiple Image Processing

        Since a  GIF  data  stream  can  contain  multiple  images,  it  is

   necessary  to  describe  processing and display of such a file.  Because

   the image descriptor allows  for  placement  of  the  image  within  the

   logical  screen,  it is possible to define a sequence of images that may

   each be a partial screen, but in total  fill  the  entire  screen.   The

   guidelines for handling the multiple image situation are:

   1.  There is no pause between images.  Each is processed immediately  as

       seen by the decoder.

   2.  Each image explicitly overwrites any image  already  on  the  screen

       inside  of  its window.  The only screen clears are at the beginning

       and end of the  GIF  image  process.   See  discussion  on  the  GIF

       terminator.