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

3 views
Skip to first unread message

j...@ora.com

unread,
Dec 4, 1996, 3:00:00 AM12/4/96
to

Posted-By: auto-faq 3.1.1.2
Archive-name: graphics/fileformats-faq/part1
Posting-Frequency: monthly
Last-modified: 01Dec96

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

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

This 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
j...@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?

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

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

Subject: 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

In case nobody noticed, there were no October or November releases
of the GFF FAQ. Too busy with other projects and not much new or
revised info to include. Starting next month the GFF FAQ will be
posted to Usenet every 60 days. I will continue to revise the GFF FAQ
on its Web site every month at:

http://www.ora.com/centers/gff/gff-faq/

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

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

o Revised a few product entries in part 2
o Revised a few file formats in part 3

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

Subject: 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.

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

Subject: 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/fileformats-faq
ftp://rtfm.mit.edu/pub/usenet/comp.graphics.misc

To receive a copy of this FAQ via email, send an email message to
mail-...@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
http://www.smartpages.com/faqs/graphics/fileformats-faq/


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

Subject: 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-...@rtfm.mit.edu with the body:

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

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

Subject: 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 j...@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.

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

Subject: 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.

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

Subject: 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.

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

Subject: 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
<gu...@cnri.reston.va.us>
or <gu...@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

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

Subject: 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.

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

Subject: 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.

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

Subject: 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.

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

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

[ Still working on this ]


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

Subject: 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

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

Subject: 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.

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

Subject: 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.

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

Subject: 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).

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

Subject: 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.

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

Subject: 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.

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

Subject: 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.

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

Subject: 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.

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

Subject: 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.

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

Subject: 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

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

Subject: 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 us...@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 us...@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.

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

Subject: 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.

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

Subject: 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.

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

Subject: 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.

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

Subject: 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.

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

Subject: 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.io.org/faq/www/index.html
http://www.vir.org/WWWfaq/index.html
http://www.island.net/help/faq/www_faq/

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://melmac.corp.harris.com/transparent_images.html
http://dragon.jpl.nasa.gov/~adam/transparent.html
ftp://csi.jpl.nasa.gov/pub/graphics/transparent.faq

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

Subject: 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

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

Subject: 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

http://www.uspto.gov
U.S. Patent and Trademark Office

http://www.spi.org
Software Patent Institute

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

Subject: 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: 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_...@unisys.com

General licensing information may also be obtained from the home page
of the Unisys Web Server:

http://www.unisys.com/

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://cs.columbia.edu/archives/mirror2/world-info/obi/USPatents/lzw-patent.gz
ftp://ftp.std.com/obi/USPatents/lzw-patent.Z
ftp://ftp.uu.net/doc/literary/obi/USPatents/lzw-patent.Z
ftp://gatekeeper.dec.com/.8/misc/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/lzwterms.html
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/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

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

Subject: 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.

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

Subject: 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


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

Subject: 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.

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

Subject: 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".

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

Subject: 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".

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

Subject: 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.

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

Subject: VI. Graphics File Resources

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

Subject: 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/graphic-formats
ftp://mirrors.aol.com/pub/pc_games/programming/formats
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/format_specs
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
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

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

Subject: 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/SPACE
NASA/Ames Archives. Space images in GIF format.

ftp://amiga.physik.unizh.ch/amiga/gfx/misc
VistaPro graphics

ftp://asterix.inescn.pt/pub/PC/flidemos
FLI and FLC animations

ftp://ftp.catt.ncsu.edu/pub/graphics
FLIC and QuickTime movies and many GIF and JPG images

ftp://ftp.cdrom.com/pub/aminet/pix
JPG, GIF, and Multimedia files

ftp://ftp.cnam.fr/Fractals/anim
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/graphics
ftp://ftp.sunet.se/pub/multimedia
MPEG, JPEG, FLC, HDF, AF, VR, and GIF files.
Also /pub/pictures and /pub/comics contain many images

ftp://ftp.tcp.com/pub/anime
ftp://ftp.tcp.com/pub/anime-manga/anim
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/CHVRTD
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 5592 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/anim
Space animation files

ftp://ftp.wustl.edu/pub/aminet/gfx/anim
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/images
Space images in GIF format

ftp://spectrum.xerox.com/pub/map/dem
ftp://spectrum.xerox.compub/map/dlg
Digital Elevation Model (DEM) and Digital Line Graph (DLG) archives

ftp://src.doc.ic.ac.uk/gfx/misc
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.best.com/~bryanw/index.html
The Graphics Archive

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.delphi.com/fx/fxscreen.html
fX Networks' Download Goodies promo videoclips in AVI and QT formats

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: in...@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

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

Subject: 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.

agoc...@mailbase.ac.uk
Discussion of all aspects of image processing. To subscribe:
send an email message to mail...@mailbase.ac.uk with the body
"join agocg-ip yourfirstname yourlastname".

digv...@ucdavis.edu
Discussion of digital video, mostly of the desktop variety.
To subscribe: send an email message to list...@ucdavis.edu
with the body: "subscribe digvid-l yourfirstname yourlastname".

geo...@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...@tazboy.jpl.nasa.gov.

gra...@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...@cs.man.ac.uk with the body "subscribe
graphuk".

illst...@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 list...@netcom.com with the body "subscribe illstrtr-l".

inf...@spie.org
SPIE's Electronic Imaging Listserver. Discussion of electronic imaging.
To subscribe: send an email message to info-ei...@spie.org with
the body "SUBSCRIBE INFO-EI". A complete listing of SPIE's online
services may be obtained by sending email to info-optol...@spie.org
with the word HELP in the message body.

lex...@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-li...@lexicor.com with the body
"subscribe youremailaddress".

list...@info.kodak.com
Information on the Kodak Photo-CD format. To subscribe: send an
email message to list...@info.kodak.com with the body:
"INFO PHOTO-CD".

list...@soils.umn.edu
NIH image processing discussion. To subscribe: send an email message
to list...@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%polygra...@mitvma.mit.edu with the body
"subscribe medimage".

nuc...@uwovax.uwo.ca
Nuclear medicine and medical imaging discussion. To subscribe:
send an email message to nucmed-...@uwovax.uwo.ca with the
body "subscribe nucmed".

Photo...@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 LIST...@LISTSERVER.ISC.RIT.EDU with the body
"SUBSCRIBE PhotoForum yourfirstname yourlastname".

pi...@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-...@essex.ac.uk.

png-...@dworkin.wustl.edu
png-an...@dworkin.wustl.edu
png-im...@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...@dworkin.wustl.edu with "help" in the body.

xim...@expo.lcs.mit.edu
Discussion of image processing using The X Window System. To
subscribe send an email message to ximage-...@expo.lcs.mit.edu
with the body "subscribe ximage".

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

Subject: 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 to search for books using the Web.

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: or...@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 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: sa...@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:a...@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.

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

Subject: 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.

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

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

Subject: 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 <gar...@tis.llnl.gov>
Oliver Grau <gr...@tnt.uni-hannover.de>
John T. Grieggs <gri...@netcom.com>
Lee Kimmelman <lee.ki...@twwde.com>
David Kuo <dk...@dabulls.kodak.com>
Tom Lane <t...@netcom.com>
Angus Montgomery <an...@cgl.citri.edu.au>
Glen Ozymok <o...@ludwig.virtualprototypes.ca>
Greg Roelofs <ne...@uchicago.edu>
Rsiw <rs...@aol.com>
Daniel Sears <se...@netcom.com>
Marc Soucy <mso...@imetric.qc.ca>
Bjoern Stabell <bjo...@acm.org>
Mark T. Starr <Sta...@po4.bb.unisys.com>

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

Subject: 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 j...@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.

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

Subject: 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.

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


j...@ora.com

unread,
Dec 4, 1996, 3:00:00 AM12/4/96
to

Posted-By: auto-faq 3.1.1.2
Archive-name: graphics/fileformats-faq/part3
Posting-Frequency: monthly
Last-modified: 01Dec96

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

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

This 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
j...@ora.com. Relevant information posted to newsgroups will not
automatically make it into this FAQ.

-- James D. Murray

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

Subject: 0. Contents of Where to Get File Format Specifications

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?

II. Where to Get File Format Specifications

3DMF - QuickDraw 3D Metafile
3DS - Autodesk 3D Studio
ABF - Adobe Binary Screen Font
ADI - AutoCAD Device-Independent Binary Plotter Format
AFM - Adobe Font Metrics File Format
AI - Adobe Illustrator File Format
ART - Another Ray Tracer
Atari ST Graphics File Formats
AVS - Application Visualization System
AWD - Microsoft Fax At Work Document
BDF - Adobe Glyph Bitmap Distribution Format
BIN - SGI Powerflip
BMP - Windows Bitmap Format
BRender
BRL-CAD - Ballistic Research Laboratory CAD
BUFR - Binary Universal Form for the Representation of Meteorological Data
BYU - BYU Movie
CAD-3D
CALS - Computer Aided Acquisition and Logistics Support Raster Format
CAM - Casio Camera
CCITT - CCITT Group 3 and Group 4 Encoding
CDF - Common Data Format
CDF - Cyberspace Description Format
CDL - CADKey CADL Language
CGM - Computer Graphics Metafile
CIF
CMP - LeadView
CMU - Carnegie Mellon University Formats
COB - Calgari trueSpace2 File Format
CXS
Cyberware
DEM - Digital Elevation Model
DGN - Microstation
DKB - DKB-Trace
DLG - Digital Line Graph
DPX - Digital Moving Picture Exchange
DRW - Micrografx Designer/Draw Plus Format
DWB - Coryphaeus Software Designers Workbench
DWG - Autodesk drawing
DXF - Autodesk Drawing eXchange Format
EMF - Microsoft Enhanced Metafile
ENFF - Extended Neutral File Format
EPS - Encapsulated PostScript
FACT
FBM - Fuzzy Bitmap
FFIVW - File Format for the Interchange of Virtual Worlds
FITS - Flexable Image Transport System
FLASHPIX
FLT - MultiGen Flight
GDS - McDonnell-Douglas Things
GFO - SGI Radiosity
GIF - Graphics Interchange Format
GKS - Graphics Kernel System
GrADS - Metafile
GRASP - Graphical System for Presentation
GRIB - Gridded Binary
HDF - Hierarchical Data Format
HDS - Hierarchical Data System
HPGL - Hewlett-Packard Graphics Language
HPPCL - Hewlett-Packard Printer Control Language
HRF - Hitachi Raster Format
IFF - Electronic Arts Interchange File Format
IGES - Initial Graphics Exchange Specification
IM - Performer
IMA - Zenographics Mirage Graphics File Format
IMJ - Image JPEG
INGR - Intergraph Raster File Format
IRTP - Graphicon-2000 Interactive Real-Time PHIGS
IV - SGI Inventor
IV-VRML - Inventor VRML Format
JBIG - Joint Bilevel Image Group
JCAMP
JFIF - JPEG File Interchange Format
LSA/LSB - Lightscape Technologies ASCII and Binary
LWOB - Lightwave Object Format
MedFileS
MGF - Materials and Geometry Format
MIFF - Magick Image File Format
MNG - Multiple Network Graphics
MSDL - Manchester Scene Description Language
MTL - Wavefront
NAPLPS - North American Presentation Layer Protocol Syntax
netCDF - Network Common Data Format
NFF - Haines Neutral File Format
NFF - WorldToolKit Neutral File Format
NITF - National Imagery Transmission Format
OBJ - Wavefront Object
ODIF - Open Document Interchange Format
ODL - Object Description Language
OFF - Object File Format
OpenMath
PBM - Portable Bitmap
PCX - ZSoft Paint
PDF - Portable Document Format
PDS - Planetary Data System Format
PGM - Portable Greymap
PHD - PolyHedra Database
PIC - Lotus PIC Graphics Format
PIC - Micrografx Draw! Graphics Format
PIC - Pegasus Imaging Corporation Format
PIC - Video Show Graphics Format
PICT - Macintosh Picture
PIX - Inset Pix
PLY - ZipPack


PNG - Portable Network Graphics

PPM - Portable Pixmap
POL - InnovMetric Software Polygon Models Format
POV - Persistence of Vision Raytracing
PS - PostScript
PSD - Adobe Photoshop
PTU - Performer Terrain Utilities
QT - QuickTime
QTVR - QuickTime VR
RAD - Radience
RAS - Sun Rasterfile
RAW - Photoshop RAW
RAY - Rayshade
RFT-DCA - Revisable-Form Text Document Content Architecture
RIB - Renderman Interface Bytestream
RIFF - Microsoft Resource Interchange File Format
RIX - ColoRIX Image File
RTF - Rich Text Format
RWX - MEME Shape File
RWX - Criterion RenderWare
S1K - S1000 Simnet Format
SAF - Standard Archive Format
SAIF - Spatial Archive Interchange Format
SAT - ACIS
Scene
Scitex HandShake Formats
SCN - SCeNe RTrace
SDL - Alias Wavefront Scene Description Language
SDML - Spacial Data Modeling Language
SDTS - Spatial Data Transfer Standard
SFF - Scene File Format
SGI - Silicon Graphics Image File Format
SHG - Segmented Hyper-Graphic
Softimage
SPIFF - Still Picture Interchange File Format
STL - Stereolithography Interface Format
TDDD - Imagine Object File Format
TGA - Truevision (Targa) File Format
TIFF - Tag Image File Format
TRIF - Tiled Raster Interchange Format
TTF - TrueType Font
Type 42 Font Format
URT - Utah Raster Toolkit
VCA - Visual Clip Art
VICAR - Video Image Communication and Retrieval
VIFF - Visualization Image File Format
VIT - VITec Scanner Raster Format
VPF - Vector Product Format
VRML - Virtual Reality Modeling Language
WebOOGL - Web Object Oriented Graphics Library
WMF - Windows Meta File
WPG - WordPerfect Graphics Metafile
X3D - x3d and xdart Formats
XBM - X BitMap
XOF - RenderMorphics
XPM - X PixMap
WSQ - Wavelet-packet Scalar Quantization Format
XWD - X Window Dump

III. Document Sources

0. U.S. Government and Military Standards Sources
1. International Standards Document Sources
2. Commercial Document Sources
3. Other Standards Sources

IV. Kudos and Assertions

0. Acknowledgments
1. About The Author
2. Disclaimer
3. Copyright Notice


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

Subject: I. General questions about this FAQ

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

Subject: 0. Maintainer's Comments

One of the reasons you are looking through this FAQ collection is most
likely to locate the specification for one or more graphics file formats.
That assumption on my part makes this file one of the most important parts
of the Graphics File Formats FAQ collection. I therefore wish to make this
section as complete as possible.

If you have any suggestions for formats to include then please email me at
j...@ora.com and let me know!

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

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

o Updated PNG and several Adobe URLs
o Added AI, MNG, RFT, RTF, DRW, IMA, PIC, PIC, and PIC

Many of the new sections added have not been completely filled in yet.
Hopefully I'll have it finished in a near future release.

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

Subject: II. Where to Get File Format Specifications

This section contains an alphabetical listing of file formats, the
names of the creators/caretakers, and where to obtain the official
specifications, and a brief description of each format.

If you are searching for detailed information on the internals of a
file format, then I suggest you check out the resources listed here,
and have a look at the books and journals articles listed in Part 1
of this FAQ.

Each format section contains a common header that is a quick reference to
the file format.

Type: Bitmap, Vector, Metafile, 3D, VRML, general data, PDL, multimedia
Extension: File extension(s) or type
Version: Latest version number
Compression: All supported compression methods
Color Depth: Pixel depth and maximum number of colors supported
Maintainer: Who created and/or maintains the format
Specification: Where to get a copy of the format

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

Subject: 3DMF - QuickDraw 3D Metafile

Type: 3D
Extension: 3DMF
Version:
Compression:
Color Depth:
Maintainer: Apple Computer
Specification: http://product.info.apple.com/qd3d/3DMFspec.HTML
http://www.mediatel.lu/mmedia/render/files/3DMF.pdf

Apple's 3D Metafile is a format used for the storage and interchange of
3D data.

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

Subject: 3DS - Autodesk 3D Studio

