Xref: utzoo comp.graphics:17203 comp.compression:326
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!jarthur!nntp-server.caltech.edu!toddpw
From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.graphics,comp.compression
Subject: Re: gif encoding questions
Message-ID: <1991Apr9.203611.5823@nntp-server.caltech.edu>
Date: 9 Apr 91 20:36:11 GMT
References: <1991Apr9.142255.186@unhd.unh.edu>
Organization: California Institute of Technology, Pasadena
Lines: 32

rg@msel.unh.edu (Roger Gonzalez) writes:

>Let c = (2**bitsize) - 1

>When encoding in GIF format, do you increase the bitsize when you
>_output_ code c, or when you _add_ an entry to the c-th entry in the 
>string table?

You increase the bitsize whenever the maximum code value you could output
can't be represented with the current bitsize. For encoders this means
you do it when you add the c-th entry.

>What about when c = 4095?  Do you output the clear code and reinitialize
>after 4095 is output, or after the 4095th entry in the table is used?

According to the 89a standard you are not required to output a clear code
at all. However I would encourage outputting a clear code INSTEAD of filling
the 4095th table entry; this way the decompressor sees the clear code before
there is any question as to its bitsize. When I was first teaching myself GIF
I forgot to max out the bitsize at 12 and would lose sync with the data on
only some of my GIFs when the table maxed out for the first time, because the
clear code was being read as 13 bits. This is not overridingly important but
it's a nice touch to know that your picture can be read in full by a decoder
that almost works.

>Why have I seen gray scale (256) GIFs that don't have simple color maps like
>00 00 00 01 01 01 02 02 02 03 03 03 ... FE FE FE FF FF FF

Who knows? Maybe they have been sorted by popularity or something.

Todd Whitesel
toddpw @ tybalt.caltech.edu