#99346018 - Slot machine with lucky seventh jackpot, 777. Slot machines retro. #131053210 - vector pixel art lucky number isolated cartoon. All due respect posted by dailyhaha on.
Table of Contents
- Introduction
- Credit and Blame
- The GIF descriptor
- Decoding (dgif_lib.c)
- Encoding (egif_lib.c)
- Color map handling and allocation routines
- Graphics control extension handling
- Error Handling (gif_err.c)
- The GIF Utility Font
- Error codes
- Encoding errors
- Decoding errors
- Utility support library
- Error Handling
- Command Line Parsing
- Sequential access
- Sequential reading
- Sequential writing
- Forward and Backward Compatibility
- General behavior
- In documented functions:
- In undocumented functions:
- Error handling:
- Skeletons of GIF filters
- Unimplemented features
The Graphics Interchange Format(c) is the Copyright property ofCompuServe Incorporated. GIF(sm) is a Service Mark property of CompuServeIncorporated.
This document explains the GIF library code in directory `lib'. Thecode is collected into a service library which is used in all the utilities in`util'. It can be used in any application needs to read/write the GIFfile format. This document does not explain the GIF fileformat and assumes you know it, at least to the level of the GIF filestructure.
Gershon wrote: 'This library was written because I couldn't findanything similar and I wanted one. I was inspired by the RLE Utah tool kit,which I hoped to port to an IBM PC, but found it to be too machine specific,and its compression ratio too low. I compromised on the GIF format, but I amnot sure how long 8 bits per pixel will be enough.'
During his first spell of maintainership between 1989 and 1994, EricS. Raymond (aka 'ESR') ported the code to Unix, wrote the high-levelDGIfSlurp()/EGifSpew() interface, rationalized the internal datastructures, and did a lot of general cleanup and refactoring toimprove the code quality.
Between 1994 and 2012 Toshio Kuratomi fixed various tool bugs,build-recipe problems and rare segfaults. He partially untangled thesomewhat misdesigned extension-block handling in earlier versions. The core code was very stable during this period.
During his second spell of maintainership, ESR fixed theextension API, made the library re-entrant and thread-safe, wrote aregression-test suite, greatly improved the documentation, anddiscarded a lot of obsolete code.
When a GIF file is opened, a GIF file descriptor is created whichis a pointer to GifFileType structure as follows:
This structure was copied from gif_lib.h - the header file for the GIFlibrary. Any application program that uses the libgif.a library shouldinclude it. Members beginning with S refer to the GIF screen; others holdproperties of the current image (a GIF file may have more than one image)or point to allocated store used by various routines.
The user almost never writes into this structure (exception: itmay occasionally be useful to alter things in the SavedImages array andTrailing member), but can read any of these items at any time it isvalid (Image information is invalid until the first image has been read;read; SavedImages information is valid only after a DGifSlurp() call).
As the library needs to keep its own internal data, a Private pointerto hidden data is included. Applications should ignore this.
The library allocates its own memory dynamically, on opening of files,and releases that once closed. The user is never required to allocateany memory for any of the functions of this library, and is almost neverrequired to free them directly. The 'almost' in the latter clause is becauseone manual free() call may be required on a failed file close; see thedocumentation of DGifClose() and EGifClose() for details.
Here is a module summary:
Encoding routines, all prefixed with E.
Decoding routines, all prefixed with D.
Routines for colormap handling and GIF record allocation.
The 8x8 font table for the GIF utility font.
The library includes a sixth file of hash-function code which is accessedinternally only.
Most of the routines return GIF_ERROR (see gif_lib.h) if somethingwent wrong, GIF_OK otherwise. After an error return, all routines thattake a pointer-to-GifFileType argument set the Error member with a code thatcan be interpreted into an explanatory string with the function GifErrorString() in gif_err.c. (The exception to this is theDGifClose() and EGifClose() routines, which deallocate that structureand must therefore return any error code through a pointer argument.)
The following functions are used to set up input from a GIF:
Open a new GIF file (in binary mode, if under Windows) using thegiven GifFileName, and read its Screen information.
If any error occurs, NULL is returned and ErrorCode is set (ifnon-NULL).
Open a new GIF file using the given FileHandle, and read its Screeninformation.
If any error occurs, NULL is returned and ErrorCode is set (ifnon-NULL).
Once you have acquired a handle on a GIF, the high-levelfunction
reads the rest of a complete (possibly multi-image) GIF file from theindicated file handle into in-core allocated structures. It returnsGIF_OK on success, GIF_ERROR on failure; on failure, the Error member will be set.
Once you have done this, all image, raster, and extension-blockdata in the GIF is accessable in the SavedImages member (see thestructures in gif_lib.h). When you have modified the image to taste,write it out with EGifSpew().
One detail that may not be clear from just looking at thestructures is how extension blocks and sub-blocks are stored. EachExtensionBlock structure represents an extension data block. Thosewith a zero function code represent continuation data blocks attachedto previous blocks with nonzero function codes.
You can read from a GIF file through a function hook. Initializewith
and see the library header file for the type of InputFunc.
There is also a set of deprecated functions for sequential I/O,described in a later section.
The high-level function
writes a complete (possibly multi-image) GIF file to the indicated filehandle from in-core allocated structures created by a previous DGifSlurp()or equivalent operations. Its argument is a GIF file descriptor, whichimnplicitly points to storage previously allocated by DGifSlurp().
The file is written with a GIF87 stamp unless it contains one of the fourspecial extension blocks defined in GIF89, in which case it is writtenwith a GIF89 stamp.
EGifSpew() finishes by closing the GIF (writing a terminationrecord to it) and deallocating the associated storage.
You can write to a GIF file through a function hook. Initializewith
and see the library header file for the type of OutputFunc.
There is also a set of deprecated functions for sequential I/O,described in a later section.
Allocate storage for a color map object with the given number ofRGB triplet slots. If the second argument is non-NULL, initializethe color table portion of the new map from it. Returns NULL ifmemory is exhausted or if the size is not a power of 2 <= 256.
Free the storage occupied by a ColorMapObject that is no longerneeded.
Create the union of two given color maps and return it. If the resultwon't fit into 256 colors, NULL is returned, the allocated unionotherwise. ColorIn1 is copied as it to ColorUnion, while colors fromColorIn2 are copied iff they didn't exist before. ColorTransIn2 mapsthe old ColorIn2 into ColorUnion color map table.
Add an image block to the SavedImages array. The image block isinitially zeroed out. This image block will be seen by any followingEGifSpew() calls.
GIF89 added a graphics control extension block, but versionsof GIFLIB before 5.0 weren't much help in reading or modifying them. This lack has been remedied with the following structure and functions:
With these functions you can extract the data from a graphicscontrol extension associated with a saved image into aGraphicsControlBlock, modify it, and write it back out. Note that ifthe specified saved image doesn't have a graphics control extension,DGifSavedExtensionToGCB() will fill the GCB with default values andreturn GIF_ERROR (which can be ignored); EGifGCBToSavedExtension()will create a new leading extension block.
Returns a sting describing the specified GIFLIB error code.Return NULL if the argument is not a valid error code.
The 8x8 utility font used in gifecho and gifcolor lives in the librarymodule gif_font.c, in a table called GifAsciiTable. The library header fileincludes suitable externs and defines.
The GIF utility font support includes entry points for drawing legendson in-core images, drawing boxes and rectangles, and boxing text.These entry points are as follows:
Draw text using the 8x8 utility font on the saved image. Upperleft corner of the text is at image pixel (x, y). Use the specifiedcolor index.
Draw a box on the saved image. Upper left corner of the box is atimage pixels (x, y), width is w, height is h. Use the specified colorindex.
Draw a (filled) rectangle on the saved image. Upper left corner ofthe box is at image pixels (x, y), width is w, height is h. Use thespecified color index.
Draw text on a filled rectangle. The rectangle will be sized to fitthe text, with upper left hand corner at (x, y) on the saved image.The `border' argument specifies a pixel margin around the text. The`bg' argument is the color table index to fill the rectangle with;`fg' is the color table index to draw the text with.
This function interprets some characters in the legend stringspecially. A tab (t) is interpreted as a command to center thefollowing text in the box. A carriage return (r) is interpretedas a request for a line break.
Errors as reported from the GIFLIB library are divided to two majorcategories: the encoder (errors prefixed by E_GIF_ERR), and thedecoder (errors prefixed by D_GIF_ERR). This document explains thembriefly.
Message printed using PrintGifError: 'Failed to open given file' IO error result when attempt to open the given GIF file.
Message printed using PrintGifError: 'Failed to Write to given file' IO error result when attempt to write to the given GIF file.
Message printed using PrintGifError: 'Screen Descriptor already been set' Attempt to write second screen descriptor to same GIF file. GIF file should have exactly one screen descriptor which should be set directly after the file is opened.
Message printed using PrintGifError: 'Image Descriptor is still active' Image descriptor should be sent before and image dump, and no second image descriptor should be sent before current image dump ended. This error occurred probably because current image was not complete.
Message printed using PrintGifError: 'Neither Global Nor Local color map' An image must have either global (screen) or local (image) color map. Neither were given in this case.
Message printed using PrintGifError: '#Pixels bigger than Width * Height' The number of pixels dumped for this image is bigger than specified by image Height times image Width.
Message printed using PrintGifError: 'Fail to allocate required memory' Once an attemp is made to open GIF file, special structures are allocated to hold internal data for it. If allocation fails this error is returned.
Message printed using PrintGifError: 'Write failed (disk full?)' Writing encoded data failed.
Message printed using PrintGifError: 'Failed to close given file' Closing file failed.
Message printed using PrintGifError: 'Given file was not opened for write' GIF files can be opened both for read (DGIF part of library) and write (EGIF part of library). This error occurs when a file is opened for read (using DGIF) is given to one of the encoding (EGIF) routines.
Message printed using PrintGifError: 'Failed to open given file' IO error result when attempt to open the given GIF file.
Message printed using PrintGifError: 'Failed to read from given file' IO error result when attempt to write to the given GIF file.
Message printed using PrintGifError: 'Data is not a GIF file' GIF files should have special stamp identifies them as such, If that stamp is not found, this error is issued.
Message printed using PrintGifError: 'No screen descriptor detected' Each GIF file should have screen descriptor in its header. This error will be generated if no such descriptor was found.
Message printed using PrintGifError: 'No image descriptor detected' Each image should have image descriptor in its header. This error will be generated if no such descriptor was found.
Message printed using PrintGifError: 'Neither global nor local color map' An image must have either global (screen) or local (image) color map. Neither were given in this case.
Message printed using PrintGifError: 'Wrong record type detected' Each record in a GIF file has a special identifier in its header. If the record has an unrecognized identifier, this error is generated.
Message printed using PrintGifError: 'Number of pixels bigger than width * height' The number of pixels dumped for this image is bigger than specified by image Height times image Width.
Message printed using PrintGifError: 'Failed to allocate required memory' Once an attemp is made to open GIF file, special structures are allocated to hold internal data for it. If allocation fails this error is returned.
Message printed using PrintGifError: 'Failed to close given file' Closing file failed.
Message printed using PrintGifError: 'Given file was not opened for read' GIF files can be opened both for read (DGIF part of library) and write (EGIF part of library). This error occurs when a file is opened for write (using EGIF) is given to one of the decoding (DGIF) routines.
Message printed using PrintGifError: 'Image is defective, decoding aborted' This error is generated, once the decoding failed - probably image is defect.
Message printed using PrintGifError: 'Image EOF detected, before image complete' This error is generated once EOF errorname is detected in encoded image before all the pixels (Width * Height) has be decoded.
These functions are not part of the core GIF library. They are partof the getarg library that supports the utilities.
Print a one-line diagnostic on the last giflib error to stderr.
Main routine of this module. Given argc & argv as received bythe main procedure, the command line CtrlStr, and the addresses ofall parameters, parse the command line, and update the parameters.
The CtrlStr defines what types of variables should follow. Look at thebeginning of getarg.c for exact usage.
Returns false if successful, returns true on failure.
If an error occurred in GAGetARgs, this routine may be used to printone line diagnostic to stderr.
Given the same CtrlStr as for GAGetArgs, can be used to print a one line'how to use'.
If you are handling large images on an extremely memory-limitedmachine, you may need to use the following functions for sequentialread and write. It's better to avoid them and use the simpler DGifSlurp()/EGifSpew() interface.
Reads the screen information into the GifFile structure. Note thisroutine is automatically called once a file is opened, and thereforeusually need not be called explicitly.
Returns GIF_ERROR if something went wrong, GIF_OK otherwise.
As the GIF file can have different records in arbitrary order, thisroutine should be called once the file was open to detect the nextrecord type, and act upon it. It can return these types in GifType:
something is wrong!
screen information. As the screen info is automatically read in when the file is open, this should not happen.
next record is an image descriptor.
next record is extension block.
last record reached, can close the file.
The first two types can usually be ignored. The functionreturns GIF_ERROR if something went wrong, GIF_OK otherwise.
Reads image information into the GifFile structure.Returns GIF_ERROR if something went wrong, GIF_OK otherwise.
Load a block of pixels from the GIF file. The line can beof any length. More than that, this routine may be interleaved withDGifGetPixel until all pixels have been read.
Returns GIF_ERROR if something went wrong, GIF_OK otherwise.
Loads one pixel from the GIF file. This routine may be interleavedwith DGifGetLine(), until all pixels areread. Because of the overhead per each call, use of this routine isnot recommended.
Returns GIF_ERROR if something went wrong, GIF_OK otherwise.
Loads an extension block from the GIF file. Extension blocksare optional in GIF files. This routine should be followed byDGifGetExtensionNext.
Returns GIF_ERROR if something went wrong, GIF_OK otherwise.
As extensions may contain more than one block, use this routine tocontinue after DGifGetExtension, until *GifExtension is NULL.
Returns GIF_ERROR if something went wrong, GIF_OK otherwise.
It sometimes may be desired to read the compressed code as iswithout decoding it. This routine does exactly that (withDGifGetCodeNext), and can be used instead of DGifGetLine.
This compressed code information can be written out using theEGifPutCode/EGifPutCodeNext sequence (see gifpos.c for example).Returns GIF_ERROR if something went wrong, GIF_OK otherwise.
See DGifGetCode above.
This routine can be called instead of DGifGetLine/DGifGetPixel orDGifGetCode/DGifGetCodeNext to get the 12 bits LZ codes of the images.It will be used mainly for debugging purposes (see GifText.c forexample).
Returns GIF_ERROR if something went wrong, GIF_OK otherwise.
Write a termination block to the GIF, close the GIF file andfree all memory allocated for managing it. GifFile should not be used afterthis routine has been called.
Returns GIF_ERROR if something went wrong, GIF_OK otherwise. WhenGIF_ERROR is returned, the diagnostic error code is left in ErrorCode.The GifFile structure is unconditionally freed.
(Note: In versions before 5.1.0, the ErrorCode argument wasabsent and the GifFile structure was not freed so that thediagnostic error code will remain accessible in GifFile->Error.This behavior was changed because it caused problems for theimplementation of library wrappers in dynamic languages.)
Get the GIF version collected during sequential read. This ishandy for sequential API users who want to set an encoder's versionfrom a decoder (e.g. for gif resizing). For the all-at-once users thisisn't necessary because gif encoder inspects all the extension blocks,but sequential users do not have that luxury.
If you are handling large images on a memory-limited machine, you may needto use the following functions for sequential write.
Open a new GIF file using the given GifFileName (in binary mode,if under Windows). If GifTestExistance is TRUE, and file exists, thefile is not destroyed, and NULL returned.
If any error occurs, NULL is returned and the ErrorCode is set.
Open a new GIF file using the given GifFileHandle.
If any error occurs, NULL is returned and ErrorCode is set.
The file is opened in binary mode, and its buffer size is set toFILE_BUFFER_SIZE bytes.
That version computation is available through this function.
Set the GIF type, to GIF89 if the argument is true and GIF87 ifit is false. The default type is GIF87. This function may be calledaftert the GifFile record is allocated but beforeEGifPutScreenDesc().
Update the GifFile Screen parameters, in GifFile structure and inthe real file. If error occurs, returns GIF_ERROR (see gif_lib.h),otherwise GIF_OK.
This routine should be called immediately after the GIF file wasopened.
Update GifFile Image parameters, in GifFile structure and in the realfile. if error occurs returns GIF_ERROR (see gif_lib.h), otherwiseGIF_OK.
This routine should be called each time a new image must bedumped to the file.
Dumps a block of pixels out to the GIF file. The slab can be ofany length. More than that, this routine may be interleaved withEGifPutPixel(), until all pixelshave been sent.
Returns GIF_ERROR if something went wrong, GIF_OK otherwise.
Dumps one pixel to the GIF file. This routine may be interleaved withEGifPutLine(), until all pixels were sent.Because of the overhead for each call, use of this routine is notrecommended.
Returns GIF_ERROR if something went wrong, GIF_OK otherwise.
Uses extension GIF records to save a string as a comment is the file.The extension code is 'C' (for Comment).
Returns GIF_ERROR if something went wrong, GIF_OK otherwise.
Dumps the given extension block into the GIF file. Extension blocksare optional in GIF file. Extension blocks of more than 255 bytes ormore than one block are not supported in this function. Please useEGifPutExtensionFirst, EGifPutExtensionBlock, and EGifPutExtensionTrailerif your extension blocks may fall into this category.
Returns GIF_ERROR if something went wrong, GIF_OK otherwise.
Dumps the beginning of a GIF extension block to a GIF file.Extension blocks are optional in GIF files. This function outputs thetype code information necessary for a GIF extension block.
Further blocks of the GIF Extension should be dumped usingEGifPutExtensionBlock. When finished with this extension block,EGifPutExtensionTrailer should be called to output the block termination.
Returns GIF_ERROR if something went wrong, GIF_OK otherwise.
Dumps a subblock of a GIF extension to a GIF File; should beused only following an initializing call to EGifPutExtensionLeader().Extension blocks are optional in GIF files. This function will writethe Extension Data in GifExtension to the file as a subblock of thepreceding Extension Block. Repeat calling of this function until alldata subblocks have been output.
Note that EGifPutExtensionLeader needs to be called before anycalls to this function. EGifPutExtensionTrailer should be called tofinish the Extension block after all data subblocks have beenoutput.
Returns GIF_ERROR if something went wrong, GIF_OK otherwise.
Pixel Slot Machine Gif Png
Dumps the GIF extension block terminator to a GIF File to endthe current Extension block.
Note that a call to EGifPutExtensionLeader is needed to open the GIFExtension Block prior to calling this function.
Returns GIF_ERROR if something went wrong, GIF_OK otherwise.
It sometimes may be desired to write the compressed code as iswithout decoding it. For example a filter for a GIF file that changeonly screen size (GifPos), does not need the exact pixel values.Piping out the compressed image as is makes this process muchfaster.
This routine does exactly that (with EGifPutCodeNext), and can beused instead of EGifPutLine. You'll usually use this with theDGifGetCode/DgifGetCodeNext routines, which reads the compressedcode, while EGifPutCode/EGifPutCodeNext write it out. See gifpos.cfor example.
Returns GIF_ERROR if something went wrong, GIF_OK otherwise.
See EGifPutCode above.
Write a termination block to the GIF, close the GIF file, andfree all memory allocated for managing it. GifFile should not be usedafter this routine has been called.
Returns GIF_ERROR if something went wrong, GIF_OK otherwise. WhenGIF_ERROR is returned, the diagnostic error code is left in ErrorCode.The GifFile structure is unconditionally freed.
(Note: In versions before 5.1.0, the ErrorCode argument wasabsent and the GifFile structure was not freed so that thediagnostic error code will remain accessible in GifFile->Error.This behavior was changed because it caused problems for theimplementation of library wrappers in dynamic languages.)
Except for some details of extension-block handling and the additionof read/write function hooks, the DGifSlurp()/EGifSpew() interface hasbeen stable since 1990. It is expected to remain so.
However, the signatures of the file-opener functions were changed in 5.0in order to make the library fully reentrant and thread-safe - earlier libraryversions did not feature the final pointer-to-error-code argument in DGifOpen() and friends. For the same reason, the static storage queried byGifLastError() in older versions is gone, and that function abolished.
The library header contains some version #defines you can use if youneed to condition your code so it can compile with different library versions
Versions up to 4.1.6 defined a GIF_LIB_VERSION macro that wasstring-valued with a tricky format to parse. This macro has beenretired.
Versions after 4.1.6 define integer-valued GIFLIB_MAJOR, GIFLIB_MINOR,and GIFLIB_RELEASE macros for the three components of the version. See theNEWS file in the GIFLIB distribution to track API changes.
The following functions are entirely new:
New functions DGifSavedExtensionToGCB() andEGifGCBToSavedExtension() make it easy to read and edit GIF89 graphicscontrol blocks in saved images.
The new function DGifGetGifVersion() is convenientfor people doing sequential reads.
A few changes in behavior were introduced in 5.0:
The library is now fully re-entrant andthread-safe.
All functions exported by this library now have DGif,EGif, or Gif as a name prefix.
The default GIF version to write is now computed atwrite time from the types of an image's extension blocks. (FormerlyEGifSpew() behaved this way, but the sequential-writing code didn't.)The result of this computation is available through the new functionEGifGetGifVersion().
GIF file openers and closers - DGifOpenFileName(),DGifOpenFileHandle(), DGifOpen(), DGifClose(), EGifOpenFileName(),EGifOpenFileHandle(), EGifOpen(), and EGifClose() - all now take afinal integer address argument. If non-null, this is used to passback an error code when the function returns NULL.
EGifSlurp() and EGifSpew() read and writeextension blocks trailing after the last image, handle interlaced images properly.
EGifPutExtensionFirst() has been replaced byEGifPutExtensionLeader(); the difference is the new function doesn'ttake an optional block, it just writes a blockleader.
EGifPutExtensionNext() has been replaced byEGifPutExtensionBlock(); the difference is that the new function doesnot take and then discard a function code argument.
EGifPutExtensionLast() has been replaced byEGifPutExtensionTrailer(); all it does is write the terminatorblock. Split your old EGifPutExtensionLast() calls intoEGifPutExtensionBlock() followed byEGifPutExtensionTrailer().
Some undocumented functions have been renamed. AddExtensionBlock() is now GifAddExtensionBlock(), and takes an additionalfunction code argument. ApplyTranslation() is now GifApplyTranslation();FreeExtension() has become GifFreeExtensions() and takes a different argumenttype; MakeSavedImage() is now GifMakeSavedImage(), FreeSavedImages() isnow GifFreeSavedImages(), and BitSize() is now GifBitSize().
Three documented functions - MakeMapObject(),FreeMapObject(), and UnionColorMap() - have been renamed toGifMakeMapObject(), GifFreeMapObject(), and GifUnionColorMap()respectively.
Library error handling no longer uses a static cell tostore the last error code registered; that made the librarythread-unsafe.
For functions other than GIF file openers, the Errorcode is now put in an Error member of the GifFileTypestructure.
The GifError() andGifLastError() functions that referenced that static cell are gone,and the GifErrorString() function introduced in the 4.2 release nowtakes an explicit error code argument.
If you are developing on a virtual-memory OS such as most flavors ofUNIX, or are otherwise sure of having enough memory to keep all of GIFs youneed to operate in core, writing a filter is trivial. See the filegifsponge.c in util.
A sequential filter skeleton will usually look like the example filegiffilter.c in util.
Please look at the utilities in the util directory for more ideas onceyou feel comfortable with these skeletons. Also try to follow the codingstandards of this package if you want the maintainer to officially add your newutility to it.
Some features of the original GIF specification have not stood thetest of time. This library mostly ignores them, but they are describedhere for completeness.
The GIF standard fails to be explicit about a small but crucial detail:the unsigned two-byte integer fields in it are little-endian.
The GIF format seems to have been designed with the idea that viewerswould render multiple images in a GIF on a common canvas, giving an effect likea picture wall. The 'logical screen descriptor block' (LSDB), 6 bytes rightafter the 6-byte GIF stamp and version header at the beginning of aGIF file, includes both two-byte canvas width and canvas heightfields and a canvas background color. Each image, besides height andwidth, also has 'left' and 'top' cordinates specifying where it is tobe placed on the canvas.
GIFLIB can read and set these fields; the gifpos and giftoolutilities will enable you to script such changes. But browsers andmodern image viewers ignore them. Nowadays multiple-image GIFs are generally used either as animations in which each sub-image is a frameor as image libraries, with the GIF client handling compositing intosome canvas about which the GIF format holds no information.
Pixel Art Gifs
Another feature of the LSDB that is generally ignored is thepixel aspect ratio byte. Until 5.0, GIFLIB ignored this flag on inputand zeroed it on output; now it is read and preserved if present. TheGIF standard doesn't give a rationale for it, but it seems likely thatthe designers intended it for representing image captures from theanalog television of the day, which had rectangular pixel-equivalents.
Yet another ignored feature of both the LSDB and sub-images isthe sort flag, which is supposed to signal whether the colors in theassociated color map are sorted by decreasing importance in case thedisplay device can only render a limited number of them. This featurereflected the high cost of dual-port memory at the time the GIFspecification was written in the late 1980s. That kind of limitdisappeared in the mid-1990s. Until 5.0, GIFLIB ignored this flag oninput and zeroed it on output; now it is read and preserved ifpresent.
Finally, the plaintext extension block. This is an extension block that contains instructions for overlaying text captions on a following image.GIFLIB treats these blocks as raw data, not attempting to parse out the location and text data.