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