Path: news1.ucsd.edu!ihnp4.ucsd.edu!swrinde!howland.erols.net!cam-news-hub1.bbnplanet.com!prod.mpi.com!news3.near.net!amber.ora.com!not-for-mail
From: jdm@ora.com
Newsgroups: comp.graphics.misc,comp.answers,news.answers
Subject: Graphics File Formats FAQ (Part 1 of 4): General Graphics Format Questions
Supersedes: <graphics/fileformats-faq-1-838937736@ora.com>
Followup-To: poster
Date: 8 Sep 1996 12:38:31 -0700
Organization: O'Reilly & Associates, Inc.
Lines: 2047
Sender: jdm@ruby.ora.com
Approved: news-answers-request@MIT.EDU
Distribution: world
Expires: 10/13/96 12:38:30
Message-ID: <graphics/fileformats-faq-1-842211510@ora.com>
Reply-To: jdm@ora.com (James D. Murray)
NNTP-Posting-Host: ruby.ora.com
Summary: This document answers many of the most frequently asked
questions about graphics file formats on Usenet.
Keywords: FAQ, GRAPHICS, FORMAT, IMAGE, MULTIMEDIA, 3D
Xref: news1.ucsd.edu comp.graphics.misc:8987 comp.answers:16233 news.answers:64949
Posted-By: auto-faq 3.1.1.2
Archive-name: graphics/fileformats-faq/part1
Posting-Frequency: monthly
Last-modified: 01Sep96
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
jdm@ora.com. Relevant information posted to newsgroups will not
automatically make it into this FAQ.
-- James D. Murray
------------------------------
Subject: 0. Contents of General Graphics Format Questions
Subjects marked with <NEW> are new to this FAQ. Subjects marked with <UPD>
have been updated since the last release of this FAQ.
I. General questions about this FAQ
0. Maintainer's Comments
1. What's new in this latest FAQ release?
2. Why does a graphics formats FAQ exist?
3. Where can I get the latest copy of this FAQ?
4. Are there other related FAQs I should read as well?
5. I have a question, correction, or some information for this FAQ.
6. This FAQ doesn't contain enough detail!
7. Why isn't the XXX file format covered?
8. Why aren't audio file formats covered?
9. Why aren't word processing formats covered?
10. What about multimedia file formats?
11. What is an "Internet File Format?"
12. Which file formats should I and should I not use?
13. What is ray tracing?
II. General Graphics File Questions
0. Who cares about graphics file formats?
1. What is raster, vector, metafile, PDL, VRML, and so forth?
2. Why should I care about previous versions of a file format?
3. Can graphics files be infected with a virus?
4. Can graphics files be encrypted?
5. How can I convert the XXX format to the YYY format?
6. Do I really need the specification of the format I'm using?
7. How can I tell if a graphics file is corrupt?
8. What do I put in my own graphics file format specification?
III. Working with Graphics Files on Usenet and the Internet
0. How can I email a graphics file?
1. Where can I find graphics files on Usenet?
2. How do I decode a graphics file posted to Usenet?
3. How can I post a graphics file to Usenet?
4. How do I submit a file format specification to an archive?
5. How can I make transparent and interlaced GIFs for a Web page?
6. How do I combine still images to make animations?
IV. Copyrights, Patents, and other Legalities of Graphics File Formats
0. Can a graphics file be copyrighted?
1. Is it now illegal to use CompuServe's GIF format?
V. Graphics Formats Misnomers, Misgivings, and Miscellany
0. Why aren't JPEG, MPEG, LZW, and CCITT Group 3 & 4 file formats?
1. Why aren't IGES, GKS, NAPLPS, PCL, and HPGL file formats either?
2. Is it "Tag" or "Tagged" Image File Format?
3. Whaddya mean there's no "Targa" file format?
4. Choosy programmers choose "gif" or "jif"?
5. Why are there so many ".PIC" and ".IMG" formats?
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
New GFF FAQ Web page!
http://www.ora.com/centers/gff/gff-faq/
------------------------------
Subject: 1. What's new in this latest FAQ release?
o Five new file format information Web sites
------------------------------
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-server@rtfm.mit.edu with the body:
send usenet/news.answers/graphics/fileformats-faq/part1
send usenet/news.answers/graphics/fileformats-faq/part2
send usenet/news.answers/graphics/fileformats-faq/part3
send usenet/news.answers/graphics/fileformats-faq/part4
or via UUCP:
uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part1
uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part2
uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part3
uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part4
Other sites on the World Wide Web that archive this FAQ include:
http://www.jazzie.com/ii/internet/faqs.html
http://www.cs.ruu.nl/wais/html/na-dir/graphics/fileformats-faq/.html
http://www.lib.ox.ac.uk/search/search_faqs.html
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-server@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 jdm@ora.com.
I don't always read the newsgroups this FAQ is posted to, so please contact
me directly via email rather than attempting to reach me by posting to a
newsgroup. All suggestions and contributions within the scope of this FAQ
are welcome and contributors receive full credit in the Acknowledgments
section of this FAQ.
------------------------------
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
<guido@cnri.reston.va.us>
or <guido@python.org>.
You may obtain this FAQ from the Usenet newsgroups comp.dsp, comp.answers, and news.answers, from the FTP archive sites:
ftp://ftp.cwi.nl/pub/audio/
ftp://rtfm.mit.edu/pub/usenet/news.answers/comp.dsp/
or via the Web page:
http://www.cwi.nl/ftp/audio/AudioFormats.part1/
http://www.cwi.nl/ftp/audio/AudioFormats.part2/
The FAQ for comp.speech may of also be of interest to audio people. It is
available at:
ftp://rtfm.mit.edu/pub/usenet/news.answers/comp-speech-faq/
ftp://svr-ftp.eng.cam.ac.uk/pub/comp.speech/FAQ-complete
------------------------------
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 user@host.site
This command will pipe the output of the uuencode command to the input of
an email program. Realize that if your email program is set up to keep a
copy of all of the email you send, and you email a lot of uuencoded
graphics files, your outgoing email folder will grow quite large. You can
modify your .mailrc (or equivalent) file to route the copy of the outgoing
graphics file to /dev/null, or you can write-protect your outgoing mail
folder so the data can't be written:
% chmod -w ~/Mail/mbox.out
% uuencode picture.img picture.img | Mail user@host.site
/home/Mail/mbox.out: Permission denied
% chmod +w ~/Mail/mbox.out
Once the emailed data is received, you will need to strip off the mailing
header before you can uudecode it. The uuencoded data starts with the word
"begin" and is followed by the file mode, file name, and a series of
61-character lines. The file is ASCII, so you can use an editor such as vi
to do the stripping. Assuming the received data is saved to a file named
"file", the uudecoing process is thus:
% uudecode file
The original graphics file is now in the current directory. You may delete
the uuencoded file if you wish to do so.
The uuencode and uudecode programs have been ported to other systems, such
as MS-DOS, MS Windows, OS/2, Amiga, and the Macintosh (the BinHex program
for the Mac does not produce the same ASCII data as uuencode), and may be
used in the same way.
For more information on accessing the Internet via email, please refer to
the FAQ "Accessing The Internet By E-Mail: Doctor Bob's Guide to Offline
Internet Access", found on the news.answers and alt.internet.services Usenet
newsgroups and your favorite FAQ archives.
------------------------------
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_info@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: info@infomedia.com
http://www.jpl.nasa.gov/galileo/
Galileo Mission to Jupiter Images
http://www.kodak.com/digitalImages/samples/samples.shtml
Kodak Sample Digital Images archive
http://www.kodak.com/digitalImaging/cyberScene/sites.shtml
Kodak Image Archive Sites
http://www.lightside.com/~dani/cgi/images-index.html
3DWEB - World Wide Web site for 3D Computer Graphics
http://www.picker.com/pgw
Picker Graphic Workstations
http://www.sd.tgs.com/~template
Web3D - World Wide Web site for 3D Graphics
http://www.seas.gwu.edu/faculty/musgrave/art_gallery.html
A gallery collection of fractal artwork by Ken Musgrave
http://www.state51.co.uk/state51/
State51 Interactive Media
http://www.viewpoint.com
Large collection of 3D models
http://www.webcity.co.jp/info/andoh/vrml/geom_trans.html
VRML Repository
http://www.wimsey.com/PhotoModeler/
Many links to 3D Technology topics
------------------------------
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.
agocg-ip@mailbase.ac.uk
Discussion of all aspects of image processing. To subscribe:
send an email message to mailbase@mailbase.ac.uk with the body
"join agocg-ip yourfirstname yourlastname".
digvid-l@ucdavis.edu
Discussion of digital video, mostly of the desktop variety.
To subscribe: send an email message to listserv@ucdavis.edu
with the body: "subscribe digvid-l yourfirstname yourlastname".
geotiff@tazboy.jpl.nasa.gov.
Discussion regarding the establishment of a set of TIFF tags for
storing geographic map projection information, such as UTM zones,
Lambert Standard parallels, etc. Participants include
representatives from SPOT, Intergraph, ERDAS, ESRI, and USGS. To
subscribe: send an email message to geotiff-request@tazboy.jpl.nasa.gov.
graphuk@cs.man.ac.uk
GraphUK mailing list. Discussion of graphics systems such as PHIGS
and GKS, and training in the area of graphics. To subscribe: send an
email message to graphuk-request@cs.man.ac.uk with the body "subscribe
graphuk".
illstrtr-l@netcom.com
Adobe Illustrator mailing list. Discussion of the Adobe Illustrator
application and issues related to its use. To subscribe: send an email
message to listserv@netcom.com with the body "subscribe illstrtr-l".
info-ei@spie.org
SPIE's Electronic Imaging Listserver. Discussion of electronic imaging.
To subscribe: send an email message to info-ei-request@spie.org with
the body "SUBSCRIBE INFO-EI". A complete listing of SPIE's online
services may be obtained by sending email to info-optolink-request@spie.org
with the word HELP in the message body.
lexicor@lexicor.com
Discussion of Atari computer graphics, hardware, software, programming,
and formats for graphics and animation (2D and 3D). To subscribe: send
an email message to lexicor-list-request@lexicor.com with the body
"subscribe youremailaddress".
listserv@info.kodak.com
Information on the Kodak Photo-CD format. To subscribe: send an
email message to listserv@info.kodak.com with the body:
"INFO PHOTO-CD".
listserv@soils.umn.edu
NIH image processing discussion. To subscribe: send an email message
to listserv@soils.umn.edu with the body "subscribe nih-image
yourfirstname yourlastname". You may seach past messages of this list
by using http://rsb.info.nih.gov/nih-image/faq.html#Searching
medimage@polygraf
Medical imaging discussion. To subscribe: send an email message
to listserv%polygraf.bitnet@mitvma.mit.edu with the body
"subscribe medimage".
nucmed@uwovax.uwo.ca
Nuclear medicine and medical imaging discussion. To subscribe:
send an email message to nucmed-request@uwovax.uwo.ca with the
body "subscribe nucmed".
PhotoForum@listserver.isc.rit.edu
Photographic and imaging discussions of aesthetics, processes
instructional strategies, techniques, criticism, equipment, history,
electronic imaging, ethics, and educational topics. To subscribe: send
an email message to LISTSERV@LISTSERVER.ISC.RIT.EDU with the body
"SUBSCRIBE PhotoForum yourfirstname yourlastname".
pixel@essex.ac.uk
British Machine Vision Association newsletter for machine vision,
image processing, pattern recognition, remote sensing, etc. To
subscribe: send an email message to pixel-request@essex.ac.uk.
png-list@dworkin.wustl.edu
png-announce@dworkin.wustl.edu
png-implement@dworkin.wustl.edu
PNG file format mailing lists. These lists contain a general discussion
of PNG, announcements related to PNG, and discussions regarding PNG
PNG implementation. To subscribe: send an email message to
png-list-request@dworkin.wustl.edu with "help" in the body.
ximage@expo.lcs.mit.edu
Discussion of image processing using The X Window System. To
subscribe send an email message to ximage-request@expo.lcs.mit.edu
with the body "subscribe ximage".
------------------------------
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: order@ora.com, 800.998.9938 voice, 707.829.014 fax.
Visit http://www.ora.com/www/item/gffcd.html for more information.
File Formats for Popular PC Software: A Programmer's Reference,
Walden, Jeff, John Wiley & Sons, Inc. 1986. ISBN 0-471-83671-0,
287 pages.
File Format Handbook, Allen G. Taylor, Microtrend Books 1992.
The File Format Handbook, Guenter Born, International Thomson Computer
Press 1995. ISBN 1-850-32128-0, 1-85032-117-5, $79.95 hardcover,
1274 pages. Order: sales@clbooks.com, http://www.clbooks.com
Graphical Treasures on the Internet, Bridget Mintz Testa, AP Profesional.
ISBN 0-12-685375-4, $29.95US softcover, 428 pages.
Order: mailto:app@acad.com or http://www.apnet.com/approfessional
Graphics File Formats (2nd ed.), David C. Kay and John R. Levine,
Windcrest Books/McGraw-Hill 1995. ISBN 0-07-034025-0, $26.95
softcover, 476 pages.
Order: Tab Software Department, Blue Ridge Summit, PA 17294-0850.
Graphics File Formats: Reference and Guide, C. Wayne Brown and
Barry J. Shepherd, Manning Publications 1994.
The Graphic File Toolkit: Converting and Using Graphic Files,
Steve Rimmer, Addison-Wesley, 1992. 335 pages.
High-Resolution Graphics Display Systems, Jon Peddie,
Windcrest Books/McGraw-Hill 1994. ISBN 0-8306-4292-7,
ISBN 0-8306-4291-9 $34.95 softcover
Inside Windows File Formats, Tom Swan, Sams Publishing 1993.
ISBN 0-672-30338-8 $24.95 softcover, 337 pages and 1 disk (3.5 in.).
Order: Sams Publishing, 2201 West 103rd Street, Indianapolis,
IN 46290
Internet File Formats, Tim Kientzle, The Coriolis Group 1995.
ISBN 1-883577-56-X $39.99 softcover, 398 pages and one CD.
Order: 7339 E. Acoma Drive, Suite 7, Scottsdale, AZ 85260.
800.410.0192, 602.483.0192
The Internet Voyeur, Jim Howard, Sybex, 1995. ISBN 0-7821-1655-8.
369 pages, $19.99 softcover + PC/Windows disk. More info at
http://infolane.com/infolane/deej/voyeur.html
More File Formats for Popular PC Software: A Programmer's Reference,
Jeff Walden, John Wiley and Sons 1987. 369 pages.
Multimedia File Formats on the Internet: A Beginner's Guide for PC Users,
Allison Zhang, Special Libraries Association 1995.
PC File Formats & Conversions, Ralf Kussmann, Abacus 1990. 287 pages
and 1 disk (5.25 in.).
PC Graphics with GKS, P.R. Bono, J.L. Encarnacao and W.R. Herzner,
Prentice-Hall 1990.
PostScript Language Reference Manual, Adobe Systems Inc. (2nd ed.),
Ed Taft and Jeff Walden, Addison-Wesley 1990.
The Programmer's PC Sourcebook, Thom Hogan, Microsoft Press, 1988.
Programming for Graphics Files in C and C++, by John R. Levine,
John Wiley & Sons 1994. ISBN 0-471-59854-2, $29.95 softcover,
494 pages.
------------------------------
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 <garner@tis.llnl.gov>
Oliver Grau <grau@tnt.uni-hannover.de>
John T. Grieggs <grieggs@netcom.com>
Lee Kimmelman <lee.kimmelman@twwde.com>
David Kuo <dkuo@dabulls.kodak.com>
Tom Lane <tgl@netcom.com>
Angus Montgomery <angus@cgl.citri.edu.au>
Glen Ozymok <oz@ludwig.virtualprototypes.ca>
Greg Roelofs <newt@uchicago.edu>
Rsiw <rsiw@aol.com>
Daniel Sears <sears@netcom.com>
Marc Soucy <msoucy@imetric.qc.ca>
Bjoern Stabell <bjoerns@acm.org>
Mark T. Starr <StarrMT@po4.bb.unisys.com>
------------------------------
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 jdm@ora.com,
or via U.S. Snail at: P.O. Box 70, Orange, CA 92666-0070 USA.
------------------------------
Subject: 2. Disclaimer
While every effort has been taken to insure the accuracy of the
information contained in this FAQ list compilation, the author and
contributors assume no responsibility for errors or omissions, or for
damages resulting from the use of the information contained herein.
------------------------------
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.
------------------------------
----------------------------------------------------------------------
Path: news1.ucsd.edu!ihnp4.ucsd.edu!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!imci5!pull-feed.internetmci.com!newsfeed.internetmci.com!howland.erols.net!cam-news-hub1.bbnplanet.com!prod.mpi.com!news3.near.net!amber.ora.com!not-for-mail
From: jdm@ora.com
Newsgroups: comp.graphics.misc,comp.answers,news.answers
Subject: Graphics File Formats FAQ (Part 2 of 4): Image Conversion and Display Programs
Supersedes: <graphics/fileformats-faq-2-838937736@ora.com>
Followup-To: poster
Date: 8 Sep 1996 12:38:37 -0700
Organization: O'Reilly & Associates, Inc.
Lines: 1143
Sender: jdm@ruby.ora.com
Approved: news-answers-request@MIT.EDU
Distribution: world
Expires: 10/13/96 12:38:30
Message-ID: <graphics/fileformats-faq-2-842211510@ora.com>
References: <graphics/fileformats-faq-1-842211510@ora.com>
Reply-To: jdm@ora.com (James D. Murray)
NNTP-Posting-Host: ruby.ora.com
Summary: This document answers many of the most frequently asked
questions about graphics file formats on Usenet.
Keywords: FAQ, GRAPHICS, FORMAT, IMAGE, MULTIMEDIA, 3D
Xref: news1.ucsd.edu comp.graphics.misc:8985 comp.answers:16231 news.answers:64947
Posted-By: auto-faq 3.1.1.2
Archive-name: graphics/fileformats-faq/part2
Posting-Frequency: monthly
Last-modified: 01Sep96
Graphics File Formats FAQ (Part 2 of 4): Image Conversion and Display
Programs
------------------------------
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
jdm@ora.com. Relevant information posted to newsgroups will not
automatically make it into this FAQ.
-- James D. Murray
------------------------------
Subject: 0. Contents of Image Conversion and Display Programs
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. Graphics Conversion and Display Programs
0. Image Conversion and Display Programs for MS-DOS
1. Image Conversion and Display Programs for Windows and OS/2
2. Image Conversion and Display Programs for Macintosh
3. Image Conversion and Display Programs for Unix and X Window
4. Image Conversion and Display Programs for Amiga
5. Platform-Independent Image Conversion Toolkits
III. FTP and WWW Graphics Software Archives
0. Graphics Software Archives for MS-DOS
1. Graphics Software Archives for Windows and OS/2
2. Graphics Software Archives for Macintosh
3. Graphics Software Archives for Unix and X Window
4. Graphics Software Archives for Amiga
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
This FAQ is for all of you looking for that special display or image
conversion program to run on your system and to work with all those
graphics files you've been downloading from the alt.binaries.pictures.*
newgroups for whose-knows-what reasons.
If you know of any MS-DOS/Windows/Unix/X/Macintosh/Amiga graphical
display, editing, or translation programs or application that are not
listed here then send me the information! I'm also willing to start
sections on VMS, NeXTStep, Atari ST, or just about any other operating
system that the masses demand.
------------------------------
Subject: 1. What's new in this latest FAQ release?
o A few small updates
------------------------------
Subject: II. Graphics Conversion and Display Programs
------------------------------
Subject: 0. Image Conversion and Display Programs for MS-DOS
Name: DISPLAY
Purpose: Image display and conversion
Version: 1.88
Author: Jih-Shin Ho <u7711501@bicmos.ee.nctu.edu.tw>
FTP: ftp://ftp.edu.tw/PC/graphics/disp/disp188?.zip
Imports: GIF, Japan MAG, Japan PIC, Sun Raster, JPEG, XBM, Utah RLE,
PBM, PGM, PPM, PM, PCX, Japan MKI, TIFF, TGA, XPM, Mac Paint,
GEM/IMG, IFF/ILBM, BMP, QRT, Mac PICT, VIS, PDS, VIKING, VICAR,
FITS, Usenix FACE, IRIS, YUV, RAW RGB, PCPAINT/Pictor, RAW GREY,
Photo-CD, DL, FLI, FLC, RAW, MPEG, AVI, GL, and PNG.
Exports: GIF, Sun Raster, JPEG, XBM, PBM, PGM, PPM, PM, Tiff, Targa,
XPM, Mac Paint, Ascii, Laser Jet, IFF/ILBM, Windows BMP,
Mac PICT, VIS, FITS, FACE, PCX, GEM/IMG, IRIS, YUV, RAW RGB,
Postscript, RAW GREY, and PNG.
Features: Batch conversion, image preview, command-line configuration,
contact sheet creation, slide shows.
Comments: I am impressed with the large number of file formats
supported, including all of their eccentric variations, and
several formats I have not seen supported in other packages.
The DOS file directory navigation and maintenance features are
easy to use and the command line usage is very convenient,
especially for batch format conversions of images.
Name: GIFBLAST - Lossless GIF file compressor
See GIFBLAST entry in the "Image Conversion and Display Programs
for Unix and X Window" section.
Name: GIFLITE
Purpose: Lossy GIF file reencoder
Version: 1.00 (Shareware)
Author: Mr. Tsung Hu <72070.3515@compuserve.com>
P.O.Box 938, Unit 105, St. Catharines, Ontario, L2R 6Z4 Canada
FTP: ftp://ftp.wustl.edu/systems/ibmpc/garbo.uwasa.fi/gifutil/glite10.zip
Imports: GIF
Exports: GIF
Features: Lossy reencoding of GIF files providing a 15%-30% reduction in
file size. Reencoded files are readable by GIF file viewers and
conform to GIF87a or GIF89a format specifcation. Three levels
of compression. Dithered images, and images with fewer than 16
colors, do not compress well.
Name: Graphics Display System (GDS)
Purpose: Image display, conversion, thumbnail catalogs
Version: 3.1e
Author: Photodex Corporation <photodex@netcom.com>
FTP: ftp://ftp.netcom.com/pub/ph/photodex
CIS: GO PHOTODEX, GDS Viewing Software (Lib 3)
Imports: ANS (ANSI text), BBM, BMF, BMP, CUT/PAL (Dr. Halo), DIB, DL,
FLC, FLI, FLX, GDS, GIF, GL, HAM, ICO, IFF/ILBM, IMG, JFI,
JPG (JFIF), LBM, MAC, MP2 & MPA (MPEG Audio), MPG, PCC,
PCX, RAX, RFX, RLE, SC? (ColoRIX), TGA, TIFF and TXT (text).
Exports: ANS (ANSI text), BBM, BMP, CUT/PAL (Dr. Halo), GDS, GIF,
IFF/ILBM, IMG, JFI, JPG (JFIF), LBM, PCC, PCX, RAX, RFX,
RLE, SC? (ColoRIX), TGA, and TIFF.
Features: File viewing, batch conversions, easy thumbnail catalog
creation with many options, slide shows, automatic
configuration. Includes 5000+ lines of hypertext help
and prints 98 page cross referenced manual. Supports HGC,
CGA, EGA, S-EGA, VGA, SVGA, XGA, TIGA and VESA. Registered
versions print to HP PCL & 100% compatible laser and inkjet
printers.
Comments: Used by CompuServe sysops to catalog over 40,000 images
regularly. ASP approved shareware.
Name: pbmplus - Portable Bitmap Utilities (MS-DOS version)
Purpose: Graphical file format conversion
Version: 1.91d (10 December 1991)
Author: Mike Castle <mcastle@cs.umr.edu> and D.J. Delorie <dj@ctron.com>
FTP: ftp://oak.oakland.edu/pub/msdos/graphics/pbmp191d.zip
Imports:
Exports:
Name: NView
Purpose: Graphics file viewer
Version: 1.5
Author: Jacques Nomssi Nzali <nomssi@physik.tu-chemnitz.de>
FTP: ftp://oak.oakland.edu/SimTel/msdos/graphics/nview150.zip
WWW: http://www.tu-chemnitz.de/~nomssi/nview150.zip
Imports:
Exports:
Name: PICTOPS
Purpose: Image conversion to PostScript Level-2
Version: 3.11 (2.22 Shareware)
Author: Dr. Igor Vassiliev <vasiliev_i@mx.ihep.su>
FTP: ftp://oak.oakland.edu/SimTel/msdos/graphics/magps311.zip
ftp://garbo.uwasa.fi/pc/graphics/magps311.zip
Imports: BMP, GIF, ICO, PCX, PBM, PGM, PPM, RLE, TGA
Exports: Compressed PostScript within Level 2 & 1
Features: PICTOPS V3.00 converts 1-, 4-, and 8-bit image files to color,
gray scale, and bi-level PostScript file format. Uses
PostScript Level 2 implementation and compression
(RunLengthEncode, LZWEncode, ASCIIHexEncode and ASCII85Encode
filters). Creation of both ASCII and binary PostScript file.
Image source data may be provided by string,procedure or
filter. PostScript color features support simple 5-operand form
of the image, 7-operand form colorimage, and image dictionaries.
Comments: Output from PICTOPS may be larger or smaller than standard
PostScript Level 1 output. PKZIP and ARJ compresses PICTOPS
output from 5-20%.
Name: TN-Image
Purpose: Image analysis software
Version: 2.09 (Shareware)
Author: tjnelson@helix.nih.gov
FTP: ftp://las2.ninds.nih.gov or ftp://las1.ninds.nih.gov
Imports: TIF (Mac or PC), PCX, JPEG, TGA, BMP, GIF, IMG, ASCII, and raw
bytes; all pixel depths from 1-32 bits/pixel, including CMYL,
medical grayscale images, and unusual color formats.
Exports: TIF, PCX, JPEG, TGA, BMP, IMG, and custom file formats. Saves
images in 1-32 bits/pixel as RGB, pseudocolor, CMYK, or grayscale.
FFT data can be saved in ASCII format.
Features: Menu driven GUI interface, many image editing operations, and
analysis features (calibration, strip/spot densitometry, area and
distance measurement, automatic background subtraction, 2D FFT,
image reconstruction using Fourier convolution and deconvolution,
automatic detection and quantitation of bands, spots, rectangular
areas and arbitrarily-shaped regions, and user-definable equations
for point manipulation). Programmable macro language, batch mode,
image inter-conversion. Tutorials for deconvolution, densitometry,
and macro programming.
------------------------------
Subject: 1. Image Conversion and Display Programs for Windows and OS/2
Name: Crystal Kaleidoscope
Purpose: High-end Video Graphics Suite
Version:
Author: CrystalGraphics, Inc.,
3110 Patrick Henry Drive, Santa Clara, CA 95054.
Voice: 1.800.TOPAS.3D; Fax: 408.496.0970
Contact: Debbie Derana, Director, Customer Relations
Voice: 408.496.6175
TechExport for international dealers
Voice: 617.229.6900
Cost: US$1995 (USA)
Features: Built on the Crystal TOPAS Professional 5.1 3D modeling,
rendering and animation package. Other packages bundled into this
suite include: TOPAS Network Renderer, Elastic Reality 1.01
morphing and special effects package from Elastic Reality, Inc.,
Kai's Power Tools" 2.0 Windows SE version from HSC Software,
Leadview 3.0 from LEAD Technologies, Inc., Fractal Design Painter"
3 for Windows from Fractal Design Corporation, and offers from
several other industry-leading manufacturers for CD-ROMs full of
images, textures and backgrounds are included from IMAGETECTS
(ImageCELs), Artbeats (Prelude), CrystalGraphics (Crystal GEMS),
and the 3D model CD-ROM catalog from Viewpoint is included.
Name: Generlised Bitmap Module
Purpose: Image display and conversion
Version:
Platform: OS/2
Author: Andy Key <ak@nyangau.aladdin.co.uk>
FTP: ftp://hobbes.nmsu.edu/pub/os2/32bit/graphics/gbm.zip (OS/2 exes)
ftp://hobbes.nmsu.edu/pub/os2/32bit/graphics/gbmsrc.zip (source)
Imports: Bitmap, GIF, PCX, TIFF, Targa, ILBM, YUV12C, Graymap, Pixmap,
KIPS, IAX, XBitmap, Sprite, PSEG, GemRas and Portrait
Exports: Bitmap, GIF, PCX, TIFF, Targa, ILBM, YUV12C, Graymap, Pixmap,
KIPS, IAX, XBitmap, Sprite, PSEG, GemRas and Portrait
Features: Batch conversion, full portable source available, library with
format independent loading/saving, reflect, rotate, crop, map to
common palette, error-diffuse, halftoning, median-cut, scaling,
gamma/colour-space conversion, map to common or slightly differing
(frame-to-frame) palettes for animations, fullscreen animation
viewer, simple and sophisticated PM viewers.
Name: Graphics Viewer
Purpose: Graphics file display and printing utility
Version: 2.1
Author: Joe Oliphant <joe_oliphant@csufresno.edu>
<71742.1451@compuserve.com>
FTP: ftp://ftp.winsite.com/pub/pc/win3/desktop/GV21.ZIP
CIS: MSBASIC forum
Imports: ART, BMP, CUT, DIB. GEM, GIF, HRZ, IFF, IMG, JPG, LBM, MAC, MSP,
PCX, PIC, RAS, RLE, TGA, TIF, WMF, and WPG
Features: Full Visual Basic and C source code included.
Name: GraphX Viewer
Purpose: Image Display, Conversion, Thumbnails, Editing
Version: 1.5
Platforms: Windows, Windows 3.11, Windows NT, SCO-Open Desktop, SunOS,
Solaris, HPUX, AIX, and DGUX
Author: Group 42, Inc.
Voice: 800.520.0042, 513.831.3400; Email: info@group42.com
FTP: ftp://ftp.group42.com/pub/gviewer/
WWW: http://www.group42.com
CIS: GO GRAPHICS, Library 3
Cost: $49 Windows, $99 Unix
Imports: OS/2 BMP, Windows BMP, GIF, JPEG, PCX, PNG, Sun Raster, TGA,
TIFF (raw, RLE, G3 & G4, LZW), XWD, and UUE/XXE encoded.
Exports: OS/2 BMP, Windows BMP, GIF ([non]interlaced), JPEG, PCX,
PostScript (Levels 1 & 2), PNG, Sun Raster, TGA, TIFF (raw, RLE,
G3 & G4, LZW), XWD, and UUE/XXE decoding (single and multi-part)
Features: Excellent 8-bit display of 24-bit images, color and size
reduction, image filters and adjustment, thumbnail catalog
creation and management, "smart" decoder for multi-part
UUE/XXE files, contact sheet creation, extensive help, SDI
support for Enhanced Mosaic. Export options include color
reductions for all format specific color levels (1, 4, 8, 16,
24-bit color and gray scale).
Name: Hijaak Graphics Suite
Purpose: Graphics file editing, browsing, and conversion tools
Version: 3.0
Author: Inset Systems Inc., 71 Commerce Drive, Brookfield, CT 06804 USA
Voice: 203.740.2400; Fax: 203-775-5634
Programs: Hijaak Pro 3.0 (Image file conversion)
Hijaak TouchUp 3.0 (Desktop publishing and image editing)
Hijaak Browser 3.0 (Graphics file manager)
Hijaak Draw 3.0 (Vector drawing and illustration tool)
Cost:
Formats: Hijaak Pro - AI, ATT, BMP, CAL, CDR, CLP, CPR, CUT, DBX, DRW, DXF,
DIB, ED5, ED6, EPS, FAX, GCA, GED, GEM, GIF, ICA, ICO, IFF, IGA,
IGF, IMG, JPG, KFX, MAC, MSP, NIF, P10, PCL, PICT1, PICT2, PCX,
PDW, PGL, PIC, PIX, RAS, RLC, RLE, SBP, TGA, TIF, TXT, WMF, WPG
Hijaak TouchUp - BMP, CUT GIF, IMG, JPG, MSP, PCD, PCX, TGA, TIF
Hijaak Browser - AI, ATT, BMP, CAL, CDR, CLP, CPR, CUT, DBX, DRW,
DXF, DIB, ED5, ED6, EPS, FAX, GCA, GED, GEM, GIF, ICA, ICO, IFF,
IGA, IGF, IMG, JPG, KFX, MAC, MSP, P10, PCL, PICT1, PICT2, PCX,
PDW, PIC, PCX, RAS, RLC, RLE, SBP, TGA, TIF, TXT, WMF, WPG
Hijaak Draw - AI, BMP, CDR, CGM, EPS, GIF, PCX, PDW, TIF, WMF
Features: Hijaak Pro - DOS and Windows screen capture, zoom, center, trace,
edit, and print images. Full integration with other Hijaak tools.
Hijaak TouchUp - Add text to images, enhancement tools, merge
images, special imaging effect, many printing options, and uses
TWAIN compliant scanners.
Hijaak Browser - Catalog of image thumbnails, index of file
attributes, search for images, import from Windows clipboard.
Hijaak Draw - Palette editor, blending and envelope distortion,
text editing and spell check, multiple color graduated fills,
extrsion of 3D objects, variable light sources, brightness and
contrast control.
Name: ImagePals 2
Purpose: Image editor and DTP media management tool
Version: 2.0
Author: Ulead Systems Inc., 970 W. 190th St., #520, Torrance, CA 90502
Voice: 800.858.5323, 310.523.9393; Fax: 310.523.9399
Cost: ImagePals 2, $129; upgrade from ImagePals 1.x, $49;
Formats: BMP, CLP, CUR, DCS, EPS, GIF, ICO, IFF, IMG, JPG, MAC, MSP, PCD,
PCT, PCX, PSD, CGM, CLP, DRW, DXF, HGL, PCT, PIC, WMF, WPG, PXR,
RAS, RLE, SCT, TGA, TIF, WMF, VOC, WAV, MID, RMI, AVI, FLC, FLI,
FLX, WRI, TXT, DBF, DOC, PPT, RTF, CDR
Features: Photo album image cataloger, image editor and graphics toolbox,
screen capture, file format conversion, Kodak PhotoCD browser,
slide show, TWAIN and OLE compatible.
Reviews: PC Magazine May 17, 1994 v13 n9 p52(1)
InfoWorld, June 13, 1994, v16 n24 p97(2);
PC Magazine July 1994 v13 n13 p224(2)
Windows Sources August 1994 v2 n8 p82(2)
Windows Magazine August 1994 v5 n8 p274(9)
Name: InterChange
Purpose: 3D file format conversion
Version: 4.0
Author: Syndesis Corp., 235 South Main Street, Jefferson, WI, 53549 USA
Voice: 414.674.5200; Fax: 414.674.6363;
Email: syndesis@threedee.com; Web: http://www.threedee.com
Cost: Windows $495 US, SGI $1,495 US
Platforms: Windows, Windows 3.11, Windows NT, Silicon Graphics
Imports: 3DS and MLI, Alias polysets, BRender, CAD-3D, Coryphaeus .dwb,
GDS, Imagine, LightWave .lwo and .lws, Movie BYU, Haines NFF, PLG,
Prisms, Pro/E .slp, QuickDraw 3D, raw and .tpoly, RenderMorphics,
Sculpt, Sense8 NFF, Stereolithography, Swivel, Symbolics, trueSpace,
Vertigo, Vista DEM, VideoScape, Wavefront OBJ and MTL.
The SGI IRIX version also imports Inventor, Alias "wire",
and VRML 1.0 files.
Exports: 3DS and MLI, Alias polysets, BRender, CADL, Coryphaeus .dwb,
Direct3D ".x", GDS, Inventor, Imagine, LightWave .lwo and .lws,
Movie BYU, Haines NFF, PLG, POV-Ray 2.0, Prisms, Pro/E .slp,
QuickDraw 3D, raw and .tpoly, RenderMorphics, RenderWare,
RIB, Sculpt, Sense8 NFF, Stereolithography, Alias StyleGuide,
Symbolics, trueSpace, Vertigo, Vista DEM, VideoScape,
Wavefront OBJ and MTL.
The SGI IRIX version also exports Alias "wire" files.
Features: More than 50 formats translated. Translates surface attributes
and sub-objects for most formats. Batch conversion.
Name: MediaStudio
Purpose: Video/audio authoring and multimedia presentation
Version: 1.0
Author: Ulead Systems Inc., 970 W. 190th St., #520, Torrance, CA 90502
Voice: 800.858.5323, 310.523.9393; Fax: 310.523.9399
Cost: $349US (CD-ROM)
Formats: BMP, CLP, CUR, DCS, EPS, GIF, ICO, IFF, IMG, JPG, MAC, MSP, PCD,
PCT, PCX, PSD, CGM, CLP, DRW, DXF, HGL, PCT, PIC, WMF, WPG, PXR,
RAS, RLE, SCT, TGA, TIF, WMF, VOC, WAV, MID, RMI, AVI, FLC, FLI,
FLX, WRI, TXT, DBF, DOC, PPT, RTF, CDR
Features: Photo album image cataloger, image, audio, and video editor,
screen and video capture, file format conversion, morphing editor,
Kodak PhotoCD browser, HQ-9000, TWAIN, and OLE compatible.
Reviews: Computer Shopper, Nov 1994, v14 n11 p796(1);
Comments: MediaStudio is a very nice collection of utilities for creating,
modifying, and maintaining multimedia files and resources under
the Microsoft Windows environment. I am especially impressed with
its professional appearance, large selection of features, and
ease of use.
Name: Picture Man
Purpose: Image conversion and manipulation application
Version: 1.55 (Shareware)
Author: Dr. Igor Plotnikov <igor@corvette.insoft.com>
FTP: ftp://oak.oakland.edu/SimTel/win3/graphics/pman155.zip
Imports: TIFF, PCX, GIF, TGA, JPEG, BMP
Exports: TIFF, PCX, GIF, TGA, JPEG, BMP, EPS
Features: Paint, filter, and transform functions, virtual memory on disk,
TWAIN driver interface for scanners, digital cameras, and
video capturing boards, and runs multiple instances.
Name: PlayIt
Purpose: Multimedia playback utility
Version: 2.03
Author: Patrick Arial <patrick@shamrck.ersys.edmonton.ab.ca>
Shamrock Systems and Technology, Edmonton, Alberta, Canada
FTP: ftp://ftp.wustl.edu/pub/msdos_uploads/win3_desktop
ftp://ftp.cica.indiana.edu/pub/pc/win3/desktop/plyit203.zip
CIS: GO GRAPHSUP, Library 'Graphics Viewers', file PLYIT203.ZIP
GO WINMM, Library '3rd Part S/W', file PLYIT203.ZIP
Formats: ANIM, AVI, BMP/DIB, FLC/FLI, GIF, HAM/EHB, IFF/LBM, JPEG, MIDI,
MOV, MPEG, PCX, PGM, PICT, PPM, TGA, TIFF, and WAVE.
Features: Supports Microsoft Video for Windows, Apple Quicktime for Windows,
and Xing Technologies MCI MPEG driver. Interlaced GIF output,
writes audio to AVI files, convert individual frames to AVI,
full scripting language for batch processing, features several
image processing tools, and licensed to use LZW compression.
Name: PolyForm
Purpose: 3D file format conversion and editing
Version:
Author: Vivid Technologies, 13000 Bluemound Road, Elm Grove, WI 53122 USA
Voice: 800.962.7659; Fax: 414.641.0524
Cost:
Platforms: Windows 3.x, Windows95, Windows NT
Formats: 3DS, DXF, trueSpace, Wavefront, LightWave 3D, Imagine, Sculpt 4D,
Caligari, Vista Pro DEM, Scenery Animator DEM, Color PostScript,
EPS
Features: Converts over 20 3D file formats. Move, rotate, and scale
objects. 3D extrusion, beveling, and point editing. 3D polygon
surface stroking, flooding, picking, flipping, and selecting.
Many object manipulation algorithms.
Name: R2V for Windows
Purpose: Raster to vector conversion application
Version: 1.7.2
Author: Able Software Co.
Voice: 617.862.2804, Fax: 617.862.2640, Email: able@world.std.com
Cost: US$1895.00 (USA), US$2400.00 (International)
FTP: ftp://ftp.std.com/pub/r2v/r2vdemo.zip
Imports: TIFF, Arc/Info, and SPOT satellite image formats
Exports: MapInfo, DXF and Arc/Info, and TIFF
Features: Batch processing, vector editing and image processing functions,
vector registration and merge, and printer support.
------------------------------
Subject: 2. Image Conversion and Display Programs for Macintosh
Name: AddJFIFcomment
Purpose: Adds a comment to a JFIF file
Version: 1.0 (Freeware)
Author: Victor Tan <victort@extro.ucc.su.OZ.AU>
Imports: JFIF
Exports: JFIF
Features: Attaches a comment to a JFIF (JPEG) file that may be displayed
by a JPEG file viewing program.
Name: CH-Interchange 2
Purpose: JPEG toolkit (CH-Interchange, CH-JPEG, and CH-PegIt)
Author: HighWater Designs Inc., 6 Bedford Farms, Bedford, NH
03110-6532 USA. Voice: 603.669.7466, Fax: 603.669.7456
Imports: TIFF (RGB and CMYK), EPSF, JPEG, EPSJPEG, DCSJPEG
Exports: TIFF (RGB and CMYK), EPSF, JPEG, EPSJPEG, DCSJPEG
Features: CH-Interchnage provides file format conversion. CH-JPEG is an
Adobe Photoshop Plug-in that allows acquire/export of JPEG and
EPSJPEG formats. CH-PegIt provides low-resolution compression for
EPS and DCS files and uses the Mac's QuickTime extension.
Name: DeBabelizer and BeBabelizer Lite
Purpose: Editing and conversion of graphics, animation, and digital video
Version:
Author: Equilibrium, 475 Gate FIve Road, Suite 225, Sausalito, CA 94965
Voice: 415.332.4343, 800.524.8651; Fax: 415.332.4433;
Web: http://www.equilibrium.com
Imports: Abekas, Alias Pix, Apple II and IIGS, BMP, BOB, C64, Clipboard,
Degas, DPaint ANIM, Dr. Halo CUT, Electric Image, EPSF, FITS,
FLC, FLI, GIF, HAM, IFF, ILBM, IMG, JPEG, Lotus PIC, MacPaint,
MSP Type 1, NEO, OMF, PCC, PCP, PCX, PSD, PICS, PICT1, PICT2,
Pictor, Pixar, PixelPaint 1.0, QDV, QuickTime Movies and Stills,
Raw RGB, RIFF, RLE, Scrapbook, SGI Image, Softimage, Spectrum,
Startup screen, Sun raster, System 7 Pict Icons and Previews,
TGA, Thunderscan, TIFF, Titleman, Video FX, Wavefront RLA, WPG,
X11 XBM, XWD
Exports: Abekas, Alias Pix, Apple II and IIGS, BMP, BOB, Clipboard, Degas,
DPaint ANIM, Dr. Halo CUT, Electric Image, EPSF, FITS, FLC, FLI,
GIF, IFF, ILBM, IMG, JPEG, Lotus PIC, MacPaint, MSP Type 1, NEO,
OMF, PCX, PICS, PICT1, PICT2, Pixar, QDV, QuickTime Movies and
Stills, Raw RGB, RLE, Scrapbook, SGI Image, Softimage, Startup
screen, Sun raster, System 7 Pict Icons and Previews, TGA,
Thunderscan, TIFF, Titleman, Video FX, Wavefront RLA, XWD
Features: Script and batch processing, image cataloging, slideshow, image
compare, palette and quantization control. AppleScript and
Apple Events supported, Adobe Photoshop Acquire, Filter, and
Export plug-ins supported, Andromeda, Fotomagic, Kai's Power
Tools Xaos Tools, Paint Alchemy, and Terrazzo filters supported.
Name: GIFConverter
Purpose: Image display, conversion, and printing
Version: 2.3.7 (Shareware)
Author: Kevin A. Mitchell <kam@kamit.com> <74017.2573@compuserve.com>
P.O. Box 803066 Chicago, IL 60680-3066 USA
FTP: ftp://mac.archive.umich.edu/mac/graphics/graphicsutil/gif-converter-237.hqx
WWW: http://www.kamit.com/gifconverter.html
Imports: GIF, TIFF, RIFF, MacPaint, Thunderscan, PICT, RLE, Startup Screen,
and JPEG (with or without QuickTime)
Exports: GIF, TIFF, RIFF, MacPaint, Thunderscan, PICT, RLE, Startup Screen,
EPS, and JPEG (with or without QuickTime)
Features: Dithers and halftones, image enhancement, cropping, color table
selection, and laser printer support.
Name: GraphicConverter
Purpose: Graphics file format conversion
Version: 2.1.2 (Shareware)
Author: Thorsten Lemke <thorsten_lemke@pe2.escape.de>
Insterburger Str. 6 31228 Peine Germany
Imports: PICT, Startup-Screen, MacPaint, TIFF (raw, packbits, CCITT 3/4,
LZW), RIFF, PICS, 8BIM, 8BPS/PSD, JPEG/JFIF, GIF, PCX/SCR,
GEM-IMG/-XIMG, BMP (raw and RLE), ICO/ICN, PIC (16 bit), FLI/FLC,
TGA, MSP, PIC (PC Paint), SCX (ColoRIX), SHP, WPG, PBM/PGM/PPM,
CGM (binary only), SUN (uncompressed), RLE, XBM, PM, IFF/LBM, PAC,
Degas, TINY, NeoChrome, PIC (ATARI), SPU/SPC, GEM-Metafile,
Animated NeoChrome, Imagic, ImageLab/Print, Technic, HP-GL/2,
FITS, SGI, DL, XWD, WMF, Scitex-CT, DCX, KONTRON
Exports: PICT, Startup-Screen, MacPaint, TIFF (raw, packbits, LZW), GIF,
PCX, GEM-IMG/-XIMG, BMP, IFF/LBM, TGA, PSD, JPEG/JFIF, HP-GL/2,
EPSF, Movie (QuickTime), SUN, PICS, PICT in Resource, PBM/PGM/PPM
Name: JPEGView
Purpose: Image file viewer
Version: 3.3 (Freeware)
Author: Aaron Giles <giles@med.cornell.edu>
P.O. Box 2967 San Rafael, CA 94912 USA
FTP: ftp://guru.med.cornell.edu/pub/jpegview/jpegview32.sit.hqx
Imports: JPEG, JFIF, TIFF (Raw and LZW), BMP, GIF, PICT, Startup Screen,
MacPaint, QuickTime JPEG
Exports: JFIF-standard JPEG, QuickTime JPEG
Features: Uses QuickTime, full AppleScript support, high-quality
dithering, slide show, and floating windows.
Name: NIH Image
Purpose: Digital image processing and analysis program
Version: 1.5.5 (Freeware)
Author: Wayne Rasband <wayne@helix.nih.gov>
FTP: ftp://zippy.nimh.nih.gov/pub/nih-image/nih-image-155-nonfpu.hqx
WWW: http://rsb.info.nih.gov/nih-image/
Imports: TIFF, PICT, MacPaint
Exports: TIFF, PICT, MacPaint
Features: Ability to acquire, display, edit, enhance, analyze, print, and
animate images. Image processing functions include: histogram
equalization, contrast enhancement, density profiling, smoothing,
sharpening, edge detection, median filtering, and spatial
convolution with user defined kernels up to 63x63. Pascal-like
macro programming language.
Name: Show!
Purpose: Graphics file cataloging program
Version: 1.0.3 (Freeware)
Author: Henk W. den Bok <H.W.denBok@fys.ruu.nl>
Physics Laboratory Utrecht University P.O. Box 80.000 3508 TA
Utrecht, The Netherlands. Voice: (+31)-(0)30-537556
Formats: JPEG
Features: Creates thumbnails to preview full-scale images. View images and
sort, move, or copy thumnails between documents. Also views
thumnails embedded in JFIF files.
Name: Sparkle
Purpose: MPEG and QuickTime movie viewer and converter
Version: 2.3.5 (Freeware)
Author: Maynard Handley <maynard@elwing.otago.ac.nz>
284 Stuart Street Dunedin New Zealand
FTP: ftp://sumex-aim.stanford.edu/info-mac/grf/util
Imports: MPEG, QuickTime
Exports: MPEG, QuickTime
Features: Uses the QuickTime movie controller. Multiple movie viewing
capability.
Name: Transparency
Purpose: GIF transparency editor
Version: 1.0b4
Author: Aaron Giles <giles@med.cornell.edu>
182 E. 95th Street 11E New York, NY 10128 USA
FTP: ftp://ftp.med.cornell.edu/pub/aarong/transparency/
Imports: GIF
Exports: GIF
Features: Allows the designation of one color in a GIF image which is to be
treated as transparent. Useful in modifying GIF files for HTML
documents where the images are plotted against the arbitrary
background a Web client's window.
------------------------------
Subject: 3. Image Conversion and Display Programs for Unix and X Window
Name: fbm - Fuzzy pixmap manipulation
Purpose: Graphics file format manipulation and conversion toolkit
Version: 1.0
Author: Michael L. Mauldin <mlm@cs.cmu.edu>
FTP: ftp://ftp.wustl.edu/graphics/graphics/packages/fbm.tar.Z
ftp://nl.cs.cmu.edu/usr/mlm/ftp/fbm.tar.Z
Imports: Sun Rasterfile, GIF, IFF ILBM/HAM, TIFF, PCX, PBM, FBM,
PostScript, Face, Utah RLE
Exports: Sun Rasterfile, GIF, IFF ILBM/HAM, TIFF, PCX, PBM, FBM,
PostScript, Face, Utah RLE
Features: Image processing functions (resize, scaling, halftoning,
quantizing, etc.), TIFF functions based on libtiff library,
Utah RLE functions based on Utah Raster Toolkit, full source
code included in the distribution.
Name: GIFBLAST
Purpose: Lossless GIF file compressor
Version: 1.1 (Freeware)
Author: Isaac Dimitrovsky Labs, 147 Second Ave #484, New York NY 10003
FTP: ftp://ftp.wustl.edu/systems/ibmpc/garbo.uwasa.fi/gifutil/gifbla11.zip
Imports: GFB GIF
Exports: GFB GIF
Features: GIFBLAST reads and compresses GIF files into GFB files with no
loss of data. GFB files are typically 20-25% smaller than their
source GIF files. GIFBLAST also uncompresses GFB files into GIF
files with no loss of data. GFB files must be uncompressed to be
read by GIF file viewers. Package includes full source code.
Name: GLE
Purpose: High-quality graphics package for scientists
Version:
Cost: Free
OS: Unix/X Window (Solaris, SunOS, Alpha OSF/1, Linux),
DOS (16- and 32-bit), OS/2 Warp, VAX/VMS
Author: Chris Pugmire <chrisp@grv.grace.cri.nz>
FTP: ftp://tui.marc.cri.nz/pub/gle/
WWW: http://tbone.biol.sc.edu/~dean/glelist/
Exports: PostScript, X Window, REGIS, TEK4010, PC graphics cards, VT100,
HPGL, PCL, DI, TIFF, Epson, Sixel
Features: Uses LaTEX and PostScript fonts, driven by instructions from
scripts or via the grahical user interface, full source included.
Additional utilities included with GLE are: SURFACE for hidden
line surface plotting, CONTOUR to allow contour plots, MANIP to
allow columns of data to be changed, and FITLS that allows
arbitrary data to be fitted to equasions.
Name: The Graphics Connection (tm)
Purpose: Batch utility for converting to editable vector formats
Version: 2.01
OS: UNIX (Sun and HP)
Author: Square One bv, Willemsparkweg 52-I, 1071 HJ Amsterdam,
The Netherlands, tel: +31-20-673-1102, fax: +31-20-675-7844,
email: square1@island.nl, www: http://www.square1.nl
Cost: Software: $495 1-user, $1500 5-users
Volume and University discounts available.
On-Line Service for Mac & PC users: starting at $29 per file
Formats: Input: PostScript (.ps) and Encapsulated PostScript (.eps)
Vector Output: MIF, WMF, WPG, CGM, HPGL, PCL-5, EPS
Image Output: TIFF, GIF, Sunraster
Text Output: ASCII
Features: Batch utility converts many files at once. Callable by other
applications, utilities for splitting PostScript files,
modular installation, creates editable line-art and text.
Reviews: Publish Magazine Product Watch, March 1996,
Open Computing (Netherlands), March 1996.
Name: GraphX Viewer
See GraphX Viewer entry in the "Image Conversion and Display
Programs for Windows" section.
Name: HighWater JPEG Library
Purpose: High-speed JPEG compression/decompression for Solaris-2
Version: 1.2
Author: HighWater Designs Inc., 6 Bedford Farms, Bedford, NH
03110-6532 USA. Voice: 603.669.7466, Fax: 603.669.7456
Imports: JPEG
Exports: JPEG
Features: Library of functions callable from C programs, optimized for
high-speed operation, fully compliant with the JPEG
specification, operates on all SPARC-based platforms, and
example source code included.
Name: ImageMagick
Purpose: X Window-based image display and conversion
Version: 3.7
Author: John Cristy <cristy@dupont.com>
FTP: ftp://ftp.x.org/contrib/applications/ImageMagick/ImageMagick-3.7.tar.gz
FTP: ftp://ftp.wizards.dupont.com/pub/ImageMagick/ImageMagick-3.7.tar.gz
WWW: http://www.wizards.dupont.com/cristy/ImageMagick.html
Imports: AVS, BMP, Raw CMYK, Group 3 FAX, FITS, GIF, Raw GRAY, HDF, JBIG,
JPEG, MIFF, MPEG, MTV, Photo CD, PCX, Mac PICT, PBM, PDF, PDS,
PGM, PNG, PPM, PM Postscript, RAD, Raw RGB, Utah RLE, SGI RGB,
SUN Raster, Targa, ASCII Text, TIFF, VICAR, Visual Image Directory,
VIFF, X Screen, XBM, XPM, XWD, Raw YUV.
Exports: AVS, BMP, Raw CMYK, Group 3 FAX, FITS, GIF, Raw GRAY, HDF, JBIG,
JPEG, MIFF, MTV, PCX, Mac PICT, PBM, PDF, PGM, PNG, PPM,
PM Postscript, Raw RGB, Utah RLE, SGI RGB, SUN Raster, Targa,
TIFF, Visual Image Directory, VIFF, X Screen, XBM, XPM, XWD,
Raw YUV.
Features: Batch conversion, image preview, contact sheet creation,
slide shows, animation.
Name: patimg2tiff
Purpose: conversion from the USAPat IMAGE FILE format to TIFF
Version: 1.1
Author: Inlab Software GmbH, Josef-Wuerth-Str. 1, 82031 Gruenwald, Germany
Email: obermair@acm.org Voice: +49896412795 Fax: +49896411160
Cost: Please contact the author
Imports: USAPat IMAGE FILE
Exports: TIFF
Features: patimg2tiff converts the 'USAPat IMAGE FILE' format (as
found on the USAPat CDROM series produced by the U.S. Patent
and Trademark Office) to TIFF (multipage, G4-encoding).
The USAPat CDROM's are containing the facsimile images
of US patents in 300dpi. Source code licenses are
available with and without the right of redistribution
in binary form. The program itself runs on almost any modern
Un*x.
Name: pbmplus - Extended Portable Bitmap Toolkit
Purpose: Graphics file format manipulation and conversion toolkit
Version: 1.91d (10 December 1991)
Version: 10 December 1991
Author: Jef Poskanzer <jef@well.sf.ca.us> <jef@netcom.com>
FTP: ftp://ftp.wustl.edu/graphics/graphics/packages/pbmplus/pbmplus10dec91.tar.Z
ftp://gatekeeper.dec.com/.b/X11-contrib/pbmplus10dec91.tar.Z
Imports: Sun Icon, X10 and X11 bitmap, Mac Paint, CMU, MGR, G3 FAX,
GEM IMG, FACE, .pi1, .pi3, Andrew Raster Object, Xerox Doodle,
FITS, FaceSaver, LISP machine bit-array, HIPS, PostScript, RAW,
GIF, IFF ILBM, PICT, XPM, PCX, TGA HPPJ, YUV, MTV/PRT, QRT,
Img-whatnot, Xim, Spectrum, SLD, Sun Rasterfile, TIFF, X10 and
X11 XWD
Exports: Sun Icon, X10 and X11 bitmap, Mac Paint, CMU, MGR, G3 FAX,
GEM IMG, FACE, .pi1, .pi3, Andrew Raster Object, ASCII, HPLJ,
GraphOn, BBN, Printronix, Gemini 10x, Epson, Unix plot, Zinc Icon,
FITS, FaceSaver, LISP machine bit-array, GIF, NCSA, X11 puzzle,
IFF ILBM, PICT, XPM, PCX, TGA HPPJ, YUV, Motif UIL Icon,
DEC sixel, PostScript, TIFF, X11 XWD, Sun Rasterfile, DXF, SLD
Features: Supports monochrome, grayscale, and full-color bitmaps. Runs
under all flavors of Unix. Full source code included in the
distribution.
Name: NetPBM - Extended Portable Bitmap Toolkit
Purpose: Graphics file format manipulation and conversion toolkit
Version: 1 March 1994
Author: Bill Davidsen <davidsen@tmr.com>
FTP: ftp://ftp.wustl.edu/graphics/graphics/packages/NetPBM/*
ftp://ftp.cs.ubc.ca/ftp/archive/netpbm/*
ftp://ftp.x.org/contrib
Imports: Sun Icon, X10 and X11 bitmap, Mac Paint, CMU, MGR, G3 FAX,
GEM IMG, FACE, .pi1, .pi3, Andrew Raster Object, Xerox Doodle,
FITS, FaceSaver, LISP machine bit-array, HIPS, PostScript, RAW,
GIF, IFF ILBM, PICT, XPM, PCX, TGA HPPJ, YUV, MTV/PRT, QRT,
Img-whatnot, Xim, Spectrum, SLD, Sun Rasterfile, TIFF, X10 and
X11 XWD, BDF, PK font, SPOT, Biorad, BMP, Mitsubishi S340-10,
XV thumbnail, HP PaintJet XL PCL, SGI, Solitaire image recorder,
Zeiss
Exports: Sun Icon, X10 and X11 bitmap, Mac Paint, CMU, MGR, G3 FAX,
GEM IMG, FACE, .pi1, .pi3, Andrew Raster Object, ASCII, HPLJ,
GraphOn, BBN, Printronix, Gemini 10x, Epson, Unix plot, Zinc Icon,
FITS, FaceSaver, LISP machine bit-array, GIF, NCSA, X11 puzzle,
IFF ILBM, PICT, XPM, PCX, TGA HPPJ, YUV, Motif UIL Icon,
DEC sixel, PostScript, TIFF, X11 XWD, Sun Rasterfile, DXF, SLD,
BDF, PK font, SPOT, Biorad, BMP, Mitsubishi S340-10, XV thumbnail,
HP PaintJet XL PCL, SGI, Solitaire image recorder, Zeiss
Features: Based on the 10Dec91 version of pbmplus, image processing
functions include scaling, contrast and gamma adjustment, and
edge detection. Package also available for VMS, MS-DOS, and Amiga
Name: xanim
Purpose: Animation file viewer
Version: 2.70.3
Author: Mark Podlipec (podlipec@shell.portal.com)
FTP: ftp://ftp.portal.com/pub/podlipec/xanim2703.tar.Z
WWW: http://http://www.portal.com/~podlipec/home.html
Imports: DL, FLI, FLC, GIF, IFF, MovieSetter, PFX, Quicktime, AVI, RLE
Name: XDim
Purpose: Creation of 3D representations of 2D data sets
Version: 2.6 (Freeware)
Author: Walter Benzing <benzing@iegi01.etec.uni-karlsruhe.de>
FTP: ftp://ftp.uni-stuttgart.de/pub/X11/graphics/xdim/xdim2_6.tar.gz
Imports: GIF, JPEG, table calculation programs
Exports: GIF, JPEG, table calculation programs
Features: Motif interface, view data in several viewports, color
representation independent of hardware, allows the use of complex
data sets, fast redraw for modes without color interpolation.
Image processing (FFT, Inverse FFT, filters, histogram
equalization, free ordering from z-value to color, etc.), and
data processing (add,subtract,multiply and divide data fields,
linear and spline interpolation, mirror x-/y, complex data fields,
etc.) features. Required are a Unix system with an ANSI C
compiler, X11R4 or later, and the Motif widget set.
Name: Xew widget set
Purpose: X Window widget set
Version:
Author: Markku Savela <msa@hemuli.tte.vtt.fi>
Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203, FIN-02044 VTT
http://www.vtt.fi/tte/staff/msa/
WWW: http://www.vtt.fi/tte/EuroBridge/Xew/
Imports:
Name: xli
Purpose: X Window image file display and manipulation
Version: 1.16
Author: Graeme Gill <graeme@digideas.com.au>
FTP: ftp://ftp.x.org/contrib/applications/xli.1.16.tar.gz
Imports: CMU, GEM, GIF, JFIF, TIFF, Mac Paint, PCX, Sun Raster, Utah RLE,
TGA, X Window formats, PBM, FBM, Photograph on CD, Windows,
OS/2 BMP Image.
Name: xloadimage
Purpose: X Window image file display
Version: 4.1
Author: Jim Frost <jimf@centerline.com>
FTP: ftp://ftp.x.org/R5contrib/xloadimage.4.1.tar.gz
Imports: CMU, GEM, JFIF, TIFF, Mac Paint, PCX, Sun Raster, Utah RLE,
X Window famats, PBM formats, FBM formats.
Name: XPaint
Purpose: Paint program (bitmap/pixmap editing tool)
Version: 2.1
Author: David Koblas <koblas@netcom.com>
Extra Mile Consulting, PO Box 1352, Mountain View, CA 94042-1352 USA
FTP: ftp://ftp.netcom.com/pub/ko/koblas/xpaint-2.1.1.tar.gz
Imports: X11 Bitmaps, PPM, GIF, XPM, TIFF, SGI RGB
Exports: X11 Bitmaps, PPM, GIF, XPM, TIFF, SGI RGB, PostScript
Features: Brushes, Spray paint, Pencil Lines, Arcs, Pattern Fill, Text,
Boxes, Circles, Polygons. Works on multiple images simultaneously,
Cut/Copy/Paste between all active images, and Fatbits/Zoom on the
image windows. Full source code included.
Name: xv
Purpose: X Window-based image display
Version: 3.10a
Author: John Bradley <bradley@cis.upenn.edu>
FTP: ftp://ftp.cis.upenn.edu/pub/xv/xv-3.00a.tar.Z
Imports: GIF, JPEG, TIFF, PBM, PGM, PPM, X11 bitmap, Sun Rasterfile,
Utah Raster Toolkit RLE, PDS/VICAR, BMP, PCX, IRIS RGB,
PostScript, and PM
Exports: GIF, PM, PBM (raw), PBM (Ascii), X11 Bitmap, Sun Rasterfile,
BMP, PostScript, IRIS, JPEG, TIFF
------------------------------
Subject: 4. Image Conversion and Display Programs for Amiga
Name: AmigaJPEG
Purpose: Graphics file format converter
Version:
Author:
FTP: ftp://nic.funet.fi/pub/amiga/graphics/applications/convert/AmigaJPEG-*-bin.lha
Cost:
Imports: JPEG, GIF, TGA, PPM
Exports: JPEG, GIF, TGA, PPM
Features:
Name: GIFMachine
Purpose: Graphics file format viewer and converter
Version:
Author:
Cost:
FTP: ftp://bongo.cc.utexas.edu/amiga/GIFMachine.lzh
Imports:
Exports:
Features:
Name: HamLab Plus
Purpose: Graphics file format viewer and converter
Version: 2.0.8 (Shareware)
Author:
Cost: $20US
FTP: ftp://nic.funet.fi/pub/amiga/graphics/applications/convert/HAMLABPlus-2.08-demo.lha
Imports: JPEG
Exports: JPEG
Features: Crops images larger than 512x512
Name: ImageFX 2.0
Purpose: Professional image manipulation and special effects package
Version: 2.0
Author: Nova Design, Inc., 1910 Byrd Avenue, Suite 214, Richmond, VA 23230
Voice: 804.282.6528, Fax: 804.282.3768,
Email: Kermit@cup.portal.com (Kermit Woodall)
Cost:
Imports: ILBM/IFF w/Alpha, ANIM/ANIM 7/ANIM 8, Clipboard,
Datatypes, DCTV, Digiview DV21, FAXX, HAM-E, IMG8 (PP&S format),
Impulse, Rendition/Caligari, Sculpt 3D/4D, Toaster Framestore,
DPS PAR loader, Applied Magic Jstream, YUVN, PICT (w/vector and
JPEG variations), TIFF, MacPaint, Windows Icons, BMP, DP-IIe,
DL-View animation frame, FLI/FLC, GIF, PCX, PIC, GRASP/GL,
TGA w/Alpha, Alias, SGI RGB, Wavefront, Softimage, Abekas A60
series, JPEG, MPEG, C64 Koala, FITS, PS/EPS, PDS/Vicar,
QRT/POV/MTV, Sunraster, and X-Window formats.
Exports: ILBM/IFF w/Alpha, ANIM/ANIM 7/ANIM 8, Clipboard,
Datatypes, DCTV, Digiview DV21, FAXX, HAM-E, IMG8 (PP&S format),
Impulse, Rendition/Caligari, Sculpt 3D/4D, Toaster Framestore,
DPS PAR loader, Applied Magic Jstream, YUVN, PICT (w/vector and
JPEG variations), TIFF, MacPaint, Windows Icons, BMP, DP-IIe,
DL-View animation frame, FLI/FLC, GIF, PCX, PIC, GRASP/GL,
TGA w/Alpha, Alias, SGI RGB, Wavefront, Softimage, Abekas A60
series, JPEG, MPEG, C64 Koala, FITS, PS/EPS, PDS/Vicar,
QRT/POV/MTV, Sunraster, and X-Window formats.
Features: 24/32/56bit color painting, image retouching, prepress image
correction, special effects, morphing, and batch processing.
Name: JIV
Purpose: Graphics file viewer
Version: 1.19
Author: Juergen Weinelt <jow@hcast.franken.de>
Cost: Shareware donation (determined by the user)
FTP: Aminet FTP mirrors and the Aminet #6 CDROM
Imports: IFF/ILBM (1-8 and 24 planes, EHB, HAM, HAM8), uncompressed BMP
(OS/2 and MS Windows w/ 1, 4, 8 and 24 planes), GIF87a (including
GIF animations) and a subset of GIF89a, PNM (PBM, PGM and PPM,
ASCII and binary), PCX, and JPEG/JFIF.
Features: Support for all native Amiga graphics chipsets (OCS, ECS, AGA),
A2024 greyscale monitor, Picasso-II graphics board (village
emulation), and CyberGraphics emulation. Supports Workbench and
CLI/Shell. Slide show and autoscroll modes.
Name: PBMPlus
Purpose: Graphics file format convertion toolkit
Version: 1.91d (Amiga port)
Author: Jef Poskanzer <jef@well.sf.ca.us> <jef@netcom.com>
FTP: ftp://nic.funet.fi/pub/amiga/graphics/applications/convert/pbmplus
Imports: Sun Icon, X10 and X11 bitmap, Mac Paint, CMU, MGR, G3 FAX,
GEM IMG, FACE, .pi1, .pi3, Andrew Raster Object, Xerox Doodle,
FITS, FaceSaver, LISP machine bit-array, HIPS, PostScript, RAW,
GIF, IFF ILBM, PICT, XPM, PCX, TGA HPPJ, YUV, MTV/PRT, QRT,
Img-whatnot, Xim, Spectrum, SLD, Sun Rasterfile, TIFF, X10 and
X11 XWD
Exports: Sun Icon, X10 and X11 bitmap, Mac Paint, CMU, MGR, G3 FAX,
GEM IMG, FACE, .pi1, .pi3, Andrew Raster Object, ASCII, HPLJ,
GraphOn, BBN, Printronix, Gemini 10x, Epson, Unix plot, Zinc Icon,
FITS, FaceSaver, LISP machine bit-array, GIF, NCSA, X11 puzzle,
IFF ILBM, PICT, XPM, PCX, TGA HPPJ, YUV, Motif UIL Icon,
DEC sixel, PostScript, TIFF, X11 XWD, Sun Rasterfile, DXF, SLD
Features: Supports monochrome, grayscale, and full-color bitmaps. Runs
and compiles under the Amiga. Full source code included.
Name: Photogenics
Purpose: Paint and image processing package
Version: V1.2
Author: Almathera <almathera@cix.compulink.co.uk>
Almathera, Southerton House, Boundary Business Court,
92-94 Church Rd, Mitcham, Surrey, CR4 3TD, ENGLAND.
Cost: (UK) )163 AB(54.95 UKPounds. International orders 62 UKPounds inc.
airmail delivery
Imports: JPEG, IFF (all varieties), IFF-DEEP, Targa, PCX, PCD, TIFF,
ACBM, BMP, CDXL, QRT, QuadAnim, RAW, RGB8 and RGBN
Exports: JPEG, IFF, IFF-DEEP, Targa, PCX, TIFF, BMP, QRT, RAW, Sculpt
Features: Full 24-bit painting, image manipulation, unique 'paint layer'
system.
Name: Transition
Purpose: Image processing package
Version: 1.2.1
Author: Joel A. Corn, DarkSoftWare/DarkSoft Computers
610 S. Iowa Avenue, East Wenatchee, WA 98802 USA
Voice: 509.886.0581, Email: darksoft@ncw.net
Order: Better Concepts, Inc. Voice: 800.252.6442
Cost: $59.95 retail
Imports: IFF-ILBM, GIF, JPEG, PCX,,PBM+, BMP-Windows and OS/2 variety
Exports: IFF-ILBM, GIF, JPEG, PCX,,PBM+, BMP-Windows and OS/2 variety
Features: Built-in batch processing, Quantizing, Precise scaling,
Color Correction, and easy to use.
Reviews: Amiga World, August 1994
Amiga Report - online hyper-guide magazine
Name: WASPFast
Purpose: Graphics file format converter
Version: 2.0.2
Author:
Cost:
FTP: ftp://nic.funet.fi/pub/amiga/graphics/applications/convert/Wasp-2.02b.lha
Imports: GIF, IFF, MTV, PPM, SUN
Exports: GIF, IFF, MTV, PPM, SUN
Features:
------------------------------
Subject: 5. Platform-Independent Image Conversion Toolkits
Name: Berkeley MPEG Tools
Purpose: Software MPEG1 video decoder and encoder
Author: Berkeley Plateau Multimedia Research Group
Contact: mpeg-bugs@plateau.cs.berkeley.edu
FTP: ftp://mm-ftp.cs.berkeley.edu/pub/multimedia/mpeg
WWW: http://www-plateau.cs.berkeley.edu/mpeg/index.html
http://www-plateau.cs.berkeley.edu/plateau.html
Features: MPEG-1 statistics gathering and analysis tools, including two
new tools, mpeg_blocks and mpeg_bits, which analyze
videobitstreams allowing you to examine block encoding and bit
rate allocation.
Name: gd
Purpose: GIF manipulating library
Version: 1.1.1
Platforms: Unix, VMS, Windows 3.1 and NT, OS/2, MS-DOS
Author: Tom Boutell <boutell@netcom.com>
116 14th Ave E, Apt 2, Seattle, WA 98102
http://sunsite.unc.edu/boutell/index.html
FTP: ftp://isis.cshl.org/pub/gd/gd1.1.1.tar.Z
WWW: http://www.boutell.com/gd
Imports: GIF
Exports: GIF
Features: On-the-fly creation of charts and graphs for WWW. Polygon
drawing and filling, brushes, tiles, line styling (even with
brushes), and supports interlaced GIFs. Online HTML manual and
full source code included.
Name: libtiff
Purpose: TIFF file manipulation toolkit
Version: 3.3
Author: Sam Leffler <sam@okeeffe.berkeley.edu>
FTP: ftp://sgi.com/graphics/tiff/
Imports: TIFF, SGI
Exports: TIFF
Features: Tools for image conversions and transformations, and much
contributed software.
Name: Independent JPEG Group's JPEG Library
Purpose: JPEG image manipulation toolkit
Version: 6a
Author: Independent JPEG Group <jpeg-info@uunet.uu.net>
FTP: ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6a.tar.gz
Imports: JPEG, JFIF, BMP, GIF TGA, Utah RLE, PBM formats
Exports: JPEG, JFIF, BMP, GIF TGA, Utah RLE, PBM formats
Features: Baseline and extended processes, format conversion
Complete source code included.
Comments: This is *the* standard toolkit for implementing JPEG
functionality into software.
------------------------------
Subject: III. FTP and WWW Graphics Software Archives
------------------------------
Subject: 0. Graphics Software Archives for MS-DOS
ftp://oak.oakland.edu/pub/msdos/graphics
ftp://oak.oakland.edu/SimTel/msdos/graphics
------------------------------
Subject: 1. Graphics Software Archives for Windows and OS/2
ftp://ftp.cica.indiana.edu/pub/pc/win3/desktop
------------------------------
Subject: 2. Graphics Software Archives for Macintosh
http://wwwhost.ots.utexas.edu/mac/main.html
------------------------------
Subject: 3. Graphics Software Archives for Unix and X Window
ftp://ftp.uu.net/graphics
ftp://ftp.x.org/contrib/applications
------------------------------
Subject: 4. Graphics Software Archives for Amiga
ftp://wuarchive.wustl.edu/pub/aminet/gfx/conv
ftp://nic.funet.fi/pub/amiga/graphics/applications/convert
http://wuarchive.wustl.edu/~aminet/dirs/gfx_conf.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):
Ron Augustine <ronaug@pixi.com>
Iljitsch van Beijnum <iljitsch@xs4all.nl>
Greg Broiles <gbroiles@scubed.com>
Vincent Chen <vchen@ulead.com>
John Cristy <cristy@magick.es.dupont.com>
Graeme Gill <graeme@digideas.com.au>
Andy Key <ak@nyangau.aladdin.co.uk>
Chris Komnick <komnick@group42.com>
Tom Lane <tgl@netcom.com>
Gustav "Gurre" Kalvesten <a94guska@ida.his.se>
Jonathan Law <jonlaw@princeton.edu>
Angus Montgomery <angus@cgl.citri.edu.au>
Joe Oliphant <joe_oliphant@csufresno.edu>
Borut Podlipnik <borut@lasco1.mpae.gwdg.de>
Jolyon Ralph <jralph@cix.compulink.co.uk>
Markku Savela <msa@hemuli.tte.vtt.fi>
Paul Schmidt <photodex@ix.netcom.com>
Marc Stengel <msss@netcom.com>
Juergen Weinelt <jow@hub-n.franken.de>
Kermit Woodall <Kermit@cup.portal.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 jdm@ora.com,
or via U.S. Snail at: P.O. Box 70, Orange, CA 92666-0070 USA.
------------------------------
Subject: 2. Disclaimer
While every effort has been taken to insure the accuracy of the
information contained in this FAQ list compilation, the author and
contributors assume no responsibility for errors or omissions, or for
damages resulting from the use of the information contained herein.
------------------------------
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.
------------------------------
----------------------------------------------------------------------
Path: news1.ucsd.edu!ihnp4.ucsd.edu!swrinde!howland.erols.net!cam-news-hub1.bbnplanet.com!prod.mpi.com!news3.near.net!amber.ora.com!not-for-mail
From: jdm@ora.com
Newsgroups: comp.graphics.misc,comp.answers,news.answers
Subject: Graphics File Formats FAQ (Part 3 of 4): Where to Get File Format Specifications
Supersedes: <graphics/fileformats-faq-3-838937736@ora.com>
Followup-To: poster
Date: 8 Sep 1996 12:38:43 -0700
Organization: O'Reilly & Associates, Inc.
Lines: 4505
Sender: jdm@ruby.ora.com
Approved: news-answers-request@MIT.EDU
Distribution: world
Expires: 10/13/96 12:38:30
Message-ID: <graphics/fileformats-faq-3-842211510@ora.com>
References: <graphics/fileformats-faq-1-842211510@ora.com>
Reply-To: jdm@ora.com (James D. Murray)
NNTP-Posting-Host: ruby.ora.com
Summary: This document answers many of the most frequently asked
questions about graphics file formats on Usenet.
Keywords: FAQ, GRAPHICS, FORMAT, IMAGE, MULTIMEDIA, 3D
Xref: news1.ucsd.edu comp.graphics.misc:8988 comp.answers:16234 news.answers:64950
Posted-By: auto-faq 3.1.1.2
Archive-name: graphics/fileformats-faq/part3
Posting-Frequency: monthly
Last-modified: 01Sep96
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
jdm@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
AFM - Adobe Font Metrics 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
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
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
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 - Pegasus Imaging Corporation 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
RIB - Renderman Interface Bytestream
RIFF - Microsoft Resource Interchange File Format
RIX - ColoRIX Image File
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
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
jdm@ora.com and let me know!
------------------------------
Subject: 1. What's new in this latest FAQ release?
o Updated TIFF, GIF, and JFIF
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: ftp://ftp.adobe.com/pub/adobe/DeveloperSupport/TechNotes/PSfiles/5006.ABF_Spec.ps
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: 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: ART - Another Ray Tracer
Type: 3D
Extension: art
Version:
Compression:
Color Depth:
Maintainer: Tom Wilson <twilson@sunny5.dab.ge.com>
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 <dmb@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 "BMP Format Specification".
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/1194.09/bmp.zip
ftp://ftp.mv.com/pub/ddj/1995/1195.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: keith@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: mike@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: jstack@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
SNELSON921@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 "CDF Interface".
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 <carlt@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: info@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: support@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: sales@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.com/
------------------------------
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: sales@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:
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 <broehl@waterloo.ca>
Kerry Bonin <74367.1630@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 fits@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: 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: info@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 <GJWard@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: GJWard@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: cristy@dupont.com
------------------------------
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: mpdillon@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 <erich@eye.com>
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: erich@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: info@sense8.com
WWW: http://www.sense8.com/
Questions about Sense8's NFF format should be directed to:
Ben Discoe <ben@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: mignone@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: edi@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_Operator@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 - Pegasus Imaging Corporation Format
Type:
Extension:
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: 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-info@uunet.uu.net
or directed to the principle author of the PNG specification:
Thomas Boutell <boutell@boutell.com>
PNG developers may join the PNG mailing list. Send email to
png-info@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-list@dworkin.wustl.edu General PNG discussion
png-announce@dworkin.wustl.edu Announcements related to PNG
png-implement@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-request@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: info@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/1195.07/ptot.zip
And a rather CompuServe-biased official press release:
http://www.compuserve.com/new/news_rel/png2.html
------------------------------
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 <msoucy@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.1655@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.
------------------------------
Subject: PSD - Adobe Photoshop
Type: Bitmap
Extension: PSD
Version:
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 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.).
------------------------------
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 DEVSUPPORT@applelink.apple.com.
To join the QuickTime Developer mailing list, send an email to
listproc@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 <gjward@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: cek@princeton.edu
------------------------------
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: 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: infosafe@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 <whiteh@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: rodney@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 sdts@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 (paul@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-person@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:
Extension:
Version:
Compression:
Color Depth:
Maintainer:
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.
------------------------------
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.).
------------------------------
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-request@cs.utah.edu
urt-request@caen.engin.umich.edu
------------------------------
Subject: VCA - Visual Clip Art
Type:
Extension:
Version:
Compression:
Color Depth:
Maintainer: Superscape <http://www.superscape.com>
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.Deen@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-request@chama.eece.unm.edu
Email: khorus@chama.eece.unm.edu (User's Group)
Newsgroup: comp.soft-sys.khoros
------------------------------
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. <mpesce@netcom.com>
Anthony Parsi, Labyrinth Group <dagobert@netcom.com>
Gavin Bell, Silicon Graphics, Inc. <gavin@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: lehors@sophia.inria.fr
You may subscribe to the XPM mailing list by sending a subscription request
to:
xpm-talk-request@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: edi@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: jhoward@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: helpdesk@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: clientservices.phi@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 <brox@corena.no>
Mike Beanes <mike@virage.com>
John Cristy <cristy@magick.es.dupont.com>
Michael Dillon <michael@memra.com>
Ben Discoe <ben@sense8.com>
James Durham <durhamj@CC.IMS.DISA.MIL>
Bruce Garner <garner@tis.llnl.gov>
Eric Haines <erich@eye.com>
Glenn Herteg <glenn@ia-us.com>
Chris Komnick <komnick@group42.com>
Tom Lane <tgl@netcom.com>
Stanley F. Quayle <quayle@scriptel.com>
Glenn Randers-Pehrson <glennrp@arl.mil>
Jonathan Shekter <jshekter@interlog.com>
Marc Soucy <msoucy@imetric.qc.ca>
------------------------------
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 jdm@ora.com,
or via U.S. Snail at: P.O. Box 70, Orange, CA 92666-0070 USA.
------------------------------
Subject: 2. Disclaimer
While every effort has been taken to insure the accuracy of the
information contained in this FAQ list compilation, the author and
contributors assume no responsibility for errors or omissions, or for
damages resulting from the use of the information contained herein.
------------------------------
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.
------------------------------
----------------------------------------------------------------------
Path: news1.ucsd.edu!ihnp4.ucsd.edu!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!news.sdsmt.edu!news.mid.net!news.dra.com!netaxs.com!hunter.premier.net!www.nntp.primenet.com!nntp.primenet.com!howland.erols.net!cam-news-hub1.bbnplanet.com!prod.mpi.com!news3.near.net!amber.ora.com!not-for-mail
From: jdm@ora.com
Newsgroups: comp.graphics.misc,comp.answers,news.answers
Subject: Graphics File Formats FAQ (Part 4 of 4): Tips and Tricks of the Trade
Supersedes: <graphics/fileformats-faq-4-838937736@ora.com>
Followup-To: poster
Date: 8 Sep 1996 12:38:49 -0700
Organization: O'Reilly & Associates, Inc.
Lines: 550
Sender: jdm@ruby.ora.com
Approved: news-answers-request@MIT.EDU
Distribution: world
Expires: 10/13/96 12:38:30
Message-ID: <graphics/fileformats-faq-4-842211510@ora.com>
References: <graphics/fileformats-faq-1-842211510@ora.com>
Reply-To: jdm@ora.com (James D. Murray)
NNTP-Posting-Host: ruby.ora.com
Summary: This document answers many of the most frequently asked
questions about graphics file formats on Usenet.
Keywords: FAQ, GRAPHICS, FORMAT, IMAGE, MULTIMEDIA, 3D
Xref: news1.ucsd.edu comp.graphics.misc:8986 comp.answers:16232 news.answers:64948
Posted-By: auto-faq 3.1.1.2
Archive-name: graphics/fileformats-faq/part4
Posting-Frequency: monthly
Last-modified: 01Sep96
Graphics File Formats FAQ (Part 4 of 4): Tips and Tricks of the Trade
------------------------------
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
jdm@ora.com. Relevant information posted to newsgroups will not
automatically make it into this FAQ.
-- James D. Murray
------------------------------
Subject: 0. Contents of Tips and Tricks of the Trade
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. Programming Tips for Graphics File Formats
0. What's the best way to read a file header?
1. What's this business about endianness?
2. How can I determine the byte-order of a system at run-time?
3. How can I identify the format of a graphics file?
4. What are the format identifiers of some popular file formats?
III. 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
Programmer's are code-hungry people. They just want the secrets and they want
them to work NOW! But always in the back of a hack's mind there are the
questions: "Is this really the best way to do this? Could it be better?".
This FAQ is to share ideas on the implementation details of reading, writing,
converting, and displaying graphics file formats. You'll probably get some
good ideas here, find a few things you didn't know about, and even have a few
suggestions and improvements of you own to add (send them to jdm@ora.com).
If you need to know the best way to do something with file formats, or
just find it embarrassing to implement a chunk of some other programmer's
code and then have to admit you really don't understand how it works, then
this FAQ is for you.
------------------------------
Subject: 1. What's new in this latest FAQ release?
o Minor bug fixed in GetLittleWord() and GetLittleDword() functions
------------------------------
Subject: II. Programming Tips for Graphics File Formats
------------------------------
Subject: 0. What's the best way to read a file header?
You wouldn't think there's a lot of mystery about reading a few bytes from
a disk file, eh? Programmer's, however, are constantly loosing time
because they don't consider a few problems that may occur and cause them
to loose time. Consider the following code:
typedef struct _Header
{
BYTE Id;
WORD Height;
WORD Width;
BYTE Colors;
} HEADER;
HEADER Header;
void ReadHeader(FILE *fp)
{
if (fp != (FILE *)NULL)
fread(&Header, sizeof(HEADER), 1, fp);
}
Looks good, right? The fread() will read the next sizeof(HEADER) bytes from
a valid FILE pointer into the Header data structure. So what could go
wrong?
The problem often encountered with this method is one of element alignment
within structures. Compilers may pad structures with "invisible" elements
to allow each "visible" element to align on a 2- or 4-byte address
boundary. This is done for efficiency in accessing the element while in
memory. Padding may also be added to the end of the structure to bring
it's total length to an even number of bytes. This is done so the data
following the structure in memory will also align on a proper address
boundary.
If the above code is compiled with no (or 1-byte) structure alignment the
code will operate as expected. With 2-byte alignment an extra two bytes
would be added to the HEADER structure in memory and make it appear as
such:
typedef struct _Header
{
BYTE Id;
BYTE Pad1; // Added padding
WORD Height;
WORD Width;
BYTE Colors;
BYTE Pad2; // Added padding
} HEADER;
As you can see the fread() will store the correct value in Id, but the
first byte of Height will be stored in the padding byte. This will throw
off the correct storage of data in the remaining part of the structure
causing the values to be garbage.
A compiler using 4-byte alignment would change the HEADER in memory as such:
typedef struct _Header
{
BYTE Id;
BYTE Pad1; // Added padding
BYTE Pad2; // Added padding
BYTE Pad3; // Added padding
WORD Height;
WORD Width;
BYTE Colors;
BYTE Pad4; // Added padding
BYTE Pad5; // Added padding
BYTE Pad6; // Added padding
} HEADER;
What started off as a 6-byte header increased to 8 and 12 bytes thanks to
alignment. But what can you do? All the documentation and makefiles you
write will not prevent someone from compiling with the wrong options flag
and then pulling their (or your) hair out when your software appears not
to work correctly.
Now considering this alternative to the ReadHeader() function:
HEADER Header;
void ReadHeader(FILE *fp)
{
if (fp != (FILE *)NULL)
{
fread(&Header.Id, sizeof(Header.Id), 1, fp);
fread(&Header.Height, sizeof(Header.Height), 1, fp);
fread(&Header.Width, sizeof(Header.Width), 1, fp);
fread(&Header.Colors, sizeof(Header.Colors), 1, fp);
}
}
What both you and your compiler now see is a lot more code. Rather than
reading the entire structure in one, elegant shot, you read in each
element separately using multiple calls to fread(). The trade-off here is
increased code size for not caring what the structure alignment option of
the compiler is set to. These cases are also true for writing structures
to files using fwrite(). Write only the data and not the padding please.
But is there still anything we've yet over looked? Will fread() (fscanf(),
fgetc(), and so forth) always return the data we expect? Will fwrite()
(fprintf(), fputc(), and so forth) ever write data that we don't want, or
in a way we don't expect? Read on to the next section...
------------------------------
Subject: 1. What's this business about endianness?
So you've been pulling you hair out trying to discover why your elegant
and perfect-beyond-reproach code, running on your Macintosh or Sun, is
reading garbage from PCX and TGA files. Or perhaps your MS-DOS or Windows
application just can't seem to make heads or tails out of that Sun Raster
file. And, to make matters even more mysterious, it seems your most
illustrious creation will read some TIFF files, but not others.
As was hinted at in the previous section, just reading the header of a
graphics file one field is not enough to insure data is always read correctly
(not enough for portable code, anyway). In addition to structure, we must also
consider the endianness of the file's data, and the endianness of the
system's architecture our code is running on.
Here's are some baseline rules to follow:
1) Graphics files typically use a fixed byte-ordering scheme. For example,
PCX and TGA files are always little-endian; Sun Raster and Macintosh
PICT are always big-endian.
2) Graphics files that may contain data using either byte-ordering scheme
(for example TIFF) will have an identifier that indicates the
endianness of the data.
3) ASCII-based graphics files (such as DXF and most 3D object files),
have no endianness and are always read in the same way on any system.
4) Most CPUs use a fixed byte-ordering scheme. For example, the 80486
is little-endian and the 68040 is big-endian.
5) You can test for the type of endianness a system using software.
6) There are many systems that are neither big- nor little-endian; these
middle-endian systems will possibly cause such byte-order detection
tests to return erroneous results.
Now we know that using fread() on a big-endian system to read data from a
file that was originally written in little-endian order will return
incorrect data. Actually, the data is correct, but the bytes that make up
the data are arranged in the wrong order. If we attempt to read the 16-bit
value 1234h from a little-endian file, it would be stored in memory using
the big-endian byte-ordering scheme and the value 3412h would result. What
we need is a swap function to change the resulting position of the bytes:
WORD SwapTwoBytes(WORD w)
{
register WORD tmp;
tmp = (w & 0x00FF);
tmp = ((w & 0xFF00) >> 0x08) | (tmp << 0x08);
return(tmp);
}
Now we can read a two-byte header value and swap the bytes as such:
fread(&Header.Height, sizeof(Header.Height), 1, fp);
Header.Height = SwapTwoBytes(Header.Height);
But what about four-byte values? The value 12345678h would be stored as
78563412h. What we need is a swap function to handle four-byte values:
DWORD SwapFourBytes(DWORD dw)
{
register DWORD tmp;
tmp = (dw & 0x000000FF);
tmp = ((dw & 0x0000FF00) >> 0x08) | (tmp << 0x08);
tmp = ((dw & 0x00FF0000) >> 0x10) | (tmp << 0x08);
tmp = ((dw & 0xFF000000) >> 0x18) | (tmp << 0x08);
return(tmp);
}
But how do we know when to swap and when not to swap? We always know the
byte-order of a graphics file that we are reading, but how do we check
what the endianness of system we are running on is? Using the C language,
we might use preprocessor switches to cause a conditional compile based on
a system definition flag:
#define MSDOS 1
#define WINDOWS 2
#define MACINTOSH 3
#define AMIGA 4
#define SUNUNIX 5
#define SYSTEM MSDOS
#if defined(SYSTEM == MSDOS)
// Little-endian code here
#elif defined(SYSTEM == WINDOWS)
// Little-endian code here
#elif defined(SYSTEM == MACINTOSH)
// Big-endian code here
#elif defined(SYSTEM == AMIGA)
// Big-endian code here
#elif defined(SYSTEM == SUNUNIX)
// Big-endian code here
#else
#error Unknown SYSTEM definition
#endif
My reaction to the above code was *YUCK!* (and I hope yours was too!). A
snarl of fread(), fwrite(), SwapTwoBytes(), and SwapFourBytes() functions
laced between preprocessor statements is hardly elegant code, although
sometimes it is our best choice. Fortunately, this is not one of those
times.
What we first need is a set of functions to read the data from a file
using the byte-ordering scheme of the data. This effectively combines the
read\write and swap operations into one set of functions. Considering the
following:
WORD GetBigWord(FILE *fp)
{
register WORD w;
w = (WORD) (fgetc(fp) & 0xFF);
w = ((WORD) (fgetc(fp) & 0xFF)) | (w << 0x08);
return(w);
}
WORD GetLittleWord(FILE *fp)
{
register WORD w;
w = (WORD) (fgetc(fp) & 0xFF);
w |= ((WORD) (fgetc(fp) & 0xFF) << 0x08);
return(w);
}
DWORD GetBigDoubleWord(FILE *fp)
{
register DWORD dw;
dw = (DWORD) (fgetc(fp) & 0xFF);
dw = ((DWORD) (fgetc(fp) & 0xFF)) | (dw << 0x08);
dw = ((DWORD) (fgetc(fp) & 0xFF)) | (dw << 0x08);
dw = ((DWORD) (fgetc(fp) & 0xFF)) | (dw << 0x08);
return(dw);
}
DWORD GetLittleDoubleWord(FILE *fp)
{
register DWORD dw;
dw = (DWORD) (fgetc(fp) & 0xFF);
dw |= ((DWORD) (fgetc(fp) & 0xFF) << 0x08);
dw |= ((DWORD) (fgetc(fp) & 0xFF) << 0x10);
dw |= ((DWORD) (fgetc(fp) & 0xFF) << 0x18);
return(dw);
}
void PutBigWord(WORD w, FILE *fp)
{
fputc((w >> 0x08) & 0xFF, fp);
fputc(w & 0xFF, fp);
}
void PutLittleWord(WORD w, FILE *fp)
{
fputc(w & 0xFF, fp);
fputc((w >> 0x08) & 0xFF, fp);
}
void PutBigDoubleWord(DWORD dw, FILE *fp)
{
fputc((dw >> 0x18) & 0xFF, fp);
fputc((dw >> 0x10) & 0xFF, fp);
fputc((dw >> 0x08) & 0xFF, fp);
fputc(dw & 0xFF, fp);
}
void PutLittleDoubleWord(DWORD dw, FILE *fp)
{
fputc(dw & 0xFF, fp);
fputc((dw >> 0x08) & 0xFF, fp);
fputc((dw >> 0x10) & 0xFF, fp);
fputc((dw >> 0x18) & 0xFF, fp);
}
If we were reading a little-endian file on a big-endian system (or visa
versa), the previous code:
fread(&Header.Height, sizeof(Header.Height), 1, fp);
Header.Height = SwapTwoBytes(Header.Height);
Would be replaced by:
Header.Height = GetLittleWord(fp);
The code to write the same value to a file would be changed from:
Header.Height = SwapTwoBytes(Header.Height);
fwrite(&Header.Height, sizeof(Header.Height), 1, fp);
To the slightly more readable:
PutLittleWord(Header.Height, fp);
Note that these functions are the same regardless of the endianness of a
system. For example, the ReadLittleWord() will always read a two-byte value
from a little-endian file regardless of the endianness of the system;
PutBigDoubleWord() will always write a four-byte big-endian value, and so
forth.
------------------------------
Subject: 2. How can I determine the byte-order of a system at run-time?
You may wish to optimize how you read (or write) data from a graphics file
based on the endianness of your system. Using the GetBigDoubleWord()
function mentioned in the previous section to read big-endian data from a
file on a big-endian system imposes extra overhead we don't really need
(although if the actual number of read/write operations in your program is
small you might not consider this overhead to be too bad).
If our code could tell what the endianness of the system was at run-time,
it could choose (using function pointers) what set of read/write functions
to use. Look at the following function:
#define BIG_ENDIAN 0
#define LITTLE_ENDIAN 1
int TestByteOrder(void)
{
short int word = 0x0001;
char *byte = (char *) &word;
return(byte[0] ? LITTLE_ENDIAN : BIG_ENDIAN);
}
This code assigns the value 0001h to a 16-bit integer. A char pointer is
then assigned to point at the first (least-significant) byte of the
integer value. If the first byte of the integer is 01h, then the system
is little-endian (the 01h is in the lowest, or least-significant,
address). If it is 00h then the system is big-endian.
------------------------------
Subject: 3. How can I identify the format of a graphics file?
When writing any type of file or data stream reader it is very important
to implement some sort of method for verifying that the input data is in
the format you expect. Here are a few methods:
1) Trust the user of your program to always supply the correct data,
thereby freeing you from the tedious task of writing any type of format
identification routines. Choose this method and you will provide solid
proof that contradicts the popular claim that users are inherently far
more stupid than programmers.
2) Read the file extension or descriptor. A GIF file will always have the
extension .GIF, right? Targa files .TGA, yes? And TIFF files will have an
extension of .TIF or a descriptor of TIFF. So no problem?
Well, for the most part, this is true. This method certainly isn't
bulletproof, however. Your reader will occasionally be fed the odd-batch
of mis-label files ("I thought they were PCX files!"). Or files with
unrecognized mangled extensions (.TAR rather than .TGA or .JFI rather
than .JPG) that your reader knows how to read, but won't read because it
doesn't recognize the extensions. File extensions also won't usually tell
you the revision of the file format you are reading (with some revisions
creating an almost entirely new format). And more than one file format
share the more common file extensions (such as .IMG and .PIC). And last of
all, data streams have no file extensions or descriptors to read at all.
3) Read the file and attempt to recognize the format by specific patterns
in the data. Most file formats contain some sort of identifying pattern of
data that is identical in all files. In some cases this pattern gives and
indication of the revision of the format (such as GIF87a and GIF89a) or
the endianness of the data format.
Nothing is easy, however. Not all formats contain such identifiers (such
as PCX). And those that do don't necessarily put it at the beginning of
the file. This means if the data is in the format of a stream you many
have to read (and buffer) most or all of the data before you can determine
the format. Of course, not all graphics formats are suitable to be read as
a data stream anyway.
Your best bet for a method of format detection is a combination of methods
two and three. First believe the file extension or descriptor, read some
data, and check for identifying data patterns. If this test fails, then
attempt to recognize all other known patterns.
Run-time file format identification a black-art at best.
------------------------------
Subject: 4. What are the format identifiers of some popular file formats?
Here are a few algorithms that you can use to determine the format of a
graphics file at run-time.
GIF: The first six bytes of a GIF file will be the byte pattern of
474946383761h ("GIF87a") or 474946383961h ("GIF89a").
JFIF: The first three bytes are ffd8ffh (i.e., an SOI marker followed
by any marker). Do not check the fourth byte, as it will vary.
JPEG: The first three bytes are ffd8ffh (i.e., an SOI marker followed
by any marker). Do not check the fourth byte, as it will vary.
This works with most variants of "raw JPEG" as well.
PNG: The first eight bytes of all PNG files are 89504e470d0a1a0ah.
SPIFF: The first three bytes are ffd8ffh (i.e., an SOI marker followed
by any marker). Do not check the fourth byte, as it will vary.
Sun: The first four bytes of a Sun Rasterfile are 59a66a95h. If you have
accidentally read this identifier using the little-endian byte order
this value will will be read as 956aa659h.
TGA: The last 18 bytes of a TGA Version 2 file is the string
"TRUEVISION-XFILE.\0". If this string is not present, then the file
is assumed to be a TGA Version 1 file.
TIFF: The first four bytes of a big-endian TIFF files are 4d4d002ah and
49492a00h for little-endian TIFF files.
------------------------------
Subject: III. Kudos and Assertions
------------------------------
Subject: 0. Acknowledgments
Chris M. Cooney <cooney1@imssys.imssys.com>
Tom Lane <tgl@netcom.com>
Charles R. Patton <crpatton@ingr.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 jdm@ora.com,
or via U.S. Snail at: P.O. Box 70, Orange, CA 92666-0070 USA.
------------------------------
Subject: 2. Disclaimer
While every effort has been taken to insure the accuracy of the
information contained in this FAQ list compilation, the author and
contributors assume no responsibility for errors or omissions, or for
damages resulting from the use of the information contained herein.
------------------------------
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.
------------------------------