GIFLIB is a package of portable tools and library routines for working
with GIF images. You can find the latest version at the GIFLIB home
page http://www.ccil.org/~esr/giflib.
The Graphics Interchange Format(c) specification is the copyrighted
property of CompuServe Incorporated. GIF(sm) is a service mark
property of CompuServe Incorporated. As this package existed before
UniSys's lawyeritis attack of New Years' Day 1995, it is grandfathered
in under their license terms and you do not have to pay fees
for using it.
This package has been released under an X Consortium-life freeware
license. Use and copy as you see fit. If you make useful changes,
add new tools, or find and fix bugs, please send your mods to the
maintainers for general distribution.
The util directory includes programs to clip, rotate, scale, and
position GIF images. It includes an X11 viewer, code to dump GIFs to
an Epson-compatible printer in graphics mode, and many conversion
utilities. These are no replacement for an interactive graphics
editor, but they can be very useful for scripted image generation or
transformation.
The library includes program-callable entry points for reading and writing
GIF files, an 8x8 utility font for embedding text in GIFs, and an error
handler. GIF manipulation can be done at a relatively low level by
sequential I/O (which automatically does/undoes image compression) or at
a higher level by slurping an entire GIF into allocated core.
This library speaks both GIF87a and GIF89. The differences between
GIF87 and GIF89 are minor: in the latter, the interpretation of some
extension block types is defined. The library never needs to actually
interpret these, but giftext notices them.
Utilities
Here is a summary of the utilities in this package. If you're looking
at this page through a web browser, each utility name should be a
hotlink to HTML documentation.
template code for filtering a GIF with in-core operations
Under MS-DOS, most filters will print the current input scan line number
(counting up) whenever they read image input, and will print output image line
number (counting down) when they dump output. Utilities that only read or
write always print in increasing order. Utilities (like GifPos that only
change positions) that copy the image as a block of compressed data will print
nothing --- they cannot identify a scan line number, and are enough faster that
the feedback to the user doesn't seem necessary.
Some of the utilities require memory on the order of the whole screen, while
others read one scan line at a time. Each utility HTML file has entry called
Memory Usage which will be one of:
Line
memory required is on the order of one scan line
Image
proportional to the size of the biggest image in GIF file
Screen
proportional to GIF screen size
In all cases a byte is allocated per pixel, so an image of 320 by 200 pixels
will requires approximately 64k bytes of main memory.
Library Functions
The library contains two groups of C functions. One group does sequential
I/O on the stream-oriented GIF format. The other supports grabbing an
entire GIF into allocated core, operating on it in core, and then writing
the modified in-core GIF out to disk.
Unless you are on a 286 or some other very memory-limited machine
running under DOS, you probably want to use the second group.
Detailed documentation on the library entry points is in gif_lib.html. Library error codes are
described in liberror.html
This package was originally written by Gershon Elber
in 1990 on an IBM PC under MS-DOS using Borland Turbo C. He made it portable
to several UNIX environments.
The 2.1 version featured substantial changes and additions by Eric
S. Raymond . These included the
DGifSlurp/EGifSpew function pair for enabling non-sequential
operations on GIF images and the tools icon2gif, gifovly, gifburst, and
gifcompose.
The 2.4 version converted all the docs from an idiosyncratic
plain-text formal to to HTML.
Package Status
GIFLIB's current maintainer is Eric S. Raymond. You can find his home
page at http://www.ccil.org/esr.
GIFLIB is not under active development, but bug fixes are being accepted.