|
Posted-By: auto-faq 3.1.1.2
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
jdm@ora.com. 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
forth?
2. Why should I care about previous versions of a file
format?
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
using?
7. How can I tell if a graphics file is corrupt?
8. What do I put in my own graphics file format
specification?
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
archive?
5. How can I make transparent and interlaced GIFs for a Web
page?
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
either?
2. Is it "Tag" or "Tagged" Image File
Format?
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"
formats?
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
Pages
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
at:
http://www.sandybay.com/pc-web/graphics_file_format.htm
------------------------------
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
formats.
------------------------------
ubject: 3. Where can I get the latest copy of this FAQ?
The latest revision of this FAQ is always available at
http://www.ora.com/infocenters/gff/gff-faq/. This FAQ is also
distributed monthly on the Usenet newsgroups comp.graphics.misc,
comp.answers, and news.answers as four separate files. It may also
be obtained via anonymous FTP from:
ftp://rtfm.mit.edu/pub/usenet/news.answers/graphics/
ftp://rtfm.mit.edu/pub/usenet/
To receive a copy of this FAQ via email, send an email message to
mail-server@rtfm.mit.edu 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:
uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part1
uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part2
uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part3
uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part4
Other sites on the World Wide Web that archive this FAQ include:
http://www.jazzie.com/ii/internet/faqs.html
http://www.cs.ruu.nl/wais/html/na-dir/graphics/fileformats-faq/.html
http://www.lib.ox.ac.uk/search/search_faqs.html
------------------------------
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
alt.binaries.pictures pictures-faq/part[1-3]
alt.graphics.pixutils 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]
mpeg-faq/part[1-8]
comp.dsp dsp-faq/part[1-3]
audio-fmts/part[1-2]
comp.fonts fonts-faq/part[1-2]
comp.graphics.misc graphics/faq
graphics/colorspace-faq
graphics/resources-list/part[1-3]
jpeg-faq/part[1-2]
comp.graphics.animation graphics/animation-faq
comp.graphics.rendering.raytracing graphics/raytrace-faq/part[1-2]
comp.infosystems.gis geography/infosystems-faq/part[1-2]
comp.infosystems.www.authoring.images
comp.multimedia comp-multimedia-faq
comp.speech comp-speech-faq/part[1-3]
comp.sys.sgi.misc sgi/faq/graphics
sci.data.formats sci-data-formats
sci.image.processing image-processing/Macintosh
sci/Satellite-Imagery-FAQ/part[1-5]
These FAQs may also be found the newsgroups alt.answers, comp.answers,
sci.answers, and news.answers, and in the FAQ archives at rtfm.mit.edu 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 http://rtfm.mit.edu/pub/usenet/news.answers/news-answers/introduction
To FTP any of these FAQs use the listed Archive-name with the following
FTP address:
ftp://rtfm.mit.edu/pub/usenet/news.answers/ [Archive-name]
To receive a copy of these FAQs via email, send an email message to
mail-server@rtfm.mit.edu 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 jdm@ora.com.
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 <guido@cnri.reston.va.us> or
<guido@python.org>.
You may obtain this FAQ from the Usenet newsgroups comp.dsp,
comp.answers, and news.answers, from the FTP archive sites:
ftp://ftp.cwi.nl/pub/audio/
ftp://rtfm.mit.edu/pub/usenet/news.answers/comp.dsp/
or via the Web page:
http://www.cwi.nl/ftp/audio/AudioFormats.part1
http://www.cwi.nl/ftp/audio/AudioFormats.part2
The FAQ for comp.speech may of also be of interest to audio people. It is
available at:
ftp://rtfm.mit.edu/pub/usenet/news.answers/comp-speech-faq/
ftp://svr-ftp.eng.cam.ac.uk/pub/comp.speech/FAQ-complete
------------------------------
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:
http://www.cm.cf.ac.uk/Ray.Tracing/index.old.html
The Ray Tracing Home Page
http://www.povray.org/rtn/
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
well.
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
information.
------------------------------
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 comp.graphics.misc
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
file.
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
corrupted.
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
graphics.
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 user@host.site
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 user@host.site
/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 alt.internet.services 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
alt.binaries.pictures.* 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 alt.binaries.pictures.* newsgroups, please
consult the alt.binaries.pictures FAQ (pictures-faq/part[1-3]) posted to
news.answers and alt.binaries.pictures.d.
------------------------------
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
alt.binaries.pictures FAQ (pictures-faq/part[1-3]) posted to news.answers
and alt.binaries.pictures.d 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:
ftp://ftp.cadence.com/utils
http://mrcnext.cso.uiuc.edu/~deej/index.html
Refer to the alt.binaries.pictures FAQ (pictures-faq/part[1-3]) posted to
news.answers and alt.binaries.pictures.d 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
chromakeying.
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
user.
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:
http://www.vrl.com/Imaging/
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:
http://www.island.net/help/faq/www_faq/
http://www.io.org/faq/www/index.html
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
at:
http://members.aol.com/htmlguru/transparent_images.html
http://dragon.jpl.nasa.gov/~adam/transparent.html
ftp://csi.jpl.nasa.gov/pub/graphics/
------------------------------
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:
http://www.prism.uvsq.fr/public/wos/multimedia/
------------------------------
Subject: IV. Copyrights, Patents, and other Legalities of Graphics File
Formats
------------------------------
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
contains?
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 misc.legal, misc.legal.computing, misc.int-property, and
comp.patents newsgroups:
ftp://rtfm.mit.edu/pub/usenet/news.answers/law/Copyright-FAQ/
ftp://rtfm.mit.edu/pub/usenet/news.answers/law/Copyright-FAQ/myths/
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
at:
http://www.questel.orbit.com/patents/readings.html
Patent and trademark information
http://www.uspto.gov
U.S. Patent and Trademark Office
http://www.spi.org
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
PostScript.
In 1991, Unisys licensed Aldus for the use of the Unisys LZW patent in
TIFF.
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: lzw_info@unisys.com
General licensing information may also be obtained from the home page
of the Unisys Web Server:
http://www.unisys.com/
http://www.unisys.com/ServerInformation/contact/contact.html
http://www.unisys.com/LeadStory/lzwfaq.html
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
software?
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
license?
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 comp.graphics.misc and other related
graphical newsgroups. The official newsgroup where much discussion
takes place is alt.gif-agreement. You might also find information on
the misc.legal.computing, misc.int-property, 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:
ftp://ftp.std.com/obi/USPatents/
ftp://ftp.uu.net/doc/literary/obi/USPatents/lzw-patent.Z
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:
http://www.unisys.com/LeadStory/lzwfaq.html
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:
http://www.lpf.org/Patents/Gif/unisys.html
http://www.lpf.org/Patents/Gif/Gif.html
http://www-cmpo.mit.edu/met_links/resources/LZW_patent.html
http://www.webhaven.com/izivkov/scanfax/GIF.HTM
http://rom.oit.gatech.edu/~willday/gif.html
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
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]
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.
ftp://avalon.viewpoint.com/pub/format_specs
ftp://ftp.cc.monash.edu.au/pub/graphics.formats
ftp://ftp.ncsa.uiuc.edu/misc/file.formats/graphics.formats
ftp://ftp.std.com/obi/Standards/Graphics/Formats
ftp://ftp.switch.ch/mirror/simtel/msdos/graphics/
ftp://ftp.uu.net/doc/literary/obi/Standards/Graphics/Formats
ftp://ftp.wustl.edu/doc/
ftp://mirrors.aol.com/pub/pc_games/programming/
ftp://peipa.essex.ac.uk/ipa/info/file.formats
ftp://titan.cs.rice.edu/pubic/graphics/graphics.formats
ftp://wuarchive.wustl.edu/graphics/graphics/mirrors/avalon/
ftp://x2ftp.oulu.fi/pub/msdos/programming/formats
http://ac.dal.ca/~dong/appen.html
http://dao.gsfc.nasa.gov/data_stuff/dataFormats.html
http://erau.db.erau.edu/~gonzalec/html/image.html
http://killy.shinshu-u.ac.jp/mawatar/dv/develop.html
http://sckb.ucssc.indiana.edu/kb/data/aamt.html
http://speckle.ncsl.nist.gov/~lst/cgm_std.htm
http://sslab.colorado.edu:2222/datastandards.html
http://topaz.sensor.com/work/fmt/
http://www.agocg.ac.uk:8080/agocg/cgm.html
http://www.cica.indiana.edu/graphics/3D.objects.html
http://www.cica.indiana.edu/graphics/image.formats.html
http://www.dcs.ed.ac.uk/~mxr/gfx
http://www.echo.lu/impact/oii/raster.html
http://www.hq.nasa.gov/office/oss/aisr/results/formats.html
http://www.matisse.net/files/formats.html
http://www.mcad.edu/guests/ericb/xplat.html
http://www.mediatel.lu/mmedia/render/h_formats.html
http://www.myo.inst.keio.ac.jp/FAQ/formats/image-formats.html
http://www.pi.net/~ayr/filefor1.htm
http://www.ru/gisa/english/cssitr/format/
http://www.soften.ktu.lt/~marius/graphics.html
http://www.tnt.uni-hannover.de/data/info/www/tnt/soft/sci/sig/image/fileformats/overview.html
http://www.tnt.uni-hannover.de/data/info/www/tnt/soft/sci/vis/compgraph/fileformats/overview.html
http://www.w3.org/hypertext/WWW/Graphics/Overview.html
http://www-ocean.tamu.edu/~baum/graphics-formats.html
------------------------------
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:
ftp://ames.arc.nasa.gov/pub/
NASA/Ames Archives. Space images in GIF format.
ftp://amiga.physik.unizh.ch/amiga/gfx/
VistaPro graphics
ftp://asterix.inescn.pt/pub/PC/
FLI and FLC animations
ftp://ftp.catt.ncsu.edu/pub/
FLIC and QuickTime movies and many GIF and JPG images
ftp://ftp.cnam.fr/Fractals/
Fractal animation files
ftp://edcftp.cr.usgs.gov/pub/data/DEM/250
ftp://edcftp.cr.usgs.gov/pub/data/DLG/{2M,100K}
Digital Elevation Model (DEM) and Digital Line Graph (DLG) archives
ftp://ftp.photodex.com/PNG/images
PNG images
ftp://ftp.povray.org/pub/povray/images
ftp://ftp.povray.org/pub/povray/scenes
GIF, JPEG, and POV scene files rendered using PovRAY
ftp://ftp.sdsc.edu/pub/sdsc/images
ftp://ftp.sdsc.edupub/sdsc/sound
San Diego Supercomputer Center sound and image file archives
ftp://ftp.sunet.se/pub/
ftp://ftp.sunet.se/pub/
MPEG, JPEG, FLC, HDF, AF, VR, and GIF files.
Also /pub/pictures and /pub/comics contain many images
ftp://ftp.tcp.com/pub/
ftp://ftp.tcp.com/pub/anime-manga/
Animation and multimedia files in MPEG, QuickTime, AVI, and FLI formats
ftp://ftp.netcom.com://pub/sjledet/illustrator/
Adobe Illustrator resources and tips
ftp://omicron.cs.unc.edu/pub/softlab/
MRI and CT scan volume data of human anatomy
ftp://photo1.si.edu/images
Smithsonian Institution photoimage archives
ftp://ftp.povray.org
POV animation files
ftp://src.doc.ic.ac.uk:/pub/packages/faces
USENIX faces archive (contains thousands of different faces)
ftp://ftp.uni-erlangen.de/pub/pictures/mpeg/LOCAL/RedsNightmare.tar
Red's Nightmare (a ray-traced animation)
ftp://ftp.univ-rennes1.fr/Images/ASTRO/
Space animation files
ftp://ftp.wustl.edu/pub/aminet/gfx/
Various Amiga anims (also on other aminet sites)
ftp://ftp.wustl.edu/multimedia/images/
GIF and JPEG files
ftp://nic.funet.fi/pub/graphics/misc/test-images/
JBIG, CCITT, and other test images
ftp://ftp.povray.org/pub/povray/Official/
POV-Ray Hall Of Fame ray tracing graphics archive
ftp://pubinfo.jpl.nasa.gov/
Space images in GIF format
ftp://spectrum.xerox.com/pub/map/
ftp://spectrum.xerox.compub/map/dlg
Digital Elevation Model (DEM) and Digital Line Graph (DLG) archives
ftp://src.doc.ic.ac.uk/gfx/
Digital Elevation Model (DEM) and Digital Line Graph (DLG) archives
ftp://sunsite.unc.edu/pub/multimedia/pictures
ftp://sunsite.unc.edu/pub/multimedia/animation
Graphics and MPEG file collection
ftp://toybox.gsfc.nasa.gov/pub/images
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:
http://afrodite.lira.dist.unige.it/
European Network of Excellence in Computer Vision
http://archpropplan.auckland.ac.nz/People/Mat/gallery/animations.html
Mat Carr's animations
http://ccf.arc.nasa.gov/dx/
http://ccf.arc.nasa.gov/galileo_probe/
Galileo Mission to Jupiter Images
http://www.cm.cf.ac.uk/Ray.Tracing/
Links to many site with ray-traced graphics
http://cui_www.unige.ch:80/OSG/MultimediaInfo/
Index to Multimedia Information Resources
http://found.cs.nyu.edu/
NYU State Center for Advanced Technology
http://fuzine.mt.cs.cmu.edu/im/informedia.html
Informedia Digital Video Library Project
http://jasper.ora.com:80/comp.fonts/Internet-Font-Archive/
Internet Font Archive (IFA)
http://mambo.ucsc.edu:80/psl/thant/thant.html
Thant's Animation index
http://netlab.itd.nrl.navy.mil/imaging.html
Listings of imaging resources and archive sites
http://www.povray.org/pub/povray/Official/
POV-Ray Hall Of Fame ray tracing graphics archive
http://scorch.doc.ic.ac.uk/~np2/multimedia/
http://sunsite.unc.edu/louvre/about/tech.html
http://mistral.enst.fr/louvre/about/tech.html
WebLouvre - Using and troubleshooting the web
http://the-tech.mit.edu/KPT/
Kai's Power Tips and Tricks for Photoshop
http://w3.eeb.ele.tue.nl/mpeg/index.html
Various MPEG animations
http://web.msi.umn.edu/WWW/SciVis/umnscivis.html
Scientific visualization and graphics
http://www.cs.purdue.edu/homes/gwp/dtp/dtp.html
DTP Internet Jumplist. Links to many desktop publishing pages.
http://www.cs.ubc.ca/nest/imager/imager.html
MPEG animations done using hierarchical b-splines
http://www.demon.co.uk/
Demon Internet
http://www.dfrc.nasa.gov/PhotoServer/photoServer.html
NASA Dryden Research Aircraft Photo Archive
http://www.infomedia.com:8600
Liquid Mercury's new WWW Site designed for "New Media" professionals.
Current industry data and product profiles. Email: info@infomedia.com
http://www.jpl.nasa.gov/galileo/
Galileo Mission to Jupiter Images
http://www.kodak.com/digitalImages/samples/samples.shtml
Kodak Sample Digital Images archive
http://www.kodak.com/digitalImaging/cyberScene/sites.shtml
Kodak Image Archive Sites
http://www.lightside.com/~dani/cgi/images-index.html
3DWEB - World Wide Web site for 3D Computer Graphics
http://www.picker.com/pgw
Picker Graphic Workstations
http://www.sd.tgs.com/~template
Web3D - World Wide Web site for 3D Graphics
http://www.seas.gwu.edu/faculty/musgrave/art_gallery.html
A gallery collection of fractal artwork by Ken Musgrave
http://www.state51.co.uk/state51/
State51 Interactive Media
http://www.viewpoint.com
Large collection of 3D models
http://www.webcity.co.jp/info/andoh/vrml/geom_trans.html
VRML Repository
http://www.wimsey.com/PhotoModeler/
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.
agocg-ip@mailbase.ac.uk
Discussion of all aspects of image processing. To subscribe:
send an email message to mailbase@mailbase.ac.uk with the body
"join agocg-ip yourfirstname yourlastname".
digvid-l@ucdavis.edu
Discussion of digital video, mostly of the desktop variety.
To subscribe: send an email message to listserv@ucdavis.edu
with the body: "subscribe digvid-l yourfirstname yourlastname".
geotiff@tazboy.jpl.nasa.gov.
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 geotiff-request@tazboy.jpl.nasa.gov.
graphuk@cs.man.ac.uk
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 graphuk-request@cs.man.ac.uk with the body "subscribe
graphuk".
illstrtr-l@netcom.com
Adobe Illustrator mailing list. Discussion of the Adobe Illustrator
application and issues related to its use. To subscribe: send an email
message to listserv@netcom.com with the body "subscribe illstrtr-l".
info-ei@spie.org
SPIE's Electronic Imaging Listserver. Discussion of electronic imaging.
To subscribe: send an email message to info-ei-request@spie.org with
the body "SUBSCRIBE INFO-EI". A complete listing of SPIE's online
services may be obtained by sending email to info-optolink-request@spie.org
with the word HELP in the message body.
lexicor@lexicor.com
Discussion of Atari computer graphics, hardware, software, programming,
and formats for graphics and animation (2D and 3D). To subscribe: send
an email message to lexicor-list-request@lexicor.com with the body
"subscribe youremailaddress".
listserv@info.kodak.com
Information on the Kodak Photo-CD format. To subscribe: send an
email message to listserv@info.kodak.com with the body:
"INFO PHOTO-CD".
listserv@soils.umn.edu
NIH image processing discussion. To subscribe: send an email message
to listserv@soils.umn.edu with the body "subscribe nih-image
yourfirstname yourlastname". You may seach past messages of this list
by using http://rsb.info.nih.gov/nih-image/faq.html#Searching
medimage@polygraf
Medical imaging discussion. To subscribe: send an email message
to listserv%polygraf.bitnet@mitvma.mit.edu with the body
"subscribe medimage".
nucmed@uwovax.uwo.ca
Nuclear medicine and medical imaging discussion. To subscribe:
send an email message to nucmed-request@uwovax.uwo.ca with the
body "subscribe nucmed".
PhotoForum@listserver.isc.rit.edu
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".
pixel@essex.ac.uk
British Machine Vision Association newsletter for machine vision,
image processing, pattern recognition, remote sensing, etc. To
subscribe: send an email message to pixel-request@essex.ac.uk.
png-list@dworkin.wustl.edu
png-announce@dworkin.wustl.edu
png-implement@dworkin.wustl.edu
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
png-list-request@dworkin.wustl.edu with "help" in the body.
ximage@expo.lcs.mit.edu
Discussion of image processing using The X Window System. To
subscribe send an email message to ximage-request@expo.lcs.mit.edu
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 http://www.books.com and http://www.amazon.com 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: order@ora.com, 800.998.9938 voice, 707.829.014 fax.
Visit http://www.ora.com/www/item/gffcd.html 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: sales@clbooks.com, http://www.clbooks.com
Graphical Treasures on the Internet, Bridget Mintz Testa, AP Profesional.
ISBN 0-12-685375-4, $29.95US softcover, 428 pages.
Order: mailto:app@acad.com or http://www.apnet.com/approfessional
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
http://infolane.com/infolane/deej/voyeur.html
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 <garner@tis.llnl.gov>
Oliver Grau <grau@tnt.uni-hannover.de>
John T. Grieggs <grieggs@netcom.com>
Lee Kimmelman <lee.kimmelman@twwde.com>
David Kuo <dkuo@dabulls.kodak.com>
Tom Lane <tgl@netcom.com>
Angus Montgomery <angus@cgl.citri.edu.au>
Glen Ozymok <oz@ludwig.virtualprototypes.ca>
Greg Roelofs <newt@uchicago.edu>
Rsiw <rsiw@aol.com>
Daniel Sears <sears@netcom.com>
Marc Soucy <msoucy@imetric.qc.ca>
Bjoern Stabell <bjoerns@acm.org>
Mark T. Starr <StarrMT@po4.bb.unisys.com>
------------------------------
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 jdm@ora.com,
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.
------------------------------
|
Comment about this article, ask questions, or add new information about this topic: