It seems to me that there are two separable decisions to be made:
  1. what overall file format to use;
  2. what compression mechanism to use within that overall format.
We could reasonably drop GZIP or Huffman or another compression method
into any file format design, so these are separate issues.  The
compression method will pretty much determine the file size for any
given image data, but the file format will determine the features and
future extensibility of the design.

For the file format choice, I think there are two reasonable
alternatives:
  1. Use GIF as-is, or with a few extensions such as 24-bit support.
  2. Use an all-new design, whether Tom Boutell's or something else.
The third alternative, bolting a new compression method onto some other
existing spec such as Targa, doesn't appeal to me.  It will not be
noticeably easier to implement, and it will not address the existing
application areas of GIF as well as GIF does.

Choice #1 assumes that Compuserve will cooperate and make the revised
"GIF95" spec available on the same terms as previous versions.  Onerous
requirements such as we saw in the proposed license agreement are
unacceptable and will certainly lead to the adoption of choice #2.
But for now let's assume that CIS will play ball.

To make a reasoned choice between these alternatives, we need to look at
the feature set that we want the file format to have.  Which of GIF89's
capabilities must be preserved?  Which would we be willing to give up?
What new capabilities, not found in GIF89, do we really need?

I am not a fan of including features in the file format definition that
we don't desperately need.  To be widely portable, especially in the
short time frame we have here, the definition must be simple and easy to
implement.  I'd remind you also that few existing implementations
support all of GIF89; the "portable" part of GIF is probably GIF87 with
only one image per file.

For example, Boutell's proposal does not support multiple images in one
file, nor does it handle the animation capabilities of GIF89.  As far as
I know there are no Internet applications that make use of those
features, so eliminating them is a reasonable idea for Internet
purposes.  I do not know how many CIS-related applications really need
those features.  If that stuff is widely used anywhere, then perhaps we
need to stick closely to the existing GIF format.

The question of just which features to include and which not needs much
more discussion before any format proposal is frozen.  Here are a few
thoughts of my own:
  1. Serial access read and write (ie, the format must be readable and
     writable on-the-fly as a datastream): essential to keep.
  2. Palette image storage: essential to keep, though it might be enough
     to support only 4 and 8 bits per pixel, not 1 to 8 as GIF does.
     Odd-size bit depths are more complex to program and don't compress
     very well --- the space savings may be illusory.
  3. Lossless true color storage: not in GIF89, but many people want to
     add this.  Do we need both 16 and 24 bits/pixel, or just 24?
  4. Lossy true color storage: I think it would be better to keep lossy
     storage out of the picture.  It's tough enough getting people to
     understand the differences between JPEG and GIF; having both lossy
     and lossless options in one file format will case untold confusion.
  5. Text comments: essential.
  6. Support for non-square pixels: I'd rather like to see this crock
     go away :-).  If anyone still has that sort of silly hardware,
     their viewers should compensate for it, not make the rest of us
     live with it.
  7. Interleaved display capability: I once thought this capability was
     useless, but it is coming back into favor on the World Wide Web.
     We probably want to keep it.  Do we want an interleave order
     smarter than GIF89's ?  (Ie interleave in both directions?)
  8. Animation, user interaction, etc: I'd say lose these.
  9. Multiple images per file: I'd say lose this, too.
No doubt others will have their own opinions on these points.  Let's
hear them!  We need a discussion!!

On to the second basic issue, which is what compression method to
provide.  I think there's not much question that we want a lossless
compression method that gives compression at least approaching what
we got from LZW.  I see two reasonable choices:
  1. GZIP.  This is pretty close to state of the art (better than LZW)
     and while it is not absolutely certain to be patent-free, a lot of
     effort has gone towards making it so.  I think we could safely use it.
  2. Some ancient method such as plain Huffman coding, which will
     certainly be patent-free by virtue of age.  This is likely to give
     noticeably poorer compression than LZW, however.
Anything else will pose a distinct risk of being blindsided later by
some patent, as originally happened with LZW.

My feeling is that GZIP is a better choice.

                        regards, tom lane
                        organizer, Independent JPEG Group