Part1 - Part2 - Part3 - Part4

Graphics File Formats FAQ (Part 1 of 4): General Graphics Format Questions



Subject: Graphics File Formats FAQ (Part 1 of 4): General Graphics Format Questions

Supersedes: <graphics/>

Followup-To: poster

Date: 20 Jan 1997 00:13:01 -0800

Organization: O'Reilly & Associates, Inc.


Expires: 02/24/97 00:13:00

Message-ID: <graphics/>

Reply-To: (James D. Murray)

Summary: This document answers many of the most frequently asked 

        questions about graphics file formats on Usenet.


Posted-By: auto-faq

Archive-name: graphics/fileformats-faq/part1

Posting-Frequency: monthly

Last-modified: 20Jan97

Graphics File Formats FAQ (Part 1 of 4): General Graphics Format Questions


his FAQ (Frequently Asked Questions) list contains information on

graphics file formats, including, raster, vector, metafile, Page

Description Language, 3D object, animation, and multimedia formats.

This FAQ is divided into four parts, each covering a different area of

graphics file format information:

  Graphics File Formats FAQ (Part 1 of 4): General Graphics Format Questions

  Graphics File Formats FAQ (Part 2 of 4): Image Conversion and Display Programs

  Graphics File Formats FAQ (Part 3 of 4): Where to Get File Format Specifications

  Graphics File Formats FAQ (Part 4 of 4): Tips and Tricks of the Trade

Please email contributions, corrections, and suggestions about this FAQ to Relevant information posted to newsgroups will not

automatically make it into this FAQ.

-- James D. Murray


Subject: 0. Contents of General Graphics Format Questions

Subjects marked with <NEW> are new to this FAQ. Subjects marked with <UPD>

have been updated since the last release  of this FAQ.

I. General questions about this FAQ

0. Maintainer's Comments

1. What's new in this latest FAQ release?

2. Why does a graphics formats FAQ exist?

3. Where can I get the latest copy of this FAQ?

4. Are there other related FAQs I should read as well?

5. I have a question, correction, or some information for

this FAQ.

6. This FAQ doesn't contain enough detail!

7. Why isn't the XXX file format covered?

8. Why aren't audio file formats covered?

9. Why aren't word processing formats covered?

10. What about multimedia file formats?

11. What is an "Internet File Format?"

12. Which file formats should I and should I not use?

13. What is ray tracing?

II. General Graphics File Questions

0. Who cares about graphics file formats?

1. What is raster, vector, metafile, PDL, VRML, and so


2. Why should I care about previous versions of a file


3. Can graphics files be infected with a virus?

4. Can graphics files be encrypted?

5. How can I convert the XXX format to the YYY format?

6. Do I really need the specification of the format I'm


7. How can I tell if a graphics file is corrupt?

8. What do I put in my own graphics file format


III. Working with Graphics Files on Usenet and the Internet

0. How can I email a graphics file?

1. Where can I find graphics files on Usenet?

2. How do I decode a graphics file posted to Usenet?

3. How can I post a graphics file to Usenet?

4. How do I submit a file format specification to an


5. How can I make transparent and interlaced GIFs for a Web


6. How do I combine still images to make animations?

IV. Copyrights, Patents, and other Legalities of Graphics File Formats

0. Can a graphics file be copyrighted?

1. Is it now illegal to use CompuServe's GIF format?

V. Graphics Formats Misnomers, Misgivings, and Miscellany

0. Why aren't JPEG, MPEG, LZW, and CCITT Group 3 & 4

file formats?

1. Why aren't IGES, GKS, NAPLPS, PCL, and HPGL file formats


2. Is it "Tag" or "Tagged" Image File


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

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

5. Why are there so many ".PIC" and ".IMG"


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

7. Is there an uncompressed GIF format?

VI. Graphics File Resources

0. File Format Specifications FTP Archives and WWW


1. Graphics and Image File FTP Archives and WWW Pages

2. Internet Mailing Lists for Graphics and Imaging

3. Books on Graphics File Formats

4. Magazine Articles on Graphics File Formats

VII. Kudos and Assertions

0. Acknowledgments

1. About The Author

2. Disclaimer

3. Copyright Notice


Subject: I. General questions about this FAQ


ubject: 0. Maintainer's Comments

The GFF FAQ is now included in the Sandy Bay Software PC Webopaedia



ubject: 1. What's new in this latest FAQ release?


  o Add some new LZW information. Need to update this section more.

  o Added section on uncompressed GIF files

  o Several new file format book entries and one new journal article

  o Updated many URLs


ubject: 2. Why does a graphics formats FAQ exist?

The purpose of this FAQ is to answer many of the frequently asked questions

about graphics file formats posted on Usenet. You will find definitions of

terms, references to format information, very general descriptions of many

formats, information on programs which read, write, convert, and display

graphics files, and some handy programming tips for writing your own code. 

This FAQ is not a substitute for actual file format specifications, nor can

it possibly go into a great amount of specific detail on graphics file



ubject: 3. Where can I get the latest copy of this FAQ?

The latest revision of this FAQ is always available at This FAQ is also

distributed monthly on the Usenet newsgroups,

comp.answers, and news.answers as four separate files. It may also

be obtained via anonymous FTP from:

To receive a copy of this FAQ via email, send an email message to with the body:

  send usenet/news.answers/graphics/fileformats-faq/part1

  send usenet/news.answers/graphics/fileformats-faq/part2

  send usenet/news.answers/graphics/fileformats-faq/part3

  send usenet/news.answers/graphics/fileformats-faq/part4

or via UUCP:





Other sites on the World Wide Web that archive this FAQ include:


ubject: 4. Are there other related FAQs I should read as well?

Information related to file formats not covered by this FAQ may be

found in the following FAQs:

  Newsgroup                Archive-name       pictures-faq/part[1-3]       pixutils-faq

  alt.image.medical           medical-image-faq/part[1-8]

  alt.sci.astro.apis          astronomy/aips-faq

  comp.compression            compression-faq/part[1-3]


  comp.dsp                    dsp-faq/part[1-3]


  comp.fonts                  fonts-faq/part[1-2]          graphics/faq



                              jpeg-faq/part[1-2]     graphics/animation-faq  graphics/raytrace-faq/part[1-2]

  comp.infosystems.gis        geography/infosystems-faq/part[1-2]


  comp.multimedia             comp-multimedia-faq

  comp.speech                 comp-speech-faq/part[1-3]

  comp.sys.sgi.misc           sgi/faq/graphics            sci-data-formats

  sci.image.processing        image-processing/Macintosh


These FAQs may also be found the newsgroups alt.answers, comp.answers,

sci.answers, and news.answers, and in the FAQ archives at and mirror sites.

Please read the news.answers FAQ for a log listing of WWW, FTP, gopher, and

mail server FAQ archives. This FAQ is housed at

To FTP any of these FAQs use the listed Archive-name with the following

FTP address: [Archive-name]

To receive a copy of these FAQs via email, send an email message to with the body:

  send usenet/news.answers/[Archive-name]


ubject: 5. I have a question, correction, or some information for this FAQ.

All questions, comments, additions, and corrections should be sent to the

author of this FAQ at

I don't always read the newsgroups this FAQ is posted to, so please contact

me directly via email rather than attempting to reach me by posting to a

newsgroup. All suggestions and contributions within the scope of this FAQ

are welcome and contributors receive full credit in the Acknowledgments

section of this FAQ.


ubject: 6. This FAQ doesn't contain enough detail!

This FAQ only attempts to answer Frequently Asked Questions. It is not a

book on graphics file formats. It is instead a thick source of information

that will help you obtain more information that you need. Or perhaps even

clear up a few of your misconceptions and thereby saving you from wasting

some time.


ubject: 7. Why isn't the XXX file format covered?

If you have read and/or grepped this FAQ and not found information on the

format you need the reason might be that:

  * You are looking for the format under the wrong name.

  * This FAQ is new and the information you need hasn't been included yet.

  * I don't know about the format and I need you to email me information

    on it (See Subject: 5).

  * The format is proprietary and its caretakers do not wish information

    on the format distributed in this FAQ.

And let me make one thing perfectly clear: I have have not proposley

omitted the reference to any file formats, books, or software applications

