home *** CD-ROM | disk | FTP | other *** search
- Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!cam-news-feed2.bbnplanet.com!amber.ora.com!not-for-mail
- From: jdm@ora.com
- Newsgroups: comp.graphics.misc,comp.answers,news.answers
- Subject: Graphics File Formats FAQ (Part 1 of 4): General Graphics Format Questions
- Supersedes: <graphics/fileformats-faq-1-849730784@ora.com>
- Followup-To: poster
- Date: 20 Jan 1997 00:13:01 -0800
- Organization: O'Reilly & Associates, Inc.
- Lines: 2150
- Sender: jdm@ruby.ora.com
- Approved: news-answers-request@MIT.EDU
- Distribution: world
- Expires: 02/24/97 00:13:00
- Message-ID: <graphics/fileformats-faq-1-853747980@ora.com>
- Reply-To: jdm@ora.com (James D. Murray)
- NNTP-Posting-Host: ruby.ora.com
- Summary: This document answers many of the most frequently asked
- questions about graphics file formats on Usenet.
- Keywords: FAQ, GRAPHICS, FORMAT, IMAGE, MULTIMEDIA, 3D
- Xref: senator-bedfellow.mit.edu comp.graphics.misc:18679 comp.answers:23815 news.answers:92564
-
- Posted-By: auto-faq 3.1.1.2
- Archive-name: graphics/fileformats-faq/part1
- Posting-Frequency: monthly
- Last-modified: 20Jan97
-
- Graphics File Formats FAQ (Part 1 of 4): General Graphics Format Questions
-
- ------------------------------
-
- his FAQ (Frequently Asked Questions) list contains information on
- graphics file formats, including, raster, vector, metafile, Page
- Description Language, 3D object, animation, and multimedia formats.
-
- This FAQ is divided into four parts, each covering a different area of
- graphics file format information:
-
- Graphics File Formats FAQ (Part 1 of 4): General Graphics Format Questions
- Graphics File Formats FAQ (Part 2 of 4): Image Conversion and Display Programs
- Graphics File Formats FAQ (Part 3 of 4): Where to Get File Format Specifications
- Graphics File Formats FAQ (Part 4 of 4): Tips and Tricks of the Trade
-
- Please email contributions, corrections, and suggestions about this FAQ to
- jdm@ora.com. Relevant information posted to newsgroups will not
- automatically make it into this FAQ.
-
- -- James D. Murray
-
- ------------------------------
-
- Subject: 0. Contents of General Graphics Format Questions
- Subjects marked with <NEW> are new to this FAQ. Subjects marked with <UPD>
- have been updated since the last release of this FAQ.
-
- I. General questions about this FAQ
-
- 0. Maintainer's Comments
- 1. What's new in this latest FAQ release?
- 2. Why does a graphics formats FAQ exist?
- 3. Where can I get the latest copy of this FAQ?
- 4. Are there other related FAQs I should read as well?
- 5. I have a question, correction, or some information for
- this FAQ.
- 6. This FAQ doesn't contain enough detail!
- 7. Why isn't the XXX file format covered?
- 8. Why aren't audio file formats covered?
- 9. Why aren't word processing formats covered?
- 10. What about multimedia file formats?
- 11. What is an "Internet File Format?"
- 12. Which file formats should I and should I not use?
- 13. What is ray tracing?
- II. General Graphics File Questions
-
- 0. Who cares about graphics file formats?
- 1. What is raster, vector, metafile, PDL, VRML, and so
- forth?
- 2. Why should I care about previous versions of a file
- format?
- 3. Can graphics files be infected with a virus?
- 4. Can graphics files be encrypted?
- 5. How can I convert the XXX format to the YYY format?
- 6. Do I really need the specification of the format I'm
- using?
- 7. How can I tell if a graphics file is corrupt?
- 8. What do I put in my own graphics file format
- specification?
- III. Working with Graphics Files on Usenet and the Internet
-
- 0. How can I email a graphics file?
- 1. Where can I find graphics files on Usenet?
- 2. How do I decode a graphics file posted to Usenet?
- 3. How can I post a graphics file to Usenet?
- 4. How do I submit a file format specification to an
- archive?
- 5. How can I make transparent and interlaced GIFs for a Web
- page?
- 6. How do I combine still images to make animations?
- IV. Copyrights, Patents, and other Legalities of Graphics File Formats
-
- 0. Can a graphics file be copyrighted?
- 1. Is it now illegal to use CompuServe's GIF format?
- V. Graphics Formats Misnomers, Misgivings, and Miscellany
-
- 0. Why aren't JPEG, MPEG, LZW, and CCITT Group 3 & 4
- file formats?
- 1. Why aren't IGES, GKS, NAPLPS, PCL, and HPGL file formats
- either?
- 2. Is it "Tag" or "Tagged" Image File
- Format?
- 3. Whaddya mean there's no "Targa" file format?
- 4. Choosy programmers choose "gif" or "jif"?
- 5. Why are there so many ".PIC" and ".IMG"
- formats?
- 6. Where can I get the spec for the GIF24 format?
- 7. Is there an uncompressed GIF format?
- VI. Graphics File Resources
-
- 0. File Format Specifications FTP Archives and WWW
- Pages
- 1. Graphics and Image File FTP Archives and WWW Pages
- 2. Internet Mailing Lists for Graphics and Imaging
- 3. Books on Graphics File Formats
- 4. Magazine Articles on Graphics File Formats
- VII. Kudos and Assertions
-
- 0. Acknowledgments
- 1. About The Author
- 2. Disclaimer
- 3. Copyright Notice
-
- ------------------------------
-
-
- Subject: I. General questions about this FAQ
-
- ------------------------------
-
- ubject: 0. Maintainer's Comments
-
- The GFF FAQ is now included in the Sandy Bay Software PC Webopaedia
- at:
- http://www.sandybay.com/pc-web/graphics_file_format.htm
-
- ------------------------------
-
- ubject: 1. What's new in this latest FAQ release?
-
- o Add some new LZW information. Need to update this section more.
- o Added section on uncompressed GIF files
- o Several new file format book entries and one new journal article
- o Updated many URLs
-
- ------------------------------
-
- ubject: 2. Why does a graphics formats FAQ exist?
-
- The purpose of this FAQ is to answer many of the frequently asked questions
- about graphics file formats posted on Usenet. You will find definitions of
- terms, references to format information, very general descriptions of many
- formats, information on programs which read, write, convert, and display
- graphics files, and some handy programming tips for writing your own code.
- This FAQ is not a substitute for actual file format specifications, nor can
- it possibly go into a great amount of specific detail on graphics file
- formats.
-
- ------------------------------
-
- ubject: 3. Where can I get the latest copy of this FAQ?
-
- The latest revision of this FAQ is always available at
- http://www.ora.com/infocenters/gff/gff-faq/. This FAQ is also
- distributed monthly on the Usenet newsgroups comp.graphics.misc,
- comp.answers, and news.answers as four separate files. It may also
- be obtained via anonymous FTP from:
-
- ftp://rtfm.mit.edu/pub/usenet/news.answers/graphics/fileformats-faq
- ftp://rtfm.mit.edu/pub/usenet/comp.graphics.misc
-
- To receive a copy of this FAQ via email, send an email message to
- mail-server@rtfm.mit.edu with the body:
-
- send usenet/news.answers/graphics/fileformats-faq/part1
- send usenet/news.answers/graphics/fileformats-faq/part2
- send usenet/news.answers/graphics/fileformats-faq/part3
- send usenet/news.answers/graphics/fileformats-faq/part4
-
- or via UUCP:
-
- uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part1
- uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part2
- uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part3
- uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part4
-
- Other sites on the World Wide Web that archive this FAQ include:
-
- http://www.jazzie.com/ii/internet/faqs.html
- http://www.cs.ruu.nl/wais/html/na-dir/graphics/fileformats-faq/.html
- http://www.lib.ox.ac.uk/search/search_faqs.html
-
- ------------------------------
-
- ubject: 4. Are there other related FAQs I should read as well?
-
- Information related to file formats not covered by this FAQ may be
- found in the following FAQs:
-
- Newsgroup Archive-name
-
- alt.binaries.pictures pictures-faq/part[1-3]
- alt.graphics.pixutils pixutils-faq
- alt.image.medical medical-image-faq/part[1-8]
- alt.sci.astro.apis astronomy/aips-faq
- comp.compression compression-faq/part[1-3]
- mpeg-faq/part[1-8]
- comp.dsp dsp-faq/part[1-3]
- audio-fmts/part[1-2]
- comp.fonts fonts-faq/part[1-2]
- comp.graphics.misc graphics/faq
- graphics/colorspace-faq
- graphics/resources-list/part[1-3]
- jpeg-faq/part[1-2]
- comp.graphics.animation graphics/animation-faq
- comp.graphics.rendering.raytracing graphics/raytrace-faq/part[1-2]
- comp.infosystems.gis geography/infosystems-faq/part[1-2]
- comp.infosystems.www.authoring.images
- comp.multimedia comp-multimedia-faq
- comp.speech comp-speech-faq/part[1-3]
- comp.sys.sgi.misc sgi/faq/graphics
- sci.data.formats sci-data-formats
- sci.image.processing image-processing/Macintosh
- sci/Satellite-Imagery-FAQ/part[1-5]
-
- These FAQs may also be found the newsgroups alt.answers, comp.answers,
- sci.answers, and news.answers, and in the FAQ archives at rtfm.mit.edu and mirror sites.
- Please read the news.answers FAQ for a log listing of WWW, FTP, gopher, and
- mail server FAQ archives. This FAQ is housed at http://rtfm.mit.edu/pub/usenet/news.answers/news-answers/introduction
-
- To FTP any of these FAQs use the listed Archive-name with the following
- FTP address:
-
- ftp://rtfm.mit.edu/pub/usenet/news.answers/ [Archive-name]
-
- To receive a copy of these FAQs via email, send an email message to
- mail-server@rtfm.mit.edu with the body:
-
- send usenet/news.answers/[Archive-name]
-
- ------------------------------
-
- ubject: 5. I have a question, correction, or some information for this FAQ.
-
- All questions, comments, additions, and corrections should be sent to the
- author of this FAQ at jdm@ora.com.
-
- I don't always read the newsgroups this FAQ is posted to, so please contact
- me directly via email rather than attempting to reach me by posting to a
- newsgroup. All suggestions and contributions within the scope of this FAQ
- are welcome and contributors receive full credit in the Acknowledgments
- section of this FAQ.
-
- ------------------------------
-
- ubject: 6. This FAQ doesn't contain enough detail!
-
- This FAQ only attempts to answer Frequently Asked Questions. It is not a
- book on graphics file formats. It is instead a thick source of information
- that will help you obtain more information that you need. Or perhaps even
- clear up a few of your misconceptions and thereby saving you from wasting
- some time.
-
- ------------------------------
-
- ubject: 7. Why isn't the XXX file format covered?
-
- If you have read and/or grepped this FAQ and not found information on the
- format you need the reason might be that:
-
- * You are looking for the format under the wrong name.
-
- * This FAQ is new and the information you need hasn't been included yet.
-
- * I don't know about the format and I need you to email me information
- on it (See Subject: 5).
-
- * The format is proprietary and its caretakers do not wish information
- on the format distributed in this FAQ.
-
- And let me make one thing perfectly clear: I have have not proposley
- omitted the reference to any file formats, books, or software applications
- that I see as within the scope of this FAQ. If you don't see information
- here that you consider relavent and necessary, then *tell me* and I will
- include it.
-
- ------------------------------
-
- ubject: 8. Why aren't audio file formats covered?
-
- Information on file formats used specifically for storing audio data
- are already covered quite nicely by the Audio File Formats FAQ
- maintained by Guido van Rossum <guido@cnri.reston.va.us> or
- <guido@python.org>.
-
- You may obtain this FAQ from the Usenet newsgroups comp.dsp,
- comp.answers, and news.answers, from the FTP archive sites:
-
- ftp://ftp.cwi.nl/pub/audio/
- ftp://rtfm.mit.edu/pub/usenet/news.answers/comp.dsp/
-
- or via the Web page:
-
- http://www.cwi.nl/ftp/audio/AudioFormats.part1
- http://www.cwi.nl/ftp/audio/AudioFormats.part2
-
- The FAQ for comp.speech may of also be of interest to audio people. It is
- available at:
-
- ftp://rtfm.mit.edu/pub/usenet/news.answers/comp-speech-faq/
- ftp://svr-ftp.eng.cam.ac.uk/pub/comp.speech/FAQ-complete
-
- ------------------------------
-
- ubject: 9. Why aren't word processing formats covered?
-
- It is true that there are many types of file formats that cannot store
- graphics data (older word processor and spreadsheet formats, and so forth).
- These formats are not within the scope of this FAQ and are therefore not
- covered. Perhaps someone who works in the biz of writing file translators
- for these formats will put together such a FAQ one day.
-
- ------------------------------
-
- ubject: 10. What about multimedia file formats?
-
- Multimedia file formats store more than just graphics data. They may also
- contain audio, video, animation, and textual data in addition to bitmapped
- and vectored graphics. Such formats, although a superset of graphics
- formats, are considered to be within the scope of this FAQ and are
- therefore covered. Also check the comp.multimedia FAQ for additional
- information you may require.
-
- ------------------------------
-
- ubject: 11. What is an "Internet File Format?"
-
- If you have searched the Web lately using the key phrases "file format",
- "data format", or "graphics format", you have most likely run across many
- Web pages claiming to have all the information you need on "Internet File
- Formats." In fact, there is no such thing.
-
- The Internet is a global communications network used for one thing--to
- move data from one location to another. The data does not need to be in
- the format of a "file" to be moved, nor are file and data formats created
- originally for use on the Internet (e.g. MIME, X.400, uucode, and so
- forth) only found on the Internet.
-
- There are many file formats you will constantly encounter while using the
- Internet. GIF and JPEG for still-images, MPEG, MOV, and AVI for video, WAV
- and AU for audio, Z and gz for compressed files, and ZIP, tar, and ARJ for
- file archives. And while these formats are found in great profusion on the
- Internet, they were by no means created to be specifically used on or by
- the Internet and its community. Therefore, the term "Internet File Format"
- is inaccurate and misleading.
-
- ------------------------------
-
- ubject: 12. Which file formats should I and should I not use?
-
- [ Still working on this ]
-
-
- ------------------------------
-
- ubject: 13. What is ray tracing?
-
- The following FTP sites and Web pages contain ray tracing information:
-
- http://www.cm.cf.ac.uk/Ray.Tracing/index.old.html
- The Ray Tracing Home Page
-
- http://www.povray.org/rtn/
- Ray Tracing News Guide
-
- ------------------------------
-
- Subject: II. General Graphics File Questions
-
- ------------------------------
-
- ubject: 0. Who cares about graphics file formats?
-
- Well, programmers do mostly. But end-users (that is, non-programmers) do as
- well.
-
- The typical end-user only cares about storing their graphics information
- using a format that most graphics programs and filters can read. End-users
- are typically not concerned with the internal arrangement of the data
- within the graphics file itself. They only want the format to do its job
- by representing their data correctly in a permanent form.
-
- Programmers, on the other hand, are that rare breed of human that just
- can't leave information well enough alone. They need to know how every
- byte is arranged to see if someone knows something that they don't (and
- often snicker contentedly to themselves when they find that it is really
- they that know more). Programmers will then use this information to write
- code that may never see the light of distribution, but nevertheless, they
- will have had fun and gained enlightenment from writing it.
-
- It doesn't matter which of these two types of people you are. If you have
- even the slightest interest in graphics file formats then you may be
- counted as one who cares.
-
- ------------------------------
-
- ubject: 1. What is raster, vector, metafile, PDL, VRML, and so forth?
-
- These terms are used to classify the type of data a graphics file contains.
- Raster files (also called bitmapped files) contain graphics information
- described as pixels, such as photographic images. Vector files contain
- data described as mathematical equations and are typically used to store
- line art and CAD information. Metafiles are formats that may contain
- either raster or vector graphics data. Page Description Languages (PDL)
- are used to describe the layout of a printed page of graphics and text.
- Animation formats are usually collections of raster data that is displayed
- in a sequence. Multi-dimensional object formats store graphics data as a
- collection of objects (data and the code that manipulates it) that may be
- rendered (displayed) in a variety of perspectives. Virtual Reality
- Modeling Language (VRML) is a 3D, object-oriented language used for
- describing "virtual worlds" networked via the Internet and hyperlinked
- within the World Wide Web. Multimedia file formats are capable of storing
- any of the previously mentioned types of data, including sound and video
- information.
-
- ------------------------------
-
- ubject: 2. Why should I care about previous versions of a file format?
-
- When version 2.0 of the XXX format is released all of the thousands of
- files created using version 1.0 of the XXX format don't magically
- disappear or transform to version 2.0 overnight. Although version 2.0
- might claim to be fully backwards compatible, the new specification may
- obfuscate or even omit details of the previous version of the format. In
- short, never throw away older information just because you have something
- newer. At one point in time that "out dated" format spec was
- state-of-the-art, and it may still contain a singular precious tid-bit of
- information that the caretakers of the format didn't carry over to the new
- spec (but Murphy will make sure you desperately need to know).
-
- ------------------------------
-
- ubject: 3. Can graphics files be infected with a virus?
-
- For most types of graphics file formats currently available the answer is
- "no". A virus (or worm, Trojan horse, and so forth) is fundamentally a
- collection of code (that is, a program) that contains instructions which
- are executed by a CPU. Most graphics files, however, contain only static
- data and no executable code. The code that reads, writes, and displays
- graphics data is found in translation and display programs and not in the
- graphics files themselves. If reading or writing a graphics file caused a
- system malfunction is it most likely the fault of the program reading the
- file and not of the graphics file data itself.
-
- With the introduction of multimedia we have seen new formats appear, and
- modifications to older formats made, that allow executable instructions to
- be stored within a file format. These instructions are used to direct
- multimedia applications to play sounds or music, prompt the user for
- information, or display other graphics and video information. And such
- multimedia display programs may perform these functions by interfacing
- with their environment via an API, or by direct interaction with the
- operating system. One might also imagine a truly object-oriented graphics
- file as containing the code required to read, write, and display itself.
-
- Once again, any catastrophes that result from using these multimedia
- application is most like the result of unfound bugs in the software and
- not some sinister instructions in the graphics file data. Such "logic
- bombs" are typically exorcised through the use of testing using a wide
- variety of different image files for test cases.
-
- If you have a virus scanning program that indicates a specific graphics
- file is infected by virus, then it is very possible that the file
- coincidentally contains a byte pattern that the scanning programming
- recognizes as a key byte signature identifying a virus. Contact the author
- (or even read the documentation!) of the virus scanning program to discuss
- the probability of the mis-identification of a clean file as being
- infected by a virus. Save the graphics file, as the author will most
- likely wish to examine it as well.
-
- If you suspect a graphics file to be at the heart of a virus problem you
- are experiencing, then also consider the possibility that the graphics
- file's transport mechanism (floppy disk, tape or shell archive file,
- compressed archive file, and so forth) might be the original source of the
- virus and not the graphics file itself.
-
- ------------------------------
-
- ubject: 4. Can graphics files be encrypted?
-
- Of course you can encrypt a graphics file. After all, most encryption
- algorithms don't care about the intellectual content of a file. All they
- chew on is a series of byte values. Therefore, most any encryption program
- that works on ordinary text files will work on graphics files as well.
-
- Why would you want to encrypt a graphics file? Mostly to control who can
- view its contents. You can invent a proprietary file format and that might
- slow a file format hack down for, say, five or ten minutes. You could add
- a proprietary data compression scheme, possibly a twisted variation of an
- already public algorithm. But there are so many people out there with
- nothing better to do than hack at unknown data formats that your data
- would probably be exposed in little time. But suppose we top off all this
- effort by encrypting the graphics file itself as we would an ordinary text
- file. Would your data then be safe?
-
- Realize that an encrypted graphics file still might not be very secure.
- For every data encryption algorithm there exists at least one method of
- getting around it, although it may take hundreds of computers and many
- years to fully employ and execute that method!
-
- For example, one of the more popular methods used to encrypt data is the
- Vernam or XOR cipher. This cipher Exclusive ORs the plain-text data with a
- single, random, fixed-length key. The longer the key the harder it is to
- break the cipher. A totally random key the length of your data is
- impossible to break. Shorter and less-random keys are easier to break.
-
- XOR is very simple and fast, which is a must for a graphics file
- translators/viewers that must decrypt a file on the fly. A problem,
- however, is that most graphics files contain fixed size headers which vary
- only slightly in content from file to file. If you knew the approximate
- contents of the header of an encrypted file you could XOR a "decrypted"
- header with the encrypted file and possibly produce the key used to
- encrypt the file. A short key might be very easily discovered in this way.
-
- If you wish to use a public key/private key encryption method, then
- storing the public key in the file format header (usually as a 4-byte
- field) and only encrypting the image data would be the way to go. The
- SMPTE DPX file format supports such an encryption feature.
-
- If you really need to make the contents of a graphics file secure, then
- I'd suggest not only using some form of data encryption, but also create
- an unconventional and proprietary file format and do not publish its
- format specification.
-
- For more info on data encryption:
-
- Bruce Schneier, "Applied Cryptography: Protocols, Algorithms,
- and Source Code in C", John Wiley & Sons, 1994.
-
- ------------------------------
-
- ubject: 5. How can I convert the XXX format to the YYY format?
-
- With a file conversion program, of course! Without a doubt one of the
- most frequently asked categories of questions on comp.graphics.misc
- is how to convert one format to another. In every case the answer is
- some type of conversion program or filter, but which one?
-
- Section IV of the FAQ is an attempt to list every known graphics file
- display and conversion program and application. Although far from
- complete, this list may contain the program you need. Go to the
- subsection of the particular operating system you are using and scan
- through Imports: and Exports: formats listed and see if the formats
- you needs to use are there.
-
- In some cases the information in a listing may make the conversion
- capabilities of a program a bit misleading. For example, a program
- that can import a vector .DWG file and export a raster .BMP file may
- not necessarily be able to perform a .DWG->.BMP (vector->raster)
- conversion (AutoCAD R12 can, BTW). And just because a program can
- both import and export TIFF files doesn't mean it's capable of a
- TIFF(CMYK)->TIFF(RGB) conversion (as Adobe Photoshop can do). As
- always, read the documentation, contact and ask the author of the
- program, or find a user of the program and ask them.
-
- ------------------------------
-
- ubject: 6. Do I really need the specification of the format I'm using?
-
- It depends upon the results you are trying to obtain. If you have code
- that supports the XXX format and you find it easy (and legal) to integrate
- that code into your program, then you may be tempted to do so. But realize
- that your program will support the XXX format in just the same way as the
- previous program did. In other words, your program will now work the same,
- but it will really be no better.
-
- By obtaining the format specification you can make an attempt to fully
- support all of the features and capabilities a graphics or multimedia file
- format has to offer. If you use pre-written code that only supports a
- small subset of the format's features then you are not doing justice to
- the format and cheating your users out of functionality they might need.
-
- Always strive to create the best programs possible within reason of time
- and money. Obtain the specs, look at code, and talk to programmers who
- have worked with the format before. You might gain some insight and save
- yourself some hair-pulling by supporting a feature that someone didn't
- think to include in the original requirements for your program.
-
- ------------------------------
-
- ubject: 7. How can I tell if a graphics file is corrupt?
-
- The easiest way is to display the file and decide if what you see on the
- screen or the printer is correct. This method is not fool-proof, however,
- because not all information stored in a graphics file is used for
- displaying the data it contains. Textual comments, alternate color maps,
- and unused fields in the header might be munged and go undetected.
-
- A frequent source of corruption occurs when 8-bit graphics data is
- transported via a 7-bit communications channel. The 8th bit of each byte
- is cleared (set to zero) and you are left with garbage. ASCII-mode file
- transfers may also translate carriage returns (0Dh) to line feeds (0Ah),
- or to CR/LF pairs depending upon if the file is being transferred to a
- Unix (LF-only), Macintosh (CR-only), or MS-DOS (CR/LF) system.
-
- The PNG file format supports an elegant solution to the quick detection of
- this type of corruption. The first character of every PNG file is the
- 8-bit value 89h. If this value is read as 09h, the 8th bit has been zeroed
- and you know the file is corrupt.
-
- Most graphics files do not contain any real, built-in error detection
- features. The standard way to check for corruption of any type of data
- file is to perform some sort of error-detection scheme on the file. Such
- schemes commonly used are Checksum calculations and the Cyclic Redundancy
- Check (CRC). These algorithms are commonly used in the world of
- synchronous serial communications for detecting errors in data streams.
-
- If you only wanted to provide error detection for the graphical data
- contained in a file, but not the header, then a 2- or 4-byte field in the
- header could be used to store the CRC-16 or CRC-32 value of the data. But
- what good is pure data if the header is possibly corrupt?
-
- If we calculate the CRC value of the entire file and then store that
- calculated value in the header we will have just "corrupted" the file! You
- could initialize the CRC field with zeros, calculate the value, store the
- value, and specify that the entire file need be read into memory and the
- CRC value field set to all zeros before the CRC calculation is made.
-
- File formats that segment their data into blocks or chunks would be able
- to perform a CRC on each section individually (another feature found in
- the PNG file format). Each section would store the CRC value as the last 2
- or 4 bytes of the block and the CRC value field would never be read for
- the purpose of the CRC calculation. This method makes it easier to find
- the location of the error(s) in a file. If the CRC error occured in an
- unnecessary block of data, the file might still be useful anyway. This
- block-style CRC checking also saves the reader from performing a
- time-consuming CRC calculation an entire, possibly very large, graphics
- file.
-
- But all this can be quite a pain. Can't we avoid modifying a file and just
- store the CRC value externally to the file? Maybe using some sort of
- encapsulating "wrapper"?
-
- If you want to make sure a graphics file (or any file for that matter) has
- been transported through a communications channel without sustaining any
- corruption, first store it using a file archiving program that supports
- error checking of the files contained in the archive. (Several good
- error-checking file archiving programs include PKZIP, gzip, and zoo. The
- ar and tar Unix archiving programs do not support error checking). When
- the graphics file is stored, the archival program calculates the CRC value
- of the file. If the CRC value does not match the file's calculated CRC
- after it is unarchived after transport, you know that the file has been
- corrupted.
-
- Note: make sure you turn compression OFF when archiving many types of
- graphics files. File archival programs use compression by default and will
- attempt to make your compressed data even smaller (which usually results
- in larger data, unless the archiver is smart enough to detect the negative
- compression and not attempt to compress the file). ASCII-based files (such
- as PostScript and DXF) and some RLE-encoded files (such as PCX) will be
- compressed, while other formats supporting more advanced data compression
- methods (such as JPEG and LZW) will surely grow in size.
-
- ------------------------------
-
- ubject: 8. What do I put in my own graphics file format specification?
-
- For people that are faced with the task of writing up a specification for
- their own format (or perhaps to better document someone else's), a few
- suggestions are hereby offered.
-
- A large spec needs a table of contents, bibliography, and an index.
- Most specs do not fall into this category though.
-
- On the cover sheet give the full information of your company, products
- associated with the format, the format version, date of release,
- where the latest copy of the spec may be obtained, and how developers
- may get in contact with you to ask questions.
-
- Detail the full history of the spec (including the difference between the
- current version and all previous versions) and not just the dates of its
- revision. Tell why the format was created. Detail some insights of
- how it was designed. Speculate on what features future version might
- contain. And give the names of your developers and other people
- involved. Show the human thought that exists behind the cold chunk of
- data that is your format.
-
- List the features of your format and explain how you intend that it
- should be used and not used (tell what your format is and is not).
- Give the developer your reasons that they should use your format (and
- why they should not bother with others).
-
- Include both block diagrams and ANSI C code examples of the format's
- internal data structures. Illustrate actual examples of ASCII file
- format data and hexadecimal dumps of binary format data (very useful
- to programmers, I might say).
-
- If your format includes one or more forms of data compression, error
- checking, encryption, etc., place this information in a separate
- section and give plenty of examples (both written and code) of how
- these algorithms work. Include mathematical formulas if you believe it
- makes your concepts clearer.
-
- Make the specification available both in hardcopy and electronic
- form. The hardcopy version should be formatted as a technical
- document and using a font that won't degrade badly when the spec is
- photocopied or faxed. Use a standard sized page layout so the spec
- isn't a hassle to fit in an envelope when mailed. The electronic
- version should be available as both ASCII text and PostScript files.
- Making the spec available in a word processing format (such as
- Microsoft Word or Framemaker) is nice, but not absolutely necessary.
-
- Consider making a developer's toolkit for your format. A collection
- of benchmark graphics files (one of each flavor of your format), and
- a parser written in ANSI C that reads and writes your format, is of
- tremendous help to programmers. Such a kit will allow developers to
- implement your format quickly in their products and helps minimize
- the chances of numerous software packages appearing which create
- graphics files that don't meet your spec. Examples of formats with
- toolkits include TIFF, TGA (Truevision), WordPerfect Graphics (WPG),
- and PNG.
-
- Submit your specification to every FTP/Gopher/WWW site and BBS that
- archives file format specs. Notify the maintainers of related FAQs
- (graphics, animation, multimedia, audio, medical, etc.) that your
- format exists and ask for a mention. Send your literature to graphics
- and imaging software companies to sell support of your format and/or
- software products.
-
- And a few guidelines on good technical writing in general:
-
- Write in a tutorial style with explanations and examples of your
- topics. Don't just give a terse, dictionary description of a topic
- which often leaves the readers confused and needing more.
-
- Write in simple terms. Don't assume your readers enjoy 70-word
- sentences, or have advanced degrees in mathematics or computer
- graphics.
-
- Have other people read and attempt to understand your spec. Don't
- assume that just because you understand what you've written that
- every reader will too. You, as the file format specification's
- author, understand the format inside and out. Your readers, however,
- do not. An explanation that may seem clear to you may be just
- another confusing paragraph to your readers.
-
- Write for a world-wide audience of programmers. Omit slang or regional
- expressions that a developer living on the other side of the planet
- might not understand.
-
- Programs that check spelling and grammar are our friends. Use them.
-
- Examples of some well-written format specs include: TGA, TIFF, PNG, EPSF,
- and PostScript. Some specs are written well, but contain so much
- extraneous information that they are quite complex and very tedious to
- read. Most government and military formats are in this group (for example,
- CALS, NITF, NAPLPS, IGES, GKS, and CGM). Format specs such as PCX, GIF,
- JFIF, and Sun Raster definitely fall into the "don't let this happen to
- you" catagory.
-
- ------------------------------
-
- Subject: III. Working with Graphics Files on Usenet and the Internet
-
- ------------------------------
-
- ubject: 0. How can I email a graphics file?
-
- Normally you would move a file around the Internet using a data transport
- program that handles binary data, such as UUCP and FTP. If you only have
- an ASCII-only data transport mechanism available to you, such as
- electronic mail, you will need to convert your binary graphics files to an
- ASCII format before sending them. This process is only necessary for
- binary files. ASCII-based file formats, such as DXF and PostScript, do
- not require uuencoding before emailing.
-
- On the Unix operating system you will use a program called uuencode to
- convert the 8-bit data of a graphics file to a 7-bit ASCII data file. The
- data file is then emailed and uudecoded on the receiving end.
-
- To uuencode and email a file:
-
- % uuencode picture.img picture.img | Mail user@host.site
-
- This command will pipe the output of the uuencode command to the input of
- an email program. Realize that if your email program is set up to keep a
- copy of all of the email you send, and you email a lot of uuencoded
- graphics files, your outgoing email folder will grow quite large. You can
- modify your .mailrc (or equivalent) file to route the copy of the outgoing
- graphics file to /dev/null, or you can write-protect your outgoing mail
- folder so the data can't be written:
-
- % chmod -w ~/Mail/mbox.out
- % uuencode picture.img picture.img | Mail user@host.site
- /home/Mail/mbox.out: Permission denied
- % chmod +w ~/Mail/mbox.out
-
- Once the emailed data is received, you will need to strip off the mailing
- header before you can uudecode it. The uuencoded data starts with the word
- "begin" and is followed by the file mode, file name, and a series of
- 61-character lines. The file is ASCII, so you can use an editor such as vi
- to do the stripping. Assuming the received data is saved to a file named
- "file", the uudecoing process is thus:
-
- % uudecode file
-
- The original graphics file is now in the current directory. You may delete
- the uuencoded file if you wish to do so.
-
- The uuencode and uudecode programs have been ported to other systems, such
- as MS-DOS, MS Windows, OS/2, Amiga, and the Macintosh (the BinHex program
- for the Mac does not produce the same ASCII data as uuencode), and may be
- used in the same way.
-
- For more information on accessing the Internet via email, please refer to
- the FAQ "Accessing The Internet By E-Mail: Doctor Bob's Guide to Offline
- Internet Access", found on the news.answers and alt.internet.services Usenet
- newsgroups and your favorite FAQ archives.
-
- ------------------------------
-
- ubject: 1. Where can I find graphics files on Usenet?
-
- The vast majority of graphics files posted to Usenet will be found in the
- alt.binaries.pictures.* newgroups. If you do not have access to Usenet,
- then you will not be able to retrieve files posted to these groups.
-
- For much more information on the alt.binaries.pictures.* newsgroups, please
- consult the alt.binaries.pictures FAQ (pictures-faq/part[1-3]) posted to
- news.answers and alt.binaries.pictures.d.
-
- ------------------------------
-
- ubject: 2. How do I decode a graphics file posted to Usenet?
-
- Graphics files are posted to Usenet as uuencoded binaries. Although you
- may see files posted using BinHex or someother ASCII format, the uuencode
- data format is the defacto standard of Usenet.
-
- A graphics file may be contained in a single-part posting, which you will
- save to a file, strip off the mailing header using a text editor, and use
- the uudecode program to convert the data into the original graphics file.
- Many online news readers will perform this operation for you.
-
- Graphics files are usually quite large and uuencoding will increase the
- file size by another 33%. For this reason, graphics files (and most binary
- files) are split into 1000 line or 60KB chunks (multi-part postings) for
- easier handling. If each chunk includes a shell wrapper (the string "[sh]"
- usually appears in the Subject: line of such postings), online news
- readers, such as tin, can tag each part of the posting and decode it into
- the original file for you.
-
- The most labor-intensive way to decode a multi-part uuencoded posting is to
- save each part into a separate file, edit each file to remove the mailing
- headers, concatenate them all into a single file, uudecode the file, and
- delete the original parts:
-
- % vi picture.1 picture.2 picture.3
- % cat picture.1 picture.2 picture.3 | uudecode
- % rm picture.1 picture.2 picture.3
-
- There are, of course, several utilities to decode single- and multi-part
- binary posting for you without all this bother. Please refer to the
- alt.binaries.pictures FAQ (pictures-faq/part[1-3]) posted to news.answers
- and alt.binaries.pictures.d for more information on decoding graphics files
- posted to Usenet.
-
- ------------------------------
-
- ubject: 3. How can I post a graphics file to Usenet?
-
- Posting a graphics file to a Usenet newsgroup is very similar to emailing
- a graphics file, but there are some important extra steps you must take in
- order to do so.
-
- First, a graphics file must be uuencoded. That is, converted from 8-bit
- binary data to 7-bit ASCII data. Second, the resulting uuencoded file must
- be split into 60K chunks (1000 lines) for posting. And lastly, each chunk
- posted must be given a description and a part number.
-
- Under Unix we would use the uuencode, split, expr, and inews commands to
- post a graphics (or any binary) file as such:
-
- % uuencode picture.img picture.img > picture.img.uue
- % split -1000 picture.img.uue picture.img.uue.
- % ls
- Total 535
- picture.img picture.img.uue picture.img.uue.1
- picture.img.uue.2 picture.img.uue.3
- % sh
- $ i=1
- $ for j in picture.img.uue.*; do
- > (echo "Subject: picture.img [$i/3]"
- > echo "Newsgroups: news.test
- > echo
- > cat $j) | /usr/lib/news/inews
- > i=`expr "$i" + 1`
- > done
- $ rm picture.img.*
- $ exit
- %
-
- In this example, we take a graphics file named picture.img, uuencode it,
- and place the output in a file names picture.img.uue. This file is then
- split into three chunks named picture.img.uue.1, picture.img.uue.2, and
- picture.img.uue.3. We then loop through each file and create a Subject:
- and Newsgroup: line for each of the file chunks and post them using inews.
-
- There are, of course, programs which automate this process. One such
- program is xmitBin, written by Jim Howard and availble via FTP from:
-
- ftp://ftp.cadence.com/utils
- http://mrcnext.cso.uiuc.edu/~deej/index.html
-
- Refer to the alt.binaries.pictures FAQ (pictures-faq/part[1-3]) posted to
- news.answers and alt.binaries.pictures.d for more information on posting
- graphics files to Usenet.
-
- ------------------------------
-
- ubject: 4. How do I submit a file format specification to an archive?
-
- There are several FTP and WWW sites which act as archives for graphics
- file format specifications (see the section "Graphics and Image File FTP
- Archives and WWW Pages"). If you have a file format specification that is
- legal to share with the rest of the world-wide Internet community, then
- you may wish to submit it to one or more of these archives.
-
- There are generally two ways to submit a file format specification to an
- FTP archive:
-
- 1) Upload (or "put") the file in the /incoming or /pub/incoming directory.
- 2) Email the file to the archive maintainer (the email address is usually
- in the README or similar file in the root FTP directory).
-
- Realize that most FTP sites don't allow unsolicited uploads and instead
- require you to contact the archive maintainer to make a submission. Many
- sites are simply mirrors for other archives and don't accepts any kind of
- submissions at all.
-
- In any case, it's usually good form to include a description file with
- your submission to describe in a few words what you have uploaded and
- where it originated. If your upload is named foo.doc then the description
- file should be named foo.txt. If your upload is named foo.txt, improvise.
-
- ------------------------------
-
- ubject: 5. How can I make transparent and interlaced GIFs for a Web page?
-
- Transparent GIFs are used to eliminate the typical rectangular borders
- associated with most bitmapped images that appear on a Web page. The
- creator of a GIF image may set certain pixels within the bitmap to a color
- desiganted within the image file as "transparent". When this GIF image is
- displayed by a Web browser the transparent pixels take on the color of the
- user's display. This is identical to the blue screen effect found in
- chromakeying.
-
- GIF89a files are made transparent by the use of graphics file editing
- software (GIF87a files do not support transparency and must first be
- converted to the GIF89a format). Such software will set the transparency
- color flag and the transparent color index value of a Graphics Control
- Extension block within the GIF89a file. Any pixel set to the specified
- transparent color index value will take on the background color of the
- display device when displayed.
-
- Interlaced GIFs are used to give the user a idea of that an image looks
- like before all of the bitmapped data has been received. Non-interlaced
- images paint in a linear fashion from the top to the bottom of the
- display. Over a slow link it make take several minutes for an image to
- paint. When 50% of the bitmapped data is received only the top half of the
- image is displayed. The contents bottom half is still a mystery to the
- user.
-
- Interlaced GIFs paint quickly over the entire display first as a very low
- resolution image. Only about 12.5% of the bitmap is displayed in this
- first pass. The GIF image is then repainted in three more passes, with
- each pass supplying more resolution until all of the data is received
- (12.5%, 25%, and 50% respectively). A user can usually get a good idea of
- what the entire image is when only 30-50% of the bitmapped data has been
- received. This is very useful for knowing when to abort an image being
- viewd via a slow link.
-
- Interlacing is supported by both the GIF87a and GIF89a formats. Graphics
- file editing software that supports interlaced GIF should not only be able
- to display such GIF files, but also convert non-interlaced GIFs to the
- interlaced format (and back again as well). This involves reading in the
- GIF bitmap and writing it back out using the GIF 4-pass interlace scheme.
- In a non-interlaced GIF the pixel lines are displayed in consecutive
- order. For example, the lines of a 16-line non-interlaced GIF file are
- stored as 0, 1, 2, 3, 4, 5...15. The lines of the same 16-line bitmap in
- an interlaced GIF would be stored as 0, 8, 4, 12, 2, 6, 10, 14, 1, 3, 5,
- 7, 9, 11, 13, 15.
-
- Graphics file format software packages for Unix which handles both
- trasparent and interlaced GIFs include NETPBM and giftool. For the
- Macintosh: Transparency, Graphic Converter, Imagery, and clip2gif
-
- The Visioneering image manipulation page will allow you to convert your
- GIFs to transparent and interlaced without having special software on your
- system. Your GIF files will be read, converted, and written using the Web.
- Visioneering's page is at:
-
- http://www.vrl.com/Imaging/
-
- More detailed information on images used in Web pages can be found in the
- FAQ for the newsgroup comp.infosystems.www.authoring.images found at:
-
- http://www.island.net/help/faq/www_faq/
- http://www.io.org/faq/www/index.html
-
- A collection of links to a number of Web and FTP resources that store
- information on transparent and interlaced GIFs for Unix, Macintosh, and
- MS-DOS/Windows, including executable programs and tutorials, may be found
- at:
-
- http://members.aol.com/htmlguru/transparent_images.html
- http://dragon.jpl.nasa.gov/~adam/transparent.html
- ftp://csi.jpl.nasa.gov/pub/graphics/transparent.faq
-
- ------------------------------
-
- ubject: 6. How do I combine still images to make animations?
-
- You might have a collection of imaes and drawings stored in a variety of
- still-image formats (TIFF, BMP, IFF, and so forth) and want to combine them
- into an animation or video file format that wil allow you to play them back.
-
- Have a look at the following Web page:
-
- http://www.prism.uvsq.fr/public/wos/multimedia/
-
- ------------------------------
-
-
- Subject: IV. Copyrights, Patents, and other Legalities of Graphics File
- Formats
-
- ------------------------------
-
- ubject: 0. Can a graphics file be copyrighted?
-
- No. A graphics file cannot normally be copyrighted under United States
- copyright laws (although the rulings of some judges may disagree on this).
- The specification of a format and the contents of a graphics file,
- however, are subject to copyright.
-
- For anything to be copyrighted it must be:
-
- 1) A work of authorship
- 2) Fixed in a tangible medium of expression
-
- The description of a graphics format does meet both of these criteria (it
- is fixed in a medium and a work of authorship) and is therefore protected
- under the copyright laws. A graphics file created using the format
- description, however, meets the second criteria, but not the first (that
- is, it is not considered to be a work of authorship). The format itself is
- considered instead to be an idea or system, and is therefore not protected
- by copyright.
-
- So the description of a file format is copyrightable, but the format as it
- exists in its medium is not. What about the graphics data that the file
- contains?
-
- If the graphical data written to a graphics file also meets the above two
- criteria, then it is also protected by the copyright laws as intellectual
- property. You will not wave your copyright protection by storing any
- original information using a graphics file format.
-
- For more information on copyright, please refer to the Copyright FAQ found
- on the misc.legal, misc.legal.computing, misc.int-property, and
- comp.patents newsgroups:
-
- ftp://rtfm.mit.edu/pub/usenet/news.answers/law/Copyright-FAQ/
- ftp://rtfm.mit.edu/pub/usenet/news.answers/law/Copyright-FAQ/myths/
-
- Apparently, quite a number of copyright discussions also occur on the
- comp.infosystems.www.* newsgroups as well.
-
- Information on patents, copyrights, and intellectual property may be found
- at:
-
- http://www.questel.orbit.com/patents/readings.html
- Patent and trademark information
-
- http://www.uspto.gov
- U.S. Patent and Trademark Office
-
- http://www.spi.org
- Software Patent Institute
-
- ------------------------------
-
- ubject: 1. Is it now illegal to use CompuServe's GIF format?
-
- It is not illegal to own, transmit, or receive GIF files (provided that no
- unlicensed compression and/or decompression of the files occurs). You must
- realize, however, that GIF files are not the issue. The issue is, in fact,
- the LZW data compression algorithm.
-
- In 1984, while working for Sperry Corporation, Terry Welch modified the
- Lempel-Ziv 78 (LZ78) compression algorithm for greater efficiency for
- implementation in high-performance disk controllers. The result was the
- LZW algorithm. The world was informed of the existence of LZW by the
- following journal article, published by Mr. Welch after he left the
- employment of Sperry:
-
- Welch, T. A., "A Technique for High Performance Data Compression,"
- IEEE Computer, Volume 17, Number 6, June 1984.
-
- In 1985, Sperry Corporation was granted a patent (4,558,302) for the Welch
- invention and implementation of the LZW data compression algorithm. Since
- that time, this LZW patent has been publicly available for all to see in
- the US Patent Office and many public libraries, and is available through
- many on-line services.
-
- In 1987, CompuServe Corporation created the GIF (Graphical Interchange
- Format) file format to be used for the storage and on-line retrieval of
- bitmapped graphical data. The GIF specification required the use the LZW
- algorithm to compress the data stored in each GIF file. It is very
- possible that CompuServe did not check the patent files to determine
- whether the GIF format infringed on any patents. Such a check would have
- found the Welch LZW patent, which was then owned by Unisys as a result of
- their having purchased Sperry in 1986. At that time, Unisys also did not
- know that LZW was the method of compression used by the very popular GIF
- file format.
-
- In 1988, Aldus Corporation released Revision 5 the TIFF file format. This
- revision added a new feature giving TIFF the ability to store RGB
- bitmapped data using either a raw format, or a compressed format using the
- LZW algorithm. (Although the LZW algorithm used by TIFF is considered to
- be "broken", it is still covered by the Unisys patent). Since 1991, in
- accordance with their agreement with Unisys, Aldus has been required to
- place a notice regarding the Unisys patent and its applicability to TIFF,
- in Aldus documentation. The 1992 release of Revision 6 of the TIFF
- specification includes this notice of the Unisys patent regarding LZW. The
- TIFF Revision 6 specification also recommends against using LZW to
- compress RGB bitmaps stored using the TIFF format.
-
- In 1990, Unisys licensed Adobe for the use of the Unisys LZW patent for
- PostScript.
-
- In 1991, Unisys licensed Aldus for the use of the Unisys LZW patent in
- TIFF.
-
- In 1994, Unisys and CompuServe came to an understanding whereby the use of
- the LZW algorithm would be licensed for the application of the GIF file
- format in software.
-
- In 1995, America Online Services and Prodigy Services Company also entered
- license agreements with Unisys for the utilization of LZW. Published
- information indicates that Unisys' licensing policies are as follows:
-
- 1) Unisys considers all software created or modified before January 1,
- 1995 that supports the GIF and/or TIFF-LZW formats to be
- inadvertently infringing upon its patent; Unisys will therefore not
- require a license for GIF software products delivered before January
- 1, 1995. Unisys will therefore not pursue legal actions against such
- pre-1995 software products.
-
- 2) However, Unisys expects developers of commercial or for-profit
- software to obtain a GIF-LZW license agreement from Unisys if, after
- December 31, 1994, the developer creates new software or updates or
- modifies existing software, or issues a new release of software that
- supports the GIF file format.
-
- 3) Unisys does not require licensing of non-commercial, not-for-profit
- software applications that support the GIF file format.
-
- 4) With respect to TIFF, if a license is entered before July 1, 1995,
- there will be no liability for pre-1995 software with respect to
- that software's support of TIFF which uses LZW.
-
- Unisys has drafted licenses for several different applications of the LZW
- algorithm. The two license agreements of most interest in this FAQ are
- applicable to software supporting the GIF file format alone and the
- agreement applicable to software supporting both GIF and the TIFF file
- format's LZW compression feature.
-
-
- Realizing that you have many questions about GIF-LZW and TIFF-LZW
- licensing, the remainder of this section is arranged in a Question/Answer
- format to help convey information about this subject more clearly.
-
- Q: Just what is this all about?
- A: Unisys has asserted its claim to the ownership of the LZW compression
- and decompression algorithm. If you wish to implement LZW in a software
- or firmware application, you must arrange to pay a small royalty to
- Unisys for every software package that you sell. You do this by applying
- to Unisys for an LZW license agreement for your software.
-
- Q: What file formats are effected?
- A: GIF, TIFF, PDF, and PostScript Level II. All of these formats use, or
- can use, LZW compression. For example, a TIFF or PostScript Level II
- file may or may not use the LZW algorithm to compress the data it
- contains. GIF files, and most PDF files, always store bitmap data that
- is compressed using LZW.
-
- Q: How does this agreement affect my use of GIF and TIFF files?
- A: It does not affect the ownership, transmission, or reception of GIF
- and TIFF-LZW files themselves. Only the software that performs
- compression and/or decompression of GIF may be effected in any way
- by license agreements. You are free to store and transport GIF and
- TIFF-LZW files without fear of legalities or cost from the Unisys
- licenses provided that any compression and/or decompression on GIF
- files is performed by licensed software, or by software products
- delivered prior to 1995.
-
- Q: Which agreement do I need?
- A: If your software supports only GIF then you need the GIF-LZW agreement.
- If it supports TIFF-LZW or both GIF and TIFF-LZW then you need the
- TIFF-LZW and GIF-LZW agreement.
-
- Q: My software supports TIFF-LZW, but not GIF.
- A: You still need to obtain the TIFF-LZW and GIF-LZW agreement.
-
- Q: So if my software only supports non-LZW versions of TIFF and PostScript
- Level II I don't need to worry about obtaining a license agreement?
- A: That is correct. Only software that is capable of using the LZW
- algorithm requires an agreement. This includes all software that
- supports the GIF file format.
-
- Q: What about file compression programs such as compress, PKZIP, zoo, and
- lha? Don't they use LZW too?
-
- A: Most file compression programs use the LZ77 algorithm for compressing
- text. The LZ77 compression algorithms (and several of its
- derivatives) predates LZW by several years and is covered by its own
- series of patents. The predecessor to LZW, LZ78, is used primarily
- for compressing binary data and bitmaps. Any software that uses the
- LZ77 and/or LZ78 algorithms without the LZW improvement is not
- affected by the Unisys LZW patent. Of the mentioned software
- packages, the Unix compress utility does use LZW and therefore
- requires a license.
-
- Q: Doesn't IBM also hold a patent on LZW?
- A: IBM was granted a patent (4,814,746) for use of LZW in disk drive
- technology. This patent does not award ownership of LZW to IBM.
-
- Q: Is there a chance that the Unisys patent is actually invalid?
- A: In 1994, the U.S Patent Office reexamined the Welch patent and, on
- January 4th of that year, not only confirmed the patentability of the
- original 181 patent claims, but also confirmed that 51 claims added
- during the reexamination were also patentable.
-
- Q: I have heard that the Welch patent only covers LZW compression and
- not decompression. Is this true?
- A: Many people who have read the patent claim that this is true. Unisys,
- of course, strongly maintains that the patent does cover LZW decompression,
- and will pursue legal action against unlicensed software which only
- performs LZW decompression. It is not clear (to the author of this text)
- if the 1994 patent reexamination specifically asserted the existence
- of the description of LZW decompression in the original Welch patent.
-
- Q: But you can't patent a mathematical abstraction. Doesn't this also
- include algorithms implemented as computer software?
- A: A patent grants the exclusive rights, title, or license to produce,
- use, or sell an invention or process. One or more algorithms may be
- applied using software to create an invention. It is this invention
- whose use is restricted by the patent and not the algorithm(s) involved.
- In the case of software, it seems that it is not very easy to separate
- the algorithm(s) from the invention itself. Use of the algorithm(s)
- would seem to imply use of the invention as well.
-
- Q: I use LZW in my programs, but not for GIF or TIFF graphics. What should
- I do?
- A: If you are not a business, and the programs are for your own personal
- non-commercial or not-for-profit use, Unisys does not require you to
- obtain a license. If they are used as part of a business and/or you
- sell the programs for commercial or for-profit purposes, then you must
- contact the Welch Patent Licensing Department at Unisys and explain your
- circumstances. They will have a license agreement for your application
- of their LZW algorithm.
-
- Q: Where can I apply for a GIF-LZW, TIFF-LZW and GIF-LZW, PDF, PostScript
- Level II, or any other LZW license?
- A: You can write to:
-
- Welch Patent Licensing Department
- Unisys Corporation
- Mail Stop C1SW19
- P.O. Box 500
- Blue Bell, PA 19424 USA
-
- Or fax: 215.986.3090
-
- Or email: lzw_info@unisys.com
-
- General licensing information may also be obtained from the home page
- of the Unisys Web Server:
-
- http://www.unisys.com/
- http://www.unisys.com/ServerInformation/contact/contact.html
- http://www.unisys.com/LeadStory/lzwfaq.html
-
- Q: How much does a license cost?
- A: The terms and cost of the license policy has changed since its
- introduction in 1995. Contact Unisys for the latest LZW licensing terms.
-
- Q: Do I need a separate license for each GIF-using software product I sell?
- A: If you sell three products that all use the GIF format, for example,
- then you will need only one license. License fees must be paid for
- each product sold.
-
- Q: Do I need to obtain a new license if I release a new version of my
- software?
- A: No. However, a license fee is required for each update, improvement,
- or enhancement of your software that is sold.
-
- Q: What if I give my software away?
- A: If you distribute for free your product directly to end-users for their
- personal use and your distributing the software is non-commercial and
- not-for-profit use and you receive no financial gain (such as Shareware
- donations, royalties for CD-ROM distributions, or as advertising to
- attract for-profit business), then you do not need a license.
-
- Q: But what about Shareware donations?
- A: Each Shareware "payment" you receive is considered the selling price of
- that unit. Whatever a user pays to you for your GIF-using software is
- required to be included in your quarterly license fee payment to Unisys.
- However, minimum license fees per unit must be always paid.
-
- Q: My Shareware GIF software is being sold for-profit on a CD-ROM, but I do
- not make any profit from its sale. Can I get in trouble? Do I need a
- license?
- A: The person/business that is selling your program for profit on their
- CD-ROM is responsible for obtaining the proper license. You would only
- need a license if you received any payments from the CD-ROM vendor or
- from users of your Shareware.
-
- Q: I do not live in the United States and my software is not available
- there. Do I still need to obtain a license agreement?
- A: Yes, you do. The Unisys patent has many foreign counterparts and the
- legalities of using LZW apply to most other countries in addition
- the US.
-
- Q: What will happen to me if I continue to revise my GIF-using software,
- sell it for profit, and yet not bother to obtain a license?
- A: Most likely, when your unlicensed program is discovered by Unisys,
- you will be notified of your need to obtain a license for your product.
- If you then fail to obtain the proper license, Unisys may seek an
- injunction against your product including damages. You could also be
- charged with willful infringement, which could result in treble damages.
-
- Q: On what Usenet newsgroups is this LZW agreement being discussed?
- A: You will find threads appearing on comp.graphics.misc and other related
- graphical newsgroups. The official newsgroup where much discussion
- takes place is alt.gif-agreement. You might also find information on
- the misc.legal.computing, misc.int-property, and comp.patents newsgroups.
-
- Q: Where can I get a copy of the Unisys patent?
- A: Copies of patents may be found in public libraries or be obtained
- directly from the U.S. Patent Office. The patent is also available
- at many Internet sites, including:
-
- ftp://ftp.std.com/obi/USPatents/lzw-patent.Z
- ftp://ftp.uu.net/doc/literary/obi/USPatents/lzw-patent.Z
-
- Q: What are my alternatives to GIF and TIFF-LZW file formats?
- A: A good alternative to LZW for compressing ASCII data is the LZ77
- algorithm used by the zip and PKZIP file archivers and the gzip
- (GNU zip) file compression program. The most popular alternative for
- multi-bit image data is the JPEG compression algorithm and the JFIF
- and SPIFF file formats. JFIF and SPIFF-JPEG files are smaller and
- store far more colors than GIF files.
-
- Another newer alternative is the PNG format, which is currently under
- development (see the section "PNG - Portable Network Graphics" in
- Part 3 of this FAQ). PNG is unencumbered by patent licenses and has
- much potential and promise in replacing GIF. But, most software that
- supports PNG will likely have been written after January 1, 1995, so
- make sure that your GIF-to-PNG conversion program has the proper
- Unisys license.
-
- Q: Will Unisys' actions hurt the use of GIF?
- A: Yes it will. People will continue to write software that supports GIF
- only if their customers demand it. The licensing will hasten the
- eventual demise of GIF, as both people and companies will be more
- motivated to standardize on "free" formats, such as JFIF, SPIFF, PNG,
- BMP, and TGA.
-
- Q: This agreement is bogus! I refuse to ever use GIF again!
- A: As an end-user you are free never to read, write, or archive another
- LZW-encoded file as long as you live. As a developer you are only
- free of the legal implications of the Unisys patent if you remove any
- LZW code from your programs, including those shipped to your customers
- after 1994.
-
- Q: Wait! I have more questions!
- A: Contact the Welch Patent Licensing Department at the aforementioned
- addresses. I (the author of this FAQ) am not an employee nor legal
- representative of Unisys. You can also find this information on the
- Unisys web page:
-
- http://www.unisys.com/LeadStory/lzwfaq.html
-
- And in the following InfoWorld article:
-
- "Graphics file format patent Unisys seeks royalties from GIF developers",
- Karen Rodriguez, InfoWorld, Jan 09, 1995 (Vol.17, Issue 02, p3)
-
- And the following Web pages are devoted to this issue:
-
- http://www.lpf.org/Patents/Gif/unisys.html
- http://www.lpf.org/Patents/Gif/Gif.html
- http://www-cmpo.mit.edu/met_links/resources/LZW_patent.html
- http://www.webhaven.com/izivkov/scanfax/GIF.HTM
- http://rom.oit.gatech.edu/~willday/gif.html
-
- Disclaimer: The information in this FAQ regarding the Unisys LZW
- licensing agreement has been presented in an attempt to allow the
- reader to understand some of the legalities they may face by the use
- of the LZW algorithm. The author has rendered this explanation and
- example questions using the most accurate information available to
- him at the date of this FAQ. In no regard should this text be
- considered an official publication of Unisys Corporation or a legal
- representation of the policies of Unisys, or in any way obligating
- Unisys to enter into a license agreement based upon the terms,
- interpretations, and/or answers to question provided in this text.
-
- ------------------------------
-
- Subject: V. Graphics Formats Misnomers, Misgivings, and Miscellany
-
- ------------------------------
-
- ubject: 0. Why aren't JPEG, MPEG, LZW, and CCITT Group 3 & 4 file formats?
-
- One of the most commonly confused concepts found in file formats is the
- difference between the file format and the method(s) of data encoding that
- has been used to reduce the size of the data the file contains. JPEG,
- MPEG, LZW, and CCITT are all algorithms, or algorithm toolkits, which
- encode a stream of data to a physically smaller size. None of these data
- compression methods define a specific format used to store data.
-
- Several formats have become popular based on their use of one or more of
- these methods of compression, such as GIF (LZW), JFIF (JPEG), and TIFF
- (CCITT Group 3 and Group 4). So if you ask for a "CCITT Group 3" image
- file you will most likely get a file containing only CCITT Group 3 data
- and not a TIFF file containing bitmapped data compressed using the CCITT
- Group 3 algorithm, which might have been what you were expecting.
-
- ------------------------------
-
- ubject: 1. Why aren't IGES, GKS, NAPLPS, PCL, and HPGL file formats either?
-
- IGES (Initial Graphics Exchange Specification), GKS (Graphics Kernel
- System), NAPLPS (North American Presentation Layer Protocol Syntax),
- Xerox Sixel, DEC ReGIS, and Tecktronix vector graphics are not
- actually file formats. They are instead protocols which specify how
- text and graphical data should be transmitted over a communications
- link (such as a serial cable or telephone line) to a remote device
- (such as a graphical workstation).
-
- The X protocol is used by X Window System clients and servers to
- communicatte over Ethernet. Although you can save X protocol-encoded
- data to a file, this does not mean that there is an "X protocol file
- format".
-
- HPGL (Hewlett-Packard Graphics Language) and PCL (Printer Control
- Language) are data stream definition standards used to transfer and
- manipulate data used by printers and plotters.
-
- In most cases, each of these protocols define a previously existing
- file format, such as CGM or JFIF, to be the actual format used to
- store the graphics data (CGM and PCL use a raw or compressed bitmap).
- Occasionally the transmitted data stream may be stored to a file for
- buffering or archival purposes. This file is then often identified as
- using the "{IGES,GKS,NAPLPS,PCL,HPGL} file format".
-
- Descriptions of each of these standards may be found in Part 3 (Where
- to Get File Format Specifications) of this FAQ. For more information
- on graphical protocols, have a look at the following:
-
- http://www.cs.utk.edu/~shuford/terminal_index.html
- Video Terminal Information
-
-
- ------------------------------
-
- ubject: 2. Is it "Tag" or "Tagged" Image File Format?
-
- Revision 5.0 of TIFF specification specifically states the acronym "TIFF"
- is "Tag Image File Format". The majority of people, however, intuitively
- say "Tagged" rather than "Tag". Interestingly enough, the TIFF 6.0
- specification does not spell out the acronym TIFF.
-
- ------------------------------
-
- ubject: 3. Whaddya mean there's no "Targa" file format?
-
- The popular "Targa" file format is really the "TGA format". "Targa" is the
- name of the Truevision graphics display adapter which first used the TGA
- format. Specifically, Revision 1.0 of TGA is designated the "Original TGA
- format" and Revision 2.0 is the "New TGA Format".
-
- ------------------------------
-
- ubject: 4. Choosy programmers choose "gif" or "jif"?
-
- The pronunciation of "GIF" is specified in the GIF specification to be
- "jif", as in "jiffy", rather then "gif", which most people seem to prefer.
- This does seem strange because the "G" is from the word "Graphics" and not
- "Jraphics".
-
- ------------------------------
-
- ubject: 5. Why are there so many ".PIC" and ".IMG" formats?
-
- Because people with very little imagination are allowed to choose file
- extensions for graphics files, that's why.
-
- But seriously, there does seem to be a proliferation of file formats with
- the file extension ".PIC" (for "picture") and ".IMG" (for "image"). Other
- popular extensions (in both upper and lower case) are ".RGB", ".RAW",
- ".ASC", and ".MAP".
-
- My advise to you is never assume the format of a data file based only on
- its file extension. The name and the extension of any file are completely
- arbitrary and therefore could be anything. This is why the most graphics
- file conversion and display programs attempt to recognize graphics files
- based on their internal structure and not their file name or extension.
-
- ------------------------------
-
- ubject: 6. Where can I get the spec for the GIF24 format?
-
- A GIF24 standard file format has never been officially introduced or
- released to the public. The original effort by CompuServe and others,
- to create a 24-bit revision of the GIF format was never completed.
- The problems create by Unisys' LZW patent restrictions and the subsequent
- disdainment of GIF by many developers is probably mostly to blame.
-
- It has been said that CompuServe abandoned GIF24 in favor of PNG
- format, who developers hope that one day will completely replace GIF.
- But it is not evident that CompuServe contributes in any remarkable way
- to the ongoing development of PNG.
-
- ------------------------------
-
- ubject: 7. Is there an uncompressed GIF format?
-
- Realizing that the heart of the GIF patent controversy is the LZW
- data compression algorithm itself, you may ask if there is a raw or
- uncompressed version of GIF that can be read and written without
- using the LZW alogrithm. Officially, the answer is no.
-
- The GIF specification does not defined a way to store uncompressed
- bitmap data. All bitmap data stored in a GIF file is compressed using
- the LZW algorithm. If you did write a program that stored
- uncompressed data using the GIF format, no other GIF reader would be
- able to decode the GIF files it created.
-
- So is there a way to modify the compressed data in a GIF file so it is
- no longer in a format described by the LZW patent, but still readable
- by GIF decoders? They answer to this is yes!
-
- When a GIF file is compressed, an initial LZW code table is created
- based on the bit-depth of the raw image data being LZW-encoded. For
- example, a bitmap with 4-bit pixels will be encoded with an LZW code
- table initially containing 18 entries: 16 color indicies ranging from
- 00000 to 01111, a clear code (10000), and a end-of-data code (10001).
-
- As LZW encoding proceedes, color codes from the data are used to form
- new table entries, and its the formation of these new entries that is
- the heart of LZW encoding. If an encoder only used the initial table
- and did not create any new table entry codes, then all of the
- resulting encoded data will be codes representing the indicies of the
- colors stored the in the GIF file's active color table.
-
- This process is explained in a post made to comp.graphics.misc by
- Dr. Tom Lane on 05 Dec 1996:
-
- ...the idea is to emit only single-symbol string codes, plus a Clear
- code every so often to keep the decoder from jacking up the code
- width. In this mode your encoder is simply packing N-bit pixel
- values into N+1-bit fields and keeping count; nothing patentable
- there. Note that the data is not merely not compressed, it's
- *expanded*: you need 9 bits per pixel for an 8-bit GIF. I wouldn't
- care to use this trick for low-depth data. The worst case is for
- 1-bit (black and white) data; not only do you need 2 bits/pixel, but
- every other symbol has to be a Clear to keep the code width down to 2
- bits ... net result, 4:1 expansion.
-
- Because this encoder ends up storing N+1 bits for every N bits of
- data, plus a clear code every 2^N-2 codes, an 8-bit "non-compressed"
- GIF image will be 1/8th larger than the same bitmap stored as an
- LZW-compressed GIF.
-
- Tom explained this a few days later:
-
- Note, however, that you have to insert "clear" codes often enough to
- prevent the decoder from ratcheting up the symbol width, or else
- keep track of what the current symbol width should be. It's been a
- while since I looked at this in detail, but I think you need a clear
- every 2^N-2 codes, where N is the underlying data depth, if you want
- the symbol width to stay at N+1 bits.
-
- [Note: Thanks to Tom Lane of the Independant JPEG Group and Neil
- Aggarwal of Bellcore for provising the Usenet discussion that
- contained this material]
- ------------------------------
-
- Subject: VI. Graphics File Resources
-
- ------------------------------
-
- ubject: 0. File Format Specifications FTP Archives and WWW Pages
-
- The following anonymous FTP and WWW sites are known to archive file format
- specifications and information. These documents may be official releases
- of specifications by the creator/caretaker of the formats, or information
- transcribed by people from various sources and released onto the net,
- possibly without permission from the format's owner.
-
- ftp://avalon.viewpoint.com/pub/format_specs
- ftp://ftp.cc.monash.edu.au/pub/graphics.formats
- ftp://ftp.ncsa.uiuc.edu/misc/file.formats/graphics.formats
- ftp://ftp.std.com/obi/Standards/Graphics/Formats
- ftp://ftp.switch.ch/mirror/simtel/msdos/graphics/
- ftp://ftp.uu.net/doc/literary/obi/Standards/Graphics/Formats
- ftp://ftp.wustl.edu/doc/graphic-formats
- ftp://mirrors.aol.com/pub/pc_games/programming/formats
- ftp://peipa.essex.ac.uk/ipa/info/file.formats
- ftp://titan.cs.rice.edu/pubic/graphics/graphics.formats
- ftp://wuarchive.wustl.edu/graphics/graphics/mirrors/avalon/format_specs
- ftp://x2ftp.oulu.fi/pub/msdos/programming/formats
-
- http://ac.dal.ca/~dong/appen.html
- http://dao.gsfc.nasa.gov/data_stuff/dataFormats.html
- http://erau.db.erau.edu/~gonzalec/html/image.html
- http://killy.shinshu-u.ac.jp/mawatar/dv/develop.html
- http://sckb.ucssc.indiana.edu/kb/data/aamt.html
- http://speckle.ncsl.nist.gov/~lst/cgm_std.htm
- http://sslab.colorado.edu:2222/datastandards.html
- http://topaz.sensor.com/work/fmt/
- http://www.agocg.ac.uk:8080/agocg/cgm.html
- http://www.cica.indiana.edu/graphics/3D.objects.html
- http://www.cica.indiana.edu/graphics/image.formats.html
- http://www.dcs.ed.ac.uk/~mxr/gfx
- http://www.echo.lu/impact/oii/raster.html
- http://www.hq.nasa.gov/office/oss/aisr/results/formats.html
- http://www.matisse.net/files/formats.html
- http://www.mcad.edu/guests/ericb/xplat.html
- http://www.mediatel.lu/mmedia/render/h_formats.html
- http://www.myo.inst.keio.ac.jp/FAQ/formats/image-formats.html
- http://www.pi.net/~ayr/filefor1.htm
- http://www.ru/gisa/english/cssitr/format/
- http://www.soften.ktu.lt/~marius/graphics.html
- http://www.tnt.uni-hannover.de/data/info/www/tnt/soft/sci/sig/image/fileformats/overview.html
- http://www.tnt.uni-hannover.de/data/info/www/tnt/soft/sci/vis/compgraph/fileformats/overview.html
- http://www.w3.org/hypertext/WWW/Graphics/Overview.html
- http://www-ocean.tamu.edu/~baum/graphics-formats.html
-
- ------------------------------
-
- ubject: 1. Graphics and Image File FTP Archives and WWW Pages
-
- The following anonymous FTP sites are known to archive image, graphics,
- and multimedia files and information:
-
- ftp://ames.arc.nasa.gov/pub/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.cnam.fr/Fractals/anim
- Fractal animation files
-
- ftp://edcftp.cr.usgs.gov/pub/data/DEM/250
- ftp://edcftp.cr.usgs.gov/pub/data/DLG/{2M,100K}
- Digital Elevation Model (DEM) and Digital Line Graph (DLG) archives
-
- ftp://ftp.photodex.com/PNG/images
- PNG images
-
- ftp://ftp.povray.org/pub/povray/images
- ftp://ftp.povray.org/pub/povray/scenes
- GIF, JPEG, and POV scene files rendered using PovRAY
-
- ftp://ftp.sdsc.edu/pub/sdsc/images
- ftp://ftp.sdsc.edupub/sdsc/sound
- San Diego Supercomputer Center sound and image file archives
-
- ftp://ftp.sunet.se/pub/graphics
- ftp://ftp.sunet.se/pub/multimedia
- MPEG, JPEG, FLC, HDF, AF, VR, and GIF files.
- Also /pub/pictures and /pub/comics contain many images
-
- ftp://ftp.tcp.com/pub/anime
- ftp://ftp.tcp.com/pub/anime-manga/anim
- Animation and multimedia files in MPEG, QuickTime, AVI, and FLI formats
-
- ftp://ftp.netcom.com://pub/sjledet/illustrator/
- Adobe Illustrator resources and tips
-
- ftp://omicron.cs.unc.edu/pub/softlab/CHVRTD
- MRI and CT scan volume data of human anatomy
-
- ftp://photo1.si.edu/images
- Smithsonian Institution photoimage archives
-
- ftp://ftp.povray.org
- POV animation files
-
- ftp://src.doc.ic.ac.uk:/pub/packages/faces
- USENIX faces archive (contains thousands of different faces)
-
- ftp://ftp.uni-erlangen.de/pub/pictures/mpeg/LOCAL/RedsNightmare.tar
- Red's Nightmare (a ray-traced animation)
-
- ftp://ftp.univ-rennes1.fr/Images/ASTRO/anim
- Space animation files
-
- ftp://ftp.wustl.edu/pub/aminet/gfx/anim
- Various Amiga anims (also on other aminet sites)
-
- ftp://ftp.wustl.edu/multimedia/images/
- GIF and JPEG files
-
- ftp://nic.funet.fi/pub/graphics/misc/test-images/
- JBIG, CCITT, and other test images
-
- ftp://ftp.povray.org/pub/povray/Official/
- POV-Ray Hall Of Fame ray tracing graphics archive
-
- ftp://pubinfo.jpl.nasa.gov/images
- Space images in GIF format
-
- ftp://spectrum.xerox.com/pub/map/dem
- ftp://spectrum.xerox.compub/map/dlg
- Digital Elevation Model (DEM) and Digital Line Graph (DLG) archives
-
- ftp://src.doc.ic.ac.uk/gfx/misc
- Digital Elevation Model (DEM) and Digital Line Graph (DLG) archives
-
- ftp://sunsite.unc.edu/pub/multimedia/pictures
- ftp://sunsite.unc.edu/pub/multimedia/animation
- Graphics and MPEG file collection
-
- ftp://toybox.gsfc.nasa.gov/pub/images
- NASA images in GIF, JPEG, PostScript, Sun Raster, and X Bitmap formats
-
- The following WWW sites are known to archive image, graphics, and
- multimedia files:
-
- http://afrodite.lira.dist.unige.it/
- European Network of Excellence in Computer Vision
-
- http://archpropplan.auckland.ac.nz/People/Mat/gallery/animations.html
- Mat Carr's animations
-
- http://ccf.arc.nasa.gov/dx/
- http://ccf.arc.nasa.gov/galileo_probe/
- Galileo Mission to Jupiter Images
-
- http://www.cm.cf.ac.uk/Ray.Tracing/
- Links to many site with ray-traced graphics
-
- http://cui_www.unige.ch:80/OSG/MultimediaInfo/
- Index to Multimedia Information Resources
-
- http://found.cs.nyu.edu/
- NYU State Center for Advanced Technology
-
- http://fuzine.mt.cs.cmu.edu/im/informedia.html
- Informedia Digital Video Library Project
-
- http://jasper.ora.com:80/comp.fonts/Internet-Font-Archive/
- Internet Font Archive (IFA)
-
- http://mambo.ucsc.edu:80/psl/thant/thant.html
- Thant's Animation index
-
- http://netlab.itd.nrl.navy.mil/imaging.html
- Listings of imaging resources and archive sites
-
- http://www.povray.org/pub/povray/Official/
- POV-Ray Hall Of Fame ray tracing graphics archive
-
- http://scorch.doc.ic.ac.uk/~np2/multimedia/
-
- http://sunsite.unc.edu/louvre/about/tech.html
- http://mistral.enst.fr/louvre/about/tech.html
- WebLouvre - Using and troubleshooting the web
-
- http://the-tech.mit.edu/KPT/
- Kai's Power Tips and Tricks for Photoshop
-
- http://w3.eeb.ele.tue.nl/mpeg/index.html
- Various MPEG animations
-
- http://web.msi.umn.edu/WWW/SciVis/umnscivis.html
- Scientific visualization and graphics
-
- http://www.cs.purdue.edu/homes/gwp/dtp/dtp.html
- DTP Internet Jumplist. Links to many desktop publishing pages.
-
- http://www.cs.ubc.ca/nest/imager/imager.html
- MPEG animations done using hierarchical b-splines
-
- http://www.demon.co.uk/
- Demon Internet
-
- http://www.dfrc.nasa.gov/PhotoServer/photoServer.html
- NASA Dryden Research Aircraft Photo Archive
-
- http://www.infomedia.com:8600
- Liquid Mercury's new WWW Site designed for "New Media" professionals.
- Current industry data and product profiles. Email: info@infomedia.com
-
- http://www.jpl.nasa.gov/galileo/
- Galileo Mission to Jupiter Images
-
- http://www.kodak.com/digitalImages/samples/samples.shtml
- Kodak Sample Digital Images archive
-
- http://www.kodak.com/digitalImaging/cyberScene/sites.shtml
- Kodak Image Archive Sites
-
- http://www.lightside.com/~dani/cgi/images-index.html
- 3DWEB - World Wide Web site for 3D Computer Graphics
-
- http://www.picker.com/pgw
- Picker Graphic Workstations
-
- http://www.sd.tgs.com/~template
- Web3D - World Wide Web site for 3D Graphics
-
- http://www.seas.gwu.edu/faculty/musgrave/art_gallery.html
- A gallery collection of fractal artwork by Ken Musgrave
-
- http://www.state51.co.uk/state51/
- State51 Interactive Media
-
- http://www.viewpoint.com
- Large collection of 3D models
-
- http://www.webcity.co.jp/info/andoh/vrml/geom_trans.html
- VRML Repository
-
- http://www.wimsey.com/PhotoModeler/
- Many links to 3D Technology topics
-
- ------------------------------
-
- ubject: 2. Internet Mailing Lists for Graphics and Imaging
-
- This section contains a listing of Internet mailing lists that often
- contain discussions and information on graphics and image file formats.
- Mailing lists are a good alternative form of communication for those
- netters that do not have Usenet access.
-
- agocg-ip@mailbase.ac.uk
- Discussion of all aspects of image processing. To subscribe:
- send an email message to mailbase@mailbase.ac.uk with the body
- "join agocg-ip yourfirstname yourlastname".
-
- digvid-l@ucdavis.edu
- Discussion of digital video, mostly of the desktop variety.
- To subscribe: send an email message to listserv@ucdavis.edu
- with the body: "subscribe digvid-l yourfirstname yourlastname".
-
- geotiff@tazboy.jpl.nasa.gov.
- Discussion regarding the establishment of a set of TIFF tags for
- storing geographic map projection information, such as UTM zones,
- Lambert Standard parallels, etc. Participants include
- representatives from SPOT, Intergraph, ERDAS, ESRI, and USGS. To
- subscribe: send an email message to geotiff-request@tazboy.jpl.nasa.gov.
-
- graphuk@cs.man.ac.uk
- GraphUK mailing list. Discussion of graphics systems such as PHIGS
- and GKS, and training in the area of graphics. To subscribe: send an
- email message to graphuk-request@cs.man.ac.uk with the body "subscribe
- graphuk".
-
- illstrtr-l@netcom.com
- Adobe Illustrator mailing list. Discussion of the Adobe Illustrator
- application and issues related to its use. To subscribe: send an email
- message to listserv@netcom.com with the body "subscribe illstrtr-l".
-
- info-ei@spie.org
- SPIE's Electronic Imaging Listserver. Discussion of electronic imaging.
- To subscribe: send an email message to info-ei-request@spie.org with
- the body "SUBSCRIBE INFO-EI". A complete listing of SPIE's online
- services may be obtained by sending email to info-optolink-request@spie.org
- with the word HELP in the message body.
-
- lexicor@lexicor.com
- Discussion of Atari computer graphics, hardware, software, programming,
- and formats for graphics and animation (2D and 3D). To subscribe: send
- an email message to lexicor-list-request@lexicor.com with the body
- "subscribe youremailaddress".
-
- listserv@info.kodak.com
- Information on the Kodak Photo-CD format. To subscribe: send an
- email message to listserv@info.kodak.com with the body:
- "INFO PHOTO-CD".
-
- listserv@soils.umn.edu
- NIH image processing discussion. To subscribe: send an email message
- to listserv@soils.umn.edu with the body "subscribe nih-image
- yourfirstname yourlastname". You may seach past messages of this list
- by using http://rsb.info.nih.gov/nih-image/faq.html#Searching
-
- medimage@polygraf
- Medical imaging discussion. To subscribe: send an email message
- to listserv%polygraf.bitnet@mitvma.mit.edu with the body
- "subscribe medimage".
-
- nucmed@uwovax.uwo.ca
- Nuclear medicine and medical imaging discussion. To subscribe:
- send an email message to nucmed-request@uwovax.uwo.ca with the
- body "subscribe nucmed".
-
- PhotoForum@listserver.isc.rit.edu
- Photographic and imaging discussions of aesthetics, processes
- instructional strategies, techniques, criticism, equipment, history,
- electronic imaging, ethics, and educational topics. To subscribe: send
- an email message to LISTSERV@LISTSERVER.ISC.RIT.EDU with the body
- "SUBSCRIBE PhotoForum yourfirstname yourlastname".
-
- pixel@essex.ac.uk
- British Machine Vision Association newsletter for machine vision,
- image processing, pattern recognition, remote sensing, etc. To
- subscribe: send an email message to pixel-request@essex.ac.uk.
-
- png-list@dworkin.wustl.edu
- png-announce@dworkin.wustl.edu
- png-implement@dworkin.wustl.edu
- PNG file format mailing lists. These lists contain a general discussion
- of PNG, announcements related to PNG, and discussions regarding PNG
- PNG implementation. To subscribe: send an email message to
- png-list-request@dworkin.wustl.edu with "help" in the body.
-
- ximage@expo.lcs.mit.edu
- Discussion of image processing using The X Window System. To
- subscribe send an email message to ximage-request@expo.lcs.mit.edu
- with the body "subscribe ximage".
-
- ------------------------------
-
- ubject: 3. Books on Graphics File Formats
-
- This section contains bibliographical listing of books containing
- information on graphics file formats and closely related topics. This list
- is alphabetized by title and information on how to order each book is
- included where known.
-
- And check out http://www.books.com and http://www.amazon.com to search for books using the Web.
-
- 3D Graphics File Formats : A Programmer's Reference, Keith Rule,
- Addison-Wesley, 1996, ISBN 0-201488-35-3.
-
- The AutoCAD Database Book, F.H. Jones and L. Martin, Ventana Press,
- ISBN 0-940087-04-9. Order: 919.490.0062 voice.
-
- Bit-mapped graphics (2nd ed.), Steve Rimmer, Windcrest/McGraw-Hill
- 1993. 484 pages.
-
- Bitmapped Graphics Programming in C++, Marv Luse, Addison Wesley
- 1993. ISBN 0-201632-09-8, $37.95 softcover and disk.
-
- CGM and CGI: Metafile and Interface Standards for Computer
- Graphics, David B. Arnold and Peter R. Bono, Springer-Verlag
- 1988. ISBN 3-540-18950-5, 279 pages.
-
- The CGM Handbook, Lofton R. Henderson and Anne M. Mumford,
- Academic Press 1993. ISBN 0-12-510560-6, $59.95 hardcover,
- 446 pages.
-
- Encyclopedia of Graphics File Formats, James D. Murray and
- William vanRyper, 2nd ed., O'Reilly & Associates Inc. 1996.
- ISBN 1-56592-161-5, $79.95 softcover, 1154 pages.
- Order: order@ora.com, 800.998.9938 voice, 707.829.014 fax.
- Visit http://www.ora.com/www/item/gffcd.html for more information.
-
- File Formats for Popular PC Software: A Programmer's Reference,
- Walden, Jeff, John Wiley & Sons, Inc. 1986. ISBN 0-471-83671-0,
- 287 pages.
-
- File Formats on the Internet: A Guide for PC Users, Allison B. Zhang,
- Special Libraries Assn., 1996, ISBN: 0-871114-41-0.
-
- File Format Handbook, Allen G. Taylor, Microtrend Books 1992.
-
- The File Format Handbook, Guenter Born, International Thomson Computer
- Press 1995. ISBN 1-850-32128-0, 1-85032-117-5, $79.95 hardcover,
- 1274 pages. Order: sales@clbooks.com, http://www.clbooks.com
-
- Graphical Treasures on the Internet, Bridget Mintz Testa, AP Profesional.
- ISBN 0-12-685375-4, $29.95US softcover, 428 pages.
- Order: mailto:app@acad.com or http://www.apnet.com/approfessional
-
- Graphics File Formats (2nd ed.), David C. Kay and John R. Levine,
- Windcrest Books/McGraw-Hill 1995. ISBN 0-07-034025-0, $26.95
- softcover, 476 pages.
- Order: Tab Software Department, Blue Ridge Summit, PA 17294-0850.
-
- Graphics File Formats: Reference and Guide, C. Wayne Brown and
- Barry J. Shepherd, Manning Publications 1994.
-
- The Graphic File Toolkit: Converting and Using Graphic Files,
- Steve Rimmer, Addison-Wesley, 1992. 335 pages.
-
- High-Resolution Graphics Display Systems, Jon Peddie,
- Windcrest Books/McGraw-Hill 1994. ISBN 0-8306-4292-7,
- ISBN 0-8306-4291-9 $34.95 softcover
-
- Inside Windows File Formats, Tom Swan, Sams Publishing 1993.
- ISBN 0-672-30338-8 $24.95 softcover, 337 pages and 1 disk (3.5 in.).
- Order: Sams Publishing, 2201 West 103rd Street, Indianapolis,
- IN 46290
-
- Internet File Formats, Tim Kientzle, The Coriolis Group 1995.
- ISBN 1-883577-56-X $39.99 softcover, 398 pages and one CD.
- Order: 7339 E. Acoma Drive, Suite 7, Scottsdale, AZ 85260.
- 800.410.0192, 602.483.0192
-
- The Internet Voyeur, Jim Howard, Sybex, 1995. ISBN 0-7821-1655-8.
- 369 pages, $19.99 softcover + PC/Windows disk. More info at
- http://infolane.com/infolane/deej/voyeur.html
-
- More File Formats for Popular PC Software: A Programmer's Reference,
- Jeff Walden, John Wiley and Sons 1987. 369 pages.
-
- Multimedia File Formats on the Internet: A Beginner's Guide for PC Users,
- Allison Zhang, Special Libraries Association 1995.
-
- PC File Formats & Conversions, Ralf Kussmann, Abacus 1990. 287 pages
- and 1 disk (5.25 in.).
-
- PC Graphics with GKS, P.R. Bono, J.L. Encarnacao and W.R. Herzner,
- Prentice-Hall 1990.
-
- PostScript Language Reference Manual, Adobe Systems Inc. (2nd ed.),
- Ed Taft and Jeff Walden, Addison-Wesley 1990.
-
- The Programmer's PC Sourcebook, Thom Hogan, Microsoft Press, 1988.
-
- Programming for Graphics Files in C and C++, by John R. Levine,
- John Wiley & Sons 1994. ISBN 0-471-59854-2, $29.95 softcover,
- 494 pages.
-
- Using Pcx Graphics Files: The Programmer's Definitive Guide to Pcx
- File Formats, Roger Stevens, Miller Freeman, 1996, ISBN 0-879304-32-4.
-
- Windows Undocumented File Formats: Working Inside Windows 3.X and Win 95,
- Pete Davis, Miller Freeman, 1997, ISBN 0879304375.
-
- ------------------------------
-
- ubject: 4. Magazine Articles on Graphics File Formats
-
- This section contains bibliographical listings of periodicals containing
- information on graphics file formats. This list is alphabetized by title.
-
- .mrb and .shg File Formats, Windows/DOS Developer's Journal, Pete Davis,
- February 1994 (Vol 5, No 4), pp. 37-46.
-
- The BMP File Format, Dr. Dobb's Journal, Marv Luse, #219 September
- 1994 (Vol 19, Issue 10), pp. 18-22.
-
- The BMP File Format: Part I, Dr. Dobb's Journal, David Charlap, #228
- March 1995 (Vol. 20, Issue 3).
-
- The BMP File Format: Part II, Dr. Dobb's Journal, David Charlap, #229
- April 1995 (Vol. 20, Issue 4).
-
- Inside the RIFF Specification, Dr. Dobb's Journal, Hamish Hubbard, #219
- September 1994 (Vol 19, Issue 10), pp. 38-45.
-
- PCX Graphics, C Users Journal, Ian Ashdown, Vol 9, Num 8, August 1991,
- pp. 89-96.
-
- PNG: The Portable Network Graphic Format, Dr. Dobb's Journal,
- Lee Daniel Crocker, #232 July 1995 (Vol 20, Issue 7), pp. 36-44.
-
- Portable Network Graphics, Web Techniques, Paul Atzberger and
- Andrew Zolli, Vol 1. Issue 9, December 1996, pp. 65-70.
-
- Printing PCX Files, C Gazette, Marv Luse, Vol 5, Num 2, Winter 1990-91,
- pp. 11-22.
-
- Reading GIF Files, Dr. Dobb's Journal, Wilson MacGyver Liaw, #227
- February 1995 (Vol 20, Issue 2), pp. 56-60.
-
- SPIFF: Still Picture Interchange File Format, Dr. Dobb's Journal,
- James D. Murray, #249 July 1996 (Vol 21, Issue 7), pp. 34-41.
-
- TIFF File Format, C Gazette, James Murray, Vol 5, Num 2, Winter 1990-91,
- pp. 27-42.
-
- Translating PCX Files, Dr. Dobb's Journal, K. Quirk, Vol 14, Num 8,
- August 1989, pp. 30-36, 105-108.
-
- Working with PCX files, Microcornucopia, Number 42, July-August 1988,
- p. 42.
-
- ------------------------------
-
- Subject: VII. Kudos and Assertions
-
- ------------------------------
-
- ubject: 0. Acknowledgments
-
- The following people have made this FAQ take just a little bit longer to
- read since the last time you looked at it (blame them and not me):
-
- Bruce Garner <garner@tis.llnl.gov>
- Oliver Grau <grau@tnt.uni-hannover.de>
- John T. Grieggs <grieggs@netcom.com>
- Lee Kimmelman <lee.kimmelman@twwde.com>
- David Kuo <dkuo@dabulls.kodak.com>
- Tom Lane <tgl@netcom.com>
- Angus Montgomery <angus@cgl.citri.edu.au>
- Glen Ozymok <oz@ludwig.virtualprototypes.ca>
- Greg Roelofs <newt@uchicago.edu>
- Rsiw <rsiw@aol.com>
- Daniel Sears <sears@netcom.com>
- Marc Soucy <msoucy@imetric.qc.ca>
- Bjoern Stabell <bjoerns@acm.org>
- Mark T. Starr <StarrMT@po4.bb.unisys.com>
-
- ------------------------------
-
- ubject: 1. About The Author
-
- The author of this FAQ, James D. Murray, lives in the City of Orange,
- Orange County, California, USA. He is the co-author of the book
- Encyclopedia of Graphics File Formats published by O'Reilly and
- Associates, makes a living writing books for O'Reilly, writing
- telecommuncations network management software in C++ and Visual Basic,
- and may be reached as jdm@ora.com,
- or via U.S. Snail at: P.O. Box 70, Orange, CA 92666-0070 USA.
-
-
- ------------------------------
-
- Subject: 2. Disclaimer
-
- While every effort has been taken to insure the accuracy of the
- information contained in this FAQ list compilation, the author and
- contributors assume no responsibility for errors or omissions, or for
- damages resulting from the use of the information contained herein.
-
- ------------------------------
-
- ubject: 3. Copyright Notice
-
- This FAQ is Copyright 1994-96 by James D. Murray. This work may be
- reproduced, in whole or in part, using any medium, including, but not
- limited to, electronic transmission, CD-ROM, or published in print,
- under the condition that this copyright notice remains intact.
-
- ------------------------------
-