SDN¹ Plus/SDN1_.cdr/sdn/grap/gifkit11.sdn/1001WAYS.TXT

Text File | 1989-11-16 | 5KB | 72 lines

1001 Ways to Foul Up a GIF File
                Assorted Tips on the Use of the GIFKIT


        The whole thing started because I get many of my GIF files from the
Internet via one of the UNIX hosts here at Princeton University.  I wanted
some way to do at least a cursory check of the GIF file before I spent time
downloading it to my PC.  Thus there came to be GIFLS, which analyses and
prints statistics on GIF files.  It also does rudimentary error checking.
        While using GIFLS, I discovered that many GIF files have junk bytes
on the end of the file, after the terminator.  While cataloging my GIF
files last summer, I discovered that about 2/3 (out of 600+) had anywhere
from one byte to 13K of junk pasted on the end.  Thus there came to be
GIFSTRIP, which reblocks GIF files, eliminating junk characters.
        Both GIFLS and GIFSTRIP do a lot of disk I/O (GIFLS when using the
-l option for complete analysis).  Hence, I usually copy the GIF files to a
ramdisk before using these programs.  It doesn't matter that much with
GIFLS, but it is quite important with GIFSTRIP.  Because of the nature of a
GIF file, GIFSTRIP thrashes the disk while copying the GIF file over.
Obviously a ramdisk solves this problem.  However, there is the occasional
GIF file which is larger than half the ramdisk (half the ramdisk because
both the original and the temporary copy have to reside on the disk at
once, as a failsafe).  The -t option takes care of this problem by allowing
you to specify a path for the temporary file.  Thus it is possible to put
only the temporary file on the ramdisk.  GIFSTRIP does one long read from
the original disk and one long write back and doesn't thrash the disk. The
-t option is also useful when there isn't room in the current directory for
the temporary file.
        I used GIFSTRIP in various incarnations on the 2/3 of 600+ files
mentioned above; never, under any circumstances, did it foul up irretrievably.
If an error occurs before the original file is removed, the original file
is left intact; if an error occurs afterward, the temporary file is left
alone.  It never garbled the file, either, so if the temporary file is still
around, you should be safe.
        GIFCOLOR was written to solve another problem I encountered while
cataloging: files which are essentially the same but have been enlarged or
reduced.  Obviously, comparing pixels would be difficult and
time-consuming.  However, comparing the color maps is quick and easy.  In
many of these cases, the color map is untouched during the resizing.  Thus,
identical color maps are a telltale clue.  GIFCOLOR also looks for
grayscale images and repeated colors.  Lots of files have repeated colors;
sometimes, in fact, the unique colors would fit in a much smaller color
map.  GIFCOLOR will also dump the RGB values to the screen in a variety of
ways and (on systems with MCGA or VGA) will display the colors, with
labels.
        Just when I thought I was safe, though, I encountered two pairs of
files that looked identical but whose color maps (when I compared them,
just to be sure) didn't match!  They weren't even just rearranged, they
were completely different!  Upon dumping the maps, I discovered that many
of the RGB values had been shifted by one or two.  Hardly a significant
difference, but enough to throw off an exact compare.  Thus there came to
be the fuzzy search, which allows you to specify a tolerance (i.e.
comparison within a range instead of exact).
    With this recentest release, I began pondering the fact that it is
possible to specify searches according to image height, width, and colors
in GIFLS but not in any of the other programs.  However, adding these options
to the other programs would be difficult.  I managed to solve this problem
by modifying GIFLS to serve as a front end for the other programs.  The -f
option on GIFLS causes it to write a list of filenames to stdout.  This list
can be piped to either GIFSTRIP or GIFCOLOR.   When either of these programs
detects that its stdin has been redirected, it reads stdin for a list of
targets.  This list need not come from GIFLS, either -- there programs can
read from a file of targets.  The targets must be separated by newlines.
        In conclusion, I hope you find these programs as useful as they
have been to me.

        --James W. Birdsall


GIF and "Graphic Interchange Format" are trademarks (tm) of CompuServe,
Inc., an H&R Block company.