that I see as within the scope of this FAQ. If you don't see information

here that you consider relavent and necessary, then *tell me* and I will

include it.


ubject: 8. Why aren't audio file formats covered?

Information on file formats used specifically for storing audio data

are already covered quite nicely by the Audio File Formats FAQ

maintained by Guido van Rossum <> or 


You may obtain this FAQ from the Usenet newsgroups comp.dsp, 

comp.answers, and news.answers, from the FTP archive sites:

or via the Web page:

The FAQ for comp.speech may of also be of interest to audio people. It is

available at:


ubject: 9. Why aren't word processing formats covered?

It is true that there are many types of file formats that cannot store

graphics data (older word processor and spreadsheet formats, and so forth).

These formats are not within the scope of this FAQ and are therefore not

covered. Perhaps someone who works in the biz of writing file translators

for these formats will put together such a FAQ one day.


ubject: 10. What about multimedia file formats?

Multimedia file formats store more than just graphics data. They may also

contain audio, video, animation, and textual data in addition to bitmapped

and vectored graphics. Such formats, although a superset of graphics

formats, are considered to be within the scope of this FAQ and are

therefore covered.  Also check the comp.multimedia FAQ for additional

information you may require.


ubject: 11. What is an "Internet File Format?"

If you have searched the Web lately using the key phrases "file format", 

"data format", or "graphics format", you have most likely run across many

Web pages claiming to have all the information you need on "Internet File

Formats." In fact, there is no such thing.

The Internet is a global communications network used for one thing--to

move data from one location to another. The data does not need to be in

the format of a "file" to be moved, nor are file and data formats created

originally for use on the Internet (e.g. MIME, X.400, uucode, and so

forth) only found on the Internet.

There are many file formats you will constantly encounter while using the

Internet. GIF and JPEG for still-images, MPEG, MOV, and AVI for video, WAV

and AU for audio, Z and gz for compressed files, and ZIP, tar, and ARJ for

file archives. And while these formats are found in great profusion on the

Internet, they were by no means created to be specifically used on or by

the Internet and its community. Therefore, the term "Internet File Format"

is inaccurate and misleading.


ubject: 12. Which file formats should I and should I not use?

  [ Still working on this ]


ubject: 13. What is ray tracing?

The following FTP sites and Web pages contain ray tracing information:

    The Ray Tracing Home Page

    Ray Tracing News Guide


Subject: II. General Graphics File Questions


ubject: 0. Who cares about graphics file formats?

Well, programmers do mostly. But end-users (that is, non-programmers) do as


The typical end-user only cares about storing their graphics information

using a format that most graphics programs and filters can read. End-users

are typically not concerned with the internal arrangement of the data

within the graphics file itself. They only want the format to do its job

by representing their data correctly in a permanent form.

Programmers, on the other hand, are that rare breed of human that just

can't leave information well enough alone. They need to know how every

byte is arranged to see if someone knows something that they don't (and

often snicker contentedly to themselves when they find that it is really

they that know more). Programmers will then use this information to write

code that may never see the light of distribution, but nevertheless, they

will have had fun and gained enlightenment from writing it.

It doesn't matter which of these two types of people you are. If you have

even the slightest interest in graphics file formats then you may be

counted as one who cares.


ubject: 1. What is raster, vector, metafile, PDL, VRML, and so forth?

These terms are used to classify the type of data a graphics file contains.

Raster files (also called bitmapped files) contain graphics information

described as pixels, such as photographic images. Vector files contain

data described as mathematical equations and are typically used to store

line art and CAD information. Metafiles are formats that may contain

either raster or vector graphics data. Page Description Languages (PDL)

are used to describe the layout of a printed page of graphics and text.

Animation formats are usually collections of raster data that is displayed

in a sequence. Multi-dimensional object formats store graphics data as a

collection of objects (data and the code that manipulates it) that may be

rendered (displayed) in a variety of perspectives. Virtual Reality

Modeling Language (VRML) is a 3D, object-oriented language used for

describing "virtual worlds"  networked via the Internet and hyperlinked

within the World Wide Web. Multimedia file formats are capable of storing

any of the previously mentioned types of data, including sound and video



ubject: 2. Why should I care about previous versions of a file format?

When version 2.0 of the XXX format is released all of the thousands of

files created using version 1.0 of the XXX format don't magically

disappear or transform to version 2.0 overnight. Although version 2.0

might claim to be fully backwards compatible, the new specification may

obfuscate or even omit details of the previous version of the format. In

short, never throw away older information just because you have something

newer. At one point in time that "out dated" format spec was

state-of-the-art, and it may still contain a singular precious tid-bit of

information that the caretakers of the format didn't carry over to the new

spec (but Murphy will make sure you desperately need to know).


ubject: 3. Can graphics files be infected with a virus?

For most types of graphics file formats currently available the answer is

"no". A virus (or worm, Trojan horse, and so forth) is fundamentally a

collection of code (that is, a program) that contains instructions which

are executed by a CPU. Most graphics files, however, contain only static

data and no executable code. The code that reads, writes, and displays

graphics data is found in translation and display programs and not in the

graphics files themselves. If reading or writing a graphics file caused a

system malfunction is it most likely the fault of the program reading the

file and not of the graphics file data itself.

With the introduction of multimedia we have seen new formats appear, and

modifications to older formats made, that allow executable instructions to

be stored within a file format. These instructions are used to direct

multimedia applications to play sounds or music, prompt the user for

information, or display other graphics and video information. And such

multimedia display programs may perform these functions by interfacing

with their environment via an API, or by direct interaction with the

operating system. One might also imagine a truly object-oriented graphics

file as containing the code required to read, write, and display itself.

Once again, any catastrophes that result from using these multimedia

application is most like the result of unfound bugs in the software and

not some sinister instructions in the graphics file data. Such "logic

bombs" are typically exorcised through the use of testing using a wide

variety of different image files for test cases.

If you have a virus scanning program that indicates a specific graphics

file is infected by virus, then it is very possible that the file

coincidentally contains a byte pattern that the scanning programming

recognizes as a key byte signature identifying a virus. Contact the author

(or even read the documentation!) of the virus scanning program to discuss

the probability of the mis-identification of a clean file as being

infected by a virus. Save the graphics file, as the author will most

likely wish to examine it as well.

If you suspect a graphics file to be at the heart of a virus problem you

are experiencing, then also consider the possibility that the graphics

file's transport mechanism (floppy disk, tape or shell archive file,

compressed archive file, and so forth) might be the original source of the

virus and not the graphics file itself.


ubject: 4. Can graphics files be encrypted?

Of course you can encrypt a graphics file. After all, most encryption

algorithms don't care about the intellectual content of a file. All they

chew on is a series of byte values. Therefore, most any encryption program

that works on ordinary text files will work on graphics files as well.

Why would you want to encrypt a graphics file? Mostly to control who can

view its contents. You can invent a proprietary file format and that might

slow a file format hack down for, say, five or ten minutes. You could add

a proprietary data compression scheme, possibly a twisted variation of an

already public algorithm. But there are so many people out there with

nothing better to do than hack at unknown data formats that your data

would probably be exposed in little time. But suppose we top off all this

effort by encrypting the graphics file itself as we would an ordinary text

file. Would your data then be safe?

Realize that an encrypted graphics file still might not be very secure.

For every data encryption algorithm there exists at least one method of

getting around it, although it may take hundreds of computers and many

years to fully employ and execute that method!

For example, one of the more popular methods used to encrypt data is the

Vernam or XOR cipher. This cipher Exclusive ORs the plain-text data with a

single, random, fixed-length key. The longer the key the harder it is to

break the cipher. A totally random key the length of your data is

impossible to break. Shorter and less-random keys are easier to break.

XOR is very simple and fast, which is a must for a graphics file

translators/viewers that must decrypt a file on the fly. A problem,

however, is that most graphics files contain fixed size headers which vary

only slightly in content from file to file. If you knew the approximate

contents of the header of an encrypted file you could XOR a "decrypted"

header with the encrypted file and possibly produce the key used to

encrypt the file. A short key might be very easily discovered in this way.

If you wish to use a public key/private key encryption method, then

storing the public key in the file format header (usually as a 4-byte

field) and only encrypting the image data would be the way to go. The