Type: 3D
Extension: 3ds
Version:
Compression:
Color Depth:
Maintainer: Autodesk
Specification: http://www.mediatel.lu/mmedia/render/h_3ds.html
http://www.mediatel.lu/mmedia/render/h_3DS_details.html
http://homepage.eznet.net/~frac/3dsform.txt

3DS is the native file format of Autodesk's 3D Studio program.
3D Studio is an interactive 3D modeling, rendering and animation
package from the makers of AutoCAD. 3DStudio runs under MS-DOS
and is used to create three-dimensional, photo-realistic images
for a variety of applications.

You can find Autodesk's home page and ftp site at:
http://www.autodesk.com/
ftp://ftp.autodesk.com/

Other 3D Studio Web pages include:

http://homepage.eznet.net/~frac/3ds.html
FRiC's 3D Studio Web Page

http://www.armory.com/~gandalf/3dsfaq.html
3DS Interactive FAQ

http://www.det.mun.ca/staff/gporter/3dsfaq.htm
3D Studio FAQ

And other 3D Studio information can be found on the
comp.graphics.packages.3dstudio Usenet newsgroup.

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

Subject: ABF - Adobe Binary Screen Font

Type: bitmap font
Extension: abf
Version: 2.0
Compression: None
Color Depth:
Maintainer: Adobe Systems
Specification: http://www.adobe.com/supportservice/devrelations/PDFS/TN/5006.ABF_Spec.pdf

ABF is Adobe Systems' binary screen font format. ABF is, in fact, the binary
version of the Adobe's ASCII-based Glyph Bitmap Distribution Format (BDF).
Each ABF file is a sequence of 8-, 16-, or 32-bit words in either big- or
little-endian order. Each file stores information for one font.

The specification for the ABF format is:

Adobe Binary Screen Font Files Specification (Version 2.0),
Adobe Developer Support, 31 March 1992, P/N LPS5006.

This document available via FTP as a Tech Note in PostScript format,
or as hardcopy when obtained directly from Adobe (see the PostScript
section for information on how to contact Adobe Systems, Inc.).

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

Subject: ADI - AutoCAD Device-Independent Binary Plotter Format

Type: Vector
Extension: adi
Version:
Compression: None
Color Depth:
Maintainer: Autodesk
Specification:

ADI is a plotter file format generated by AutoCAD. They are rendered as
monochome bitmaps when viewed on a display. Information on ADI may be found
in the AutoCAD Installation and Performance Guide.

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

Subject: AFM - Adobe Font Metrics File Format

Type: font metric
Extension: afm
Version: 4.0
Compression: None
Color Depth: N/A
Maintainer: Adobe Systems
Specification: ftp://ftp.adobe.com/pub/adobe/DeveloperSupport/TechNotes/PSfiles/5004.AFM_Spec.ps

AFM is Adobe's ASCII-based file format used for storing font metric data as
human-readable data. AFM is the standard Adobe font file format.

This format is also known as the Adobe Multiple Font Metrics (AMFM) and
Adobe Composite Font Metrics (ACFM) file formats. In fact, AFM, AMFM, and
ACFM are actually three variations of the same format. AFM files contain
base or composite font information. One AFM file is used per master design
of a font. AMFM files store control and global font information for a
group of AFM files. And ACFM files contain the global metrics of the
composite font program.

The specification for the AFM format is:

Adobe Font Metrics File Format Specification (Version 4.0),
Adobe Developer Support, 14 February 1992, P/N LPS5004.

This document available via FTP as a Tech Note in PostScript format, or as
hardcopy when obtained directly from Adobe (see the PostScript section for
information on how to contact Adobe Systems, Inc.).

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

Subject: AI - Adobe Illustrator File Format

Type: Metafile
Extension: ai
Version: 3.0
Compression:
Color Depth:
Maintainer: Adobe Systems
Specification: http://www.adobe.com/supportservice/devrelations/PDFS/TN/5007.AI_Spec_v3.0_Draft.pdf

Native file format of Adobe Illustrator. AI is actually a varitaion of the
Adobe Encapsulated PostScirpt (EPS) format.

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

Subject: ART - Another Ray Tracer

Type: 3D
Extension: art
Version:
Compression:
Color Depth:
Maintainer: Tom Wilson &lttw...@sunny5.dab.ge.com&gt
Specification:

Native file format of the RAT (Another Ray Tracer) ray tracing package
included with the VORT ray tracing package.


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

Subject: Atari ST Graphics File Formats

Type: Bitmap and animation
Extension: .ANI, .ANM, .CE?, .FLM, .NEO, .PAC, .PC?,
.PI?, .RGB, .SEQ, .TNY, .TN?, .UC?
Version: Variuos
Compression: None, RLE
Color Depth:
Maintainer:
Specification:

The primary graphics file format of the Atari ST system is the
Electronic Arts Interchange File Format (IFF). However, a collection
of poorly documented image file formats native to the Atari ST
computer do exist as well. These formats are used primarily for
storing still-images, animations, and screen dumps.

The Computer Eyes Raw Data Format (.CE1, .CE2), Imagic File/Picture
Format (.IC1, .IC2, .IC3), NEOchrome Format (.NEO), RGB Intermediate
Format (.RGB), STAD Format (.PAC), Tiny Format (.TNY, .TN1, .TN2,
.TN3) are bitmap file formats. The Animatic File Format (.ANM), Cyber
Paint Sequence Format (.SEQ), DEGAS Format (.PI1, PI2, .PI3, .PC1,
.PC2, .PC3), and NEOchrome Animation Format (.ANI) are animation file
formats.

There seems to be no official documentation for most of these
formats. The document, "Atari ST Picture Formats", by David M.
Baggett <d...@ai.mit.edu> does seem to be the definitive reference.
You can find it at:

ftp://atari.archive.umich.edu/.../picfmts.doc

You may also find information on Atari ST formats on the
comp.sys.atari.st Usenet newsgroup, and on the following Web sites:

Dan's Atari ST Web Pages
http://newton.ex.ac.uk/general/ug/jones/

Atari ST FAQ
http://www.smartpages.com/faqs/csas-faq/top.html

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

Subject: AVS - Application Visualization System

Type: 3D
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

AVS is a package that allows non-programmers to build visualization
applications for scientific and engineering problem solving.
Have a look at the Introduction to AVS page at http://www.bion.kth.se/~pgr/AVS/howToStart.html

The AVS home page and FTP site may be found at:

http://iac.ncsc.org/
ftp://avs.ncsc.org/

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

Subject: AWD - Microsoft Fax At Work Document
Type: Bitmap
Extension: AWD
Version:
Compression:
Color Depth:
Maintainer: Microsoft Corporation
Specification:

AWD is an OLE compound object file that stores bilevel facsimile data.
The compression algorithm used by AWD is not published, but it is based
on CCITT Group 4. The format of OLE compound object files also seems not
to be published, but there much OLE information available:

http://www.microsoft.com/oledev/oleocx/ole11.htm
OLE Control and Control Container Guidelines, Version 1.1

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

Subject: BDF - Adobe Glyph Bitmap Distribution Format

Type: Bitmap font
Extension: bdf
Version: 2.2
Compression: None
Color Depth: 1-bit
Maintainer: Adobe Systems
Specification: ftp://ftp.adobe.com/pub/adobe/DeveloperSupport/TechNotes/PSfiles/5005.BDF_Spec.ps

BDF is an ASCII-based file format used to store Adobe screen fonts as
human-readable data. The BDF sister format, ABF, stores the same font data
using a binary format.

This format was previously known as the Character Bitmap Distribution
Format, but was renamed to the Glyph Bitmap Distribution Format to bring
the format's name into agreement with current industry terminology.

The specification for the BDF format is:

Glyph Bitmap Distribution Format (BDF) Specification (Version 2.2),
Adobe Developer Support, 22 March 1993, P/N LPS5005.

This document available via FTP as a Tech Note in PostScript format, or as
hardcopy when obtained directly from Adobe (see the PostScript section for
information on how to contact Adobe Systems, Inc.).

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

Subject: BIN - SGI Powerflip

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: BMP - Windows Bitmap Format

Type: Bitmap
Extension: BMP
Version:
Compression: RLE
Color Depth: 1- to 24-bit
Maintainer: Microsoft Corporation
Specification:

BMP is the native bitmap file format of the Microsoft Windows environment.
It efficiently stores mapped or unmapped RGB graphics data with pixels 1-,
4-, 8-, or 24-bits in size. Data may be stored raw or compressed using a
4-bit or 8-bit RLE data compression algorithm. BMP is an excellent choice
for a simple bitmap format which supports a wide range of RGB image data.

