3D Graphics File Format FAQ

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: General Graphics Format Questions (Part 1 of 4)
  Graphics File Formats FAQ: Image Conversion and Display Programs (Part 2 of 4)
  Graphics File Formats FAQ: Where to Get File Format Specifications (Part 3 of 4)
  Graphics File Formats FAQ: Tips and Tricks of the Trade (Part 4 of 4)

Please email contributions, corrections, and suggestions about this FAQ to
jdm@netcom.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  are new to this FAQ.
Subjects marked with  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 concerning 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? 

II. General Graphics File Questions

0. Who cares about graphics file formats?
1. What is raster, vector, metafile, PDL, 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. Can a graphics file be copyrighted?
6. How can I convert the XXX format to the YYY format? 
7. Do I really need the specification of the format I'm using?
8. How can I tell if a graphics file is corrupt? 

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, and HPGL file formats either? 
2. Is it "Tag" or "Tagged" Image File Format?
3. Whaddya mean there's no "Targa" file format?
4. Choosy programmers choose "gif" or "jif"?
5. Why are there so many ".PIC" and ".IMG" formats?
6. Is it now illegal to use CompuServe's GIF format?

III. Graphics File Resources

0. File Format Specifications FTP Archives 
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 
5. U.S. Government and Military Standards Sources 
6. Other Standards Document Sources 

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

Welcome to another monthly release of the Graphics File Format FAQ!

If you've been following the progress of this FAQ you'll now note that it has
been split into four physical parts to accommodate its growing size.  These
parts are logically divided as follows:

  Graphics File Formats FAQ: General Questions (Part 01 of 4)
  Graphics File Formats FAQ: Image Conversion and Display Programs (Part 02 of 4)
  Graphics File Formats FAQ: Where to Get File Format Specifications (Part 03 of 4)
  Graphics File Formats FAQ: Tips and Tricks of the Trade (Part 4 of 4)

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

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

  o Included a blurb on corrupt graphics files
  o More "that isn't a file format!" information
  o Updated file format archive sites
  o Added new FAQs you should read
  o Yet another magazine article(s) added
  o And more sources for military documents

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

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?

This FAQ is distributed monthly on the Usenet newsgroups comp.graphics
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

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

To access this FAQ on the World Wide Web, use the address:

  http://www.cis.ohio-state.edu/hypertext/faq/usenet/graphics/fileformats-faq/faq.html

And you can access all of the FAQs associated with comp.graphics via the
WWW page:

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

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

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-2]
  alt.graphics.pixutils    pixutils-faq
  alt.image.medical        medical-image-faq/part[1-3]
  comp.compression         compression-faq/part[1-3]
                           mpeg-faq[1-6]
  comp.dsp                 dsp-faq[1-4]
                           audio-fmts[1-2]
  comp.fonts               fonts-faq/part[1-2]
  comp.graphics            graphics/faq
                           graphics/colorspace-faq
                           graphics/resources-list/part[1-3]
                           jpeg-faq/part[1-2]
  comp.graphics.animation  graphics/animation-faq
  comp.infosystems.gis     geography/infosystems-faq
  comp.multimedia          comp-multimedia-faq
  comp.speech              comp-speech-faq/*
  comp.sys.sgi.misc        sgi/faq/*
  sci.data.formats         sci-data-formats
  sci.image.processing     image-processing/Macintosh

These FAQs may also be found the newsgroups alt.answers, comp.answers,
sci.answers, and news.answers, and in the FAQ archives at rtfm.mit.edu
and mirror sites. 

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 concerning this FAQ.

All questions, comments, additions, and corrections should be sent to the
author of this FAQ at jdm@netcom.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 4.).

  * The format is proprietary and its caretakers do not wish information
    on the format distributed in this FAQ.

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

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 a FAQ posted to comp.dsp. You may obtain
this FAQ from the Usenet newsgroups comp.dsp, comp.answers, and news.answers,
or from the FTP archive site (and mirrors):

  ftp://rtfm.mit.edu/pub/usenet-by-group/comp.dsp

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

  ftp://svr-ftp.eng.cam.ac.uk/pub/comp.speech/FAQ-complete
  ftp://rtfm.mit.edu/pub/usenet/news.answers/comp-speech-faq/*

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

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

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, 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. 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
translator/viewer 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 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. 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.

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

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

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 used
are Checksum, Cyclic Redundancy Check (CRC), Longitudinal Redundancy Check
(LRC), and Vertical Redundancy Check (VRC). These algorithms are common in
the world of synchronous serial communications for detecting errors in data
streams.

Most graphics files do not contain the built-in feature of error detection.
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 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. Quite a pain, really. Can't we just store the
CRC value externally to the file? Maybe use 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. ar and tar 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
when the file is unarchived after transport, you know that the file has been
corrupted.

One extra tip: make sure you turn compression OFF when archiving many
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 encoding
methods (such as JPG and GIF) will surely grow in size.

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

Subject: III. Graphics File Resources

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

Subject: 0. File Format Specifications FTP Archives

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.chinalake.navy.mil/pub/format_specs
  ftp://avalon.vislab.navy.mil/pub/format_specs
  ftp://ftp.nau.edu/graphics/formats
  ftp://ftp.ncsa.uiuc.edu:/misc/file.formats/graphics.formats
  ftp://ftp.std.com/obi/Standards/Graphics/Formats
  ftp://ftp.uu.net/doc/literary/obi/Standards/Graphics/Formats
  ftp://ftp.wustl.edu/doc/graphic-formats
  ftp://peipa.essex.ac.uk/ipa/file.formats
  ftp://telva.ccu.uniovi.es/pub/graphics/file.formats
  ftp://x2ftp.oulu.fi/pub/msdos/programming/formats
  ftp://zamenhof.cs.rice.edu/pub/graphics.formats

  http://www.dcs.ed.ac.uk/home/iat/index.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.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:://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://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

  Red's Nightmare (a ray-traced animation)
    ftp://ftp.uni-erlangen.de/pub/pictures/mpeg/LOCAL/RedsNightmare.tar

  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)

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

  Mat Carr's animations
    http://archpropplan.auckland.ac.nz/People/Mat/gallery/animations.html

  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://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://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://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.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.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.lightside.com/~dani/cgi/images-index.html
    3DWEB - World Wide Web site for 3D Computer Graphics

  http://www.sd.tgs.com/~template
    Web3D - World Wide Web site for 3D Graphics

  http://www.state51.co.uk/state51/
    State51 Interactive Media
 
  http://www.yak.net/pub/emptystreet/emptystreet.html

  http://www.univ.trieste.it/mmwwwpc/mmwwwpc.html
    MultiMedia WWW PC v1.1

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

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.

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

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

  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.

  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. This list is alphabetized by title and information
on how to order each book is included where known.

  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.

  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, O'Reilly & Associates Inc. 1994.
    ISBN 1-56592-058-9, $59.95 softcover, 928 pages.
    Order: order@ora.com, 800.998.9938 voice, 707.829.014 fax.

  File Formats for Popular PC Software: A Programmer's Reference,
    Walden, Jeff, John Wiley & Sons, Inc. 1986. ISBN 0-471-83671-0, 
    287 pages.

  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.

  The Graphic File Toolkit: Converting and Using Graphic Files,
    Steve Rimmer, Addison-Wesley, 1992. 335 pages.

  Inside Windows File Formats, Tom Swan, Sams Publishing 1993.
    ISBN 0-672-30338-8 $24.95 softcover, 337 pages.
    Order: Sams Publishing, 2201 West 103rd Street, Indianapolis,
    IN 46290

  More File Formats for Popular PC Software: A Programmer's Reference,
    Jeff Walden, John Wiley and Sons 1987. 369 pages.

  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.

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

  PCX Graphics, C Users Journal, Ian Ashdown, Vol 9, Num 8, August 1991,
    pp. 89-96.

  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.
    
  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: 5. 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
  Building 4D
  700 Robbins Avenue
  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

  Global Engineering Documents
  2805 McGaw Avenue
  Irvine, CA 92714 USA
  Voice: 800.854.7179
  Voice: 714.261.1455

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

Subject: 6. Other 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: +41 22 749 01 11
  Fax:   +41 22 733 34 30

  American National Standards Institute (ANSI)
  Sales Department
  1430 Broadway
  New York, NY 10018
  Voice: 212.642.4900

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

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

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, and HPGL file formats either?

IGES (Initial Graphics Exchange Specification), GKS (Graphics Kernel System),
and NAPLPS (North American Presentation Layer Protocol Syntax) are not
actually file formats. They are instead protocols which specify how graphical
data should be transmitted over a communications link (such as a telephone
line) to a remote device (such as a graphical workstation).  HPGL
(Hewlett-Packard Graphics Language) is a printer control language (PCL) used
to transfer and manipulate data used by printers.

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 (HPGL uses 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,HPGL} file format".

Descriptions of each of these standards may be found in Part 3 (Where to Get
File Format Specifications) of this FAQ.

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

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 it's
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: 6. Is it now illegal to use CompuServe's GIF format?

[ This section to be revised (I'm still trying to get the accurate poop) ]

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

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

  John T. Grieggs 
  Lee Kimmelman 
  Tom Lane 
  Angus Montgomery 
  Glen Ozymok 
  Daniel Sears 
  Bjoern Stabell 

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

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 passable
living writing Microsoft Windows applications in C++, and may be reached as
jdm@netcom.com, or via U.S. Snail at: P.O. Box 70, Orange, CA 92666-0070 USA.

GCS d-- H++ s g- p? au+ a w+ v++ C+++(++++) US+++ p++>++++ L>++ 3 E--- N++ K-
W---$ M-@ V-- po Y+ t++ 5-- j>x R+>-- G' tv-->! b+++ D++ B e- u* h- f r-->+++
n++ y*(**)

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

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 (C) 1994-95 by James D. Murray. All Rights Reserved. 
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.




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

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: General Graphics Format Questions (Part 1 of 4)
  Graphics File Formats FAQ: Image Conversion and Display Programs (Part 2 of 4)
  Graphics File Formats FAQ: Where to Get File Format Specifications (Part 3 of 4)
  Graphics File Formats FAQ: Tips and Tricks of the Trade (Part 4 of 4)

Please email contributions, corrections, and suggestions about this FAQ to
jdm@netcom.com. Relevant information posted to newsgroups will not
automatically make it into this FAQ.

-- James D. Murray (jdm@netcom.com)  ;-{)>>>>

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

Subject: 0. Contents of Image Conversion and Display Programs

Subjects marked with  are new to this FAQ.
Subjects marked with  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. Image Conversion and Display Programs

0. Image Conversion and Display Programs for MS-DOS
1. Image Conversion and Display Programs for Windows 
2. Image Conversion and Display Programs for Macintosh
3. Image Conversion and Display Programs for Unix and X Window
4. Platform-Independent Image Conversion Toolkits 

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

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.

And yes, I know this FAQ part has seen precious little updating the last few
months. I swear that I'll get some more application in here over the next few
months. And *you* could help out by sending me some suggestions. ;-{)>>>>

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

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

  o New Window conversion application added

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

Subject: II. Image Conversion and Display Programs

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

Subject: 0. Image Conversion and Display Programs for MS-DOS

  Name:     DISPLAY
  Purpose:  Image display and conversion
  Version:  1.87
  Author:   Jih-Shin Ho 
  FTP:      ftp://NCTUCCCA.edu.tw/PC/graphics/disp
  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, and GL.
  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, and RAW GREY.
  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:     Graphics Display System (GDS)
  Purpose:  Image display, conversion, thumbnail catalogs
  Version:  3.1e
  Author:   Photodex Corporation 
  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.  
  
------------------------------

Subject: 1. Image Conversion and Display Programs for Windows

  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:     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:     $349 (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 
  FTP:      ftp://oak.oakland.edu/pub/msdos/windows3/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:     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:     GIFConverter
  Purpose:  Image display, conversion, and printing
  Version:  2.3.7
  Author:   Kevin Mitchell 
  FTP:      ftp://mac.archive.umich.edu/mac/graphics/graphicsutil/gif-converter-237.hqx
  Imports:  GIF, JPEG, JFIF, TIFF, RIFF, MacPaint, Thunderscan, PICT
  Exports:  GIF, JPEG, JFIF, TIFF, RIFF, MacPaint, Thunderscan, PICT, EPS
  Features: Dithers and halftones, laser printer support

  Name:     JPEGView
  Purpose:  Image file viewer
  Version:  3.2.1
  Author:   Aaron Giles 
  FTP:      ftp://guru.med.cornell.edu/pub/jpegview/jpegview32.sit.hqx
  Imports:  JPEG, TIFF, BMP, GIF, PICT, Startup Screen
  Exports:  
  Features: Uses QuickTime

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

Subject: 3. Image Conversion and Display Programs for Unix and X Window

  Name:     ImageMagick
  Purpose:  X Window-based image display and conversion
  Version:  3.3
  Author:   John Cristy 
  FTP:      ftp://ftp.x.org/contrib/applications/ImageMagick/ImageMagick-3.3.tar.gz
  Imports:  AVS, BMP, Raw CMYK, Group 3 FAX, FITS, GIF, Raw GRAY,
            JPEG, MIFF, MPEG, MTV, Photo CD, PCX, Mac PICT, PBM, PDS, PGM,
            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,
            JPEG, MIFF, MTV, PCX, Mac PICT, PBM, PGM, 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:     xanim
  Purpose:  Animation file viewer
  Version:  
  Author:   Mark Podlipec
  FTP:      ftp://ftp.x.org/contrib/applications/xanim???.tar.Z
  WWW:      
  Imports:  DL, FLI, FLC, GIF, IFF, MovieSetter, PFX, Quicktime, RLE

  Name:     xv
  Purpose:  X Window-based image display
  Version:  3.00c
  Author:   John Bradley 
  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. Platform-Independent Image Conversion Toolkits

  Name:     libtiff
  Purpose:  TIFF file manipulation toolkit
  Version:  3.3
  Author:   Sam Leffler 
  FTP:      ftp://sgi.com/graphics/tiff/*.tar.Z
  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:  5
  Author:   Independent JPEG Group 
  FTP:      ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v?.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

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


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

  Vincent Chen 
  John Cristy 
  Tom Lane 
  Angus Montgomery 
  Borut Podlipnik 
  Paul Schmidt 
  Marc Stengel 

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

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 passable
living writing Microsoft Windows applications in C++, and may be reached as
jdm@netcom.com, or via U.S. Snail at: P.O. Box 70, Orange, CA 92666-0070 USA.

GCS d-- H++ s g- p? au+ a w+ v++ C+++(++++) US+++ p++>++++ L>++ 3 E--- N++ K-
W---$ M-@ V-- po Y+ t++ 5-- j>x R+>-- G' tv-->! b+++ D++ B e- u* h- f r-->+++
n++ y*(**)

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

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 (C) 1994-95 by James D. Murray. All Rights Reserved. 
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.




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

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: General Graphics Format Questions (Part 1 of 4)
  Graphics File Formats FAQ: Image Conversion and Display Programs (Part 2 of 4)
  Graphics File Formats FAQ: Where to Get File Format Specifications (Part 3 of 4)
  Graphics File Formats FAQ: Tips and Tricks of the Trade (Part 4 of 4)

Please email contributions, corrections, and suggestions about this FAQ to
jdm@netcom.com. Relevant information posted to newsgroups will not
automatically make it into this FAQ.

-- James D. Murray (jdm@netcom.com)  ;-{)>>>>

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

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

Subjects marked with  are new to this FAQ.
Subjects marked with  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

0. BMP - Windows Bitmap Format 
1. CALS - Computer Aided Acquisition and Logistics Support Raster Format
2. CGM - Computer Graphics Metafile
3. DEM - Digital Elevation Model 
4. DLG - Digital Line Graph 
5. EPS - Encapsulated PostScript
6. GIF - Graphics Interchange Format 
7. GKS - Graphics Kernel System 
8. IGES - Initial Graphics Exchange Specification 
9. JFIF - JPEG File Interchange Format 
10. MGF - Materials and Geometry Format 
11. MIFF - Magick Image File Format
12. NAPLPS - North American Presentation Layer Protocol Syntax 
13. NFF - Neutral File Format 
14. NITF - National Imagery Transmission Format 
15. OFF - Object File Format
16. PCX - ZSoft Paint
17. PDS - Planetary Data Systems Format
18. PNG - Portable Network Graphics 
19. POV - Persistence of Vision Raytracing 
20. Rayshade
21. Renderman 
22. RIFF - Microsoft Resource Interchange File Format 
23. RIX - ColoRIX Image File
24. SHG - Segmented Hyper-Graphic 
25. TGA - Truevision (Targa) File Format 
26. TIFF - Tag Image File Format 
27. VICAR2 - Planetary File Format
28. VIFF - Visualization Image File Format
29. VPF - Vector Product Format 

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

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@netcom.com and let me know!

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

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

  o 6 new file format specification whereabouts added

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

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.

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

Subject: 0. BMP - Windows Bitmap Format

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.

The BMP format was created and is maintained by Microsoft Corporation:

  Microsoft Corporation
  One Microsoft Way
  Redmond, WA 98052-6399
  Voice: 206.882.8080
  Fax: 206.936.7329
  BBS: 206.637.9009

Additional BMP references:

  Luse, Marv. "The BMP File Format," Dr. Dobb's Journal, #219 September
  1994 (Vol 9, Issue 10), pp. 18-22.

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

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

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 

These documents may be obtained from the following sources:

  Standardization Documents Ordering Desk
  Building 4D
  700 Robbins Avenue
  Philadelphia, PA 19111-5094

  Global Engineering Documents
  2805 McGaw Avenue
  Irvine, CA 92714 USA
  Voice: 800.854.7179
  Voice: 714.261.1455

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 and
    Information Systems
  Headquarters Defense Logistics Agency
  Cameron Station
  Alexandria, VA 22314 USA

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

Subject: 2. CGM - Computer Graphics Metafile

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
  1430 Broadway
  New York, NY 10018
  Voice: 212.642.4900

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

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

Subject: 3. DEM - Digital Elevation Model

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

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

Subject: 4. DLG - Digital Line Graph

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: 5. EPS - Encapsulated PostScript

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: 6. GIF - Graphics Interchange Format

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

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

Subject: 7. GKS - Graphics Kernel System

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: 8. IGES - Initial Graphics Exchange 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

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

Subject: 9. JFIF - JPEG File Interchange Format

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

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

Subject: 10. MGF - Materials and Geometry Format

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 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 an alpha release stage, which means the
language may change in some incompatible ways between now and the first
release.  Use this software and data in this package at your own risk.

Questions about MGF should be directed to:

Greg Ward
Voice: 510.486.4757
Fax:   510.486.4089
Email: GJWard@lbl.gov

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

Subject: 11. MIFF - Magick Image File Format

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.x.org/contrib/ImageMagick-3.0.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: 12. NAPLPS - North American Presentation Layer Protocol Syntax

NAPLPS is a protocol for transferring ASCII-based graphical information to
remote terminals via a communications channel (telephone systems, computer
networks, and so forth). NAPLPS is used by many Videotext services and
Prodigy, the commercial on-line information service, and is specifically
designed to provide usable information transfer rates, even at data rates as
low as 2400bps.

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.  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: 13. NFF - Neutral File Format

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: 14. NITF - National Imagery Transmission Format

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

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

Subject: 15. OFF - Object File Format

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

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

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

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

Subject: 16. PCX - ZSoft Paint

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.

The PCX specification is available directly from ZSoft:

  ZSoft Corporation
  Attn: Shannon Donovan
  450 Franklin Road, Suite 100
  Marietta, GA 32067
  Voice: 404.428.0008
  Fax:   404.427.1150
  BBS:   404.427.145
  CompuServe: 76702,1207

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

Subject: 17. PDS - Planetary Data Systems Format

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

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

Subject: 18. PNG - Portable Network Graphics

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 battle involving the GIF format may also have
something to do with it too :-)

The following paragraph, excerpted from the PNG (Portable Network Graphics)
specification, eighth draft, 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 eighth draft and is expected to be
finalized in March 1995. A public draft of the current PNG specification may
be found at:

  http://sunsite.unc.edu/boutell/png.html

Questions about PNG may be asked on the comp.graphics newsgroup or
directed to the principle author of the PNG specification:

  Thomas Boutell 

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

Subject: 19. POV - Persistence of Vision Raytracing

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 site: 
  
  ftp://alfred.ccs.carleton.ca/pub/pov-ray/POV-Ray2.2/POVDOC.*

Questions about POV-Ray may also be direct to:

  Drew Wells
  POV-Team Leader
  73767.1244@compuserve.com

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.

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

Subject: 20. Rayshade

Rayshade is a ray-tracing application for the MS-DOS 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 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: 21. Renderman

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

  The RenderMAN Interface, Version 3.0 May 1988

  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: 22. RIFF - Microsoft Resource Interchange File Format

  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), on Disk 8 of the Microsoft Developer's Network CD distribution,
and as a MS Windows help file on the FTP archive site:

  ftp://ftp.microsoft.com/developer/MSDN/CD8/RIFFNE.ZIP

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

Subject: 23. RIX - ColoRIX Image File

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 available from:

  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: 24. SHG - Segmented Hyper-Graphic

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 the 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: 25. TGA - Truevision (Targa) File Format

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.truevision.com

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

Subject: 26. TIFF - Tag Image File Format

The TIFF 6.0 specification is available in the TIFF Developer's Kit.
Information on obtaining this kit and joining the Aldus Developer's
Association (ADA) may be obtained from the Developer's Desk at Aldus
Corporation:

  Aldus Corporation
  Attn:: Aldus Developer's Desk
  4411 First Avenue South
  Seattle, WA 98144-2871
  Voice: 206.628.6593, 800.331.2538
  Fax:   206.343.4240
  Email: tiff-input@aldus.com

Or from the following FTP site:

  ftp://sgi.com/graphics/tiff/TIFF6.ps.Z

The TIFF Class F specification may be obtained from ADA's FAXback service at
206.628.5753. Order document #9001 for an index of all documents available
from this service.

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

Subject: 27. VICAR2 - Planetary File Format

VICAR2 is used to store planetary image data gathered from Earth and by
spacecraft. VICAR2 is similar in design and use to the FITS and PDS formats.

Information on VICAR2 may be obtained directly from JPL:

  NASA
  Attn: Bob Deen
  Image Processing Laboratory
  Jet Propulsion Laboratory
  4800 Oak Grove Drive
  Pasadena, CA 91109
  Email: rgd059@mipl3.jpl.nasa.gov

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

Subject: 28. VIFF - Visualization Image File Format

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: 29. VPF - Vector Product Format

VPF is primarily used for transmitting digital geographic databases.  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 standards
document:

  MIL-STD-2407, 30 September 1993

This MIL-STD may be obtained from:

  Naval Publications & Forms Center
  Code 3051
  5801 Tabot Ave.
  Philadelphia, PA 19120 USA

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

Subject: III. 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 
  John Cristy 
  James Durham 
  Eric Haines 
  Tom Lane 
  Stanley F. Quayle 

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

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 passable
living writing Microsoft Windows applications in C++, and may be reached as
jdm@netcom.com, or via U.S. Snail at: P.O. Box 70, Orange, CA 92666-0070 USA.

GCS d-- H++ s g- p? au+ a w+ v++ C+++(++++) US+++ p++>++++ L>++ 3 E--- N++ K-
W---$ M-@ V-- po Y+ t++ 5-- j>x R+>-- G' tv-->! b+++ D++ B e- u* h- f r-->+++
n++ y*(**)

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

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 (C) 1994-95 by James D. Murray. All Rights Reserved. 
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.




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

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: General Graphics Format Questions (Part 1 of 4)
  Graphics File Formats FAQ: Image Conversion and Display Programs (Part 2 of 4)
  Graphics File Formats FAQ: Where to Get File Format Specifications (Part 3 of 4)
  Graphics File Formats FAQ: Tips and Tricks of the Trade (Part 4 of 4)

Please email contributions, corrections, and suggestions about this FAQ to
jdm@netcom.com. Relevant information posted to newsgroups will not
automatically make it into this FAQ.

-- James D. Murray (jdm@netcom.com)  ;-{)>>>>

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

Subject: 0. Contents of Tips and Tricks of the Trade

Subjects marked with  are new to this FAQ.
Subjects marked with  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?

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@netcom.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 First release of this new FAQ part!

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

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 WORD 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 WORD 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 >> 0x08) & 0xFF, fp);
      fputc((dw >> 0x10) & 0xFF, fp);
      fputc((dw >> 0x18) & 0xFF, fp);
      fputc(dw & 0xFF, fp);
  }
  
  void PutLittleDoubleWord(DWORD dw, FILE *fp)
  {
      fputc(w & 0xFF, fp);
      fputc((w >> 0x08) & 0xFF, fp);
      fputc((w >> 0x10) & 0xFF, fp);
      fputc((w >> 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 w = 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: III. Kudos and Assertions

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

Subject: 0. Acknowledgments

Nobody yet. 

Doesn't anybody have any neat tricks to share?

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

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 passable
living writing Microsoft Windows applications in C++, and may be reached as
jdm@netcom.com, or via U.S. Snail at: P.O. Box 70, Orange, CA 92666-0070 USA.

GCS d-- H++ s g- p? au+ a w+ v++ C+++(++++) US+++ p++>++++ L>++ 3 E--- N++ K-
W---$ M-@ V-- po Y+ t++ 5-- j>x R+>-- G' tv-->! b+++ D++ B e- u* h- f r-->+++
n++ y*(**)

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

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 (C) 1994-95 by James D. Murray. All Rights Reserved. 
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.