SMPTE DPX file format supports such an encryption feature.

If you really need to make the contents of a graphics file secure, then

I'd suggest not only using some form of data encryption, but also create

an unconventional and proprietary file format and do not publish its

format specification.

For more info on data encryption:

  Bruce Schneier, "Applied Cryptography: Protocols, Algorithms,

    and Source Code in C", John Wiley & Sons, 1994.


ubject: 5. How can I convert the XXX format to the YYY format?

With a file conversion program, of course! Without a doubt one of the

most frequently asked categories of questions on

is how to convert one format to another. In every case the answer is

some type of conversion program or filter, but which one?

Section IV of the FAQ is an attempt to list every known graphics file

display and conversion program and application. Although far from

complete, this list may contain the program you need. Go to the

subsection of the particular operating system you are using and scan

through Imports: and Exports: formats listed and see if the formats

you needs to use are there.

In some cases the information in a listing may make the conversion

capabilities of a program a bit misleading. For example, a program

that can import a vector .DWG file and export a raster .BMP file may

not necessarily be able to perform a .DWG->.BMP (vector->raster)

conversion (AutoCAD R12 can, BTW). And just because a program can

both import and export TIFF files doesn't mean it's capable of a

TIFF(CMYK)->TIFF(RGB) conversion (as Adobe Photoshop can do). As

always, read the documentation, contact and ask the author of the

program, or find a user of the program and ask them.


ubject: 6. Do I really need the specification of the format I'm using?

It depends upon the results you are trying to obtain. If you have code

that supports the XXX format and you find it easy (and legal) to integrate

that code into your program, then you may be tempted to do so. But realize

that your program will support the XXX format in just the same way as the

previous program did. In other words, your program will now work the same,

but it will really be no better.

By obtaining the format specification you can make an attempt to fully

support all of the features and capabilities a graphics or multimedia file

format has to offer. If you use pre-written code that only supports a

small subset of the format's features then you are not doing justice to

the format and cheating your users out of functionality they might need.

Always strive to create the best programs possible within reason of time

and money. Obtain the specs, look at code, and talk to programmers who

have worked with the format before. You might gain some insight and save

yourself some hair-pulling by supporting a feature that someone didn't

think to include in the original requirements for your program.


ubject: 7. How can I tell if a graphics file is corrupt?

The easiest way is to display the file and decide if what you see on the

screen or the printer is correct. This method is not fool-proof, however,

because not all information stored in a graphics file is used for

displaying the data it contains. Textual comments, alternate color maps,

and unused fields in the header might be munged and go undetected.

A frequent source of corruption occurs when 8-bit graphics data is

transported via a 7-bit communications channel. The 8th bit of each byte

is cleared (set to zero) and you are left with garbage. ASCII-mode file

transfers may also translate carriage returns (0Dh) to line feeds (0Ah),

or to CR/LF pairs depending upon if the file is being transferred to a

Unix (LF-only), Macintosh (CR-only), or MS-DOS (CR/LF) system.

The PNG file format supports an elegant solution to the quick detection of

this type of corruption. The first character of every PNG file is the

8-bit value 89h. If this value is read as 09h, the 8th bit has been zeroed

and you know the file is corrupt.

Most graphics files do not contain any real, built-in error detection

features. The standard way to check for corruption of any type of data

file is to perform some sort of error-detection scheme on the file. Such

schemes commonly used are Checksum calculations and the Cyclic Redundancy

Check (CRC).  These algorithms are commonly used in the world of

synchronous serial communications for detecting errors in data streams.

If you only wanted to provide error detection for the graphical data

contained in a file, but not the header, then a 2- or 4-byte field in the

header could be used to store the CRC-16 or CRC-32 value of the data. But

what good is pure data if the header is possibly corrupt? 

If we calculate the CRC value of the entire file and then store that

calculated value in the header we will have just "corrupted" the file! You

could initialize the CRC field with zeros, calculate the value, store the

value, and specify that the entire file need be read into memory and the

CRC value field set to all zeros before the CRC calculation is made. 

File formats that segment their data into blocks or chunks would be able

to perform a CRC on each section individually (another feature found in

the PNG file format). Each section would store the CRC value as the last 2

or 4 bytes of the block and the CRC value field would never be read for

the purpose of the CRC calculation. This method makes it easier to find

the location of the error(s) in a file. If the CRC error occured in an

unnecessary block of data, the file might still be useful anyway. This

block-style CRC checking also saves the reader from performing a

time-consuming CRC calculation an entire, possibly very large, graphics


But all this can be quite a pain. Can't we avoid modifying a file and just

store the CRC value externally to the file? Maybe using some sort of

encapsulating "wrapper"?

If you want to make sure a graphics file (or any file for that matter) has

been transported through a communications channel without sustaining any

corruption, first store it using a file archiving program that supports

error checking of the files contained in the archive. (Several good

error-checking file archiving programs include PKZIP, gzip, and zoo. The

ar and tar Unix archiving programs do not support error checking). When

the graphics file is stored, the archival program calculates the CRC value

of the file. If the CRC value does not match the file's calculated CRC

after it is unarchived after transport, you know that the file has been


Note: make sure you turn compression OFF when archiving many types of

graphics files. File archival programs use compression by default and will

attempt to make your compressed data even smaller (which usually results

in larger data, unless the archiver is smart enough to detect the negative

compression and not attempt to compress the file). ASCII-based files (such

as PostScript and DXF) and some RLE-encoded files (such as PCX) will be

compressed, while other formats supporting more advanced data compression

methods (such as JPEG and LZW) will surely grow in size.


ubject: 8. What do I put in my own graphics file format specification?

For people that are faced with the task of writing up a specification for

their own format (or perhaps to better document someone else's), a few

suggestions are hereby offered.

  A large spec needs a table of contents, bibliography, and an index.

  Most specs do not fall into this category though.

  On the cover sheet give the full information of your company, products

  associated with the format, the format version, date of release, 

  where the latest copy of the spec may be obtained, and how developers

  may get in contact with you to ask questions.

  Detail the full history of the spec (including the difference between the

  current version and all previous versions) and not just the dates of its

  revision. Tell why the format was created. Detail some insights of

  how it was designed. Speculate on what features future version might

  contain. And give the names of your developers and other people

  involved. Show the human thought that exists behind the cold chunk of

  data that is your format.

  List the features of your format and explain how you intend that it

  should be used and not used (tell what your format is and is not).

  Give the developer your reasons that they should use your format (and

  why they should not bother with others).


  Include both block diagrams and ANSI C code examples of the format's

  internal data structures. Illustrate actual examples of ASCII file

  format data and hexadecimal dumps of binary format data (very useful

  to programmers, I might say).

  If your format includes one or more forms of data compression, error

  checking, encryption, etc., place this information in a separate

  section and give plenty of examples (both written and code) of how

  these algorithms work. Include mathematical formulas if you believe it

  makes your concepts clearer.

  Make the specification available both in hardcopy and electronic

  form. The hardcopy version should be formatted as a technical

  document and using a font that won't degrade badly when the spec is

  photocopied or faxed. Use a standard sized page layout so the spec

  isn't a hassle to fit in an envelope when mailed. The electronic

  version should be available as both ASCII text and PostScript files.

  Making the spec available in a word processing format (such as

  Microsoft Word or Framemaker) is nice, but not absolutely necessary.

  Consider making a developer's toolkit for your format. A collection

  of benchmark graphics files (one of each flavor of your format), and

  a parser written in ANSI C that reads and writes your format, is of

  tremendous help to programmers. Such a kit will allow developers to

  implement your format quickly in their products and helps minimize

  the chances of numerous software packages appearing which create

  graphics files that don't meet your spec. Examples of formats with

  toolkits include TIFF, TGA (Truevision), WordPerfect Graphics (WPG),

  and PNG.

  Submit your specification to every FTP/Gopher/WWW site and BBS that

  archives file format specs. Notify the maintainers of related FAQs

  (graphics, animation, multimedia, audio, medical, etc.) that your

  format exists and ask for a mention. Send your literature to graphics

  and imaging software companies to sell support of your format and/or

  software products.

And a few guidelines on good technical writing in general:

  Write in a tutorial style with explanations and examples of your

  topics. Don't just give a terse, dictionary description of a topic

  which often leaves the readers confused and needing more.

  Write in simple terms. Don't assume your readers enjoy 70-word

  sentences, or have advanced degrees in mathematics or computer


  Have other people read and attempt to understand your spec. Don't

  assume that just because you understand what you've written that

  every reader will too. You, as the file format specification's

  author, understand the format inside and out. Your readers, however,

  do not. An explanation that may seem clear to you may be just

  another confusing paragraph to your readers.

  Write for a world-wide audience of programmers. Omit slang or regional

  expressions that a developer living on the other side of the planet

  might not understand.

  Programs that check spelling and grammar are our friends. Use them.

Examples of some well-written format specs include: TGA, TIFF, PNG, EPSF,

and PostScript. Some specs are written well, but contain so much

extraneous information that they are quite complex and very tedious to

read. Most government and military formats are in this group (for example,

CALS, NITF, NAPLPS, IGES, GKS, and CGM). Format specs such as PCX, GIF,

JFIF, and Sun Raster definitely fall into the "don't let this happen to

you" catagory.


Subject: III. Working with Graphics Files on Usenet and the Internet


ubject: 0. How can I email a graphics file?

Normally you would move a file around the Internet using a data transport

program that handles binary data, such as UUCP and FTP. If you only have

an ASCII-only data transport mechanism available to you, such as

electronic mail, you will need to convert your binary graphics files to an

ASCII format before sending them. This process is only necessary for

binary files.  ASCII-based file formats, such as DXF and PostScript, do

not require uuencoding before emailing.

On the Unix operating system you will use a program called uuencode to

convert the 8-bit data of a graphics file to a 7-bit ASCII data file. The

data file is then emailed and uudecoded on the receiving end.

To uuencode and email a file:

  % uuencode picture.img picture.img | Mail

This command will pipe the output of the uuencode command to the input of

an email program. Realize that if your email program is set up to keep a

copy of all of the email you send, and you email a lot of uuencoded

graphics files, your outgoing email folder will grow quite large. You can

modify your .mailrc (or equivalent) file to route the copy of the outgoing

graphics file to /dev/null, or you can write-protect your outgoing mail

folder so the data can't be written:

  % chmod -w ~/Mail/mbox.out

  % uuencode picture.img picture.img | Mail

  /home/Mail/mbox.out: Permission denied

  % chmod +w ~/Mail/mbox.out

Once the emailed data is received, you will need to strip off the mailing

header before you can uudecode it. The uuencoded data starts with the word

"begin" and is followed by the file mode, file name, and a series of

61-character lines. The file is ASCII, so you can use an editor such as vi

to do the stripping. Assuming the received data is saved to a file named

"file", the uudecoing process is thus:

  % uudecode file

The original graphics file is now in the current directory. You may delete

the uuencoded file if you wish to do so.

The uuencode and uudecode programs have been ported to other systems, such

as MS-DOS, MS Windows, OS/2, Amiga, and the Macintosh (the BinHex program

for the Mac does not produce the same ASCII data as uuencode), and may be

used in the same way.

For more information on accessing the Internet via email, please refer to

the FAQ "Accessing The Internet By E-Mail: Doctor Bob's Guide to Offline

Internet Access", found on the news.answers and Usenet

newsgroups and your favorite FAQ archives.


ubject: 1. Where can I find graphics files on Usenet?

The vast majority of graphics files posted to Usenet will be found in the* newgroups. If you do not have access to Usenet,

then you will not be able to retrieve files posted to these groups.

For much more information on the* newsgroups, please

consult the FAQ (pictures-faq/part[1-3]) posted to

news.answers and


ubject: 2. How do I decode a graphics file posted to Usenet?

Graphics files are posted to Usenet as uuencoded binaries. Although you

may see files posted using BinHex or someother ASCII format, the uuencode

data format is the defacto standard of Usenet.

A graphics file may be contained in a single-part posting, which you will

save to a file, strip off the mailing header using a text editor, and use

the uudecode program to convert the data into the original graphics file.

Many online news readers will perform this operation for you.

Graphics files are usually quite large and uuencoding will increase the

file size by another 33%. For this reason, graphics files (and most binary

files) are split into 1000 line or 60KB chunks (multi-part postings) for

easier handling. If each chunk includes a shell wrapper (the string "[sh]"

usually appears in the Subject:  line of such postings), online news

readers, such as tin, can tag each part of the posting and decode it into

the original file for you. 

The most labor-intensive way to decode a multi-part uuencoded posting is to

save each part into a separate file, edit each file to remove the mailing

headers, concatenate them all into a single file, uudecode the file, and

delete the original parts:

  % vi picture.1 picture.2 picture.3

  % cat picture.1 picture.2 picture.3 | uudecode

  % rm picture.1 picture.2 picture.3

There are, of course, several utilities to decode single- and multi-part

binary posting for you without all this bother. Please refer to the FAQ (pictures-faq/part[1-3]) posted to news.answers

and for more information on decoding graphics files

posted to Usenet.


ubject: 3. How can I post a graphics file to Usenet?

Posting a graphics file to a Usenet newsgroup is very similar to emailing

a graphics file, but there are some important extra steps you must take in

order to do so.

First, a graphics file must be uuencoded. That is, converted from 8-bit

binary data to 7-bit ASCII data. Second, the resulting uuencoded file must

be split into 60K chunks (1000 lines) for posting. And lastly, each chunk

posted must be given a description and a part number.

Under Unix we would use the uuencode, split, expr, and inews commands to

post a graphics (or any binary) file as such:

  % uuencode picture.img picture.img > picture.img.uue

  % split -1000 picture.img.uue picture.img.uue.

  % ls

  Total 535

  picture.img        picture.img.uue    picture.img.uue.1  

  picture.img.uue.2  picture.img.uue.3

  % sh

  $ i=1

  $ for j in picture.img.uue.*; do

  > (echo "Subject: picture.img [$i/3]"

  > echo "Newsgroups: news.test

  > echo

  > cat $j) | /usr/lib/news/inews

  > i=`expr "$i" + 1`

  > done

  $ rm picture.img.*

  $ exit


In this example, we take a graphics file named picture.img, uuencode it,

and place the output in a file names picture.img.uue. This file is then

split into three chunks named picture.img.uue.1, picture.img.uue.2, and 

picture.img.uue.3.  We then loop through each file and create a Subject:

and Newsgroup: line for each of the file chunks and post them using inews.

There are, of course, programs which automate this process. One such

program is xmitBin, written by Jim Howard and availble via FTP from:

Refer to the FAQ (pictures-faq/part[1-3]) posted to

news.answers and for more information on posting

graphics files to Usenet.


ubject: 4. How do I submit a file format specification to an archive?

There are several FTP and WWW sites which act as archives for graphics

file format specifications (see the section "Graphics and Image File FTP

Archives and WWW Pages"). If you have a file format specification that is

legal to share with the rest of the world-wide Internet community, then

you may wish to submit it to one or more of these archives.

There are generally two ways to submit a file format specification to an

FTP archive:

  1) Upload (or "put") the file in the /incoming or /pub/incoming directory.

  2) Email the file to the archive maintainer (the email address is usually

     in the README or similar file in the root FTP directory).

Realize that most FTP sites don't allow unsolicited uploads and instead

require you to contact the archive maintainer to make a submission. Many

sites are simply mirrors for other archives and don't accepts any kind of

submissions at all. 

In any case, it's usually good form to include a description file with

your submission to describe in a few words what you have uploaded and

where it originated. If your upload is named foo.doc then the description

file should be named foo.txt. If your upload is named foo.txt, improvise.


ubject: 5. How can I make transparent and interlaced GIFs for a Web page?

Transparent GIFs are used to eliminate the typical rectangular borders

associated with most bitmapped images that appear on a Web page. The

creator of a GIF image may set certain pixels within the bitmap to a color

desiganted within the image file as "transparent". When this GIF image is

displayed by a Web browser the transparent pixels take on the color of the

user's display.  This is identical to the blue screen effect found in


GIF89a files are made transparent by the use of graphics file editing

software (GIF87a files do not support transparency and must first be

converted to the GIF89a format). Such software will set the transparency

