------------------------------

ubject: 0. Why aren't JPEG, MPEG, LZW, and CCITT Group 3 & 4 file formats?

One of the most commonly confused concepts found in file formats is the
difference between the file format and the method(s) of data encoding that
has been used to reduce the size of the data the file contains. JPEG,
MPEG, LZW, and CCITT are all algorithms, or algorithm toolkits, which
encode a stream of data to a physically smaller size. None of these data
compression methods define a specific format used to store data. 

Several formats have become popular based on their use of one or more of
these methods of compression, such as GIF (LZW), JFIF (JPEG), and TIFF
(CCITT Group 3 and Group 4). So if you ask for a "CCITT Group 3" image
file you will most likely get a file containing only CCITT Group 3 data
and not a TIFF file containing bitmapped data compressed using the CCITT
Group 3 algorithm, which might have been what you were expecting.

------------------------------

ubject: 1. Why aren't IGES, GKS, NAPLPS, PCL, and HPGL file formats either?

IGES (Initial Graphics Exchange Specification), GKS (Graphics Kernel
System), NAPLPS (North American Presentation Layer Protocol Syntax),
Xerox Sixel, DEC ReGIS, and Tecktronix vector graphics are not
actually file formats. They are instead protocols which specify how
text and graphical data should be transmitted over a communications
link (such as a serial cable or telephone line) to a remote device
(such as a graphical workstation). 

The X protocol is used by X Window System clients and servers to
communicatte over Ethernet. Although you can save X protocol-encoded
data to a file, this does not mean that there is an "X protocol file
format".

HPGL (Hewlett-Packard Graphics Language) and PCL (Printer Control
Language) are data stream definition standards used to transfer and 
manipulate data used by printers and plotters.

In most cases, each of these protocols define a previously existing
file format, such as CGM or JFIF, to be the actual format used to
store the graphics data (CGM and PCL use a raw or compressed bitmap).
Occasionally the transmitted data stream may be stored to a file for
buffering or archival purposes. This file is then often identified as
using the "{IGES,GKS,NAPLPS,PCL,HPGL} file format".

Descriptions of each of these standards may be found in Part 3 (Where
to Get File Format Specifications) of this FAQ. For more information
on graphical protocols, have a look at the following:

  http://www.cs.utk.edu/~shuford/terminal_index.html
    Video Terminal Information


------------------------------

ubject: 2. Is it "Tag" or "Tagged" Image File Format?

Revision 5.0 of TIFF specification specifically states the acronym "TIFF"
is "Tag Image File Format". The majority of people, however, intuitively
say "Tagged" rather than "Tag". Interestingly enough, the TIFF 6.0
specification does not spell out the acronym TIFF.

------------------------------

ubject: 3. Whaddya mean there's no "Targa" file format?

The popular "Targa" file format is really the "TGA format". "Targa" is the
name of the Truevision graphics display adapter which first used the TGA
format. Specifically, Revision 1.0 of TGA is designated the "Original TGA
format" and Revision 2.0 is the "New TGA Format".

------------------------------

ubject: 4. Choosy programmers choose "gif" or "jif"?

The pronunciation of "GIF" is specified in the GIF specification to be
"jif", as in "jiffy", rather then "gif", which most people seem to prefer.
This does seem strange because the "G" is from the word "Graphics" and not
"Jraphics".

------------------------------

ubject: 5. Why are there so many ".PIC" and ".IMG" formats?

Because people with very little imagination are allowed to choose file
extensions for graphics files, that's why.

But seriously, there does seem to be a proliferation of file formats with
the file extension ".PIC" (for "picture") and ".IMG" (for "image"). Other
popular extensions (in both upper and lower case) are ".RGB", ".RAW",
".ASC", and ".MAP".

My advise to you is never assume the format of a data file based only on
its file extension. The name and the extension of any file are completely
arbitrary and therefore could be anything. This is why the most graphics
file conversion and display programs attempt to recognize graphics files
based on their internal structure and not their file name or extension.

------------------------------

ubject: 6. Where can I get the spec for the GIF24 format?

A GIF24 standard file format has never been officially introduced or
released to the public. The original effort by CompuServe and others, 
to create a 24-bit revision of the GIF format was never completed.
The problems create by Unisys' LZW patent restrictions and the subsequent
disdainment of GIF by many developers is probably mostly to blame.

It has been said that CompuServe abandoned GIF24 in favor of PNG
format, who developers hope that one day will completely replace GIF. 
But it is not evident that CompuServe contributes in any remarkable way 
to the ongoing development of PNG.

------------------------------

ubject: 7. Is there an uncompressed GIF format?

Realizing that the heart of the GIF patent controversy is the LZW 
data compression algorithm itself, you may ask if there is a raw or
uncompressed version of GIF that can be read and written without
using the LZW alogrithm. Officially, the answer is no.

The GIF specification does not defined a way to store uncompressed
bitmap data. All bitmap data stored in a GIF file is compressed using
the LZW algorithm. If you did write a program that stored
uncompressed data using the GIF format, no other GIF reader would be
able to decode the GIF files it created.

So is there a way to modify the compressed data in a GIF file so it is 
no longer in a format described by the LZW patent, but still readable
by GIF decoders? They answer to this is yes!

When a GIF file is compressed, an initial LZW code table is created
based on the bit-depth of the raw image data being LZW-encoded. For
example, a bitmap with 4-bit pixels will be encoded with an LZW code
table initially containing 18 entries: 16 color indicies ranging from
00000 to 01111, a clear code (10000), and a end-of-data code (10001).

As LZW encoding proceedes, color codes from the data are used to form
new table entries, and its the formation of these new entries that is
the heart of LZW encoding. If an encoder only used the initial table
and did not create any new table entry codes, then all of the
resulting encoded data will be codes representing the indicies of the
colors stored the in the GIF file's active color table.

This process is explained in a post made to comp.graphics.misc by
Dr. Tom Lane on 05 Dec 1996:

    ...the idea is to emit only single-symbol string codes, plus a Clear
    code every so often to keep the decoder from jacking up the code
    width. In this mode your encoder is simply packing N-bit pixel
    values into N+1-bit fields and keeping count; nothing patentable
    there. Note that the data is not merely not compressed, it's
    *expanded*: you need 9 bits per pixel for an 8-bit GIF. I wouldn't
    care to use this trick for low-depth data. The worst case is for
    1-bit (black and white) data; not only do you need 2 bits/pixel, but
    every other symbol has to be a Clear to keep the code width down to 2
    bits ... net result, 4:1 expansion.

Because this encoder ends up storing N+1 bits for every N bits of
data, plus a clear code every 2^N-2 codes, an 8-bit "non-compressed"
GIF image will be 1/8th larger than the same bitmap stored as an
LZW-compressed GIF.

Tom explained this a few days later:

    Note, however, that you have to insert "clear" codes often enough to
    prevent the decoder from ratcheting up the symbol width, or else
    keep track of what the current symbol width should be.  It's been a
    while since I looked at this in detail, but I think you need a clear
    every 2^N-2 codes, where N is the underlying data depth, if you want
    the symbol width to stay at N+1 bits.

[Note: Thanks to Tom Lane of the Independant JPEG Group and Neil
Aggarwal of Bellcore for provising the Usenet discussion that
contained this material]