There is not single document that is the official &quotBMP Format Specification&quot.
Instead, BMP information is spread over several programming references. You
can search the Microsoft Developers Network CD-ROMs and the Microsoft Knowledge
Base (available at ftp://ftp.microsoft.com/ and http://www.microsoft.com/), but your
best source of BMP information lies outside of Microsoft and within the following
references:

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

Luse, Marv. "The BMP File Format," Dr. Dobb's Journal, #219 September
1994 (Vol 9, 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).

The code for the above issues are available at:

ftp://ftp.mv.com/pub/ddj/1994/1994.09/bmp.zip
ftp://ftp.mv.com/pub/ddj/1995/1995.03/bmp.zip

Also have a look at:

http://www.r2m.com/windev/
Internet Resources for Windows Developers

And look in the OS/2 Developer Connection SDK for OS/2 BMP information.

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

Subject: BRender

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: BRL-CAD - Ballistic Research Laboratory CAD

Type: Bitmap, 3D, and general data
Extension: .pix, .bw
Version:
Compression:
Color Depth:
Maintainer:
Specification:

The BRL-CAD Package is a powerful Constructive Solid Geometry (CSG) based
solid modeling system. BRL-CAD consists of over 100 different programs,
including an interactive geometry editor, a ray tracing library, two
ray-tracing based lighting models, a generic framebuffer library, a
network-distributed image-processing and signal-processing capability,
and a large collection of related tools and utilities. Release 4.0 is the
latest version of software which has been undergoing continuous development
since 1979.

The BRL-CAD documentation is distributed in five volumes:

Volue I The BRL-CAD Philosophy
Volue II The BRL-CAD User's Manual
Volue III The BRL-CAD Applications Manual
Volue IV The MGED User's Manual
Volue V The BRL-CAD Analyst's Manual

To obtain a copy of this documentation, contact:

BRL-CAD Distribution
Attn: SCLBR-LV-V
Aberdeen Proving Ground, MD 21005-5066
Email: ke...@brl.mil

For general information about BRL-CAD, contact:

BRL-CAD Architect
Attn: Mike Muuss
U.S. Army Research Laboratory
Aberdeen Proving Ground, MD 21005-5068
Email: mi...@brl.mil

Additional BRL-CAD information may be found at:

BRL-CAD Home Page
http://web.arl.mil/software/brlcad/index.html

BRL-CAD Technical Reports
http://web.arl.mil/reports/

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

Subject: BUFR - Binary Universal Form for the Representation of Meteorological Data

Type: General data
Extension:
Version:
Compression:
Color Depth:
Maintainer: World Meteorological Organization
Specification:

BUFR is a data format used to store quantiative meteorological data.
BUFR is described in the documents:

Guide to the WMO Code Form FM 94-IX EXT. BUFR, W. Thorpe, Fleet Numerical
Oceanography Center, Monterey, California.

Standard Formats for Weather Data Exchange Among Automated Weather
Information Systems, Document Number FCM-S2-1990.

Documents and information on BUFR are available from:

U.S. Department of Commerce/National Oceanic and Atmospheric
Administration (NOAA)
Attn: Ms. Lena Loman
Office of the Federal Coordinator for Meteorological Services and
Supporting Research (OFCM)
6010 Executive Blvd, Suite 900
Rockville, MD 20852
Voice: 301.443.8704

U.S. Department of Commerce/National Oceanic and Atmospheric
Administration (NOAA)
Attn: Dr. John D. Stackpole
Chief, Production Management Branch, Automation Division
National Meteorological Center
WINMC42, Room 307, WWB
5200 Auth Road
Camp Springs, MD 20746
Voice: 301.763.8115
Fax: 301.763.8381
Email: jst...@sun1.wwb.noaa.gov

BUFR, the WMO standard for point data
http://dao.gsfc.nasa.gov/data_stuff/formatPages/BUFR.html

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

Subject: BYU - BYU Movie

Type: 3D
Extension: byu
Version:
Compression:
Color Depth:
Maintainer:
Specification: http://www.cica.indiana.edu/graphics/object_specs/BYU.format.txt

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

Subject: CAD-3D

Type: 3D
Extension: 3d, 3d2, 3d4
Version: 2.0
Compression:
Color Depth:
Maintainer:
Specification: http://www.mediatel.lu/mmedia/render/h_3d2.html
http://www.cica.indiana.edu/graphics/object_specs/3D2.format.txt

CAD-3D 2.0 stores 3D objects using the 3D, 3D2, or 3D4 file formats. Each format
can store up to 40 objects and contains all information about the objects,
including the lighting and color palette.

CAD-3D files are similar to the older file format, but they no longer require
the Motorola Fast Floating Point library (LIBF) for the storage of vertex
coordinates. Thia new version stores each coordinate in a two-byte word instead
of a four-byte floating-point value, saving a considerable amount of storage,
and making the file more easily usable by programs written with different
floating-point formats.

For more information on CAD-3D, contact Antic Software:

Antic Software
Product Development Department
544 Second Street
San Franscico, CA 94107
Voice: +1 415.957.0886

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

Subject: CALS - Computer Aided Acquisition and Logistics Support Raster Format

Type: Bitmap
Extension: .cal
Version:
Compression: CCITT Group 4 (MMR)
Color Depth: 1-bit
Maintainer: CALS Management Support Office (DCLSO)
Specification:

CALS files are used for document imaging and therefore only store
black-and-white, 1-bit image data. CALS Type I files only store a single
image per file and the data is always compressed using the CCITT Group 4
encoding algorithm. CALS Type II files may stored multiple images per file,
the image data may be tiled, and tiles stored as raw data or as data
compressed using CCITT Group 4 encoding.

The CALS raster file format is defined primarily in the following
military standards documents:

MIL-STD-1840A, Automated Interchange of Technical Information
MIL-R-28002A, Requirements for Raster Graphics Representation
in Binary Format

The CALS raster file format is supported through the CALS office of the
United States Department of Defense:

CALS Management Support Office (DCLSO)
Office of the Assistant Director for Telecommunications andInformation Systems
Headquarters Defense Logistics Agency
Cameron Station
Alexandria, VA 22314 USA

The CALS Home Page
http://www.acq.osd.mil/cals/

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

Subject: CAM - Casio Camera

Type: Bitmap
Extension: .cam
Version:
Compression:
Color Depth:
Maintainer: Casio
Specification: Not available

CAM is the native bitmap format of the Casio QV series digital camera
software. The CAM format specification is not published, but Photoshop
plug-ins and a TWAIN toolkit for CAM are available, as is a developmant kit
for Visual Basic and Visial C++ applications. Email Scott Nelson at
SNELS...@aol.com for more information on the toolkits. Visit the Casio
home page at http://www.casio.com/ for more information on their QV-10 and
QV-30 digital cameras.

You can find a description of the CAM file internals at:

http://www.st.rim.or.jp/~with/QV10/index_e.html


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

Subject: CCITT - CCITT Group 3 and Group 4 Encoding

Type: Data encoding format
Extension: .g3, .g4, .cit
Version:
Compression:
Color Depth: Bilevel
Maintainer: http://www.itu.ch/
Specification:


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

Subject: CDF - Common Data Format

Type: General data
Extension: CDF
Version:
Compression:
Color Depth:
Maintainer:
Specification:

CDF is a scientific data management package (known as the "CDF Library")
developed by the National Space Science Data Center (NSSDC). CDF allows
application programmers to manage and manipulate scalar, vector, and
multi-dimensional data arrays. The CDF file format is transparently utilized
and made accessible to the through a consistent set of interface routines
known as the &quotCDF Interface&quot.

http://nssdc.gsfc.nasa.gov/cdf/cdf_home.html
The Common Data Format Home Page

http://nssdc.gsfc.nasa.gov/about/about_nssdc.html
National Space Science Data Center (NSSDC)

You can download the CDF software distribution from:
ftp://nssdc.gsfc.nasa.gov/pub/cdf/dist/cdf25/

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

Subject: CDF - Cyberspace Description Format

Type: VRML
Extension: CDF
Version:
Compression:
Color Depth:
Maintainer: Carl Tollander <ca...@autodesk.com>
Specification: http://vrml.wired.com/proposals/cdf/cdf.html

CDF is an ASCII-based format used for describing cyberspace decks and
virtual worlds. This format provides a standard framework that is used to
store, retrieve, modify, and exchange descriptions of cyberspace objects;
including object initialization, state, and scheduling, and cyberspase
simulation.

CDF is based on the CDF format described in Autodesk's Cyberspace
Development Kit. Autodesk's CDF is a closed format used to support a
proprietary deveoper's tool, while the proposed CDF format is an open
format intended to be accepted as an industry standard.

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

Subject: CDL - CADKey CADL Language

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer: Cadkey Inc.
Specification:

Contact Cadkey at:

Cadkey Inc.
4 Griffin Road
Windsor, CT 06095-1511 USA
Voice: 203.298.8888
Voice: 800.394.2231
Fax: 203.298.6590
Email: in...@cadkey.com
WWW: http://www.cadkey.com/

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

Subject: CGM - Computer Graphics Metafile

Type: Metafile
Extension: CGM
Version:
Compression: None
Color Depth:
Maintainer: ANSI, ISO, IEC, DOD, NIST
Specification:

The current version of the CGM ANSI/ISO standard (commonly called
CGM:1992) is:

Information Processing Systems--Computer Graphics Metafile for the
Storage and Transfer of Picture Description Information,
ANSI/ISO 8632-1992.

This standard superseded the early CGM:1986 (ANSI X3.122-1986) ANSI
standard. The CGM standard is contained in four ISO standards documents:

ISO/IEC 8632-1:1992 Part 1: Functional Specification
ISO/IEC 8632-3:1992 Part 2: Character Encoding
ISO/IEC 8632-3:1992 Part 3: Binary Encoding
ISO/IEC 8632-4:1992 Part 4: Clear Text Encoding

These documents may be obtained from the following organizations:

International Standards Organization (ISO)
1 rue de Varembe
Case Postal 56
CH-1211 Geneva 20 Switzerland
Voice: +41 22 749 01 11
Fax: +41 22 733 34 30

American National Standards Institute (ANSI)
Sales Department
11 West 42nd Street
New York, NY 10036
Voice: 212.642.4900

Canadian Standards Association (CSA)
Sales Group
178 Rexdale Blvd.
Rexdale, Ontario, M9W 1R3
Voice: 416.747.444

And here are a few CGM Web pages:

MIL-STD-2301, CGM Implementation Standard for the NIST Format Standard
http://www.tasc.com/nitfs/NITFS_docs.html

CGM Home Page at NIST
http://speckle.ncsl.nist.gov/~lsr/cgm.htm

Overview of CGM Standards
http://speckle.ncsl.nist.gov/~lst/cgm_std.htm

The Computer Graphics Metafile (CGM)
http://www.agocg.ac.uk:8080/agocg/CGM.html

A freely available C library for creating CGM files is available at:

http://speckle.ncsl.nist.gov/~lorax/cgm/cd.html

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

Subject: CIF

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

Subject: CMP - LeadView

Type: Bitmap
Extension: CMP
Version:
Compression: LEAD CMP compression (proprietary)
Color Depth:
Maintainer: LEAD Technologies
Specification: Not available

LEAD Technologies
Technical Support Department
Voice: 704.372.9681
Fax: 704.332.5868
BBS: 704.334.9045
Email: sup...@leadtools.com
WWW: http://www.leadtools.com/

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

Subject: CMU - Carnegie Mellon University Formats

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: COB - Calgari trueSpace2 File Format

Type: 3D
Extension: COB, SCN
Version:
Compression:
Color Depth:
Maintainer:
Specification: http://www.mediatel.lu/mmedia/render/files/calgari.pdf

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

Subject: CXS

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

Subject: Cyberware

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer: Cyberware
Specification:

Contact Cyberware at:

Cyberware Inc.
2110 Del Monte Avenue
Montery, CA 93940 USA
Voice: 408.657.1450
Fax: 408.657.1494
Email: sa...@cyberware.com
WWW: http://www.cyberware.com/

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

Subject: DEM - Digital Elevation Model

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer: U.S. Geological Survey (USGS)
Specification:

The format of DEM map files is described in the publication:

Data Users Guide 5 - Digital Elevation Models

and is available for $1.00 US from:

Earth Science Information Center (ESIC)
U. S. Geological Survey
507 National Center
Reston, VA 22092 USA
Voice: 1.800.USA.MAPS
Voice: 703.860.645

The Andrew Consortium
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/atk-ftp/web/andrew-home.html

http://edcwww.cr.usgs.gov/glis/hyper/guide/1_dgr_dem

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

Subject: DGN - Microstation

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: DKB - DKB-Trace

Type: 3D
Extension: dkb
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: DLG - Digital Line Graph

Type: Vector
Extension: dlg
Version:
Compression:
Color Depth:
Maintainer: U.S. Geological Survey (USGS)
Specification:

DLG is used by USGS to store geographical data. Documentation on this
format is available at:

ftp://spectrum.xerox.com/depts/markc/demtools/demwork/dlg/doc/dlgguide.txt.Z>.

The format of DLG graph files is described in the publications:

Data Users Guide 1 - Digital Line Graphs from 1:24,000-Scale Maps
Data Users Guide 2 - Digital Line Graphs from 1:100,000-Scale Maps
Data Users Guide 3 - Digital Line Graphs from 1:2,000,000-Scale Maps

and each is available for $2.00 US from:

Earth Science Information Center (ESIC)
U. S. Geological Survey
507 National Center
Reston, VA 22092 USA
Voice: 1.800.USA.MAPS
Voice: 703.860.645

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

Subject: DPX - Digital Moving Picture Exchange

Type: Bitmap
Extension: dpx, cin
Version:
Compression:
Color Depth:
Maintainer: SMPTE <http://www.smpte.org/>
Specification:

DPX is the SMPTE (Society of Motion Picture and Television Engineers)
standard file format for Digital Moving Picture Exchange. DPX is, in fact,
the Kodak Cineon raster file format with just a few slight modifications to
the file's header.

The DPX specification is referred to as the ANSI/SMPTE 268M-1994 Standard
(dated: 18 February 1994) and is available directly from SMPTE:

The Society of Motion Picture and Television Engineers
595 W. Hartsdale Avenue
White Plains, NY 10607 USA
Voice: 914.761.1100
Fax: 914.761.3115
Web: http://www.smpte.org/

You can find a complete listng of all SMPTE standards at
http://www.smpte.org/stds/stscope.html

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

Subject: DRW - Micrografx Designer/Draw Plus Format

Type: Vector
Extension: DRW
Version:
Compression:
Color Depth:
Maintainer: Micrografx
Specification:

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

Subject: DWB - Coryphaeus Software Designers Workbench

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:


Contact Coryphaeus at:

Coryphaeus
985 University Avenue
Suite 31
Los Gatos, CA 95030 USA
Voice: 408.395.4537
Fax: 408.395.6351
Email: sa...@coryphaeus.com
WWW: http://www.coryphaeus.com/

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

Subject: DWG - Autodesk drawing

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer: Autodesk
Specification:

http://www.kovac.com/software/index.html

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

Subject: DXF - Autodesk Drawing eXchange Format

Type: Vector and 3D
Extension: DXF
Version:
Compression: None
Color Depth:
Maintainer: Autodesk
Specification:

The AutoCAD DXF (Drawing eXchange Format) and AutoCAD DXB (Drawing eXhange
Binary) formats are the native vector file formats of Autodesk's AutoCAD
CAD application.

DXF is probably one of the most widely supported vector formats in the
world today. DXF is rich in features, including: support for 3D objects,
curves, text, associative dimensioning, and is an easy format to parse.
The DXB format is a binary representation of a DXF file and they are
usually smaller and faster to load than the equivalent DXF file.

The latest "official" DXF revision is Release 12. However, there is an
even newer version of DXF containing several changes and additions to the
format. Apparently the specification of the latest version of the DXF
format is not yet (if it will ever be) freely available. Users are
required to pay $4000US for a license to AutoCAD in to obtain the specs
for this newest release of DXF file format.

The official specification for DXF R12 may be found in the AutoCAD Manual
Release 12:

AutoCAD Customization Manual, Release 12, Autodesk Inc., 1992, pp. 241-81.

The specification for DXF R12 has also been released in electonic form and
is available in several of the Internet file format archives, such as:

ftp://avalon.vislab.navy.mil/pub/format_specs/dxf_r12.txt.Z
http://www.mediatel.lu/mmedia/render/h_dxf12.html

The spec for the most current version, DXF R13, is available at:

ftp://ftp.synapse.net/private/c/cadsyst/misc/r13dxf.zip

And an excerpt of the DXF R10 specification may be found at:

http://www.mediatel.lu/mmedia/render/h_dxf10.html

Many books detail the DXF format, including:

The AutoCAD Database Book, F.H. Jones and L. Martin, Ventana Press,
ISBN 0-940087-04-9. Order: 919.490.0062 voice.

AutoCAD, The Complete Reference, 2nd Ed., Johnson, N., McGraw-Hill,
New York, NY, 1991.

Additonal information may be obtained directly from Autodesk:

Autodesk Inc.
Autodesk Developer Marketing
2320 Marinship Way
Sausalito, CA 94965
Voice: 415.491.8719
FTP: ftp://ftp.autodesk.com/
WWW: http://www.autodesk.com/

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

Subject: EMF - Microsoft Enhanced Metafile

Type: Metafile
Extension: EMF
Version:
Compression: None
Color Depth:
Maintainer: Microsoft Corporation
Specification:

The next generation Windows Metafile. EMF files are not supported by
the 16-bit Windows and OLE environments.

http://www.microsoft.com/Softlib/MSLFILES/ENMETA.EXE
This archive contains sample Windows code to manipulate EMF files.
Two sample EMF files are included.

http://www.microsoft.com/developr/MSDN/OctCD/EMFDCO.ZIP
This archive contains the Windows source code for the EMF
decoding utility.

http://www.microsoft.com/developr/MSDN/OctCD/ENHMET.ZIP
This archive contains the ENHMETA.HLP help file that describes
the EMF file format.

Also have a look at:

http://www.microsoft.com/kb/developr/win32dk/q145999.htm
Q145999 "SAMPLE: How to Create & Play Enhanced Metafiles in Win32"

http://www.gentech.com/emf/win95emf.html
Enhanced Metafile Test Suite

http://www.r2m.com/windev/
Internet Resources for Windows Developers

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

Subject: ENFF - Extended Neutral File Format

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: EPS - Encapsulated PostScript

Type: Metafile
Extension: EPS
Version:
Compression:
Color Depth:
Maintainer:
Specification: http://www.adobe.com/supportservice/devrelations/PDFS/TN/5002.EPSF_Spec_v2.0.pdf

The PostScript Language Software Development Kit is available from the
creator of PostScript, Adobe Systems:

Adobe Systems Inc.
Attn: Adobe Systems Developer Support
1585 Charleston Road
P.O. Box 7900
Mountain View, CA 94039-7900
Voice: 415.961.7900
Voice: 800.344.8335
Fax: 415.961.3769

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

Subject: FACT

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: FBM - Fuzzy Bitmap

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

FBM is the native file format of the Fuzzy pixmap image manipulation and
conversion toolkit written by Michael L. Mauldin at Carnegie Mellon
University.

Code to manipulate FBM (and many other) file formats is found in the
FBM distrbution:

ftp://nl.cs.cmu.edu/usr/mlm/ftp/fbm.tar.Z

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

Subject: FFIVW - File Format for the Interchange of Virtual Worlds

Type: VRML
Extension: ffivw
Version:
Compression:
Color Depth:
Maintainer: Bernie Roehl <bro...@waterloo.ca>
Kerry Bonin <74367...@compuserve.com>
Specification: http://vrml.wired.com/proposals/ffivw.html

FFIVM is an ASCII-based, object-oriented format used to describe virtual
objects and worlds. This format is not intended to be a native file format
of any hardware or software platform, but instead to be used as an
interchange medium used for converting one VRML format to another.

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

Subject: FITS - Flexable Image Transport System

Type: General data format
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

FITS is a standard data interchange and archival format used by
astronomy software. The FITS data format specification is part of the
NOST Standard and Uer's Guide, available from:

ftp://nssdc.gsfc.nasa.gov/pub/fits/

Other FITS resources include:

FITS Support Office Home Page
http://www.gsfc.nasa.gov/astro/fits/fits_home.html

Displaying FITS Images
http://astrosun.tn.cornell.edu/FITS.html

http://fits.cv.nrao.edu/
ftp://fits.cv.nrao.edu/fits>

FITS discussions also occur on the sci.data.formats and
sci.astro.fits Usenet newsgroups. Questions about FITS may also be
directed to fi...@nssdca.gsfc.nasa.gov.

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

Subject: FLASHPIX

Type: Bitmap
Extension:
Version:
Compression: JPEG
Color Depth:
Maintainer: Kodak http://www.kodak.com/
Specification:

FLASHPIX is Kodak's latest "will do everything you will ever need" graphical
file format. It is based on the Microsoft OLE Structured Storage format that
all of Microsoft's newer data files use. The file format will be officially
released by Kodak in late September 1996 in cooperation with Microsoft,
Hewlett-Packard, and Live Picture.

You can get a marketing-oriented whitepaper that contains a very simple
techinical overview of the FLASHPIX format at:

http://www.kodak.com/aboutKodak/cmo/drg/productsTechnologies/niftyTech.shtml

A two-page write up of FLASHPIX also appears in Photo Electronic Imaging
Magazine (Vol. 29, No. 7, 1996, pp. 18,22).

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

Subject: FLT - MultiGen Flight

Type:
Extension: flt
Version: 14.2.4 Rev A
Compression:
Color Depth:
Maintainer:
Specification: http://www.mediatel.lu/mmedia/render/files/opnflt.pdf

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

Subject: GDS - McDonnell-Douglas Things

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: GFO - SGI Radiosity

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: GIF - Graphics Interchange Format

Type: Bitmap
Extension: GIF
Version: 87a, 89a
Compression: LZW
Color Depth: 8-bit
Maintainer: Compuserve
Specification: ftp://ftp.ncsa.uiuc.edu:/misc/file.formats/graphics.formats/gif87a.doc
ftp://ftp.ncsa.uiuc.edu:/misc/file.formats/graphics.formats/gif89a.doc

GIF is a data stream-oriented file format used to define the transmission
protocol of LZW-encoded bitmap data. GIF images may be up to eight bits
(256 colors) in depth and are always compressed. Despite the fact that GIF
supports only 8-bits worth of colors, and the multimedia extensions
introduced in the 89a release have not been widely utilized, GIF still
remains a popular choice for storing lower resolution image data.

The GIF89a specification is available via many BBSs and on-line information
services. You may also obtain the specification directly from CompuServe:

CompuServe Incorporated
Attn: Graphics Technology Department
5000 Arlington Center Boulevard
Columbus, OH 43220
Voice: 614.457.8600, 800.848.8199
FTP: ftp://ftp.compuserve.com/
WWW: http://www.compuserve.com/

Note: Any software created or modified after 01 January 1995 that supports
the capability of reading and/or writing GIF files must obtain a patent
license agreement from Unisys Corporation. See Part I of the FAQ for more
details on the Unisys GIF-LZW license agreements.

Here are a few links specializing in GIF89a animations:

http://www.fastlane.net/~samiel/anim.shtml
GIF Animation Secrets

http://member.aol.com/royalef/gifanim.htm
Royal Frazier's GIF Animation on the WWW

http://www.peritas.com/~abw/multigif.html
MultiGIF GIF89a Animation Utility

http://www.iis.ee.ethz.ch/~kiwi/GIFMerge/
GIFMerge Utility

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

Subject: GKS - Graphics Kernel System

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

GKS is a standard specifying the input and output primitives for displaying
2D and 3D graphical data. Although GKS has no native file format, the CGM
(Computer Graphics Metafile) format is often closely associated with its use.

The following ISO documents describe the GKS standard:

ISO 7942 Functional Specification
ISO 8651-1 Fortran Binding
ISO 8651-2 Pascal Binding
ISO 8651-3 Ada Binding
ISO 8651-4
ISO 8805 GKS-3D
ISO 8806 GKS-3D Bindings

These documents are available from ISO, ANSI, and CSA (see the CGM section
for the addresses of these organizations).

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

Subject: GrADS - GrADS Metafile

Type: Metafile
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

http://grads.iges.org/grads/
Grid Analysis and Display System

ftp://sprite.llnl.gov/pub/fiorino/grads/doc/grads.www/grads.htm
GrADS Documentation

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

Subject: GRASP - Graphical System for Presentation

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

Paul Mace Software Home Page
http://www.pmace.com/pms.htm

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

Subject: GRIB - Gridded Binary

Type: General data format
Extension:
Version:
Compression:
Color Depth:
Maintainer: World Meteorological Organization (WMO)
Specification:

GRIB is the standard format for the storage and interchange of
meteorological data. Several "flavors" of GRIB exist, prompting the
original format to be called WMO GRIB. The format specification and
software may be found at:

ftp://ncardata.ucar.edu/libraries/grib/
ftp://nic.fb4.noaa.gov/pub/nws/nmc/docs/gribguide/guide.txt

The specification for the ECMWF GRIB format is at:

ftp://ncardata.ucar.edu/datasets/ds111.2/format
ftp://ncardata.ucar.edu/datasets/ds111.2/software


UW-NMS Home Page
http://java.meteor.wisc.edu/

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

Subject: HDF - Hierarchical Data Format

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification: http://www.mediatel.lu/mmedia/render/files/ncsa_hdf.pdf

HDF is an object-oriented interchange file format used to transport image
data from one machin architecture or operating system to another with no
conversion problems or loss of data. Both 8- and 24-bit raster images are
supported, color palettes, and data compression (RLE, Incomp, and JPEG).

The latest version of HDF is 3.3 and comes with a complete library of
functions for manipulating HDF files, includeding the netCDF library by
Unidata.

Information on HDF is available from The HDF Information Server maintained
by the National Center for Supercomputing Applications:

http://hdf.ncsa.uiuc.edu:8001/

The HDF FAQ is located at:

http://hdf.ncsa.uiuc.edu:8001/HDF-FAQ.html

Other HDF-related Web sites include:

Heirarchial Data Format (HDF)
http://www.ncsa.uiuc.edu/SDG/Software/HDF/HDFIntro.html

The HDU 3.3 User's Guide in both PostScript and MIF format:

ftp://ftp.ncsa.uiuc.edu/HDF/Documentation/HDF3.3/Users_Guide/HDF3

Source code for HDF may be FTPed from:

ftp://ftp.ncsa.uiuc.edu/HDF

And HDF-related discussions may also be found on the Usenet newsgroup
sci.data.formats and in the FAQ for that newsgroup.

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

Subject: HDS - Hierarchical Data System

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: HPGL - Hewlett-Packard Graphics Language

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

Hewlett-Packard Graphics Language (HP-GL/2)

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

Subject: HPPCL - Hewlett-Packard Printer Control Language

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

PCL is capable of rendering both raster and vector graphics.

The official specification and toolkit for PCL is contained in the following
Hewlett-Packard manuals:

PCL 5 Printer Language Technical Reference Manual
PCL 5 Developer's Guide, 3rd Edition, Part No. 5002-1847

The technical reference manual contains a complete description of PCL 5. The
developer's guide contains many software examples illustracting how to
design PCL-compatable software. These maunals may be obtained directly from
Hewlett-Packard

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

Subject: HRF - Hitachi Raster Format

Type: Bitmap
Extension: HRF
Version:
Compression:
Color Depth: 1-bit
Maintainer: Hitachi Corporation
Specification: Chris Till (Voice: 303.449.3200, Fax: 303.449.1996)

HRF is typcailly used to store scanner output data.

The HRF specification is not available unless a non-disclosure agreement
is signed with Hitachi.

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

Subject: IFF - Electronic Arts Interchange File Format

Type: Bitmap, audio, multimedia
Extension: IFF, LBM, and many more
Version:
Compression: Uncompressed, PackBits
Color Depth:
Maintainer:
Specification:

Electronic Arts Home Page
http://www.ea.com/

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

Subject: IGES - Initial Graphics Exchange Specification

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

IGES is a set of protocols for the transfer and display of graphical
information on remote devices via a telephone or computer communications
network. IGES does not define any new graphical file formats, but instead
uses existing formats (such as CGM) to encapsulate graphical data.

IGES is associated with the NCGA (National Computer Graphics Association) and
is part of the U.S. Product Data Association (USPRO) and the IGES/PDES
Organization (IGO). The NCGA administers the National IGES User Group (NIUG),
which provides access to information on IGES.

To obtain the IGES specification, you must be a member of both NIUG and a
Regional Interest Group (RIG). The IGES specification is available through
the NCGA for $100US. For more information about the NIUG, RIGs, and IGES,
contact:

National Computer Graphics Association
2722 Merrilee Drive
Suite 3200
Fairfax, VA 22031 USA
Voice: 703.698.9600

IGES - Reference Documents
http://elib.cme.nist.gov/nipde/stds/wh-iges.html

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

Subject: IM - Performer

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: IMA - Zenographics Mirage Graphics File Format

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer: Zenographics
Specification:

IMA is the native file format of the Zenographics Mirage program.
The older version of this format was used by Mirage v5.12 and
eariler. Mirage 5.20 introduced the newer version of IMA.

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

Subject: IMJ - Image JPEG

Type: Bitmap
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

IMJ was created by Pegasus Image Corporation as a variation of the JFIF file
format. IMJ is essentially a JFIF file with a Microsoft Windows BMP header
and enhanced palette optimization. The IMJ format is used in several
screensaver applications, and by orgainizations such as Delrina and the
National Center for Missing Children.

See the section describing the PIC - Pegasus Imaging Corporation Format
for more information.

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

Subject: INGR - Intergraph Raster File Format

Type: Bitmap
Extension: Many (not standardized)
Version: 3
Compression: RLE, CCITT Group 4, JPEG, quad tree, Uncompressed
Color Depth:
Maintainer: Intergraph Corporation <http://www.intergraph.com/>
Specification: ftp://ftp.intergraph.com/pub/bbs/scan/note/rffrgps.zip

Intergraph publishes the INGR format specification in the following document:

"Intergraph Raster File Format Reference Guide", Intergraph Corporation,
DRA220700, March 1994, Version 3.2.0, 84 pages.

You may order this specifiction from:

Scanning Systems Division
Intergraph Corporation
Huntsville, AL 35894-0001 USA
Voice: 205-730-5441, 800-345-4856
Fax: 205-730-9441
BBS: 205-730-8786
Email: in...@intergraph.com
WWW: http://www.intergraph.com/
FTP: ftp://ftp.intergraph.com/

It is also available in PostScript format on Intergraph's FTP site.
Sampleimages are availble at:

ftp://ftp.intergraph.com/pub/bbs/scan/note/bilevel.exe

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

Subject: IRTP - Graphicon-2000 Interactive Real-Time PHIGS

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: IV - SGI Inventor

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: IV-VRML - Inventor VRML Format

Type: VRML
Extension: iv
Version:
Compression:
Color Depth:
Maintainer: Silicon Graphics
Specification: http://www.sgi.com/tech/Inventor/VRML/VRMLDesign.html

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

Subject: JBIG - Joint Bilevel Image Group

Type: Compression Method
Extension: Not specified by specification
Version:
Compression: JBIG
Color Depth: 1-bit (see text)
Maintainer: ISO, IEC and ITU
Specification:

JBIG is a lossless method for compressing black and white (1-bit) raster
image data. Its primary benefit is as a method for transmitting bi-level
image data across a communications channel. JBIG's progressive encoding
scheme allows lower resolution version of the image to be sent first,
followed by higher resolution images which build on the previously
transmitted data (e.g. 75, 150, 300, 450, and 600 DPI). This capability makes
JBIG ideal for replacing less-efficient document imaging transmissions
methods, such as CCITT Group 3 & 4, but thus far JBIG has not been marketed
in such a way as to make this possible.

There is no official JBIG file format. You just dump a JBIG data stream into
a disk for tape file, give it the extension JBG or JBIG, and you have a JBIG
file.

JBIG is jointly sponsored by the ITU (CCITT) and ISO/IEC JTCI/SC29
committees. The JBIG standard may be found in the following documents:

Information technology -- Coded representation of picture and audio
information -- Progressive bi-level image compression, ISO/IEC 11544:1993

ITU/CCITT Recommendation T.82

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

Subject: JCAMP

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

Subject: JFIF - JPEG File Interchange Format

Type: Bitmap
Extension: JPG
Version: 1.02
Compression: JPEG
Color Depth: 24-bits
Maintainer: C-Cube
Specification: See below

JFIF is a data stream-oriented file format used to define the transmission of
JPEG-encoded bitmap data. The specification for JFIF may be obtained directly
from C-Cube Microsystems:

C-Cube Microsystems
Attn: Scott Sinclair
Corporate Communications
1778 McCarthy Blvd.
Milpitas, CA 95035
Voice: 408.944.6300
Fax: 408.944.6314

The Independent JPEG Group archive on ftp.uu.net also contains an on-line
copy of the JFIF specification and additional JPEG information as:

ftp://ftp.uu.net/graphics/jpeg/jfif.ps.gz
ftp://ftp.uu.net/graphics/jpeg/jpeg.documents.gz

If you need code to read/write JFIF files and/or a JPEG data stream, then
please use the IJG's JPEG library, available at:

ftp://ftp.uu.net/graphics/jpeg/

Any other questions you have about JPEG will be answered by Tom Lane's
JPEG FAQ, which may be found at:

comp.graphics.misc
http://www.smartpages.com/faqs/jpeg-faq/top.html
ftp://rtfm.mit.edu/pub/usenet/news.answers/jpeg-faq/

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

Subject: LSA/LSB - Lightscape Technologies ASCII and Binary

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: LWOB - Lightwave Object Format

Type: 3D
Extension: IFF
Version: 2.0
Compression:
Color Depth:
Maintainer:
Specification: http://www.pb.net/usrwww/w_limg/LWOB.HTM
http://www.mediatel.lu/mmedia/render/h_lightwave.html

LightWave is part of a suite of application that is bundled with the
Amiga Video Toster system. LightWave 3D objects are stored as IFF files
with a FORM type of LWOB. Other chunks stored in a FORM LWOB file are
PNTS, SRFS, SURF, CRVS, and POLS chunk.

Also have a look at the LightWave newsgroup:

comp.graphics.apps.lightwave

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

Subject: MedFileS

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

Subject: MGF - Materials and Geometry Format

Type: 3D
Extension: mgf
Version: 1.1
Compression: None
Color Depth: full spectral colors (i.e., infinite)
Maintainer: Greg Ward <GJW...@lbl.gov>
Specification: http://radsite.lbl.gov/mgf/HOME.html

MGF is an ASCII-based 3D rendering format designed to model surface geometry
and materials for the purpose of visible-light simulation and rendering. The
overall objective of this format is to provide a very simple yet fairly
complete modeling language that does not place unreasonable demands on the
applications programmer or the object library creator.

The materials are physically-based and rely on standard and well-accepted
definitions of color, reflectance and transmittance for good accuracy and
reproducibility. The geometry is based on boundary representation using
simple geometric primitives such as polygons, spheres and cones. The file
format itself is terse but human-readable ASCII text. Translators are
available from 3D Studio and Radiance rendering formats, and to Inventor,
VRML and Radiance. An ANSI-C standard parser is freely distributed, along
with many models and examples at the official web site.

The format specification is available bundled with an MGF file reader
and is distributed in the file mgflib0.7.tar.Z on the following sites:

http://radsite.lbl.gov/mgf/HOME.html
ftp://hobbes.lbl.gov/www/mgf

The MGF software is currently in its second official release (version 1.1).
Questions about MGF should be directed to:

Greg Ward
Voice: 510.486.4757
Fax: 510.486.4757
Email: GJW...@lbl.gov

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

Subject: MIFF - Magick Image File Format

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

MIFF is a bitmap format native to the ImageMagick toolkit which runs under
the X Window System. ImageMagick is capable of displaying and converting a
variety of still and animated graphics file formats.

The specification for MIFF is available in the ImageMagick distribution
available from:

ftp://ftp.wizards.dupont.com/pub/ImageMagick/ImageMagick-3.7.tar.gz

For more information about ImageMagick and MIFF, contact:

duPont de Nemour & Company
Attn: John Cristy
Central Research and Development
Experimental Station
P.O. Box 80328
Room 162-A
Wilmington, DE 19880-0328
Voice: 302.695.1159
Email: cri...@dupont.com

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

Subject: MNG - Multiple Network Graphics

Type: Bitmap
Extension: MNG
Version:
Compression: RLE
Color Depth: 1 to 48 bits
Maintainer: Tom Boutell
Specification: ftp://swrinde.nde.swri.edu/pub/mng/documents/

MNG (pronounced "ming") is a proposed multiple-image
extension of the PNG (Portable Network Graphics)
format.

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

Subject: MSDL - Manchester Scene Description Language

Type: 3D
Extension: msdl
Version:
Compression:
Color Depth:
Maintainer:
Specification: http://hobbes.lbl.gov/www/mgf/HOME.html

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

Subject: MTL - Wavefront

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: NAPLPS - North American Presentation Layer Protocol Syntax

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

NAPLPS is a protocol for transferring ASCII-based graphical information to
remote terminals via a communications channel (telephone systems, computer
networks, and so forth). It is specifically designed to provide usable
information transfer rates, even at data rates as low as 2400bps.

NAPLPS is used by many Videotext services, Prodigy, the commercial on-line
information service, and in standalone information kiosk systems.

Although there is no NAPLPS file format, NAPLPS data streams are often saved
as files, and the files are then referred to as using the "NAPLPS file
format".

The NAPLPS specification is a standards documents available through ANSI, ISO,
or CSA. (See the CGM section for the addresses of these organizations). The
CSA document (T500-1983) also contains a supplement (1-1991) which is not
included in the ANSI version of this standard.

Further information may be found in the February, March, April, and May 1983
issues of Byte Magazine. These articles explain much of the NAPLPS coding
system and discuss the potential for NAPLPS.

Michael Dillon has authored a paper on NAPLPS and started a NAPLPS section on
SIMTEL20, which may be access via the mirror site:

ftp://oak.oakland.edu/pub/simtel/msdos/naplps

Michael Dillon may be contacted at:

CompuServe: 71532,137
Internet: mpdi...@halcyon.halcyon.com
BBS: 604.546.2705

The BBS also contains NAPLPS Shareware and art.

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

Subject: netCDF - Network Common Data Format

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:

http://www.unidata.ucar.edu/packages/netcdf/
netCDF Home Page

http://www.unidata.ucar.edu/packages/netcdf/utilities.html
Software for Manipulating or Displaying NetCDF Data

ftp://ftp.unidata.ucar.edu/pub/netcdf/
netCDF Software Distribution

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

Subject: NFF - Haines Neutral File Format

Type:
Extension: NFF
Version:
Compression:
Color Depth:
Maintainer: Eric Haines &lte...@eye.com&gt
Specification: http://www.mediatel.lu/mmedia/render/h_nff.html

NFF is a minimal scene description language used to test rendering algorithms
and efficiency schemes. It supports basic geometry of objects, surface
characteristics, placement of lights, color of objects, and the viewing angle
of the human eye. NFF is ASCII-based and is used with the Standard Procedural
Database (SPD) software package used for creating databases for testing
rendering schemes.

The specification for NFF is available on numerous FTP sites which archive
file format documents, such as:

ftp://zamenhof.cs.rice.edu/pub/graphics.formats

and is available along with the SPD test programs, which produce NFF objects:

ftp://ftp.princeton.edu/pub/Graphics/SPD

You may also contact the author of NFF:

Eric Haines
3D/Eye Inc.
1050 Craft Road
Ithica, NY 14850
Email: er...@eye.com

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

Subject: NFF - WorldToolKit Neutral File Format

Type: 3D
Extension: nff bff
Version: 2.1
Compression:
Color Depth:
Maintainer: Sense8 Incorporated
Specification: ftp://avalon.vislab.navy.mil/pub/format_specs
http://www.mediatel.lu/mmedia/render/h_nffwtk.html

The WorldToolKit Neutral File Format is a creation of Sense8 for their
WorldToolKit software product. WorldToolKit is a C language library providing
the functionality needed to do virtual reality, including file parsing,
sensor drivers, object management, behavior, and rendering.

Sense8's NFF format was loosely adapted from the Videoscape (.geo) format,
with the addition of 12-bit color, per-polygon texture application, and
portals. It was later extended to support vertex normals, 24-bit color, and
vertex uv coordinates. The current version of NFF is 2.1.

Sense8 also supports a binary format of NFF called BFF (.bff file extension)
The BFF format layout and order is identical to the ASCII version, with the
exception that only 24-bit, and not 12-bit, colors are not supported.

The WorldToolKit Neutral File Format was created and is maintained by:

Sense8
100 Shoreline Hwy. Ste. 282
Mill Valley, CA 94941
Voice: 415.331.6318
Fax: 415.331.9148
Email: in...@sense8.com
WWW: http://www.sense8.com/

Questions about Sense8's NFF format should be directed to:

Ben Discoe <b...@sense8.com>

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

Subject: NITF - National Imagery Transmission Format

Type: Page Layout
Extension:
Version:
Compression:
Color Depth:
Maintainer: Defense Information Systems Agency
Specification:

The National Imagery Transmission Format Standard (Version 2.0) is documented
as a collection of military standards documents. The actual file format is
documented in the following standard:

MIL-STD-2500, National Imagery Transmission Format (Version 2.0) for
the National Imagery Transmission Format Standard, 18 June 1993

The remaining standards are as follows:

MIL-HDBK-1300, National Imagery Transmission Format Standard (NITFS),
18 June 1993
MIL-STD-3201, Computer Graphics Metafile (CGM) Implementation Standard
for the National Imagery Transmission Format Standard, 18 June 1993
MIL-STD-188-196, Bi-Level Image Compression for the National Imagery
Transmission Format Standard, 18 June 1993
MIL-STD-188-197 Adaptive Recursive Interpolated Differential Pulse
Code Modulation (ARIDPCM) Compression Algorithm for the National
Imagery Transmission Format Standard, 18 June 1993
MIL-STD-188-198A, Joint Photographic Experts Group (JPEG) Image Compression
for the National Imagery Transmission Format Standard, 15 December 1993
MIL-STD-188-199, Vector Quantization Decompression for the National Imagery
Transmission Format Standard, 27 June 1994
MIL-STD-245-44500, Tactical Communications Protocol 2 (TACO2) for the
National Imagery Transmission Format Standard, 18 June 1993
JIEO Circular 9008, National Imagery Transmission Format Standards (NITFS)
Certification Test & Evaluation Program Plan, 30 June 1993

The NITFS standards may be obtained via FTP from the ITSI (Information
Technology Standards Integrated) BBS at:

ftp://jcdbs.2000.disa.mil/pub/library

ITSI BSS may also be reached by modem at 703.834.6501 (14.4kbps, N-8-1).

To receive hardcopies any or all of these documents, send a request via mail,
fax, or email to:

DISA/JIEO/CFS/TBCE
c/o Logicaon
Fay Mignone
1831 Wiehle Avenue
Reston, VA 22090 USA
Fax: 703.318.1098 Attn: Fay Mignone
Email: mig...@cdbs.itsi.disa.mil

or:

Defense Information Systems Agency
Center for Standards
Carol Ciepiela
Attn: TBCE, Rm 3304
10701 Parkridge Blvd
Reston, VA 22091 USA
Voice: 703.487.3536
Email: e...@itsi.disa.mil

Questions may be directed to:

NITFS Certification Test Facility
Voice: 602.538.5458 x5494

And NITF Web pagea include:

http://www.tasc.com/NITFS/
NITFS Home Page

http://www.itsi.disa.mil/ismc/ntb/ntb.html
The NITFS Technical Board

http://topaz.sensor.com/work/fmt/nitf/

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

Subject: OBJ - Wavefront Object

Type:
Extension: obj
Version:
Compression:
Color Depth:
Maintainer:
Specification: http://www.mediatel.lu/mmedia/render/files/off.pdf

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

Subject: ODIF - Open Document Interchange Format

Type: Binary
Extension: .odf
Version:
Compression:
Color Depth:
Maintainer: Open Document Architecture Consortium (ODAC)
Specification: http://www.itu.ch/itudoc/itu-t/rec/t.html

The Open Document Interchange Format (ODIF) is the data stream interchange
format associated with the Open Document Architecture (ODA). ODA is an
object-oriented document architecture for the description of both the logical
layot stuctures of a docuemnt. ODA also supports the transfer of documents in
processable form. The ODA and ODIF standard is described in ITU docuemnts
T.411 through T.421.

More information on ODIF files and ODA is available from:

ODAC
Avenue Marcel Thiry 204
1200 Brussels
Belgium
Voice: +32 2 774 9623
Fax: +32 2 774 9690
WWW: http://titan.orem.novell.com/

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

Subject: ODL - Object Description Language

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

Subject: OFF - Object File Format

Type: 3D
Extension: off
Version:
Compression:
Color Depth:
Maintainer:
Specification:

OFF was developed in 1986 at Digital Equipment Corporation's Workstation
Systems Engineering for the interchange and archiving of 3D objects. OFF is
an ASCII-based format and is independent of languages, devices, and operating
systems.

The specification for OFF is:

Rost, Randi, OFF--A 3D Object File Format, November 6, 1986 (updated
October 12, 1989).

The OFF archive is available at:

ftp://gatekeeper.dec.com/pub/DEC/

This archive contains the format specification, tools, and objects. It is not
currently supported and is copyrighted.

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

Subject: OpenMath

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

Subject: PBM - Portable Bitmap

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

The Portable greymap file format is part of the Extended Portable Bitmap
Utilities (PBMPLUS). PBM is used as an intermediate format for storing
monochrome bitmap information generated by the PBMPLUS toolkit. PBM files may
be either binary or ASCII and store data one-bit-per-pixel in size.

Information and source code for PBM can be found in the distribution for
PBMPLUS located at:

ftp://ftp.wustl.edu/graphics/graphics/packages/pbmplus/pbmplus10dec91.tar.Z

The specification for the PBM format can also be found in the manual page for
pbm(5) on many Unix systems.

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

Subject: PCX - ZSoft Paint

Type: Raster
Extension: PCX, PCC
Version:
Compression: RLE
Color Depth: 1 to 24 bits
Maintainer:
Specification:

PCX is one of the oldest bitmapped formats popularized by MS-DOS paint
programs that first appeared in the early 1980's. PCX files may store mapped
and unmapped image data from 1- to 24-bits in pixel depth, always contain
RLE-compressed image data, and are recognized by almost all still-image
graphics programs ever written.

But because of the kludged evolution of the PCX format (caused partly by the
efforts of Zsoft to continue to support the ever-changing world of graphics
display adapters) it is generally advised that the MS Windows BMP format be
used in place of PCX whenever possible.

Once upon a time ZSoft was bought by Wordstar, who was then bought by
SoftKey. It is not currently known if anyone distributes the original,
poorly written, specification for PCX. No matter, as most book on graphics
file format completely describe the PCX format.

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

Subject: PDF - Portable Document Format

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

PDF files are viewable using Adobe's Acrobat Reader 2.0 program.

PDF was created and is maintained by Adobe Systems Incorporated:

Adobe Systems Incorporated
1585 Charleston Road P.O. Box 7900
Mountain View, CA 94039-7900
Voice: 415.961.4400
Voice: 415.961.4111 (Developer Support)
Fax: 415.961.3769

Sample PDF images files may be found at:

ftp://ftp.adobe.com/pub/adobe/Acrobat/PDFsamples/

The Adobe Acrobat Software Developer's Kits for Unix, Macintosh, Microsoft
Windows, and MS-DOS may be found at:

ftp://ftp.adobe.com/pub/adobe/Acrobat/SDK/

You can download a PDF plug-in for your Web browser from:

ftp://ftp.adobe.com/pub/adobe/Acrobat/

Additional PDF information may also be gathered from Adobe's home Web page:

http://www.adobe.com/

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

Subject: PDS - Planetary Data System Format

Type: General data format
Extension: PDS
Version:
Compression:
Color Depth:
Maintainer: NASA
Specification:

PDS was created by the Planetary Branch of the National Aeronautics and Space
Administration (NASA) to store solar, lunar, and planetary data collected both
on Earth and by spacecraft. And as with most U.S. Government documents, the
specification is quite large and spread over several documents:

Jet Propulsion Laboratory, Standard for the Preparation and Interchange of
Data Sets, JPL Document D-4683, NASA, Pasadena, CA, 1988.
Jet Propulsion Laboratory, Data Preparation Workbook,
JPL Document D-7669, NASA, Pasadena, CA, 1990.
Jet Propulsion Laboratory, Planetary Data System Standards Reference,
JPL Document D-4683, NASA, Pasadena, CA, 1990.
Jet Propulsion Laboratory, Specification for the Object Description
Language, NASA, Pasadena, CA, 1990.

These documents are available from:

NASA
Planetary Branch
Jet Propulsion Laboratory
Mail Stop 525-3610
4800 Oak Grove Drive
Pasadena, CA 91109
Voice: 818.354.7587
Email: PDS_Op...@jplpds.jpl.nasa.gov

The PDS Standards Reference Document may also be found at:

http://stardust.jpl.nasa.gov/stdref/stdref.htm

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

Subject: PGM - Portable Greymap

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

The Portable greymap file format is part of the Extended Portable Bitmap
Utilities (PBMPLUS). PGM is used as an intermediate format for storing
greyscale bitmap information generated by the PBMPLUS toolkit. PGM files may
be either binary or ASCII and store pixel values up to 8 bits in size.

Information and source code for PGM can be found in the distribution for
PBMPLUS (see the section on the PBM format for information on PBMPLUS). The
specification for the PGM format can also be found in the manual page for
pgm(5) on many Unix systems.

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

Subject: PHD - PolyHedra Database

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: PIC - Lotus PIC Graphics Format

Type: Vector
Extension: PIC
Version:
Compression: None
Color Depth:
Maintainer:
Specification:

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

Subject: PIC - Micrografx Draw! Graphics Format

Type: Vector
Extension: PIC
Version:
Compression:
Color Depth:
Maintainer: Micrografx
Specification:

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

Subject: PIC - Pegasus Imaging Corporation Format

Type:
Extension: PIC
Version:
Compression:
Color Depth:
Maintainer:
Specification:

Pegasus Image Corporation
4350 W. Cypress Street, Suite 908
Tampa, FL 33607
Voice: 813.875.7575
Fax: 813.875.7705
BBS: 813.874.5515 Name: guest guest, Password: demo
CIS: GO PEGASUS

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

Subject: PIC - Video Show Graphics Format

Type: PIC
Extension:
Version:
Compression:
Color Depth:
Maintainer: General Parametrics Corporation
Specification:

Native file format used by the General Parametrics Corporation Video
Show Film Recorder.


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

Subject: PICT - Macintosh Picture

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer: Apple Computer
Specification:

The book Inside Macintosh, Volume 5, contains a description of PICT.
The Macintosh Technical note #27 also describes PICT.
The book Inside Machintosh: Quicktime, describes PICT-JPEG.

You can obtain the Inside Macintosh books in electronic form from:

http://dev.info.apple.com/insidemac.html

ftp://ftp.info.apple.com/Apple.Support.Area/Developer_Services/Technical_Documentation/Inside_Macintosh
ftp://ftp.info.euro.apple.com/Apple.Support.Area/Developer_Services/Technical_Documentation/Inside_Macintosh

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

Subject: PIX - Inset Pix

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

Quarterdeck Home Page
http://www.insetusa.com/

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

Subject: PLY - ZipPack

Type: 3D
Extension: ply
Version:
Compression:
Color Depth:
Maintainer: Silicon Graphics
Specification:

PLY is a polygon mesh format used by the Silicon Graphics ZipPack program.

ZipPack includes the program ply which reads and writes the PLY file format.
The ZipPack distribution is available at:

ftp://graphics.stanford.edu/pub/zippack

The ZipPack distribution is also available from the ZipPack Web page:

http://www-graphics.stanford.edu/software/zippack

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

Subject: PNG - Portable Network Graphics

Type: Raster
Extension: PNG
Version:
Compression: RLE
Color Depth: 1 to 48 bits
Maintainer: Tom Boutell
Specification: http://www.boutell.com/boutell/png/

PNG (pronounced "ping") is a new bitmap format which is currently in
development. Its creation is an attempt to give the graphics community an
alternative to the shortcomings and misgivings found in most popular file
formats. The current legal situation involving the GIF format may also have
something to do with it too :-)