color flag and the transparent color index value of a Graphics Control

Extension block within the GIF89a file. Any pixel set to the specified

transparent color index value will take on the background color of the

display device when displayed.

Interlaced GIFs are used to give the user a idea of that an image looks

like before all of the bitmapped data has been received. Non-interlaced

images paint in a linear fashion from the top to the bottom of the

display. Over a slow link it make take several minutes for an image to

paint. When 50% of the bitmapped data is received only the top half of the

image is displayed.  The contents bottom half is still a mystery to the


Interlaced GIFs paint quickly over the entire display first as a very low

resolution image. Only about 12.5% of the bitmap is displayed in this

first pass. The GIF image is then repainted in three more passes, with

each pass supplying more resolution until all of the data is received

(12.5%, 25%, and 50% respectively). A user can usually get a good idea of

what the entire image is when only 30-50% of the bitmapped data has been

received. This is very useful for knowing when to abort an image being

viewd via a slow link.

Interlacing is supported by both the GIF87a and GIF89a formats. Graphics

file editing software that supports interlaced GIF should not only be able

to display such GIF files, but also convert non-interlaced GIFs to the

interlaced format (and back again as well). This involves reading in the

GIF bitmap and writing it back out using the GIF 4-pass interlace scheme.

In a non-interlaced GIF the pixel lines are displayed in consecutive

order. For example, the lines of a 16-line non-interlaced GIF file are

stored as 0, 1, 2, 3, 4, 5...15. The lines of the same 16-line bitmap in

an interlaced GIF would be stored as 0, 8, 4, 12, 2, 6, 10, 14, 1, 3, 5,

7, 9, 11, 13, 15.

Graphics file format software packages for Unix which handles both

trasparent and interlaced GIFs include NETPBM and giftool.  For the

Macintosh:  Transparency, Graphic Converter, Imagery, and clip2gif

The Visioneering image manipulation page will allow you to convert your

GIFs to transparent and interlaced without having special software on your

system. Your GIF files will be read, converted, and written using the Web.

Visioneering's page is at:

More detailed information on images used in Web pages can be found in the

FAQ for the newsgroup comp.infosystems.www.authoring.images found at:

A collection of links to a number of Web and FTP resources that store

information on transparent and interlaced GIFs for Unix, Macintosh, and

MS-DOS/Windows, including executable programs and tutorials, may be found



ubject: 6. How do I combine still images to make animations?

You might have a collection of imaes and drawings stored in a variety of

still-image formats (TIFF, BMP, IFF, and so forth) and want to combine them

into an animation or video file format that wil allow you to play them back.

Have a look at the following Web page:


Subject: IV. Copyrights, Patents, and other Legalities of Graphics File



ubject: 0. Can a graphics file be copyrighted?

No. A graphics file cannot normally be copyrighted under United States

copyright laws (although the rulings of some judges may disagree on this).

The specification of a format and the contents of a graphics file,

however, are subject to copyright.

For anything to be copyrighted it must be:

  1) A work of authorship

  2) Fixed in a tangible medium of expression

The description of a graphics format does meet both of these criteria (it

is fixed in a medium and a work of authorship) and is therefore protected

under the copyright laws. A graphics file created using the format

description, however, meets the second criteria, but not the first (that

is, it is not considered to be a work of authorship). The format itself is

considered instead to be an idea or system, and is therefore not protected

by copyright.

So the description of a file format is copyrightable, but the format as it

exists in its medium is not. What about the graphics data that the file


If the graphical data written to a graphics file also meets the above two

criteria, then it is also protected by the copyright laws as intellectual

property. You will not wave your copyright protection by storing any

original information using a graphics file format.

For more information on copyright, please refer to the Copyright FAQ found

on the,,, and

comp.patents newsgroups:

Apparently, quite a number of copyright discussions also occur on the

comp.infosystems.www.* newsgroups as well.

Information on patents, copyrights, and intellectual property may be found


    Patent and trademark information

    U.S. Patent and Trademark Office

    Software Patent Institute


ubject: 1. Is it now illegal to use CompuServe's GIF format?

It is not illegal to own, transmit, or receive GIF files (provided that no

unlicensed compression and/or decompression of the files occurs). You must

realize, however, that GIF files are not the issue. The issue is, in fact,

the LZW data compression algorithm.

In 1984, while working for Sperry Corporation, Terry Welch modified the

Lempel-Ziv 78 (LZ78) compression algorithm for greater efficiency for

implementation in high-performance disk controllers. The result was the

LZW algorithm. The world was informed of the existence of LZW by the

following journal article, published by Mr. Welch after he left the

employment of Sperry:

  Welch, T. A., "A Technique for High Performance Data Compression,"

  IEEE Computer, Volume 17, Number 6, June 1984.

In 1985, Sperry Corporation was granted a patent (4,558,302) for the Welch

invention and implementation of the LZW data compression algorithm. Since

that time, this LZW patent has been publicly available for all to see in

the US Patent Office and many public libraries, and is available through

many on-line services.

In 1987, CompuServe Corporation created the GIF (Graphical Interchange

Format) file format to be used for the storage and on-line retrieval of

bitmapped graphical data. The GIF specification required the use the LZW

algorithm to compress the data stored in each GIF file. It is very

possible that CompuServe did not check the patent files to determine

whether the GIF format infringed on any patents. Such a check would have

found the Welch LZW patent, which was then owned by Unisys as a result of

their having purchased Sperry in 1986. At that time, Unisys also did not

know that LZW was the method of compression used by the very popular GIF

file format.

In 1988, Aldus Corporation released Revision 5 the TIFF file format. This

revision added a new feature giving TIFF the ability to store RGB

bitmapped data using either a raw format, or a compressed format using the

LZW algorithm. (Although the LZW algorithm used by TIFF is considered to

be "broken", it is still covered by the Unisys patent). Since 1991, in

accordance with their agreement with Unisys, Aldus has been required to

place a notice regarding the Unisys patent and its applicability to TIFF,

in Aldus documentation. The 1992 release of Revision 6 of the TIFF

specification includes this notice of the Unisys patent regarding LZW. The

TIFF Revision 6 specification also recommends against using LZW to

compress RGB bitmaps stored using the TIFF format.

In 1990, Unisys licensed Adobe for the use of the Unisys LZW patent for


In 1991, Unisys licensed Aldus for the use of the Unisys LZW patent in


In 1994, Unisys and CompuServe came to an understanding whereby the use of

the LZW algorithm would be licensed for the application of the GIF file

format in software. 

In 1995, America Online Services and Prodigy Services Company also entered

license agreements with Unisys for the utilization of LZW.  Published

information indicates that Unisys' licensing policies are as follows:

 1) Unisys considers all software created or modified before January 1,

    1995 that supports the GIF and/or TIFF-LZW formats to be

    inadvertently infringing upon its patent; Unisys will therefore not

    require a license for GIF software products delivered before January

    1, 1995. Unisys will therefore not pursue legal actions against such

    pre-1995 software products.

 2) However, Unisys expects developers of commercial or for-profit

    software to obtain a GIF-LZW license agreement from Unisys if, after

    December 31, 1994, the developer creates new software or updates or

    modifies existing software, or issues a new release of software that

    supports the GIF file format.

 3) Unisys does not require licensing of non-commercial, not-for-profit

    software applications that support the GIF file format.

 4) With respect to TIFF, if a license is entered before July 1, 1995, 

    there will be no liability for pre-1995 software with respect to

    that software's support of TIFF which uses LZW.

Unisys has drafted licenses for several different applications of the LZW

algorithm. The two license agreements of most interest in this FAQ are

applicable to software supporting the GIF file format alone and the

agreement applicable to software supporting both GIF and the TIFF file

format's LZW compression feature.

Realizing that you have many questions about GIF-LZW and TIFF-LZW

licensing, the remainder of this section is arranged in a Question/Answer

format to help convey information about this subject more clearly.

Q: Just what is this all about?

A: Unisys has asserted its claim to the ownership of the LZW compression 

   and decompression algorithm. If you wish to implement LZW in a software

   or firmware application, you must arrange to pay a small royalty to

   Unisys for every software package that you sell. You do this by applying

   to Unisys for an LZW license agreement for your software.

Q: What file formats are effected?

A: GIF, TIFF, PDF, and PostScript Level II. All of these formats use, or

   can use, LZW compression. For example, a TIFF or PostScript Level II

   file may or may not use the LZW algorithm to compress the data it

   contains. GIF files, and most PDF files, always store bitmap data that

   is compressed using LZW.

Q: How does this agreement affect my use of GIF and TIFF files?

A: It does not affect the ownership, transmission, or reception of GIF

   and TIFF-LZW files themselves. Only the software that performs 

   compression and/or decompression of GIF may be effected in any way

   by license agreements. You are free to store and transport GIF and

   TIFF-LZW files without fear of legalities or cost from the Unisys

   licenses provided that any compression and/or decompression on GIF

   files is performed by licensed software, or by software products

   delivered prior to 1995.

Q: Which agreement do I need?

A: If your software supports only GIF then you need the GIF-LZW agreement.

   If it supports TIFF-LZW or both GIF and TIFF-LZW then you need the 

   TIFF-LZW and GIF-LZW agreement.

Q: My software supports TIFF-LZW, but not GIF.

A: You still need to obtain the TIFF-LZW and GIF-LZW agreement.

Q: So if my software only supports non-LZW versions of TIFF and PostScript

   Level II I don't need to worry about obtaining a license agreement?

A: That is correct. Only software that is capable of using the LZW 

   algorithm requires an agreement. This includes all software that 

   supports the GIF file format.

Q: What about file compression programs such as compress, PKZIP, zoo, and

   lha? Don't they use LZW too?

A: Most file compression programs use the LZ77 algorithm for compressing

   text. The LZ77 compression algorithms (and several of its

   derivatives) predates LZW by several years and is covered by its own

   series of patents.  The predecessor to LZW, LZ78, is used primarily

   for compressing binary data and bitmaps. Any software that uses the

   LZ77 and/or LZ78 algorithms without the LZW improvement is not

   affected by the Unisys LZW patent.  Of the mentioned software

   packages, the Unix compress utility does use LZW and therefore

   requires a license.

Q: Doesn't IBM also hold a patent on LZW?

A: IBM was granted a patent (4,814,746) for use of LZW in disk drive 

   technology. This patent does not award ownership of LZW to IBM.

Q: Is there a chance that the Unisys patent is actually invalid?

A: In 1994, the U.S Patent Office reexamined the Welch patent and, on

   January 4th of that year, not only confirmed the patentability of the

   original 181 patent claims, but also confirmed that 51 claims added

   during the reexamination were also patentable.

Q: I have heard that the Welch patent only covers LZW compression and 

   not decompression. Is this true?

A: Many people who have read the patent claim that this is true. Unisys,

   of course, strongly maintains that the patent does cover LZW decompression,

   and will pursue legal action against unlicensed software which only

   performs LZW decompression. It is not clear (to the author of this text)

   if the 1994 patent reexamination specifically asserted the existence

   of the description of LZW decompression in the original Welch patent.

Q: But you can't patent a mathematical abstraction. Doesn't this also

   include algorithms implemented as computer software?

A: A patent grants the exclusive rights, title, or license to produce,

   use, or sell an invention or process. One or more algorithms may be

   applied using software to create an invention. It is this invention

   whose use is restricted by the patent and not the algorithm(s) involved.

   In the case of software, it seems that it is not very easy to separate

   the algorithm(s) from the invention itself. Use of the algorithm(s)

   would seem to imply use of the invention as well.

Q: I use LZW in my programs, but not for GIF or TIFF graphics. What should

   I do?

A: If you are not a business, and the programs are for your own personal

   non-commercial or not-for-profit use, Unisys does not require you to 

   obtain a license. If they are used as part of a business and/or you

   sell the programs for commercial or for-profit purposes, then you must

   contact the Welch Patent Licensing Department at Unisys and explain your 

   circumstances. They will have a license agreement for your application

   of their LZW algorithm.

Q: Where can I apply for a GIF-LZW, TIFF-LZW and GIF-LZW, PDF, PostScript 

   Level II, or any other LZW license?

A: You can write to:

     Welch Patent Licensing Department

     Unisys Corporation 

     Mail Stop C1SW19

     P.O. Box 500

     Blue Bell, PA 19424 USA

   Or fax:    215.986.3090

   Or email:

   General licensing information may also be obtained from the home page

   of the Unisys Web Server:

Q: How much does a license cost?

A: The terms and cost of the license policy has changed since its

   introduction in 1995. Contact Unisys for the latest LZW licensing terms.

Q: Do I need a separate license for each GIF-using software product I sell?

A: If you sell three products that all use the GIF format, for example,

   then you will need only one license. License fees must be paid for

   each product sold.

Q: Do I need to obtain a new license if I release a new version of my


A: No. However, a license fee is required for each update, improvement,

   or enhancement of your software that is sold.

Q: What if I give my software away?

A: If you distribute for free your product directly to end-users for their

   personal use and your distributing the software is non-commercial and

   not-for-profit use and you receive no financial gain (such as Shareware

   donations, royalties for CD-ROM distributions, or as advertising to 

   attract for-profit business), then you do not need a license.

Q: But what about Shareware donations?

A: Each Shareware "payment" you receive is considered the selling price of

   that unit. Whatever a user pays to you for your GIF-using software is

   required to be included in your quarterly license fee payment to Unisys.

   However, minimum license fees per unit must be always paid.

Q: My Shareware GIF software is being sold for-profit on a CD-ROM, but I do

   not make any profit from its sale. Can I get in trouble? Do I need a 


A: The person/business that is selling your program for profit on their

   CD-ROM is responsible for obtaining the proper license. You would only

   need a license if you received any payments from the CD-ROM vendor or

   from users of your Shareware.

Q: I do not live in the United States and my software is not available

   there. Do I still need to obtain a license agreement?

A: Yes, you do. The Unisys patent has many foreign counterparts and the

   legalities of using LZW apply to most other countries in addition

   the US.

Q: What will happen to me if I continue to revise my GIF-using software,

   sell it for profit, and yet not bother to obtain a license?

A: Most likely, when your unlicensed program is discovered by Unisys,

   you will be notified of your need to obtain a license for your product.

   If you then fail to obtain the proper license, Unisys may seek an 

   injunction against your product including damages. You could also be 

   charged with willful infringement, which could result in treble damages.

Q: On what Usenet newsgroups is this LZW agreement being discussed?

A: You will find threads appearing on and other related

   graphical newsgroups. The official newsgroup where much discussion

   takes place is alt.gif-agreement. You might also find information on

   the,, and comp.patents newsgroups.

Q: Where can I get a copy of the Unisys patent?

A: Copies of patents may be found in public libraries or be obtained

   directly from the U.S. Patent Office. The patent is also available

   at many Internet sites, including:

Q: What are my alternatives to GIF and TIFF-LZW file formats?

A: A good alternative to LZW for compressing ASCII data is the LZ77

   algorithm used by the zip and PKZIP file archivers and the gzip

   (GNU zip) file compression program. The most popular alternative for

   multi-bit image data is the JPEG compression algorithm and the JFIF

   and SPIFF file formats. JFIF and SPIFF-JPEG files are smaller and

   store far more colors than GIF files.

   Another newer alternative is the PNG format, which is currently under

   development (see the section "PNG - Portable Network Graphics" in

   Part 3 of this FAQ). PNG is unencumbered by patent licenses and has

   much potential and promise in replacing GIF. But, most software that

   supports PNG will likely have been written after January 1, 1995, so

   make sure that your GIF-to-PNG conversion program has the proper

   Unisys license.

Q: Will Unisys' actions hurt the use of GIF?

A: Yes it will. People will continue to write software that supports GIF

   only if their customers demand it. The licensing will hasten the

   eventual demise of GIF, as both people and companies will be more

   motivated to standardize on "free" formats, such as JFIF, SPIFF, PNG, 

   BMP, and TGA.

Q: This agreement is bogus! I refuse to ever use GIF again!

A: As an end-user you are free never to read, write, or archive another

   LZW-encoded file as long as you live. As a developer you are only

   free of the legal implications of the Unisys patent if you remove any

   LZW code from your programs, including those shipped to your customers

   after 1994.

Q: Wait! I have more questions!

A: Contact the Welch Patent Licensing Department at the aforementioned

   addresses. I (the author of this FAQ) am not an employee nor legal

   representative of Unisys. You can also find this information on the

   Unisys web page:

   And in the following InfoWorld article:

   "Graphics file format patent Unisys seeks royalties from GIF developers",

   Karen Rodriguez, InfoWorld, Jan 09, 1995 (Vol.17, Issue 02, p3)

   And the following Web pages are devoted to this issue:

Disclaimer: The information in this FAQ regarding the Unisys LZW

licensing agreement has been presented in an attempt to allow the

reader to understand some of the legalities they may face by the use

of the LZW algorithm. The author has rendered this explanation and

example questions using the most accurate information available to

him at the date of this FAQ. In no regard should this text be

considered an official publication of Unisys Corporation or a legal

representation of the policies of Unisys, or in any way obligating

Unisys to enter into a license agreement based upon the terms,

interpretations, and/or answers to question provided in this text.


Subject: V. Graphics Formats Misnomers, Misgivings, and Miscellany


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


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:

    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



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 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]


Subject: VI. Graphics File Resources


ubject: 0. File Format Specifications FTP Archives and WWW Pages

The following anonymous FTP and WWW sites are known to archive file format

specifications and information. These documents may be official releases

of specifications by the creator/caretaker of the formats, or information

transcribed by people from various sources and released onto the net,

possibly without permission from the format's owner.


ubject: 1. Graphics and Image File FTP Archives and WWW Pages

The following anonymous FTP sites are known to archive image, graphics,

and multimedia files and information:

    NASA/Ames Archives. Space images in GIF format.

    VistaPro graphics

    FLI and FLC animations

    FLIC and QuickTime movies and many GIF and JPG images

    Fractal animation files{2M,100K}

    Digital Elevation Model (DEM) and Digital Line Graph (DLG) archives

    PNG images

    GIF, JPEG, and POV scene files rendered using PovRAY


    San Diego Supercomputer Center sound and image file archives

    MPEG, JPEG, FLC, HDF, AF, VR, and GIF files.

    Also /pub/pictures and /pub/comics contain many images

    Animation and multimedia files in MPEG, QuickTime, AVI, and FLI formats

    Adobe Illustrator resources and tips

    MRI and CT scan volume data of human anatomy

    Smithsonian Institution photoimage archives

    POV animation files

    USENIX faces archive (contains thousands of different faces)

    Red's Nightmare (a ray-traced animation)

    Space animation files

    Various Amiga anims (also on other aminet sites)

    GIF and JPEG files

    JBIG, CCITT, and other test images

    POV-Ray Hall Of Fame ray tracing graphics archive

    Space images in GIF format

    Digital Elevation Model (DEM) and Digital Line Graph (DLG) archives

    Digital Elevation Model (DEM) and Digital Line Graph (DLG) archives

    Graphics and MPEG file collection

    NASA images in GIF, JPEG, PostScript, Sun Raster, and X Bitmap formats

The following WWW sites are known to archive image, graphics, and

multimedia files:

    European Network of Excellence in Computer Vision

    Mat Carr's animations

    Galileo Mission to Jupiter Images

    Links to many site with ray-traced graphics

    Index to Multimedia Information Resources

    NYU State Center for Advanced Technology

    Informedia Digital Video Library Project

    Internet Font Archive (IFA)

    Thant's Animation index

    Listings of imaging resources and archive sites

    POV-Ray Hall Of Fame ray tracing graphics archive

    WebLouvre - Using and troubleshooting the web

    Kai's Power Tips and Tricks for Photoshop

    Various MPEG animations

    Scientific visualization and graphics

    DTP Internet Jumplist. Links to many desktop publishing pages.

    MPEG animations done using hierarchical b-splines

    Demon Internet

    NASA Dryden Research Aircraft Photo Archive

    Liquid Mercury's new WWW Site designed for "New Media" professionals.

    Current industry data and product profiles. Email:

    Galileo Mission to Jupiter Images

    Kodak Sample Digital Images archive


    Kodak Image Archive Sites

    3DWEB - World Wide Web site for 3D Computer Graphics

    Picker Graphic Workstations

    Web3D - World Wide Web site for 3D Graphics

    A gallery collection of fractal artwork by Ken Musgrave

    State51 Interactive Media

    Large collection of 3D models

    VRML Repository

    Many links to 3D Technology topics


ubject: 2. Internet Mailing Lists for Graphics and Imaging

This section contains a listing of Internet mailing lists that often

contain discussions and information on graphics and image file formats.

Mailing lists are a good alternative form of communication for those

netters that do not have Usenet access.

    Discussion of all aspects of image processing. To subscribe:

    send an email message to with the body

    "join agocg-ip yourfirstname yourlastname".

    Discussion of digital video, mostly of the desktop variety.

    To subscribe: send an email message to

    with the body: "subscribe digvid-l yourfirstname yourlastname".

    Discussion regarding the establishment of a set of TIFF tags for

    storing geographic map projection information, such as UTM zones,

    Lambert Standard parallels, etc. Participants include

    representatives from SPOT, Intergraph, ERDAS, ESRI, and USGS. To

    subscribe: send an email message to

    GraphUK mailing list. Discussion of graphics systems such as PHIGS 

    and GKS, and training in the area of graphics. To subscribe: send an

    email message to with the body "subscribe


    Adobe Illustrator mailing list. Discussion of the Adobe Illustrator 

    application and issues related to its use. To subscribe: send an email

    message to with the body "subscribe illstrtr-l".

    SPIE's Electronic Imaging Listserver. Discussion of electronic imaging.

    To subscribe: send an email message to with

    the body "SUBSCRIBE INFO-EI". A complete listing of SPIE's online

    services may be obtained by sending email to

    with the word HELP in the message body.

    Discussion of Atari computer graphics, hardware, software, programming,

    and formats for graphics and animation (2D and 3D). To subscribe: send

    an email message to with the body

    "subscribe youremailaddress".

    Information on the Kodak Photo-CD format. To subscribe: send an

    email message to with the body:


    NIH image processing discussion. To subscribe: send an email message

    to with the body "subscribe nih-image 

    yourfirstname yourlastname". You may seach past messages of this list

    by using


    Medical imaging discussion. To subscribe: send an email message

    to with the body

    "subscribe medimage".

    Nuclear medicine and medical imaging discussion. To subscribe: 

    send an email message to with the

    body "subscribe nucmed".

    Photographic and imaging discussions of aesthetics, processes

    instructional strategies, techniques, criticism, equipment, history,

    electronic imaging, ethics, and educational topics. To subscribe: send

    an email message to LISTSERV@LISTSERVER.ISC.RIT.EDU with the body

    "SUBSCRIBE PhotoForum yourfirstname yourlastname".

    British Machine Vision Association newsletter for machine vision,

    image processing, pattern recognition, remote sensing, etc. To

    subscribe: send an email message to

    PNG file format mailing lists. These lists contain a general discussion

    of PNG, announcements related to PNG, and discussions regarding PNG

    PNG implementation. To subscribe: send an email message to with "help" in the body.

    Discussion of image processing using The X Window System. To 

    subscribe send an email message to

    with the body "subscribe ximage".


ubject: 3. Books on Graphics File Formats

This section contains bibliographical listing of books containing

information on graphics file formats and closely related topics. This list

is alphabetized by title and information on how to order each book is

included where known.

And check out and to search for books using the Web.

  3D Graphics File Formats : A Programmer's Reference, Keith Rule,

    Addison-Wesley, 1996, ISBN 0-201488-35-3.

  The AutoCAD Database Book, F.H. Jones and L. Martin, Ventana Press,

    ISBN 0-940087-04-9. Order: 919.490.0062 voice.

  Bit-mapped graphics (2nd ed.), Steve Rimmer, Windcrest/McGraw-Hill

    1993. 484 pages.

  Bitmapped Graphics Programming in C++, Marv Luse, Addison Wesley 

    1993. ISBN 0-201632-09-8, $37.95 softcover and disk.

  CGM and CGI: Metafile and Interface Standards for Computer 

    Graphics, David B. Arnold and Peter R. Bono, Springer-Verlag

    1988. ISBN 3-540-18950-5, 279 pages.

  The CGM Handbook, Lofton R. Henderson and Anne M. Mumford,

    Academic Press 1993. ISBN 0-12-510560-6, $59.95 hardcover, 

    446 pages.

  Encyclopedia of Graphics File Formats, James D. Murray and 

    William vanRyper, 2nd ed., O'Reilly & Associates Inc. 1996.

    ISBN 1-56592-161-5, $79.95 softcover, 1154 pages.

    Order:, 800.998.9938 voice, 707.829.014 fax.

    Visit for more information.

  File Formats for Popular PC Software: A Programmer's Reference,

    Walden, Jeff, John Wiley & Sons, Inc. 1986. ISBN 0-471-83671-0, 

    287 pages.

  File Formats on the Internet: A Guide for PC Users, Allison B. Zhang,

    Special Libraries Assn., 1996, ISBN: 0-871114-41-0.

  File Format Handbook, Allen G. Taylor, Microtrend Books 1992.

  The File Format Handbook, Guenter Born, International Thomson Computer

    Press 1995. ISBN 1-850-32128-0, 1-85032-117-5, $79.95 hardcover,

    1274 pages. Order:,

  Graphical Treasures on the Internet, Bridget Mintz Testa, AP Profesional.

    ISBN 0-12-685375-4, $29.95US softcover, 428 pages.

    Order: or

  Graphics File Formats (2nd ed.), David C. Kay and John R. Levine, 

    Windcrest Books/McGraw-Hill 1995. ISBN 0-07-034025-0, $26.95 

    softcover, 476 pages.

    Order: Tab Software Department, Blue Ridge Summit, PA 17294-0850.

  Graphics File Formats: Reference and Guide, C. Wayne Brown and 

    Barry J. Shepherd, Manning Publications 1994.

  The Graphic File Toolkit: Converting and Using Graphic Files,

    Steve Rimmer, Addison-Wesley, 1992. 335 pages.

  High-Resolution Graphics Display Systems, Jon Peddie,

    Windcrest Books/McGraw-Hill 1994. ISBN 0-8306-4292-7, 

    ISBN 0-8306-4291-9 $34.95 softcover

  Inside Windows File Formats, Tom Swan, Sams Publishing 1993.

    ISBN 0-672-30338-8 $24.95 softcover, 337 pages and 1 disk (3.5 in.).               

    Order: Sams Publishing, 2201 West 103rd Street, Indianapolis,

    IN 46290

  Internet File Formats, Tim Kientzle, The Coriolis Group 1995.

    ISBN 1-883577-56-X $39.99 softcover, 398 pages and one CD.

    Order: 7339 E. Acoma Drive, Suite 7, Scottsdale, AZ 85260.

    800.410.0192, 602.483.0192

  The Internet Voyeur, Jim Howard, Sybex, 1995. ISBN 0-7821-1655-8.

    369 pages, $19.99 softcover + PC/Windows disk. More info at

  More File Formats for Popular PC Software: A Programmer's Reference,

    Jeff Walden, John Wiley and Sons 1987. 369 pages.

  Multimedia File Formats on the Internet: A Beginner's Guide for PC Users,

    Allison Zhang, Special Libraries Association 1995.

  PC File Formats & Conversions, Ralf Kussmann, Abacus 1990. 287 pages

    and 1 disk (5.25 in.).


  PC Graphics with GKS, P.R. Bono, J.L. Encarnacao and W.R. Herzner,

    Prentice-Hall 1990.

  PostScript Language Reference Manual, Adobe Systems Inc. (2nd ed.), 

    Ed Taft and Jeff Walden, Addison-Wesley 1990.

  The Programmer's PC Sourcebook, Thom Hogan, Microsoft Press, 1988.

  Programming for Graphics Files in C and C++, by John R. Levine, 

    John Wiley & Sons 1994. ISBN 0-471-59854-2, $29.95 softcover,

    494 pages. 

  Using Pcx Graphics Files: The Programmer's Definitive Guide to Pcx

    File Formats, Roger Stevens, Miller Freeman, 1996, ISBN 0-879304-32-4.

  Windows Undocumented File Formats: Working Inside Windows 3.X and Win 95,

    Pete Davis, Miller Freeman, 1997, ISBN 0879304375. 


ubject: 4. Magazine Articles on Graphics File Formats

This section contains bibliographical listings of periodicals containing

information on graphics file formats. This list is alphabetized by title.

  .mrb and .shg File Formats, Windows/DOS Developer's Journal, Pete Davis,

    February 1994 (Vol 5, No 4), pp. 37-46.

  The BMP File Format, Dr. Dobb's Journal, Marv Luse, #219 September

    1994 (Vol 19, Issue 10), pp. 18-22.

  The BMP File Format: Part I, Dr. Dobb's Journal, David Charlap, #228

    March 1995 (Vol. 20, Issue 3).

  The BMP File Format: Part II, Dr. Dobb's Journal, David Charlap, #229

    April 1995 (Vol. 20, Issue 4).

  Inside the RIFF Specification, Dr. Dobb's Journal, Hamish Hubbard, #219

    September 1994 (Vol 19, Issue 10), pp. 38-45.

  PCX Graphics, C Users Journal, Ian Ashdown, Vol 9, Num 8, August 1991,

    pp. 89-96.

  PNG: The Portable Network Graphic Format, Dr. Dobb's Journal, 

    Lee Daniel Crocker, #232 July 1995 (Vol 20, Issue 7), pp. 36-44.

  Portable Network Graphics, Web Techniques, Paul Atzberger and 

    Andrew Zolli, Vol 1. Issue 9, December 1996, pp. 65-70.

  Printing PCX Files, C Gazette, Marv Luse, Vol 5, Num 2, Winter 1990-91,

    pp. 11-22.

  Reading GIF Files, Dr. Dobb's Journal, Wilson MacGyver Liaw, #227 

    February 1995 (Vol 20, Issue 2), pp. 56-60.

  SPIFF: Still Picture Interchange File Format, Dr. Dobb's Journal, 

    James D. Murray, #249 July 1996 (Vol 21, Issue 7), pp. 34-41.


  TIFF File Format, C Gazette, James Murray, Vol 5, Num 2, Winter 1990-91,

    pp. 27-42.

  Translating PCX Files, Dr. Dobb's Journal, K. Quirk, Vol 14, Num 8, 

    August 1989, pp. 30-36, 105-108.

  Working with PCX files, Microcornucopia, Number 42, July-August 1988,

    p. 42.


Subject: VII. Kudos and Assertions


ubject: 0. Acknowledgments

The following people have made this FAQ take just a little bit longer to

read since the last time you looked at it (blame them and not me):

  Bruce Garner <>

  Oliver Grau <>

  John T. Grieggs <>

  Lee Kimmelman <>

  David Kuo <>

  Tom Lane <>

  Angus Montgomery <>

  Glen Ozymok <>

  Greg Roelofs <>

  Rsiw <>

  Daniel Sears <>

  Marc Soucy <>

  Bjoern Stabell <>

  Mark T. Starr <>


ubject: 1. About The Author

The author of this FAQ, James D. Murray, lives in the City of Orange,

Orange County, California, USA. He is the co-author of the book

Encyclopedia of Graphics File Formats published by O'Reilly and

Associates, makes a living writing books for O'Reilly, writing

telecommuncations network management software in C++ and Visual Basic,

and may be reached as,

or via U.S. Snail at: P.O. Box 70, Orange, CA 92666-0070 USA.


Subject: 2. Disclaimer

While every effort has been taken to insure the accuracy of the

information contained in this FAQ list compilation, the author and

contributors assume no responsibility for errors or omissions, or for

damages resulting from the use of the information contained herein.


ubject: 3. Copyright Notice

This FAQ is Copyright 1994-96 by James D. Murray. This work may be

reproduced, in whole or in part, using any medium, including, but not

limited to, electronic transmission, CD-ROM, or published in print,

under the condition that this copyright notice remains intact.


Part1 - Part2 - Part3 - Part4

Send corrections/additions to the FAQ Maintainer: (James D. Murray)

Last Update April 18 1999 @ 03:29 AM