1 2 3 4 5 G I F (tm) 6 7 Graphics Interchange Format (tm) 8 9 A standard defining a mechanism 10 for the storage and transmission 11 of raster-based graphics information 12 13 June 15, 1987 14 15 (c) CompuServe Incorporated, 1987 16 All rights reserved 17 18 While this document is copyrighted, the information 19 contained within is made available for use in computer 20 software without royalties, or licensing restrictions. 21 GIF and 'Graphics Interchange Format' are trademarks of 22 23 CompuServe, Incorporated. 24 an H&R Block Company 25 5000 Arlington Centre Blvd. 26 Columbus, Ohio 43220 27 (614) 457-8600 28 29 Page 2 30 31 32 33 Graphics Interchange Format (GIF) Specification 34 Table of Contents 35 INTRODUCTION . . . . . . . . . . . . . . . . . page 3 36 GENERAL FILE FORMAT . . . . . . . . . . . . . page 3 37 GIF SIGNATURE . . . . . . . . . . . . . . . . page 4 38 SCREEN DESCRIPTOR . . . . . . . . . . . . . . page 4 39 GLOBAL COLOR MAP . . . . . . . . . . . . . . . page 5 40 IMAGE DESCRIPTOR . . . . . . . . . . . . . . . page 6 41 LOCAL COLOR MAP . . . . . . . . . . . . . . . page 7 42 RASTER DATA . . . . . . . . . . . . . . . . . page 7 43 GIF TERMINATOR . . . . . . . . . . . . . . . . page 8 44 GIF EXTENSION BLOCKS . . . . . . . . . . . . . page 8 45 APPENDIX A - GLOSSARY . . . . . . . . . . . . page 9 46 APPENDIX B - INTERACTIVE SEQUENCES . . . . . . page 10 47 APPENDIX C - IMAGE PACKAGING & COMPRESSION . . page 12 48 APPENDIX D - MULTIPLE IMAGE PROCESSING . . . . page 15 49 50Graphics Interchange Format (GIF) Page 3 51 52 53 54Specification 55 56INTRODUCTION 57 58 'GIF' (tm) is CompuServe's standard for defining generalized color 59 raster images. This 'Graphics Interchange Format' (tm) allows 60 high-quality, high-resolution graphics to be displayed on a variety of 61 graphics hardware and is intended as an exchange and display mechanism 62 for graphics images. The image format described in this document is 63 designed to support current and future image technology and will in 64 addition serve as a basis for future CompuServe graphics products. 65 66 The main focus of this document is to provide the technical 67 information necessary for a programmer to implement GIF encoders and 68 decoders. As such, some assumptions are made as to terminology relavent 69 to graphics and programming in general. 70 71 The first section of this document describes the GIF data format 72 and its components and applies to all GIF decoders, either as standalone 73 programs or as part of a communications package. Appendix B is a 74 section relavent to decoders that are part of a communications software 75 package and describes the protocol requirements for entering and exiting 76 GIF mode, and responding to host interrogations. A glossary in Appendix 77 A defines some of the terminology used in this document. Appendix C 78 gives a detailed explanation of how the graphics image itself is 79 packaged as a series of data bytes. 80 81 82 Graphics Interchange Format Data Definition 83 84 GENERAL FILE FORMAT 85 86 +-----------------------+ 87 | +-------------------+ | 88 | | GIF Signature | | 89 | +-------------------+ | 90 | +-------------------+ | 91 | | Screen Descriptor | | 92 | +-------------------+ | 93 | +-------------------+ | 94 | | Global Color Map | | 95 | +-------------------+ | 96 . . . . . . 97 | +-------------------+ | ---+ 98 | | Image Descriptor | | | 99 | +-------------------+ | | 100 | +-------------------+ | | 101 | | Local Color Map | | |- Repeated 1 to n times 102 | +-------------------+ | | 103 | +-------------------+ | | 104 | | Raster Data | | | 105 | +-------------------+ | ---+ 106 . . . . . . 107 |- GIF Terminator -| 108 +-----------------------+ 109 110Graphics Interchange Format (GIF) Page 4 111 112 113 114Specification 115 116 GIF SIGNATURE 117 118 The following GIF Signature identifies the data following as a 119 valid GIF image stream. It consists of the following six characters: 120 121 G I F 8 7 a 122 123 The last three characters '87a' may be viewed as a version number 124 for this particular GIF definition and will be used in general as a 125 reference in documents regarding GIF that address any version 126 dependencies. 127 128 SCREEN DESCRIPTOR 129 130 The Screen Descriptor describes the overall parameters for all GIF 131 images following. It defines the overall dimensions of the image space 132 or logical screen required, the existance of color mapping information, 133 background screen color, and color depth information. This information 134 is stored in a series of 8-bit bytes as described below. 135 136 bits 137 7 6 5 4 3 2 1 0 Byte # 138 +---------------+ 139 | | 1 140 +-Screen Width -+ Raster width in pixels (LSB first) 141 | | 2 142 +---------------+ 143 | | 3 144 +-Screen Height-+ Raster height in pixels (LSB first) 145 | | 4 146 +-+-----+-+-----+ M = 1, Global color map follows Descriptor 147 |M| cr |0|pixel| 5 cr+1 = # bits of color resolution 148 +-+-----+-+-----+ pixel+1 = # bits/pixel in image 149 | background | 6 background=Color index of screen background 150 +---------------+ (color is defined from the Global color 151 |0 0 0 0 0 0 0 0| 7 map or default map if none specified) 152 +---------------+ 153 154 The logical screen width and height can both be larger than the 155 physical display. How images larger than the physical display are 156 handled is implementation dependent and can take advantage of hardware 157 characteristics (e.g. Macintosh scrolling windows). Otherwise images 158 can be clipped to the edges of the display. 159 160 The value of 'pixel' also defines the maximum number of colors 161 within an image. The range of values for 'pixel' is 0 to 7 which 162 represents 1 to 8 bits. This translates to a range of 2 (B & W) to 256 163 colors. Bit 3 of word 5 is reserved for future definition and must be 164 zero. 165 166Graphics Interchange Format (GIF) Page 5 167 168 169 170Specification 171 172 GLOBAL COLOR MAP 173 174 The Global Color Map is optional but recommended for images where 175 accurate color rendition is desired. The existence of this color map is 176 indicated in the 'M' field of byte 5 of the Screen Descriptor. A color 177 map can also be associated with each image in a GIF file as described 178 later. However this global map will normally be used because of 179 hardware restrictions in equipment available today. In the individual 180 Image Descriptors the 'M' flag will normally be zero. If the Global 181 Color Map is present, it's definition immediately follows the Screen 182 Descriptor. The number of color map entries following a Screen 183 Descriptor is equal to 2**(# bits per pixel), where each entry consists 184 of three byte values representing the relative intensities of red, green 185 and blue respectively. The structure of the Color Map block is: 186 187 bits 188 7 6 5 4 3 2 1 0 Byte # 189 +---------------+ 190 | red intensity | 1 Red value for color index 0 191 +---------------+ 192 |green intensity| 2 Green value for color index 0 193 +---------------+ 194 | blue intensity| 3 Blue value for color index 0 195 +---------------+ 196 | red intensity | 4 Red value for color index 1 197 +---------------+ 198 |green intensity| 5 Green value for color index 1 199 +---------------+ 200 | blue intensity| 6 Blue value for color index 1 201 +---------------+ 202 : : (Continues for remaining colors) 203 204 Each image pixel value received will be displayed according to its 205 closest match with an available color of the display based on this color 206 map. The color components represent a fractional intensity value from 207 none (0) to full (255). White would be represented as (255,255,255), 208 black as (0,0,0) and medium yellow as (180,180,0). For display, if the 209 device supports fewer than 8 bits per color component, the higher order 210 bits of each component are used. In the creation of a GIF color map 211 entry with hardware supporting fewer than 8 bits per component, the 212 component values for the hardware should be converted to the 8-bit 213 format with the following calculation: 214 215 <map_value> = <component_value>*255/(2**<nbits> -1) 216 217 This assures accurate translation of colors for all displays. In 218 the cases of creating GIF images from hardware without color palette 219 capability, a fixed palette should be created based on the available 220 display colors for that hardware. If no Global Color Map is indicated, 221 a default color map is generated internally which maps each possible 222 incoming color index to the same hardware color index modulo <n> where 223 <n> is the number of available hardware colors. 224 225Graphics Interchange Format (GIF) Page 6 226 227 228 229Specification 230 231 IMAGE DESCRIPTOR 232 233 The Image Descriptor defines the actual placement and extents of 234 the following image within the space defined in the Screen Descriptor. 235 Also defined are flags to indicate the presence of a local color lookup 236 map, and to define the pixel display sequence. Each Image Descriptor is 237 introduced by an image separator character. The role of the Image 238 Separator is simply to provide a synchronization character to introduce 239 an Image Descriptor. This is desirable if a GIF file happens to contain 240 more than one image. This character is defined as 0x2C hex or ',' 241 (comma). When this character is encountered between images, the Image 242 Descriptor will follow immediately. 243 244 Any characters encountered between the end of a previous image and 245 the image separator character are to be ignored. This allows future GIF 246 enhancements to be present in newer image formats and yet ignored safely 247 by older software decoders. 248 249 bits 250 7 6 5 4 3 2 1 0 Byte # 251 +---------------+ 252 |0 0 1 0 1 1 0 0| 1 ',' - Image separator character 253 +---------------+ 254 | | 2 Start of image in pixels from the 255 +- Image Left -+ left side of the screen (LSB first) 256 | | 3 257 +---------------+ 258 | | 4 259 +- Image Top -+ Start of image in pixels from the 260 | | 5 top of the screen (LSB first) 261 +---------------+ 262 | | 6 263 +- Image Width -+ Width of the image in pixels (LSB first) 264 | | 7 265 +---------------+ 266 | | 8 267 +- Image Height-+ Height of the image in pixels (LSB first) 268 | | 9 269 +-+-+-+-+-+-----+ M=0 - Use global color map, ignore 'pixel' 270 |M|I|0|0|0|pixel| 10 M=1 - Local color map follows, use 'pixel' 271 +-+-+-+-+-+-----+ I=0 - Image formatted in Sequential order 272 I=1 - Image formatted in Interlaced order 273 pixel+1 - # bits per pixel for this image 274 275 The specifications for the image position and size must be confined 276 to the dimensions defined by the Screen Descriptor. On the other hand 277 it is not necessary that the image fill the entire screen defined. 278 279Graphics Interchange Format (GIF) Page 7 280 281 282Specification 283 284 LOCAL COLOR MAP 285 286 A Local Color Map is optional and defined here for future use. If 287 the 'M' bit of byte 10 of the Image Descriptor is set, then a color map 288 follows the Image Descriptor that applies only to the following image. 289 At the end of the image, the color map will revert to that defined after 290 the Screen Descriptor. Note that the 'pixel' field of byte 10 of the 291 Image Descriptor is used only if a Local Color Map is indicated. This 292 defines the parameters not only for the image pixel size, but determines 293 the number of color map entries that follow. The bits per pixel value 294 will also revert to the value specified in the Screen Descriptor when 295 processing of the image is complete. 296 297 RASTER DATA 298 299 The format of the actual image is defined as the series of pixel 300 color index values that make up the image. The pixels are stored left 301 to right sequentially for an image row. By default each image row is 302 written sequentially, top to bottom. In the case that the Interlace or 303 'I' bit is set in byte 10 of the Image Descriptor then the row order of 304 the image display follows a four-pass process in which the image is 305 filled in by widely spaced rows. The first pass writes every 8th row, 306 starting with the top row of the image window. The second pass writes 307 every 8th row starting at the fifth row from the top. The third pass 308 writes every 4th row starting at the third row from the top. The fourth 309 pass completes the image, writing every other row, starting at the 310 second row from the top. A graphic description of this process follows: 311 312 Image 313 314 Row Pass 1 Pass 2 Pass 3 Pass 4 Result 315 --------------------------------------------------- 316 0 **1a** **1a** 317 1 **4a** **4a** 318 2 **3a** **3a** 319 3 **4b** **4b** 320 4 **2a** **2a** 321 5 **4c** **4c** 322 6 **3b** **3b** 323 7 **4d** **4d** 324 8 **1b** **1b** 325 9 **4e** **4e** 326 10 **3c** **3c** 327 11 **4f** **4f** 328 12 **2b** **2b** 329 . . . 330 331 The image pixel values are processed as a series of color indices 332 which map into the existing color map. The resulting color value from 333 the map is what is actually displayed. This series of pixel indices, 334 the number of which is equal to image-width*image-height pixels, are 335 passed to the GIF image data stream one value per pixel, compressed and 336 packaged according to a version of the LZW compression algorithm as 337 defined in Appendix C. 338 339Graphics Interchange Format (GIF) Page 8 340 341 342 343Specification 344 345 GIF TERMINATOR 346 347 In order to provide a synchronization for the termination of a GIF 348 image file, a GIF decoder will process the end of GIF mode when the 349 character 0x3B hex or ';' is found after an image has been processed. 350 By convention the decoding software will pause and wait for an action 351 indicating that the user is ready to continue. This may be a carriage 352 return entered at the keyboard or a mouse click. For interactive 353 applications this user action must be passed on to the host as a 354 carriage return character so that the host application can continue. 355 The decoding software will then typically leave graphics mode and resume 356 any previous process. 357 358 GIF EXTENSION BLOCKS 359 360 To provide for orderly extension of the GIF definition, a mechanism 361 for defining the packaging of extensions within a GIF data stream is 362 necessary. Specific GIF extensions are to be defined and documented by 363 CompuServe in order to provide a controlled enhancement path. 364 365 GIF Extension Blocks are packaged in a manner similar to that used 366 by the raster data though not compressed. The basic structure is: 367 368 7 6 5 4 3 2 1 0 Byte # 369 +---------------+ 370 |0 0 1 0 0 0 0 1| 1 '!' - GIF Extension Block Introducer 371 +---------------+ 372 | function code | 2 Extension function code (0 to 255) 373 +---------------+ ---+ 374 | byte count | | 375 +---------------+ | 376 : : +-- Repeated as many times as necessary 377 |func data bytes| | 378 : : | 379 +---------------+ ---+ 380 . . . . . . 381 +---------------+ 382 |0 0 0 0 0 0 0 0| zero byte count (terminates block) 383 +---------------+ 384 385 A GIF Extension Block may immediately preceed any Image Descriptor 386 or occur before the GIF Terminator. 387 388 All GIF decoders must be able to recognize the existence of GIF 389 Extension Blocks and read past them if unable to process the function 390 code. This ensures that older decoders will be able to process extended 391 GIF image files in the future, though without the additional 392 functionality. 393 394Graphics Interchange Format (GIF) Page 9 395 396Appendix A - Glossary 397 398 GLOSSARY 399 400Pixel - The smallest picture element of a graphics image. This usually 401 corresponds to a single dot on a graphics screen. Image resolution is 402 typically given in units of pixels. For example a fairly standard 403 graphics screen format is one 320 pixels across and 200 pixels high. 404 Each pixel can appear as one of several colors depending on the 405 capabilities of the graphics hardware. 406 407Raster - A horizontal row of pixels representing one line of an image. A 408 typical method of working with images since most hardware is oriented to 409 work most efficiently in this manner. 410 411LSB - Least Significant Byte. Refers to a convention for two byte numeric 412 values in which the less significant byte of the value preceeds the more 413 significant byte. This convention is typical on many microcomputers. 414 415Color Map - The list of definitions of each color used in a GIF image. 416 These desired colors are converted to available colors through a table 417 which is derived by assigning an incoming color index (from the image) 418 to an output color index (of the hardware). While the color map 419 definitons are specified in a GIF image, the output pixel colors will 420 vary based on the hardware used and its ability to match the defined 421 color. 422 423Interlace - The method of displaying a GIF image in which multiple passes 424 are made, outputting raster lines spaced apart to provide a way of 425 visualizing the general content of an entire image before all of the 426 data has been processed. 427 428B Protocol - A CompuServe-developed error-correcting file transfer protocol 429 available in the public domain and implemented in CompuServe VIDTEX 430 products. This error checking mechanism will be used in transfers of 431 GIF images for interactive applications. 432 433LZW - A sophisticated data compression algorithm based on work done by 434 Lempel-Ziv & Welch which has the feature of very efficient one-pass 435 encoding and decoding. This allows the image to be decompressed and 436 displayed at the same time. The original article from which this 437 technique was adapted is: 438 439 Terry A. Welch, "A Technique for High Performance Data 440 Compression", IEEE Computer, vol 17 no 6 (June 1984) 441 442 This basic algorithm is also used in the public domain ARC file 443 compression utilities. The CompuServe adaptation of LZW for GIF is 444 described in Appendix C. 445 446Graphics Interchange Format (GIF) Page 10 447 448 449 450Appendix B - Interactive Sequences 451 452 GIF Sequence Exchanges for an Interactive Environment 453 454 The following sequences are defined for use in mediating control 455 between a GIF sender and GIF receiver over an interactive communications 456 line. These sequences do not apply to applications that involve 457 downloading of static GIF files and are not considered part of a GIF 458 file. 459 460 GIF CAPABILITIES ENQUIRY 461 462 The GCE sequence is issued from a host and requests an interactive 463 GIF decoder to return a response message that defines the graphics 464 parameters for the decoder. This involves returning information about 465 available screen sizes, number of bits/color supported and the amount of 466 color detail supported. The escape sequence for the GCE is defined as: 467 468 ESC [ > 0 g (g is lower case, spaces inserted for clarity) 469 (0x1B 0x5B 0x3E 0x30 0x67) 470 471 GIF CAPABILITIES RESPONSE 472 473 The GIF Capabilities Response message is returned by an interactive 474 GIF decoder and defines the decoder's display capabilities for all 475 graphics modes that are supported by the software. Note that this can 476 also include graphics printers as well as a monitor screen. The general 477 format of this message is: 478 479 #version;protocol{;dev, width, height, color-bits, color-res}... <CR> 480 481 '#' - GCR identifier character (Number Sign) 482 version - GIF format version number; initially '87a' 483 protocol='0' - No end-to-end protocol supported by decoder 484 Transfer as direct 8-bit data stream. 485 protocol='1' - Can use an error correction protocol to transfer GIF data 486 interactively from the host directly to the display. 487 dev = '0' - Screen parameter set follows 488 dev = '1' - Printer parameter set follows 489 width - Maximum supported display width in pixels 490 height - Maximum supported display height in pixels 491 color-bits - Number of bits per pixel supported. The number of 492 supported colors is therefore 2**color-bits. 493 color-res - Number of bits per color component supported in the 494 hardware color palette. If color-res is '0' then no 495 hardware palette table is available. 496 497 Note that all values in the GCR are returned as ASCII decimal 498 numbers and the message is terminated by a Carriage Return character. 499 500Graphics Interchange Format (GIF) Page 11 501 502 503 504Appendix B - Interactive Sequences 505 506 The following GCR message describes three standard EGA 507 configurations with no printer; the GIF data stream can be processed 508 within an error correcting protocol: 509 510 #87a;1 ;0,320,200,4,0 ;0,640,200,2,2 ;0,640,350,4,2<CR> 511 512 ENTER GIF GRAPHICS MODE 513 514 Two sequences are currently defined to invoke an interactive GIF 515 decoder into action. The only difference between them is that different 516 output media are selected. These sequences are: 517 518 ESC [ > 1 g Display GIF image on screen 519 (0x1B 0x5B 0x3E 0x31 0x67) 520 ESC [ > 2 g Display image directly to an attached graphics printer. 521 The image may optionally be displayed on the screen as 522 well. 523 (0x1B 0x5B 0x3E 0x32 0x67) 524 525 Note that the 'g' character terminating each sequence is in lower 526 case. 527 528 INTERACTIVE ENVIRONMENT 529 530 The assumed environment for the transmission of GIF image data from 531 an interactive application is a full 8-bit data stream from host to 532 micro. All 256 character codes must be transferrable. The establishing 533 of an 8-bit data path for communications will normally be taken care of 534 by the host application programs. It is however up to the receiving 535 communications programs supporting GIF to be able to receive and pass on 536 all 256 8-bit codes to the GIF decoder software. 537 538Graphics Interchange Format (GIF) Page 12 539 540 541 542Appendix C - Image Packaging & Compression 543 544 The Raster Data stream that represents the actual output image can 545 be represented as: 546 547 7 6 5 4 3 2 1 0 548 +---------------+ 549 | code size | 550 +---------------+ ---+ 551 |blok byte count| | 552 +---------------+ | 553 : : +-- Repeated as many times as necessary 554 | data bytes | | 555 : : | 556 +---------------+ ---+ 557 . . . . . . 558 +---------------+ 559 |0 0 0 0 0 0 0 0| zero byte count (terminates data stream) 560 +---------------+ 561 562 The conversion of the image from a series of pixel values to a 563 transmitted or stored character stream involves several steps. In brief 564 these steps are: 565 566 1. Establish the Code Size - Define the number of bits needed to 567 represent the actual data. 568 2. Compress the Data - Compress the series of image pixels to a series 569 of compression codes. 570 3. Build a Series of Bytes - Take the set of compression codes and 571 convert to a string of 8-bit bytes. 572 4. Package the Bytes - Package sets of bytes into blocks preceeded by 573 character counts and output. 574 575ESTABLISH CODE SIZE 576 577 The first byte of the GIF Raster Data stream is a value indicating 578 the minimum number of bits required to represent the set of actual pixel 579 values. Normally this will be the same as the number of color bits. 580 Because of some algorithmic constraints however, black & white images 581 which have one color bit must be indicated as having a code size of 2. 582 This code size value also implies that the compression codes must start 583 out one bit longer. 584 585COMPRESSION 586 587 The LZW algorithm converts a series of data values into a series of 588 codes which may be raw values or a code designating a series of values. 589 Using text characters as an analogy, the output code consists of a 590 character or a code representing a string of characters. 591 592Graphics Interchange Format (GIF) Page 13 593 594Appendix C - Image Packaging & Compression 595 596 The LZW algorithm used in GIF matches algorithmically with the 597 standard LZW algorithm with the following differences: 598 599 1. A special Clear code is defined which resets all 600 compression/decompression parameters and tables to a start-up state. 601 The value of this code is 2**<code size>. For example if the code 602 size indicated was 4 (image was 4 bits/pixel) the Clear code value 603 would be 16 (10000 binary). The Clear code can appear at any point 604 in the image data stream and therefore requires the LZW algorithm to 605 process succeeding codes as if a new data stream was starting. 606 Encoders should output a Clear code as the first code of each image 607 data stream. 608 609 2. An End of Information code is defined that explicitly indicates the 610 end of the image data stream. LZW processing terminates when this 611 code is encountered. It must be the last code output by the encoder 612 for an image. The value of this code is <Clear code>+1. 613 614 3. The first available compression code value is <Clear code>+2. 615 616 4. The output codes are of variable length, starting at <code size>+1 617 bits per code, up to 12 bits per code. This defines a maximum code 618 value of 4095 (hex FFF). Whenever the LZW code value would exceed 619 the current code length, the code length is increased by one. The 620 packing/unpacking of these codes must then be altered to reflect the 621 new code length. 622 623BUILD 8-BIT BYTES 624 625 Because the LZW compression used for GIF creates a series of 626 variable length codes, of between 3 and 12 bits each, these codes must 627 be reformed into a series of 8-bit bytes that will be the characters 628 actually stored or transmitted. This provides additional compression of 629 the image. The codes are formed into a stream of bits as if they were 630 packed right to left and then picked off 8 bits at a time to be output. 631 Assuming a character array of 8 bits per character and using 5 bit codes 632 to be packed, an example layout would be similar to: 633 634 byte n byte 5 byte 4 byte 3 byte 2 byte 1 635 +-.....-----+--------+--------+--------+--------+--------+ 636 | and so on |hhhhhggg|ggfffffe|eeeedddd|dcccccbb|bbbaaaaa| 637 +-.....-----+--------+--------+--------+--------+--------+ 638 639 Note that the physical packing arrangement will change as the 640 number of bits per compression code change but the concept remains the 641 same. 642 643PACKAGE THE BYTES 644 645 Once the bytes have been created, they are grouped into blocks for 646 output by preceeding each block of 0 to 255 bytes with a character count 647 byte. A block with a zero byte count terminates the Raster Data stream 648 for a given image. These blocks are what are actually output for the 649 650Graphics Interchange Format (GIF) Page 14 651 652 653 654Appendix C - Image Packaging & Compression 655 656 GIF image. This block format has the side effect of allowing a decoding 657 program the ability to read past the actual image data if necessary by 658 reading block counts and then skipping over the data. 659 660Graphics Interchange Format (GIF) Page 15 661 662 663 664 665Appendix D - Multiple Image Processing 666 667 Since a GIF data stream can contain multiple images, it is 668 necessary to describe processing and display of such a file. Because 669 the image descriptor allows for placement of the image within the 670 logical screen, it is possible to define a sequence of images that may 671 each be a partial screen, but in total fill the entire screen. The 672 guidelines for handling the multiple image situation are: 673 674 1. There is no pause between images. Each is processed immediately as 675 seen by the decoder. 676 677 2. Each image explicitly overwrites any image already on the screen 678 inside of its window. The only screen clears are at the beginning 679 and end of the GIF image process. See discussion on the GIF 680 terminator. 681