The following paragraph, excerpted from the PNG (Portable Network Graphics)
specification explains the basic rationale behind the format:

The PNG format is intended to provide a portable, legally unencumbered,
simple, lossless, streaming-capable, well-compressed, well-specified
standard for bitmapped image files which gives new features to the end
user at minimal cost to the developer.

The PNG specification is now in its 10th draft. This draft is considered
finalized to the point that software may be safely written without the worry
of the specification changing in non-backwardly compatable ways.

A public draft of the current PNG specification may be found at:

http://www.boutell.com/boutell/png/
ftp://swrinde.nde.swri.edu/pub/png/documents/png10.txt
ftp://ftp.uu.net/graphics/png/documents/

Questions about PNG may be asked on the comp.graphics.misc newsgroup, or via
email at:

png-...@uunet.uu.net

or directed to the principle author of the PNG specification:

Thomas Boutell <bou...@boutell.com>

PNG developers may join the PNG mailing list. Send email to

png-...@uunet.uu.net

and ask for more information. A human will be reading your request to join
the list, so make it good. Other PNG mailing lists include:

png-...@dworkin.wustl.edu General PNG discussion
png-an...@dworkin.wustl.edu Announcements related to PNG
png-im...@dworkin.wustl.edu Implementation discussion

These lists contain a general discussion of PNG, announcements related to

PNG, and discussions regarding PNG implementation. To find out more about
the mailing list server, send mail to png-list...@dworkin.wustl.edu with
the word "help" (and nothing else) in the message body.

The official PNG FTP archive is:

ftp://ftp.uu.net/graphics/png/

A reference implementation in portable C of a PNG reader and writer is
available at:

ftp://ftp.uu.net/graphics/png/src/

And test PNG images for your benchmarking pleasure:

ftp://ftp.uu.net/graphics/png/images/
ftp://ftp.photodex.com/PNG/images/

PNG materials can also be had in great profusion from:

ftp://swrinde.nde.swri.edu/pub/png/

All programs on this site are in beta test and should be used carefully. In
the case of questionable implementation, the specification is to be
considered corrent and the code in error.

The PNG group has a home page with pointers to many other PNG resources at:

http://quest.jpl.nasa.gov/PNG/

Group 42 is the author of the PNGLIB support library for developer's using
the PNG file format. Their Web page contains a developer's section which
includes the PNGLIB library, PNG format specification, Compression Library,
and Image Test Suite. A Freeware version of theis library is currently
available. Group 42 may be reached at:

Group 42, Inc.
Voice: 800.520.0042
Voice: 513.831.3400
Email: in...@group42.com
WWW: www.group42.com

And PNG's very first journal article has appeared:

PNG: The Portable Network Graphic Format, Dr. Dobb's Journal,
Lee Daniel Crocker, #232 July 1995 (Vol 20, Issue 7), pp. 36-44.

The code for the above issues are available at:

ftp://ftp.mv.com/pub/ddj/1995/1995.07/ptot.zip

The World Wide Web Consortium now recommends PNG:

http://www.infoworld.com/cgi-bin/displayStory.pl?96104.w3c.htm

And a rather CompuServe-biased official press release:

http://www.compuserve.com/new/news_rel/png2.html

See also MNG (Multiple Network Graphics)

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

Subject: PPM - Portable Pixmap

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

The Portable pixmap file format is part of the Extended Portable Bitmap
Utilities (PBMPLUS). PPM is used as an intermediate format for storing color
bitmap information generated by the PBMPLUS toolkit. PPM files may be either
binary or ASCII and store pixel values up to 24 bits in size.

Information and source code for PPM can be found in the distribution for
PBMPLUS (see the section on the PBM format for information on PBMPLUS). The
specification for the PPM format can also be found in the manual page for
ppm(5) on many Unix systems.

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

Subject: POL - InnovMetric Software Polygon Models Format

Type: 3D
Extension: pol
Version:
Compression:
Color Depth:
Maintainer:
Specification: http://www.mediatel.lu/mmedia/render/files/pol.pdf

POL is the native 3D file format for software products created by InnovMetric
Software. The POL format was created to fill the need of storing data
representing multi-contour, simple, planular, polygons using a binary file
format.

InnovMetric Software is developing a complete line of software products for
building 3-D polygonal models using a 3-D imaging system. Two of these
software tools are targeted at real-time 3-D graphics applications.
IMCompress and IMFilter are two complementary tools for optimally reducing
the number of polygons in a 3-D model. IMCompress uses a surface-based
algorithm to downsize highly redundant models such as Digital Terrain Models
and polygonal models generated by a CAD or a 3-D imaging system. IMFilter
uses a volume-based algorithm to create ultra-compact models (20 to 500
triangles) for level of details management in applications requiring
real-time 3-D graphics.

The POL file format specification is primarily distributed as Appendix B of
the IMCompress User's Guide published by InnovMetric Software. The
specification is also available in PostScript format as the file pol.ps in a
few of the graphics file format specification archived listed in part 1 of
this FAQ.

POL was created and is maintained by:

InnovMetric Software Inc.
2065 Charest ouest, Suite 218
Sainte-Foy, Quebec
Canada, G1N 2G1

Questions about POL may be directed to:

Marc Soucy <mso...@imetric.qc.ca>

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

Subject: POV - Persistence of Vision Raytracing

Type: 3D scene description language
Extension: pov
Version: 2.2
Compression: None
Color Depth:
Maintainer: POV-Ray Team
Specification: ftp://ftp.povray.org/pub/povray/Official/docs/povdoc-2_2.zip

The POV-Ray format is used to store a scene description language used by the
POV-Ray ray tracing software package. POV-Ray files are always ASCII to allow
easy transportation between different file systems.

The specification for the POV file format and scene description language is
found in the file povray.doc in the POV-Ray distribution. You may obtain
this file (and the entire POV-Ray package) from the official POV-Ray FTP
archive and Web sites:

ftp://ftp.povray.org/pub/povray/Official/docs/povdoc-2_2.zip
http://www.povray.org/pub/povray/Official/docs/povdoc-2_2.zip

or from these official mirror sites:

ftp://alfred.ccs.carleton.ca/
ftp://uniwa.uwa.edu.au/

Questions about POV-Ray may also be direct to:

Chris Young
POV-Team Coordinator
76702...@compuserve.com

or to the comp.graphics.rendering.raytracing newsgroup on Usenet.

The following is an excellent book on ray tracing using the POV-Ray tracing
software package for the PC:

Ray Tracing Creations: Generate 3D Photo-Realistic Images on the PC,
Drew Wells and Chris Young, Waite Group Press 1993.

It is also worth noting that not only is POV-Ray an excellent ray
tracing package, but its source and binaries are availble for most
systems and widely distributed free of cost.

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

Subject: PS - PostScript

Type: Page Description Language
Extension: PS
Version:
Compression: None, LZW
Color Depth:
Maintainer: Adobe Systems
Specification:

PostScript was created and is maintained by Adobe Systems Incorporated:

Adobe Systems Incorporated
1585 Charleston Road P.O. Box 7900
Mountain View, CA 94039-7900
Voice: 415.961.4400
Voice: 415.961.4111 (Developer Support)
Fax: 415.961.3769
BBS: 206.623.6984 (14.4-N-8-1)
FTP: ftp://ftp.adobe.com/
WWW: http://www.adobe.com/

The primary source of PostScript formation may be found in the Adobe
PostScript Langauge books:

Red Book: Postscript Language Reference Manual, 2nd ed.
Adobe Systems Inc., Addison-Wesley. ISBN 0-201-18127-4,
$26.95US softcover

Blue Book: Postscript Language Tutorial and Cookbook,
Adobe Systems Inc., Addison-Wesley. ISBN 0-201-10179-3,
$16.95US softcover

Green Book: PostScript Language Program Design,
Adobe Systems Inc., Addison-Wesley. ISBN 0-201-14396-8,
$22.95US softcover

Black Book: Adobe Type 1 Font Format Specification,
Adobe Systems Inc., Addison-Wesley. ISBN 0-201-57044-0,
$14.95US softcover

Purple Book: Programming the Display PostScript System with NeXTstep,
Adobe Systems Inc., Addison-Wesley. ISBN 0-201-58135-3,
$26.95US softcover

You may order these books directly from Adobe Systems in Mountain View,
California, by calling 1.800.83.FONTS (U.S. and Canada only) or 415.961.4400
(ask for "Inside Sales"). Or from Hayden Publishing at 1.800.428.5331.


Additional information on PostScript may be found on Adobe's FTP server and
Web site:

ftp://ftp.adobe.com/pub/adobe/DeveloperSupport/Technotes/
http://www.adobe.com/

The Usenet newsgroup comp.lang.postscript covers issues relating to the Adobe
PostScript language. The PostScript FAQ is available at:

http://www.cis.ohio-state.edu/hypertext/faq/usenet/postscript-faq/top.html

The Usenet newsgroup comp.fonts also covers issues relating to fonts. The
comp.fonts FAQ is available at:

http://jasper.ora.com/comp.fonts/FAQ/

The Usenet newsgroup comp.sources.postscript contains source code of
PostScript programs. Other newsgroups that may be of interest are:
comp.periphs.printers, comp.laser-printers, comp.text.pdf, comp.text.desktop,
and comp.publish.prepress.

The Encapsulated PostScript specification (v2.0) may be found at:

http://www.adobe.com/supportservice/devrelations/PDFS/TN/5002.EPSF_Spec_v2.0.pdf

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

Subject: PSD - Adobe Photoshop

Type: Bitmap
Extension: PSD
Version: 3.0
Compression:
Color Depth:
Maintainer: Adobe Systems
Specification:

PSD is the native bitmap file format of the Adobe Photoshop graphical editing
application. PSD files have the extension .PSD under MS Windows and the file
type code 8PBS on the Macintosh.

Other file formats associated with Photoshop include: Arbitrary Map (.AMP),
Brushed (.ABR), Color Table (.ACT), Colors (.ACO), Command Buttens (.ACM),
Curves (.ACV), Duotone Options (.ADO), Halftone Screens (.AHS),
Hue/Saturation (.HSS), Ink Colors Setup (.API), Custom Kerenel (.ACF), Levels
(.ALV), Monitor Setup (.AMS), Replace Color/Color Range (.AXT), Scratch Area
(.ASR), Selective Color (.ASV), Separation Setup (.ASP), Separation Tables
(.AST), and Transfer Function (.ATF).

The format specification for PSD 2.5 and other file formats associated
with Adobe Photoshop may be found in the document PSAPIDOC.*
(distributed in the Microsoft Write, Macintosh MacWrite, and Adobe
Acrobat format) under the heading "Document File Formats".
These documents are part of the Photoshop Plug-In Software Developers
Kit, available via FTP and from the Adobe Developers Association's
home page:

http://www.adobe.com/Support/ADA.html
ftp://ftp.adobe.com/pub/adobe/Applications/Photoshop/*/Plug-In-SDK/

This SDK is also available directly from Adobe (see the PostScript section
for information on how to contact Adobe Systems, Inc.).

The specification for the Adobe Photoshop Raw File Format may be found at:

http://www.adobe.com/supportservice/custsupport/SOLUTIONS/25c6.htm

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

Subject: PTU - Performer Terrain Utilities

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: QT - QuickTime

Type: Multimedia
Extension: QT
Version:
Compression:
Color Depth:
Maintainer: Apple Computer
Specification:

You can obtain the Inside Macintosh books in electronic form from:

http://dev.info.apple.com/insidemac.html

The complete QuickTime section from Inside Macintosh in PDF formats is
available at:

http://dev.info.apple.com/Developer_Services/Technical_Documentation/Inside_Macintosh/QuickTime/CompleteBookPkg/

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

Subject: QTVR - QuickTime VR

Type: Scene
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification: Object Movie http://dev.info.apple.com/Technotes/tn1036.html
Panorama Movie http://dev.info.apple.com/Technotes/tn1035.html

You can find the QuickTime VR FAQ at
http://dev.info.apple.com/techqa/qtvr/qtvr.html

Contact Apple Developer Support at DEVSU...@applelink.apple.com.

To join the QuickTime Developer mailing list, send an email to
list...@abs.apple.com with the body "subscribe quicktime-dev
yourfirstname yourlastname".

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

Subject: RAD - Radience

Type: 3D
Extension:
Version:
Compression: None
Color Depth:
Maintainer: Greg Ward <gjw...@lbl.gov>
Specification:

RAD is the native file format for the public domain Unix Radiance radiosity
renderer. An MS-DOS version is available as part of the ADELINE 1.0 package.

The RAD specification and Radience package are available at:

http://radsite.lbl.gov/radience/HOME.html

For information on ADELINE, check out:

http://radsite.lbl.gov/adeline/HOME.html

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

Subject: RAS - Sun Rasterfile

Type: Bitmap
Extension: ras
Version:
Compression: None, RLE
Color Depth:
Maintainer: Sun Microsystems
Specification:

Sun rasterfile is the native bitmap format of Sun Microsystem Unix systems.
The rasterfile format has become more wide-spread with the growing popularity
of the SunOS operating system and Sun SPARCStation family of Unix
workststaions.

Sun rasterfiles store images up to 32 bits in pixel depth and support a basic
for of run-length data compression.

The primary source of information for Sun Rasterfiles is the SunOS include
file /usr/include/rasterfile.h and the rasterfile online manual page:

Sun Microsystems, rasterfile (5), Sun OS 4.0 Programmer's Manual, 1990.

The following jounal article is devoted to the Sun rasterfile:

McGee, Format for Byte-Encoded Rasterfiles, Sun-Spots Digest, Volume 6,
Issue 84.

And several books on graphics file formats also feature the rasterfile format.

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

Subject: RAY - Rayshade

Type: 3D
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

Rayshade is a ray-tracing application for the Unix environment. The
Rayshade format is the native scene description language used by Rayshade.
And like most 3D scene-rendering formats it is ASCII-based and supports
most features commonly found in these formats.

The specification is available in the Rayshade distribution on many BBSs
and FTP archive sites. The official Rayshade FTP site is:

ftp://princeton.edu/pub/Graphics/

And the format is detailed in the document:

Rayshade 4.0 Quick Reference

The author may be contacted at:

Princeton University
Attn: Craig Kolb
Department of Computer Science
35 Olden Street
Princeton, NJ 08544
Email: c...@princeton.edu

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

Subject: RFT-DCA - Revisable-Form Text Document Content Architecture

Type: Word processing
Extension: RFT
Version: Many
Compression:
Color Depth:
Maintainer: IBM Corporation
Specification:

RFT was developed by IBM for transfering documents between IBM and non-IBM
word processing systems. It is most commonly assocated with the DisplayWrite
word processor on the IBM 360, 370, and AS/400 systems. Information on
RFT-DCA may be found in the following IBM document:

Document Content Architecture: Revisable-Form-Text Reference,
Document SC23-0758-1, Second Edition, August 1986

RFT is often confused with the Microsoft RTF (Rich Text Format), which also
enables the portability of word processing documents between dis-similar
systems.

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

Subject: RAW - Photoshop RAW

Type: Bitmap
Extension: RAW
Version:
Compression: None
Color Depth: 24-bit
Maintainer: Adobe Systems
Specification: http://www.adobe.com/

A Photoshop Raw file is a Photoshop PSD file without a header. The header
information must be entered when the file is imported into Photoshop. The
raw format is used import and export bitmap data using a very simple,
uncompressed binary format.

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

Subject: RIB - Renderman Interface Bytestream

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

The RenderMAN file format specification may be found in the following
document available from Pixar:

The RenderMAN Interface, Version 3.1, September 1989. San Rafael, CA.

Pixar
1001 West Cutting Blvd.
Richmond, California 9484 USA
Voice: 415.236.4000

Also of interest is the following publication:

The RenderMan Companion: A Programmer's Guide to Realistic Computer
Graphics, Steve Upstill, Addison-Wesley Publishing Company,
ISBN 0-201-50868-0, $26.95

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

Subject: RIFF - Microsoft Resource Interchange File Format

Type: Multimedia
Extension: AVI, BND, WAV
Version:
Compression:
Color Depth:
Maintainer: Microsoft Corporation
Specification:

Microsoft Corporation
Attn: Multimedia System Group
Product Marketing
One Microsoft Way
Redmond, WA 98052-6399
Voice: 206.882.8080
BBS: 206.637.9009

Information on RIFF may be found in the following documents:

Microsoft Windows Multimedia Programmer's Guide, Microsoft
Corporation, Microsoft Press, Redmond, WA.

Microsoft Windows Multimedia Programmer's Reference, Microsoft
Corporation, Microsoft Press, Redmond, WA.

The specification is also available in the Microsoft Multimedia Development
Kit (MDK), the Microsoft Video for Windows Development Kit (VFWDK), and
the Microsoft Developers Network CDs.

ftp://ftp.microsoft.com/developr/drg/Multimedia/Jumpstart/VfW11e/DK/VFWDK/
Video for Windows Development Kit, v1.1e

Also have a look at:

http://www.r2m.com/windev/
Internet Resources for Windows Developers

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

Subject: RIX - ColoRIX Image File

Type: Bitmap
Extension: RIX
Version:
Compression:
Color Depth:
Maintainer:
Specification:

ColorRIX is the native bitmap format of the ColorRIX VGA Paint application
for MS-DOS.

The ColorRIX format is documented in the ColorRIX VGA Paint manual
distributed with the ColorRIX program. The last known address of
RIX Softworks was:

RIX SoftWorks Inc.
Attn: Richard Brownback or Paul Harker
18023 Sky Park Circle, Suite J
Irvine, CA 92714
Voice: 714.476.8266
Voice: 714.476.8486

ColorRIX is also bundled with several different VGA cards and the
specification may also be found on numerous FTP archive sites.

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

Subject: RTF - Rich Text Format

Type: Word processing
Extension: RTF
Version: 1.4
Compression: None
Color Depth: 24-bits
Maintainer: Microsoft Corporation
Specification:

Upon the official Microsoft blurbs I cannot improve:

"The Rich Text Format (RTF) standard is a method of encoding
formatted text and graphics for easy transfer between MS-DOS,
Windows, Windows 95, OS/2, and Apple Macintosh applications."

"The RTF standard provides a format for text and graphics
interchange that can be used with different output devices, operating
environments, and operating systems. RTF uses the ANSI, PC-8,
Macintosh, or IBM PC character set to control the representation and
formatting of a document, both on the screen and in print. With the
RTF standard, you can transfer documents created under different
operating systems and with different software."

"Version 1.4 of the RTF Specification contains all RTF controls
introduced by Microsoft applications through the release of Word
7.0."

A self-extracting archive containing the RTF 1.4 specification and a
sample RTF reader may be FTPed from Microsoft:

Or downloaded from Microsoft's BBS at: +1.206.936.6735

RTF is often confused with the IBM Revisable-Form Text Document
Content Architecture (RFT), which also enables the portability of
word processing documents between dis-similar systems.


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

Subject: RWX - MEME Shape File

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: RWX - Criterion RenderWare

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: S1K - S1000 Simnet Format

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: SAF - Standard Archive Format

Type: General
Extension: SAF
Version:
Compression: None, GZIP
Color Depth:
Maintainer: Advanced Missle Signature Center (AMSC)
Specification:

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

Subject: SAIF - Spatial Archive Interchange Format

Type: General data format
Extension:
Version: 3.2
Compression:
Color Depth:
Maintainer:
Specification: http://www.env.gov.bc.ca/~srmb/saif32/toc.html

SAIF (pronounced "safe") is a standard format for the storage and interchange
of geographical data.

The SAIF format specification is available at:

ftp://s2k-ftp.cs.berkeley.edu/pub/sequoia/schema/STANDARDS/SAIF
ftp://moon.cecer.army.mil/ogis/related/SAIF3.1

And visit the SAIF home page at:

http://www.env.gov.bc.ca/~srmb/saif.html

For more information contact:

SAIF Info
Surveys and Resource Mapping Branch
B.C. Ministry of Environment, Lands, and Parks
Fourth Floor, 1802 Douglas Street
Victoria, BA CANADA V8T 4K6
Voice: 604.387.1353
Fax: 604.356.7831
WWW: http://www.env.gov.bc.ca/srmb/saif.htm

The following company provides software tools for using SAIF:

Safe Software
Voice: 604.241.4424
Voice: 604.583.2016
Email: info...@safe.com
WWW: http://www.wimsey.com/~infosafe/saif/saifHome.html

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

Subject: SAT - ACIS

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: Scene

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: Scitex HandShake Formats

Type: Bitmap
Extension: CT, LW, BM, PG, and TX
Version: April 1988
Compression: None and RLE
Color Depth: 1-bit to 128-bit
Maintainer: Scitex Corporation <http://www.scitex.com>
Specification: Howard White <whi...@s9gate.sta.scitex.com>

The most well-known of the HandShake formats is Scitex CT (continuous tone).
This format may store from 1 to 16 8-bit color separations (color planes).
Typical CT files store four separation of CMYB image data. Adobe Photoshop
is an application that is commonly used to create Scitex CT image files.

The other HandShake formats include LW (linework, 16 color separations, 255
color maximum), BM (bitmap, 1-bit RLE image data), PG (page layout), and TX
(textual typesetter data). Of these formats, PG and BM have not been fully
implemented by Scitex and may not be in general use elsewhere.

The Scitex HandShake data formats and data exchage protocols are described
in the following document:

HandShake Foreign File Transfer Protocol, Scitex Corporation, Ltd.,
Revision A: April 1988, Document No. 788-37898A, Catalog No. 399Z37898

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

Subject: SCN - SCeNe RTrace

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: SDL - Alias Wavefront Scene Description Language

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

comp.graphics.apps.alias

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

Subject: SDML - Spacial Data Modeling Language

Type: VRML
Extension: sdml
Version:
Compression:
Color Depth:
Maintainer: Silicon Graphics
Specification: http://www.clr.toronto.edu:1080/CLRMOSAIC/SDML.html

SDML is a spatial description language used for storing CAD and GIS data,
such as found in Landscape Planning, Design, and Architectural databases.

SDML currently exists in two versions: the old SDML format and the new
(Version 1.0) format. The old format is derived from the ASCII-based format
used in the Silicon Graphics CLRview and PolyTRIM software environments. The
new format, released in 05Feb95, is a more detailed, capable, and
size-optimized revision of the old SDML and supports all the features of the
Silicon Graphics CLRMosaic software.

Additional information on CLRMosaic can be found at:

http://www.clr.toronto.edu:1080/CLRMOSAIC/help-about.html

Questions about SDML should be directed to:

Rodney Hoinkes, Head of Design Applications
Centre for Landscape Research
University of Toronto
230 College St.
Toronto, ON, M5S 1A1
Voice: 416.978.3551
Fax: 416.971.2094
Email: rod...@clr.toronto.edu
WWW: http://www.clr.toronto.edu/PEOPLE/RODNEY/rodney.html

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

Subject: SDTS - Spatial Data Transfer Standard

Type: General data format
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

SDTS is a standard (FIPS 173) format used for the storage and interchange
of gelogical data.

SDTS documentation and files are available from:

ftp://sdts.er.usgs.gov/pub/sdts/www/html/sdts.html

SDTS questions may be directed to sd...@usgs.gov.

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

Subject: SFF - Scene File Format

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: SGI - Silicon Graphics Image File Format

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

SGI is the native file format of the limage image library found on Silicon
Graphics workstations. The limage library provides a set of functions used
to read and write SGI images.

The SGI file format is a creation of Paul Haeberli (pa...@sgi.com) at Silicon
Graphics Computer Systems. The SGI format specification may be found at:

ftp://ftp.sgi.com/graphics/SGIIMAGESPEC

The SGI format is also known as the RGB file format. On SGI workstations
you can get info on RGB and the limage library by using the following
command:

% man 4 rgb

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

Subject: SHG - Segmented Hyper-Graphic

Type: Bitmap
Extension: SHG
Version:
Compression: None, RLE
Color Depth:
Maintainer: Microsoft Corporation
Specification: ftp://ftp.microsoft.com/developr/drg/Multimedia/SHED.ZIP

SHG is a file format used by Microsoft in the WinHelp on-line help facility
found in Windows 3.1. This format is used to save a Microsoft Bitmap (BMP) or
Windows Metafile (WMF) graphic and store the coordinates of specific areas of
the bitmap known as "hotspots". When the bitmap is displayed and the user
selects a hotspot, WinHelp jumps to another part of the help documentation
via a hyper-text link macro stored in the SHG file.

Another file format used with SHG files is the Multiple-Resolution Bitmap
(MRB) format. MRB files contain one or more SHG images, each rendered at a
different resolution. Several SHG files are typically created using the
SHED.EXE utility and then fed into the MRB compiler to create a single MRB
file. When WinHelp reads the MRB file it chooses which bitmap most closely
matches the resolution of the display.

SHG is currently officially undocumented by Microsoft, but a rather
questionable specification may be found at:

ftp://ftp.microsoft.com/developr/drg/Multimedia/SHED.ZIP

Information on SHG and MRB may be found in the following journal article:

.mrb and .shg File Formats, Windows/DOS Developer's Journal, Pete Davis,
February 1994 (Vol 5, No 4), pp. 37-46.

Questions about these formats may also be directed to Section 16
(WinHelp/Tools) of forum WINSDK on CompuServe.

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

Subject: Softimage

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

http://vizlab.beckman.uiuc.edu/softimage/
SOFTIMAGE Users Home Page

http://www.softimage.com/
SOFTIMAGE Official Home Page

http://softimage.co.uk/

comp.graphics.apps.softimage

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

Subject: SPIFF - Still Picture Interchange File Format

Type: Bitmap
Extension: JPG, SPF
Version:
Compression: None, JPEG, JBIG, Modified Huffman, MR, MMR
Color Depth:
Maintainer: ITU and ISO
Specification: http://www.itu.doc/

The "official" JPEG file format. Part 3 of the JPEG standard now includes a
fully defined file format to storing JPEG data.

When the JPEG format was standardized, disagreements among ISO committees
prevented a standard JPEG file format from being created. The defacto format
that appeared was JFIF from C-cube Microsystems. The JFIF format, although
now quite wide-spread, is very limited in capability as file formats go.

SPIFF is intended to replace the JFIF file format, adding features (more
colorspaces, a recognized way of including text blocks, and so forth),
and provding a backwards-compatability allowing SPIFF files to be read my
most JPEG/JFIF decoders. JFIF, however, has a five-year head start on SPIFF,
so the likelyhood of it being completely replaced anytime soon is not good.

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

Subject: STL - Stereolithography Interface Format

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

STL files are the native file format of the SLA CAD software created by 3D
Systems of Valencia, CA, USA. STL files may be ASCII or binary in form,
although binary is far more common due to the very large resulting size of
the CAD data when saved to the ASCII format.

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

Subject: TDDD - Imagine Object File Format

Type: 3D
Extension: IFF
Version:
Compression:
Color Depth:
Maintainer:
Specification: http://www.mediatel.lu/mmedia/render/h_imagine1.html

TDDD (3D Data Description) is used by Impulse's Imagine 3.0 for 3D rendering data.
TDDD files contain 3D object definitions and can be extended to describe different
types of object information. TDDD data is stored as FORM TDDD chunks using the
Amiga and Electrnic Arts Interchange File Format (IFF).

Imagine 3.0 also supports a Texture File Format stored as a FORM TFORM chunk
in an IFF file. The spec for this format may be found at:

http://www.mediatel.lu/mmedia/render/h_imagine2.html

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

Subject: TGA - Truevision (Targa) File Format

Type: Bitmap
Extension: TGA
Version:
Compression: None, RLE
Color Depth: 1- to 32-bits (8, 16, 24, and 32 typical)
Maintainer: Truevision Inc.
Specification:

The TGA format is one of the most widely used bitmap file formats for
storage of 24- and 32-bit truecolor images. TGA supports colomaps,
alpha channel, gamma value, postage stamp image, textual information,
and developer-definable data.

Copies of the TGA specification, including a sample code disk, may be
obtained from Truevision:

Truevision Incorporated
7340 Shadeland Station
Indianapolis, IN 46256-39925
Voice: 317.841.0332
Fax: 317.576.7700
BBS: 317.577.8783
FTP: ftp://ftp.truevision.com/
WWW: http://www.truevision.com/

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

Subject: TIFF - Tag Image File Format

Type: Bitmap
Extension: tif, TIFF
Version: 6.0
Compression: Uncompressed, PackBits RLE, LZW, JPEG, CCITT Group 3 & 4
Color Depth: 24-bits
Maintainer: Adobe Systems
Specification: ftp://sgi.com/graphics/tiff/TIFF6.ps.Z

The TIFF format was formerly owned and maintained by the Aldus Developer's
Association. Aldus has since merged with Adobe Systems and now the Adobe
Developers Association (ADA) maintains the TIFF file format. You may obtain a
copy of the TIFF 6.0 specification in PDF format at:

http://www.adobe.com/supportservice/devrelations/PDFS/TN/TIFF6.pdf

Or from the following FTP site:

ftp://sgi.com/graphics/tiff/TIFF6.ps.Z
ftp://ftp.adobe.com//pub/adobe/DeveloperSupport/TechNotes/PDFfiles/TIFF6.pdf

Or in hardcopy from +1.800.831.6395 for a cost of $25US.

A detailed text on TIFF enhancements for Adobe Pagemaker 6.0 is at:

http://www.adobe.com/supportservice/devrelations/PDFS/TN/TIFFPM6.pdf

You can find the specs for TIFF 4.0 and 5.0 at:

ftp://ftp.std.com/obi/Standards/Graphics/Formats/tiff.doc.4.0.Z
ftp://ftp.std.com/obi/Standards/Graphics/Formats/tiff.doc.5.0.Z

General TIFF questions may be asked of the Adobe Developer Support group
at devsup...@adobe.com.

You may also contact the ADA directly at:

Adobe Developer Association
1585 Charleston Road
P.O. Box 7900
Mountain View, CA 94039-7900 USA
Voice: 415-961-4111
FAX: 415-967.9231
BBS: 206-623-6984
FTP: ftp://ftp.adobe.com/
WWW: http://www.adobe.com/Support/ADA.html

And be sure to visit Niles Ritter's The Unofficial TIFF Home Page at:

http://www-mipl.jpl.nasa.gov/~ndr/tiff/

Information on the tag extensions of TIFF 6.0 files for storing
geographical bitmap information (GeoTIFF) may be found at:

http://www-mipl.jpl.nasa.gov/~ndr/cartlab/geotiff/geotiff.html
ftp://mtritter.jpl.nasa.gov/pub/geotiff/

And the GeoTIFF FAQ may be found at:

http://www.mmh.fi/maa/kepa/pos/geotiff/

Note: Any software created or modified after 01 January 1995 that supports
the capability of reading and/or writing bitmapped data stored in a TIFF file
and compressed using the LZW algorithm must obtain a patent license agreement
from Unisys Corporation. See Part I of the FAQ for more details on the Unisys
GIF-LZW and TIFF-LZW license agreements.

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

Subject: TRIF - Tiled Raster Interchange Format

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

TRIF was developed by the Tiling Task Group at the National Institute
for the interchange of tiled raster data. TRIF is very similar to the
CALS Type II raster format and shares many of the same standards documents.

The keeper of TRIF seems to be:

Frankie E. Spielman
National Institute of Standards and Technology
Voice: 301.975.3257

Military standards for TRIF include:

Standards for the Interchange of Large Format Tiled Raster Documents,
NISTIR 88-4017 (December 1988). Section 4, "A Document Application
Profile for the Interchange of Large Format Tiled Raster Documents",
contains the application profile definition of a TRIF coded document.

Requirements for Raster Graphics Representation in Binary Format,
MIL-R-28002A

Automated Interchange of Technical Information, MIL-STD-1840A
(22 December 1987).

Information Processing - Text and Office Systems - Office Document
Architecture (ODA) and Interchange Format - Part 1: Introduction and
General Principles, ISO 8613/1.

Information Processing - Text and Office Systems - Office Document
Architecture (ODA) and Interchange Format - Part 2: Document Structures,
ISO 8613/2.

Information Processing - Text and Office Systems - Office Document
Architecture (ODA) and Interchange Format - Part 4: Document Profile,
ISO 8613/4.

Information Processing - Text and Office Systems - Office Document
Architecture (ODA) and Interchange Format - Part 7: Raster Graphics
Content Architectures - Tiled Raster Graphics Addendum, Addendum to
ISO 8613/7.

Specification of Abstract Syntax Notation One (ASN.1), ISO 8824.

Specification of Basic Encoding Rules for Abstract Notation One (ASN.1),
ISO 8825.

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

Subject: TTF - TrueType Font

Type: Font
Extension: TTF
Version:
Compression:
Color Depth:
Maintainer: Apple Computer
Specification:

The TrueType font file format was created by Apple Computer and is
used on the Macintosh and Microsoft Windows 3 operating environments.
TTF files may be sent to a PostScript interpreter by first converting
them to Adobe Type 42 font files.

The TrueType font file specification is:

The TrueType Font Format Specification 1.0, Apple Programmers and
Developers Association (APDA), P/N M0825LL/A.

This document is available in Windows 3.1 help format and Word for Windows
2.0 format via anonymous FTP from:

ftp://ftp.microsoft.com/developr/drg/TrueType-Info

Information, programs, and code for working with TrueType files may also be
found in this directory.

The OpenType font format (TrueType Open v.2.0) is an extension of the
TrueType font format, allowing support for PostScript font data.
OpenType was developed jointly by Microsoft and Adobe. Other documents
of interest are:

Compact Font Format Specification, Version 1.0. Adobe Systems
TrueType 1.0 Font Files, Technical Specification. Microsoft Corp.

And you can find the Microsoft Typography group at:

Microsoft Typography Web Site

Microsoft Typography group
ttw...@microsoft.com

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

Subject: Type 42 Font Format

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer: Adobe Systems
Specification:

Type 42 is a PostScript font format used to download TrueType fonts to
PostScript interpreters which contain a TrueType rasterizer. A TrueType font
is first converted to a Type 42 format font and then read by a PostScript
interpreter. Type 42 yields better result than if a TrueType font is
converted to the Adobe Type 1 or Type 3 font formats.

The specification for the Type 42 font format is:

The Type 42 Font Format Specification,
Adobe Developer Support, 1 March 1993, P/N LPS5012.

This document available via FTP as a Tech Note in PostScript format,
or as hardcopy when obtained directly from Adobe (see the PostScript
section for information on how to contact Adobe Systems, Inc.).

Additional information on Type 1 fonts may be found in:

Adobe Type 1 Font Format. Addison Wesley, 1991; ISBN 0-201-57044-0.
Technical Note #5015: The Type 1 Font Format Supplement.
Technical Note #5087: Multiple Master Font Programs for the Macintosh.
Technical Note #5088: Font Naming Issues.

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

Subject: URT - Utah Raster Toolkit

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

URT is the native raster file format of the Utah Raster Toolkit. This
toolkit, which first appeared in 1983, is a rich source of bitmap
manipulation tools and source code. The toolkit is copyrighted, but
distributable on a GNU-like license.

The specification for the URT file format is found in the following document
of the Utah Raster Toolkit:

Design of the Utah RLE Format, Thomas, Spencer W., University of Utah,
Department of Computer Science.

The Utah Raster Toolkit distribution (urt-3.0.tar.Z) may be obtained via FTP
from the following sites:

ftp://cs.uath.edu
ftp://weedeater.math.yale.edu
ftp://freebie.engin.umich.edu

Questions about URT may be directed to:

toolkit...@cs.utah.edu
urt-r...@caen.engin.umich.edu

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

Subject: VCA - Visual Clip Art

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer: Superscape &lthttp://www.superscape.com&gt
Specification:


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

Subject: VICAR - Video Image Communication and Retrieval

Type: General data format
Extension:
Version:
Compression:
Color Depth:
Maintainer: NASA
Specification: http://www-mipl.jpl.nasa.gov/vic_file_fmt.html

The VICAR and VICAR2 formats are used to store planetary image data
gathered from Earth and by spacecraft, and are similar in design and
use to the FITS and PDS formats. VICAR is actually a collection of
image processing programs used to analyze image data stored using the
VICAR data format.

Information on VICAR may be obtained directly from JPL:

NASA
Attn: Bob Deen
Image Processing Laboratory
Jet Propulsion Laboratory
4800 Oak Grove Drive
MS 168-414
Pasadena, CA 91109
Email: Bob....@jpl.nasa.gov

Descriptions of the VICAR format may be found at:

ftp://lager.geo.brown.edu/pub/doc/vicar_fmt.txt
http://www-mipl.jpl.nasa.gov/vic_file_fmt.html

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

Subject: VIFF - Visualization Image File Format

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

VIFF is the native bitmap graphics file format of the Khoros System
environment implemented using the X Window System.

The VIFF format specification, including other documents related to the VIFF
format, may be found in the Khoros distribution. Chapter 1 of Volume II,
Programmer's Manual, the files in the directory src/file_formats, and the
viff.h file are the most helpful.

The following FTP sites archive the Khoros distribution:

ftp://ftp.eece.unm.edu/pub/khoros
ftp://ftp.uu.net/pub/window-sys/khoros

The Khoros Consortium may be contacted at:

Khoral Research Inc.
6001 Indian School Road NE
Suite 200
Albuquerque, NM 87110
Voice: 505.837.6500
Fax: 505.881.3842
Email: khoros-...@chama.eece.unm.edu
Email: kho...@chama.eece.unm.edu (User's Group)
Newsgroup: comp.soft-sys.khoros

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

Subject: VIT - VITec Scanner Raster Format

Type: Raster
Extension: .vit
Version:
Compression:
Color Depth:
Maintainer: VITec
Specification:

I have been unable to locate VITec to obtain a .vit file format spec.
If anyone knows their address then please email it to me.

If you have any VITec files that you need converting, the Image Alchemy
file conversion Web page will do it for you. You can find the page at:

http://www.handemadesw.com/hsi/web_alchemy.html

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

Subject: VPF - Vector Product Format

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

VPF is a standard format, structure, and organization for large geographic
databases that are based on a georelational data model. VPF is primarily used
for organizing and encapsulating such digital geographic databases for
transmission. More information on VPF may be found in the newsgroup and FAQ
of comp.infosystems.gis.

The specification for VPF may be found in the following military standard
document:

MIL-STD-600006, Vector Product Format, 13 April 1992

This MIL-STD may be obtained from:

Naval Publications & Forms Center
Code 3051
5801 Tabot Ave.
Philadelphia, PA 19120 USA

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

Subject: VRML - Virtual Reality Modeling Language

Type: VRML
Extension: vrml
Version: 1.0c
Compression:
Color Depth:
Maintainer:
Specification: http://www.eit.com/vrml/vrmlspec.html
http://vrml.wired/com/proposals/labspec.html

VRML is a proposed design based on the Silicon Graphics Open Inventor ASCII
file format. Originally called the Inventor VRML, this format has evolved
into what is now the VRML format.

VRML is also called a "Markup Language" for reasons that it is used in a
fashion similar to HTML (HyperText Markup Language), but for rendering 3D
graphics rather than text. VRML, however, is in no way derived from HTML.

The current VRML specification may be obtained from:

http://www.eit.com/vrml/vrmlspec.html

Other sources of VRML specs include:

http://www.mediatel.lu/mmedia/render/vrml1.0/vrml10-3.html
http://www.mediatel.lu/mmedia/render/vrml1.0c/vrml10c.html

Questions about VRML may be directed to:

Mark Pesce, Enterprise Integration Technology, Inc. <mpe...@netcom.com>
Anthony Parsi, Labyrinth Group <dago...@netcom.com>
Gavin Bell, Silicon Graphics, Inc. <ga...@sgi.com>

The original Inventor-VRML specification may be obtained from:

http://www.sgi.com/Technology/Inventor/VRML/VRMLDesign.html

The Labyrinth VRML specification may be obtained from:

http://vrml.wired.com/proposals.labspec.html

VRML Research and Sample images:

http://www.sdsc.edu/vrml
http://www.sgi.com/FreeStuff/Cool-Scene.vrml

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

Subject: WebOOGL - Web Object Oriented Graphics Library

Type: VRML
Extension: oogl
Version:
Compression:
Color Depth:
Maintainer:
Specification: http://www.geom.umn.edu/docs/weboogl/weboogl.html

WebOOGL is a OOGL-based format used for describing 3D graphics on the World
Wide Web. This format supports the embedding of URL links within 3D objects
and allows multiple WebOOGL objects found at different locations on the Web
to be combined into a single scene.

Additional information om the use of OOGL as a VRML may be obtained from:

http://vrml.wired.com/proposals/oogl.html

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

Subject: WMF - Microsoft Windows Metafile

Type: Metafile
Extension: WMF
Version:
Compression: None
Color Depth:
Maintainer: Microsoft Corporation
Specification:

WMF is the native vector file format for the Microsoft Windows operating
environment. WMF files are actually a collection of GDI (Graphics Device
Interface) function calls also native to the Windows environment. When a WMF
file is "played back" (typically using the Windows PlayMetaFile() function)
the graphics is rendered. WMF files are device-independant and have no limit
to their size.

Most books on Microsoft Windows programming contain sections on the internals
of WMF files. The closest thing Microsoft has for a specification for the WMF
format is in Volume 4 of the Microsoft Windows Software Development Kit
Programmer's Reference. Chapter 3 details the internals of the Metafile
Format.

The Microsoft Knowledge Base (available at ftp://ftp.microsoft.com/kb/ and on the
Microsoft Developer Network CD) also contains the complete specification of
WMF. I also highly recommend the book:

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

ISBN 0-672-30338-8 $24.95 softcover, 337 pages.

The placeable metafile format was created by Aldus Corp. to allow the
positioning of a Windows metafile on a printed page. These metafiles have
a 22-byte header then must be stripped before they can be used by the
Windows API. Have a look at the following Microsoft Knowledge Base article:

http://www.microsoft.com/Softlib/MSLFILES/METAFILE.EXE
This archive contains the METAFILE.HLP help file that describes
the WMF file format.

http://www.microsoft.com/Softlib/MSLFILES/PLAYMETA.EXE
This archive contains sample Windows code to manipulate WMF files.

http://www.microsoft.com/developr/MSDN/OctCD/METAFI.ZIP
This archive contains the METAFI.HLP help file that describes
the WMF file format.

Also have a look at:

http://www.r2m.com/windev/
Internet Resources for Windows Developers

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

Subject: WPG - WordPerfect Graphics Metafile

Type: Metafile
Extension: wpg
Version:
Compression:
Color Depth:
Maintainer:
Specification:

WPG is the native graphics file format of the WordPerfect Corporation line
of software products. For this reason it is common to find WPG files in
MS-DOS, Microsoft Windows, Apple Macintosh, and Unix environments.

WPG files may store bitmapped or vector graphics data, or Encapsulated
PostScript data as well. Bitmapped data may be up to 24-bits deep and
selectable from a palette of 256 colors.

The WPG specification is published in the WordPerfect Corporation
Developer's Toolkit for PC Products. This toolkit is available directly
from WordPerfect Information Services:

WordPerfect Information Services
Voice: 801.225.5000

Technical questions regarding WPG may be directed to:

WordPerfect Manufacturer/Developer Relations Department
Voice: 801.228.7700
Fax: 801.228.7777
CompuServe: 72567,3612

And if all else fails:

WordPerfect Corporation
1555 North Technology Way
Orem, UT 84057
Voice: 800.526.4477
Fax: 801.222.5077
BBS: 801.225.4414

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

Subject: X3D - x3d and xdart Formats

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

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

Subject: XBM - X BitMap

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

XBM is a native file format of The X Window System and is used for storing
cursor and icon bitmaps that are used in the X GUI. XBM files are quite
different in that they are actually C language source files that are
created to be read by a C compiler rather than a graphical display
program.

XBM data is typically found in headers (.h files) and are a series of
static unsigned char arrays containing the monochrome pixel data. There is
one array per image stored in the header.

XBM was created by the X Consortium as part of the X Window System. Refer
to the /bitmaps directory of the X Window distribution for examples of XBM
files. The central FTP distribution site for X version 11 is:

ftp://ftp.x.org

Reference works describing XBM include:

Xlib-C language X Interface, Gettys, James, and Robert W. Scheiffler,
Consortium Standard, X Version 11, Release 5, First Revision, August 1991.

Xlib Programming Manual, Nye, Adrian, third edition, O'Reilly & Associates,
Inc. Sebastopol, CA, 1992.

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

Subject: XOF - RenderMorphics

Type: 3D
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

RenderMorphics created the 3D renderer Reality Lab.
RenderMorphics was aquired by Microsoft in February 1995.
RealityLab is now a core component of Windows95.

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

Subject: XPM - X PixMap

Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
Specification:

XPM is a defacto standard for storing monochome, gray-scale, and color
pixmap data to disk under the X Window system. XPM files, like XBM files,
are C source code files, with each pixmap being defined as a static char
array.

The XPM format was created through the work of the KOALA Project at Groupe
Bull Research. Questions about XPM may be directed to:

BULL Research
c/o INRIA
2004 route des Lucoiles
06565 Valbonne Cedex
France
Email: leh...@sophia.inria.fr

You may subscribe to the XPM mailing list by sending a subscription request
to:

xpm-talk...@sophia.inria.fr

The XPM library (a collection of utilities that read and write XPM files)
version 3.2g (April 1993) may be obtained via FTP from:

ftp://avahi.inria.fr/contrib/xpm.tar.Z
ftp://export.lcs.mit.edu

And a collection of XPM files (mostly icons) resides at:

ftp://ftp.x.org/contrib/AIcons

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

Subject: WSQ - Wavelet-packet Scalar Quantization Format

Type: Bitmap
Extension: .wsq
Version:
Compression: Wavelet
Color Depth: 1-bit
Maintainer: Los Alamos
Specification: ftp://ftp.c3.lanl.gov/pub/WSQ/documents/wsqSpec2.ps.Z

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

Subject: XWD - X Window Dump

Type: Bitmap
Extension: .xwd
Version:
Compression: None
Color Depth: Unlimited
Maintainer: X Consortium
Specification: ftp://ftp.x.org/

XWD is used to store screen dumps created by the xwd client process in the
X Window System. The image of any window or the background may be saved
(dumped) to an XWD file. Using the following command:

xwd -root > bg.xwd

The background is saved to the file bg.xwd. By replacing the "root" flag
with the ID of a window, only that window will be saved to the XWD file.

XWD was created by the X Consortium as part of the X Window System. Refer
to the /usr/include/X11 directory for header files (XWDFile.h) that define
the X10 and X11 versions of the XWD format. The central FTP distribution
site for X version 11 is:

ftp://ftp.x.org

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

Subject: III. Document Sources

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

Subject: 0. U.S. Government and Military Standards Sources

The following organizations provide U.S. Government and Military documents
concerning graphics formats and standards:

Department of Defense
Joint Interoperability Engineering Organization
Center for Standards
10701 Parkridge Boulevard
Reston, VA 22091-4398 USA

Standardization Documents Ordering Desk
700 Robbins Avenue
Building 4D
Philadelphia, PA 19111-5094 USA

Naval Publications & Forms Center
Code 3051
5801 Tabot Ave.
Philadelphia, PA 19120 USA

Defense Information Systems Agency
Center for Standards
Attn: TBCE, Rm 3304
10701 Parkridge Blvd
Reston, VA 22091 USA
Voice: 703.487.3536
Email: e...@itsi.disa.mil

Department of Defense Single Stock Point (DODSSP)
Special Assistance Desk
Open 7:30AM to 4PM EST Mon-Fri
Voice: 215.697.2667
Voice: 215.697.2179

Department of Defense Single Stock Point (DODSSP)
Subscription Services Desk
700 Robbins Avenue
Building 4D
Philadelphia, PA 19111-5094 USA
Voice: 215.697.2569

Navy Print On Demand System (NPODS)
Telespecs automated document ordering system
Open 7AM to 10PM EST Mon-Fri
Voice: 215.697.1187 thru .1198

CALS Policy Office
DASD(S)CALS Pentagon
Room 2B322
Washington, DC 20301

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

Subject: 1. International Standards Document Sources

Many graphics file formats and graphical information transfer protocols are
ANSI/ISO standards and may be obtained through the following offices:

International Standards Organization (ISO)
1 rue de Varembe
Case Postal 56
CH-1211 Geneva 20
Switzerland
Voice: 011 41 22 749 0111
Fax: 011 41 22 733 3430
WWW: http://www.iso.ch/

American National Standards Institute (ANSI)
Customer Service
11 West 42nd Street, 13th Floor
New York, NY 10036 USA
Voice: 212.642.4900
Fax: 212.398.0023
Fax: 212.302.1286 (sales)
Email: jho...@ansi.org
WWW: http://www.ansi.org/

Canadian Standards Association (CSA)
Sales Group
178 Rexdale Boulevard
Rexdale, Ontario, M9W 1R3
Voice: 416.747.4058
Fax: 416.747.4149
WWW: http://www.csa.ca/

International Telecommunication Union (ITU)
Information Services Department
Place des Nations
CH 1211 Geneva 20
Switzerland
Voice: 011 41 22 730-6666 or 730-5554
Fax: 011 41 22 730-5337
Email: help...@itu.ch
X.400: S=helpdesk; A=arcom; P=itu; C=ch
WWW: http://www.itu.ch/

International Electrotechnical Commission (IEC)
3 rue de Varembe
CH 1211 Geneva 20
Switzerland
Voice: 011 41 22 919 0211
Fax: 011 41 22 919 0301
FTP: ftp://ftp.iec.ch/
WWW: http://www.iec.ch/

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

Subject: 2. Commercial Document Sources

Global Engineering Documents
2805 McGaw Avenue
Irvine, CA 92714 USA
Voice: 800.854.7179
Voice: 714.261.1455
Fax: 202.331.0960

Global Info Center
18201 McDurmott West
Suite B
Irvine, CA 92714 USA
Voice: 714.474.5070
Fax: 714.474.4066

Document Center
1504 Industry Way, Unit 9
Belmont, CA 94002 USA
Voice: 415.591.7600
Fax: 415.591.7617

Phillips Business Information
1201 Seven Locks Road
Potomac, MD 20854 USSA
Voice: 301.424.3338
Voice: 800.777.5006
Fax: 301.309.3847
Email: clientser...@phillips.com
WWW: http://www.phillips.com/

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

Subject: 3. Other Standards Sources

Here's a collection of Web site pointers to many other standards
organizations. You can also find more information in the Usenet
Standards FAQ posted to the comp.protocols.iso, comp.std.misc,
comp.std.internat, comp.answers, and news.answers newgroups.

http://www.smartpages.com/faqs/standards-faq/faq.html
http://www.ansi.org/resource.html
http://www.iso.ch/stbodies.html
http://stdbbs.ieee.org/faqs/othstdsorg.html

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

Subject: IV. Kudos and Assertions

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

Subject: 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):

Bjorn P. Brox <br...@corena.no>
Mike Beanes <mi...@virage.com>
John Cristy <cri...@magick.es.dupont.com>
Michael Dillon <mic...@memra.com>
Ben Discoe <b...@sense8.com>
James Durham <dur...@CC.IMS.DISA.MIL>
Bruce Garner <gar...@tis.llnl.gov>
Eric Haines <er...@eye.com>
Glenn Herteg <gl...@ia-us.com>
Chris Komnick <kom...@group42.com>
Tom Lane <t...@netcom.com>
Stanley F. Quayle <qua...@scriptel.com>
Glenn Randers-Pehrson <gle...@arl.mil>
Jonathan Shekter <jshe...@interlog.com>
Marc Soucy <mso...@imetric.qc.ca>

Reply all
Reply to author
Forward
0 new messages