DP Tool Club 24

home *** CD-ROM | disk | FTP | other *** search

/ DP Tool Club 24 / CD_ASCQ_24_0995.iso / vrac / imagefaq.zip / FAQ01.TXT next >

Wrap

Internet Message Format | 1995-06-10 | 70KB

From news.alpha.net!news.mathworks.com!gatech!news.sprintlink.net!noc.netcom.net!netcom.com!jdm Sat Jun 10 11:31:32 1995 Newsgroups: comp.graphics,comp.answers,news.answers Path: news.alpha.net!news.mathworks.com!gatech!news.sprintlink.net!noc.netcom.net!netcom.com!jdm From: jdm@netcom.com Subject: Graphics File Formats FAQ (Part 1 of 4): General Graphics Format Questions Message-ID: <graphics/fileformats-faq-1-802022477@netcom.com> Followup-To: poster Summary: This document answers many of the most frequently asked questions about graphics file formats on Usenet. Keywords: FAQ, GRAPHICS, FORMAT, IMAGE Sender: jdm@netcom9.netcom.com Supersedes: <graphics/fileformats-faq-1-799731112@netcom.com> Reply-To: jdm@netcom.com (James D. Murray) Organization: None Whatsoever Date: Thu, 1 Jun 1995 16:01:20 GMT Approved: news-answers-request@MIT.EDU Expires: Sat, 1 Jul 1995 16:01:17 GMT Lines: 1582 Xref: news.alpha.net comp.graphics:77821 comp.answers:12189 news.answers:45352 Posted-By: auto-faq 3.1.1.2 Archive-name: graphics/fileformats-faq/part1 Posting-Frequency: monthly Last-modified: 01Jun95 This FAQ (Frequently Asked Questions) list contains information on graphics file formats, including, raster, vector, metafile, Page Description Language, 3D object, animation, and multimedia formats. This FAQ is divided into four parts, each covering a different area of graphics file format information: Graphics File Formats FAQ: General Graphics Format Questions (Part 1 of 4) Graphics File Formats FAQ: Image Conversion and Display Programs (Part 2 of 4) Graphics File Formats FAQ: Where to Get File Format Specifications (Part 3 of 4) Graphics File Formats FAQ: Tips and Tricks of the Trade (Part 4 of 4) Please email contributions, corrections, and suggestions about this FAQ to jdm@netcom.com. Relevant information posted to newsgroups will not automatically make it into this FAQ. -- James D. Murray <jdm@netcom.com> ;-{)>>>> ---------------------------------------------------------------------- Subject: 0. Contents of 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? <UPD> 4. Are there other related FAQs I should read as well? 5. I have a question, correction, or some information concerning this FAQ. 6. This FAQ doesn't contain enough detail! 7. Why isn't the XXX file format covered? 8. Why aren't audio file formats covered? 9. Why aren't word processing formats covered? 10. What about multimedia file formats? II. General Graphics File Questions 0. Who cares about graphics file formats? 1. What is raster, vector, metafile, PDL, VRML, and so forth? <UPD> 2. Why should I care about previous versions of a file format? 3. Can graphics files be infected with a virus? 4. Can graphics files be encrypted? 5. Can a graphics file be copyrighted? <UPD> 6. How can I convert the XXX format to the YYY format? 7. Do I really need the specification of the format I'm using? 8. How can I tell if a graphics file is corrupt? 9. What do I put in my own graphics file format specification? 10. How do I submit a file format specification to an archive? 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. Is it now illegal to use CompuServe's GIF format? <UPD> III. Graphics File Resources 0. File Format Specifications FTP Archives and WWW Pages <UPD> 1. Graphics and Image File FTP Archives and WWW Pages <UPD> 2. Internet Mailing Lists for Graphics and Imaging 3. Books on Graphics File Formats 4. Magazine Articles on Graphics File Formats 5. U.S. Government and Military Standards Sources 6. Other Standards Document Sources VII. Kudos and Assertions 0. Acknowledgments 1. About The Author 2. Disclaimer 3. Copyright Notice ------------------------------ Subject: I. General questions about this FAQ ------------------------------ Subject: 0. Maintainer's Comments Welcome to another monthly release of the Graphics File Format FAQ! More tidbits of information added here and there. Because of the LZW licensing controversy, I've added more information on patents and coprights. I'm also including more information on VRML-type formats, especially in Part 3 of this FAQ. And it looks as though I'll be in the O'Reilly & Associates booth at SIGGRAPH in Los Angles on August 8th, 9th, and 10th. I'll be the long-haired computer nerd with the long, braided beard. ;-{)>>>> ------------------------------ Subject: 1. What's new in this latest FAQ release? o Added more info to the GIF/LZW patent section o Added a WWW site for 3D object file format information o Another file format archive included (a mirror, really) o Added another WWW FAQ server listing o Added a reference to the Copyright FAQ ------------------------------ Subject: 2. Why does a graphics formats FAQ exist? The purpose of this FAQ is to answer many of the frequently asked questions about graphics file formats posted on Usenet. You will find definitions of terms, references to format information, very general descriptions of many formats, information on programs which read, write, convert, and display graphics files, and some handy programming tips for writing your own code. This FAQ is not a substitute for actual file format specifications, nor can it possibly go into a great amount of specific detail on graphics file formats. ------------------------------ Subject: 3. Where can I get the latest copy of this FAQ? This FAQ is distributed monthly on the Usenet newsgroups comp.graphics comp.answers, and news.answers as four separate files. It may also be obtained via anonymous FTP from: ftp://rtfm.mit.edu/pub/usenet/news.answers/graphics/fileformats-faq ftp://rtfm.mit.edu/pub/usenet/comp.graphics To receive a copy of this FAQ via email, send an email message to mail-server@rtfm.mit.edu with the body: send usenet/news.answers/graphics/fileformats-faq/part1 send usenet/news.answers/graphics/fileformats-faq/part2 send usenet/news.answers/graphics/fileformats-faq/part3 send usenet/news.answers/graphics/fileformats-faq/part4 or via UUCP: uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part1 uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part2 uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part3 uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part4 To access this FAQ on the World Wide Web, use the address: http://www.cis.ohio-state.edu/hypertext/faq/usenet/graphics/fileformats-faq/top.html http://www.cs.ruu.nl/wais/html/na-dir/graphics/fileformats-faq/ And you can access all of the FAQs associated with the comp.graphics newsgroup via the WWW page: http://www.cis.ohio-state.edu/hypertext/faq/usenet/graphics/top.html http://www.cs.ruu.nl/wais/html/na-dir/graphics/ ------------------------------ Subject: 4. Are there other related FAQs I should read as well? Information related to file formats not covered by this FAQ may be found in the following FAQs: Newsgroup Archive-name alt.binaries.pictures pictures-faq/part[1-2] alt.graphics.pixutils pixutils-faq alt.image.medical medical-image-faq/part[1-3] comp.compression compression-faq/part[1-3] mpeg-faq[1-6] comp.dsp dsp-faq[1-4] audio-fmts[1-2] comp.fonts fonts-faq/part[1-2] comp.graphics graphics/faq graphics/colorspace-faq graphics/resources-list/part[1-3] jpeg-faq/part[1-2] comp.graphics.animation graphics/animation-faq comp.infosystems.gis geography/infosystems-faq comp.multimedia comp-multimedia-faq comp.speech comp-speech-faq/ comp.sys.sgi.misc sgi/faq/ sci.data.formats sci-data-formats sci.image.processing image-processing/Macintosh image-processing/Medical_Image_Volume_Visualization These FAQs may also be found the newsgroups alt.answers, comp.answers, sci.answers, and news.answers, and in the FAQ archives at rtfm.mit.edu and mirror sites. To FTP any of these FAQs use the listed Archive-name with the following FTP address: ftp://rtfm.mit.edu/pub/usenet/news.answers/ [Archive-name] To receive a copy of these FAQs via email, send an email message to mail-server@rtfm.mit.edu with the body: send usenet/news.answers/[Archive-name] ------------------------------ Subject: 5. I have a question, correction, or some information concerning this FAQ. All questions, comments, additions, and corrections should be sent to the author of this FAQ at jdm@netcom.com. I don't always read the newsgroups this FAQ is posted to, so please contact me directly via email rather than attempting to reach me by posting to a newsgroup. All suggestions and contributions within the scope of this FAQ are welcome and contributors receive full credit in the Acknowledgments section of this FAQ. ------------------------------ Subject: 6. This FAQ doesn't contain enough detail! This FAQ only attempts to answer Frequently Asked Questions. It is not a book on graphics file formats. It is instead a thick source of information that will help you obtain more information that you need. Or perhaps even clear up a few of your misconceptions and thereby saving you from wasting some time. ------------------------------ Subject: 7. Why isn't the XXX file format covered? If you have read and/or grepped this FAQ and not found information on the format you need the reason might be that: * You are looking for the format under the wrong name. * This FAQ is new and the information you need hasn't been included yet. * I don't know about the format and I need you to email me information on it (See Subject: 4.). * The format is proprietary and its caretakers do not wish information on the format distributed in this FAQ. ------------------------------ Subject: 8. Why aren't audio file formats covered? Information on file formats used specifically for storing audio data are already covered quite nicely by a FAQ posted to comp.dsp. You may obtain this FAQ from the Usenet newsgroups comp.dsp, comp.answers, and news.answers, or from the FTP archive site (and mirrors): ftp://rtfm.mit.edu/pub/usenet/news.answers/comp.dsp/ The FAQ for comp.speech may of also be of interest to audio people. It is available at: ftp://rtfm.mit.edu/pub/usenet/news.answers/comp-speech-faq/ ftp://svr-ftp.eng.cam.ac.uk/pub/comp.speech/FAQ-complete ------------------------------ Subject: 9. Why aren't word processing formats covered? It is true that there are many types of file formats that cannot store graphics data (older word processor and spreadsheet formats, and so forth). These formats are not within the scope of this FAQ and are therefore not covered. Perhaps someone who works in the biz of writing file translators for these formats will put together such a FAQ one day. ------------------------------ Subject: 10. What about multimedia file formats? Multimedia file formats store more than just graphics data. They may also contain audio, video, animation, and textual data in addition to bitmapped and vectored graphics. Such formats, although a superset of graphics formats, are considered to be within the scope of this FAQ and are therefore covered. Also check the comp.multimedia FAQ for additional information you may require. ------------------------------ Subject: II. General Graphics File Questions ------------------------------ Subject: 0. Who cares about graphics file formats? Well, programmers do mostly. But end-users (that is, non-programmers) do too. The typical end-user only cares about storing their graphics information using a format that most graphics programs and filters can read. End-users are typically not concerned with the internal arrangement of the data within the graphics file itself. They only want the format to do its job by representing their data correctly in a permanent form. Programmers, on the other hand, are that rare breed of human that just can't leave information well enough alone. They need to know how every byte is arranged to see if someone knows something that they don't (and often snicker contentedly to themselves when they find that it is really they that know more). Programmers will then use this information to write code that may never see the light of distribution, but nevertheless, they will have had fun and gained enlightenment from writing it. It doesn't matter which of these two types of people you are. If you have even the slightest interest in graphics file formats then you may be counted as one who cares. ------------------------------ Subject: 1. What is raster, vector, metafile, PDL, VRML, and so forth? These terms are used to classify the type of data a graphics file contains. Raster files (also called bitmapped files) contain graphics information described as pixels, such as photographic images. Vector files contain data described as mathematical equations and are typically used to store line art and CAD information. Metafiles are formats that may contain either raster or vector graphics data. Page Description Languages (PDL) are used to describe the layout of a printed page of graphics and text. Animation formats are usually collections of raster data that is displayed in a sequence. Multi-dimensional object formats store graphics data as a collection of objects (data and the code that manipulates it) that may be rendered (displayed) in a variety of perspectives. Virtual Reality Modeling Language (VRML) is a 3D, object-oriented language used for describing "virtual worlds" networked via the Internet and hyperlinked within the World Wide Web. Multimedia file formats are capable of storing any of the previously mentioned types of data, including sound and video information. ------------------------------ Subject: 2. Why should I care about previous versions of a file format? When version 2.0 of the XXX format is released all of the thousands of files created using version 1.0 of the XXX format don't magically disappear or transform to version 2.0 overnight. Although version 2.0 might claim to be fully backwards compatible, the new specification may obfuscate or even omit details of the previous version of the format. In short, never throw away older information just because you have something newer. At one point in time that "out dated" format spec was state-of-the-art, and it may still contain a singular precious tid-bit of information that the caretakers of the format didn't carry over to the new spec (but Murphy will make sure you desperately need to know). ------------------------------ Subject: 3. Can graphics files be infected with a virus? For most types of graphics file formats currently available the answer is "no". A virus (or worm, Trojan horse, and so forth) is fundamentally a collection of code (that is, a program) that contains instructions which are executed by a CPU. Most graphics files, however, contain only static data and no executable code. The code that reads, writes, and displays graphics data is found in translation and display programs and not in the graphics files themselves. If reading or writing a graphics file caused a system malfunction is it most likely the fault of the program reading the file and not of the graphics file data itself. With the introduction of multimedia we have seen new formats appear, and modifications to older formats made, that allow executable instructions to be stored within a file format. These instructions are used to direct multimedia applications to play sounds or music, prompt the user for information, or display other graphics and video information. And such multimedia display programs may perform these functions by interfacing with their environment via an API, or by direct interaction with the operating system. One might also imagine a truly object-oriented graphics file as containing the code required to read, write, and display itself. Once again, any catastrophes that result from using these multimedia application is most like the result of unfound bugs in the software and not some sinister instructions in the graphics file data. Such "logic bombs" are typically exorcised through the use of testing using a wide variety of different image files for test cases. If you have a virus scanning program that indicates a specific graphics file is infected by virus, then it is very possible that the file coincidentally contains a byte pattern that the scanning programming recognizes as a key byte signature identifying a virus. Contact the author (or even read the documentation!) of the virus scanning program to discuss the probability of the mis-identification of a clean file as being infected by a virus. Save the graphics file, as the author will most likely wish to examine it as well. If you suspect a graphics file to be at the heart of a virus problem you are experiencing, then also consider the possibility that the graphics file's transport mechanism (floppy disk, tape or shell archive file, compressed archive file, and so forth) might be the original source of the virus and not the graphics file itself. ------------------------------ Subject: 4. Can graphics files be encrypted? Of course you can encrypt a graphics file. After all, most encryption algorithms don't care about the intellectual content of a file. All they chew on is a series of byte values. Therefore, most any encryption program that works on ordinary text files will work on graphics files as well. Why would you want to encrypt a graphics file? Mostly to control who can view its contents. You can invent a proprietary file format and that might slow a file format hack down for, say, five or ten minutes. You could add a proprietary data compression scheme, possibly a twisted variation of an already public algorithm. But there are so many people out there with nothing better to do than hack at unknown data formats that your data would probably be exposed in little time. But suppose we top off all this effort by encrypting the graphics file itself as we would an ordinary text file. Would your data then be safe? Realize that an encrypted graphics file still might not be very secure. For every data encryption algorithm there exists at least one method of getting around it, although it may take hundreds of computers and many years to fully employ and execute that method! For example, one of the more popular methods used to encrypt data is the Vernam or XOR cipher. This cipher Exclusive ORs the plain-text data with a single, random, fixed-length key. The longer the key the harder it is to break the cipher. A totally random key the length of your data is impossible to break. Shorter and less-random keys are easier to break. XOR is very simple and fast, which is a must for a graphics file translators/viewers that must decrypt a file on the fly. A problem, however, is that most graphics files contain fixed size headers which vary only slightly in content from file to file. If you knew the approximate contents of the header of an encrypted file you could XOR a "decrypted" header with the encrypted file and possibly produce the key used to encrypt the file. A short key might be very easily discovered in this way. If you really need to make the contents of a graphics file secure, then I'd suggest not only using some form of data encryption, but also create an unconventional and proprietary file format and do not publish its format specification. For more info on data encryption: Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C", John Wiley & Sons, 1994. ------------------------------ Subject: 5. Can a graphics file be copyrighted? No. A graphics file cannot normally be copyrighted under United States copyright laws (although the rulings of some judges may disagree on this). The specification of a format and the contents of a graphics file, however, are subject to copyright. For anything to be copyrighted it must be: 1) A work of authorship 2) Fixed in a tangible medium of expression The description of a graphics format does meet both of these criteria (it is fixed in a medium and a work of authorship) and is therefore protected under the copyright laws. A graphics file created using the format description, however, meets the second criteria, but not the first (that is, it is not considered to be a work of authorship). The format itself is considered instead to be an idea or system, and is therefore not protected by copyright. So the description of a file format is copyrightable, but the format as it exists in its medium is not. What about the graphics data that the file contains? If the graphical data written to a graphics file also meets the above two criteria, then it is also protected by the copyright laws as intellectual property. You will not wave your copyright protection by storing any original information using a graphics file format. For more information on copyright, please refer to the copyright FAQs 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.www.infosystems.* newsgroups as well. Information on patents, copyrights, and intellectual property may be found at: http://www.questel.orbit.com/patents/readings.html ------------------------------ Subject: 6. How can I convert the XXX format to the YYY format? With a file conversion program, of course! Without a doubt one of the most frequently asked categories of questions on comp.graphics is how to convert one format to another. In every case the answer is some type of conversion program or filter, but which one? Section IV of the FAQ is an attempt to list every known graphics file display and conversion program and application. Although far from complete, this list may contain the program you need. Go to the subsection of the particular operating system you are using and scan through Imports: and Exports: formats listed and see if the formats you needs to use are there. In some cases the information in a listing may make the conversion capabilities of a program a bit misleading. For example, a program that can import a vector .DWG file and export a raster .BMP file may not necessarily be able to perform a .DWG->.BMP (vector->raster) conversion (AutoCAD R12 can, BTW). And just because a program can both import and export TIFF files doesn't mean it's capable of a TIFF(CMYK)->TIFF(RGB) conversion (as Adobe Photoshop can do). As always, read the documentation, contact and ask the author of the program, or find a user of the program and ask them. ------------------------------ Subject: 7. Do I really need the specification of the format I'm using? It depends upon the results you are trying to obtain. If you have code that supports the XXX format and you find it easy (and legal) to integrate that code into your program, then you may be tempted to do so. But realize that your program will support the XXX format in just the same way as the previous program did. In other words, your program will now work the same, but it will really be no better. By obtaining the format specification you can make an attempt to fully support all of the features and capabilities a graphics or multimedia file format has to offer. If you use pre-written code that only supports a small subset of the format's features then you are not doing justice to the format and cheating your users out of functionality they might need. Always strive to create the best programs possible within reason of time and money. Obtain the specs, look at code, and talk to programmers who have worked with the format before. You might gain some insight and save yourself some hair-pulling by supporting a feature that someone didn't think to include in the original requirements for your program. ------------------------------ Subject: 8. How can I tell if a graphics file is corrupt? The easiest way is to display the file and decide if what you see on the screen or the printer is correct. This method is not fool-proof, however, because not all information stored in a graphics file is used for displaying the data it contains. Textual comments, alternate color maps, and unused fields in the header might be munged and go undetected. 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. The PNG file format supports an elegant solution to the quick detection of this type of corruption. The First character of every PNG file is the 8-bit value 89h. If this value is read as 09h, the 8th bit has been zeroed and you know the file is corrupt. Most graphics files do not contain any real, built-in error detection features. The standard way to check for corruption of any type of data file is to perform some sort of error-detection scheme on the file. Such schemes commonly used are Checksum calculations and the Cyclic Redundancy Check (CRC). These algorithms are commonly used in the world of synchronous serial communications for detecting errors in data streams. If you only wanted to provide error detection for the graphical data contained in a file, but not the header, then a 2- or 4-byte field in the header could be used to store the CRC-16 or CRC-32 value of the data. But what good is pure data if the header is possibly corrupt? If we calculate the CRC value of the entire file and then store that calculated value in the header we will have just "corrupted" the file! You could initialize the CRC field with zeros, calculate the value, store the value, and specify that the entire file need be read into memory and the CRC value field set to all zeros before the CRC calculation is made. File formats that segment their data into blocks or chunks would be able to perform a CRC on each section individually (another feature found in the PNG file format). Each section would store the CRC value as the last 2 or 4 bytes of the block and the CRC value field would never be read for the purpose of the CRC calculation. This method makes it easier to find the location of the error(s) in a file. If the CRC error occured in an unnecessary block of data, the file might still be useful anyway. This block-style CRC checking also saves the reader from performing a time-consuming CRC calculation an entire, possibly very large, graphics file. But all this can be quite a pain. Can't we avoid modifying a file and just store the CRC value externally to the file? Maybe using some sort of encapsulating "wrapper"? If you want to make sure a graphics file (or any file for that matter) has been transported through a communications channel without sustaining any corruption, first store it using a file archiving program that supports error checking of the files contained in the archive. (Several good error-checking file archiving programs include PKZIP, gzip, and zoo. The ar and tar Unix archiving programs do not support error checking). When the graphics file is stored, the archival program calculates the CRC value of the file. If the CRC value does not match the file's calculated CRC after it is unarchived after transport, you know that the file has been corrupted. Note: make sure you turn compression OFF when archiving many types of graphics files. File archival programs use compression by default and will attempt to make your compressed data even smaller (which usually results in larger data, unless the archiver is smart enough to detect the negative compression and not attempt to compress the file). ASCII-based files (such as PostScript and DXF) and some RLE-encoded files (such as PCX) will be compressed, while other formats supporting more advanced data compression methods (such as JPEG and LZW) will surely grow in size. ------------------------------ Subject: 9. 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 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), and WordPerfect Graphics (WPG). 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. ------------------------------ Subject: 10. 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. ------------------------------ Subject: III. Graphics File Resources ------------------------------ Subject: 0. File Format Specifications FTP Archives and WWW Pages The following anonymous FTP and WWW sites are known to archive file format specifications and information. These documents may be official releases of specifications by the creator/caretaker of the formats, or information transcribed by people from various sources and released onto the net, possibly without permission from the format's owner. ftp://avalon.chinalake.navy.mil/pub/format_specs ftp://avalon.vislab.navy.mil/pub/format_specs ftp://cs.columbia.edu/archives/mirror2/world-info/obi/Standards/Graphics/Formats ftp://ftp.nau.edu/graphics/formats ftp://ftp.ncsa.uiuc.edu/misc/file.formats/graphics.formats ftp://ftp.std.com/obi/Standards/Graphics/Formats ftp://ftp.uu.net/doc/literary/obi/Standards/Graphics/Formats ftp://ftp.wustl.edu/doc/graphic-formats ftp://peipa.essex.ac.uk/ipa/file.formats ftp://telva.ccu.uniovi.es/pub/graphics/file.formats ftp://x2ftp.oulu.fi/pub/msdos/programming/formats ftp://zamenhof.cs.rice.edu/pub/graphics.formats http://speckle.ncsl.nist.gov/~lsr/cgm_std.html http://www.cica.indiana.edu/graphics/3D.objects.html http://www.dcs.ed.ac.uk/home/iat/index.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 ------------------------------ Subject: 1. Graphics and Image File FTP Archives and WWW Pages The following anonymous FTP sites are known to archive image, graphics, and multimedia files and information: ftp://ames.arc.nasa.gov/pub/SPACE NASA/Ames Archives. Space images in GIF format. ftp://amiga.physik.unizh.ch/amiga/gfx/misc VistaPro graphics ftp://asterix.inescn.pt/pub/PC/flidemos FLI and FLC animations ftp://ftp.catt.ncsu.edu/pub/graphics FLIC and QuickTime movies and many GIF and JPG images ftp://ftp.cdrom.com/pub/aminet/pix JPG, GIF, and Multimedia files ftp://ftp.cnam.fr/Fractals/anim Fractal animation files ftp://edcftp.cr.usgs.gov/pub/data/DEM/250 ftp://edcftp.cr.usgs.gov/pub/data/DLG/{2M,100K} Digital Elevation Model (DEM) and Digital Line Graph (DLG) archives ftp://ftp.povray.org/pub/povray/images ftp://ftp.povray.org/pub/povray/scenes GIF, JPEG, and POV scene files rendered using PovRAY ftp://ftp.sdsc.edu/pub/sdsc/images ftp://ftp.sdsc.edupub/sdsc/sound San Diego Supercomputer Center sound and image file archives ftp://ftp.sunet.se/pub/graphics ftp://ftp.sunet.se/pub/multimedia MPEG, JPEG, FLC, HDF, AF, VR, and GIF files. Also /pub/pictures and /pub/comics contain many images ftp://ftp.tcp.com/pub/anime ftp://ftp.tcp.com/pub/anime-manga/anim Animation and multimedia files in MPEG, QuickTime, AVI, and FLI formats ftp://omicron.cs.unc.edu/pub/softlab/CHVRTD MRI and CT scan volume data of human anatomy ftp://photo1.si.edu/images Smithsonian Institution photoimage archives ftp://ftp.povray.org POV animation files ftp://src.doc.ic.ac.uk:/pub/packages/faces USENIX faces archive (contains 5592 different faces) ftp://ftp.uni-erlangen.de/pub/pictures/mpeg/LOCAL/RedsNightmare.tar Red's Nightmare (a ray-traced animation) ftp://ftp.univ-rennes1.fr/Images/ASTRO/anim Space animation files ftp://ftp.wustl.edu/pub/aminet/gfx/anim Various Amiga anims (also on other aminet sites) ftp://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://cui_www.unige.ch:80/OSG/MultimediaInfo/ Index to Multimedia Information Resources http://found.cs.nyu.edu/ NYU State Center for Advanced Technology http://fuzine.mt.cs.cmu.edu/im/informedia.html Informedia Digital Video Library Project http://mambo.ucsc.edu:80/psl/thant/thant.html Thant's Animation index http://netlab.itd.nrl.navy.mil/imaging.html Listings of imaging resources and archive sites http://scorch.doc.ic.ac.uk/~np2/multimedia/ http://sunsite.unc.edu/louvre/about/tech.html http://mistral.enst.fr/louvre/about/tech.html WebLouvre - Using and troubleshooting the web http://w3.eeb.ele.tue.nl/mpeg/index.html Various MPEG animations http://web.msi.umn.edu/WWW/SciVis/umnscivis.html Scientific visualization and graphics http://www.best.com/~bryanw/index.html The Graphics Archive http://www.cs.ubc.ca/nest/imager/imager.html MPEG animations done using hierarchical b-splines http://www.delphi.com/fx/fxscreen.html fX Networks' Download Goodies promo videoclips in AVI and QT formats http://www.demon.co.uk/ Demon Internet http://www.infomedia.com:8600 Liquid Mercury's new WWW Site designed for "New Media" professionals. Current industry data and product profiles. Email: info@infomedia.com http://www.kodak.com/digitalImages/samples/samples.shtml Kodak Sample Digital Images archive 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.state51.co.uk/state51/ State51 Interactive Media http://www.univ.trieste.it/mmwwwpc/mmwwwpc.html MultiMedia WWW PC v1.1 --------------------- Subject: 2. Internet Mailing Lists for Graphics and Imaging This section contains a listing of Internet mailing lists that often contain discussions and information on graphics and image file formats. Mailing lists are a good alternative form of communication for those netters that do not have Usenet access. agocg-ip@mailbase.ac.uk Discussion of all aspects of image processing. To subscribe: send an email message to mailbase@mailbase.ac.uk with the body "join agocg-ip yourfirstname yourlastname". digvid-l@ucdavis.edu Discussion of digital video, mostly of the desktop variety. To subscribe: send an email message to listserv@ucdavis.edu with the body: "subscribe digvid-l yourfirstname yourlastname". geotiff@tazboy.jpl.nasa.gov. Discussion regarding the establishment of a set of TIFF tags for storing geographic map projection information, such as UTM zones, Lambert Standard parallels, etc. Participants include representatives from SPOT, Intergraph, ERDAS, ESRI, and USGS. To subscribe: send an email message to geotiff-request@tazboy.jpl.nasa.gov. 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". listserv@info.kodak.com Information on the Kodak Photo-CD format. To subscribe: send an email message to listserv@info.kodak.com with the body: "INFO PHOTO-CD". listserv@soils.umn.edu NIH image processing discussion. To subscribe: send an email message to listserv@soils.umn.edu with the body "subscribe nih-image yourfirstname yourlastname". medimage@polygraf Medical imaging discussion. To subscribe: send an email message to listserv%polygraf.bitnet@mitvma.mit.edu with the body "subscribe medimage". nucmed@uwovax.uwo.ca Nuclear medicine and medical imaging discussion. To subscribe: send an email message to nucmed-request@uwovax.uwo.ca with the body "subscribe nucmed". pixel@essex.ac.uk British Machine Vision Association newsletter for machine vision, image processing, pattern recognition, remote sensing, etc. To subscribe: send an email message to pixel-request@essex.ac.uk. ximage@expo.lcs.mit.edu Discussion of image processing using The X Window System. To subscribe send an email message to ximage-request@expo.lcs.mit.edu with the body "subscribe ximage". ------------------------------ Subject: 3. Books on Graphics File Formats This section contains bibliographical listing of books containing information on graphics file formats. This list is alphabetized by title and information on how to order each book is included where known. The AutoCAD Database Book, F.H. Jones and L. Martin, Ventana Press, ISBN 0-940087-04-9. Order: 919.490.0062 voice. Bit-mapped graphics (2nd ed.), Steve Rimmer, Windcrest/McGraw-Hill 1993. 484 pages. CGM and CGI: Metafile and Interface Standards for Computer Graphics, David B. Arnold and Peter R. Bono, Springer-Verlag 1988. ISBN 3-540-18950-5, 279 pages. The CGM Handbook, Lofton R. Henderson and Anne M. Mumford, Academic Press 1993. ISBN 0-12-510560-6, $59.95 hardcover, 446 pages. Encyclopedia of Graphics File Formats, James D. Murray and William vanRyper, O'Reilly & Associates Inc. 1994. ISBN 1-56592-058-9, $59.95 softcover, 928 pages. Order: order@ora.com, 800.998.9938 voice, 707.829.014 fax. File Formats for Popular PC Software: A Programmer's Reference, Walden, Jeff, John Wiley & Sons, Inc. 1986. ISBN 0-471-83671-0, 287 pages. Graphics File Formats (2nd ed.), David C. Kay and John R. Levine, Windcrest Books/McGraw-Hill 1995. ISBN 0-07-034025-0, $26.95 softcover, 476 pages. Order: Tab Software Department, Blue Ridge Summit, PA 17294-0850. The Graphic File Toolkit: Converting and Using Graphic Files, Steve Rimmer, Addison-Wesley, 1992. 335 pages. Inside Windows File Formats, Tom Swan, Sams Publishing 1993. ISBN 0-672-30338-8 $24.95 softcover, 337 pages. Order: Sams Publishing, 2201 West 103rd Street, Indianapolis, IN 46290 More File Formats for Popular PC Software: A Programmer's Reference, Jeff Walden, John Wiley and Sons 1987. 369 pages. PC Graphics with GKS, P.R. Bono, J.L. Encarnacao and W.R. Herzner, Prentice-Hall, 1990. PostScript Language Reference Manual, Adobe Systems Inc. (2nd ed.), Ed Taft and Jeff Walden, Addison-Wesley 1990. Programming for Graphics Files in C and C++, by John R. Levine, John Wiley & Sons 1994. ISBN 0-471-59854-2, $29.95 softcover, 494 pages. ------------------------------ Subject: 4. Magazine Articles on Graphics File Formats This section contains bibliographical listings of periodicals containing information on graphics file formats. This list is alphabetized by title. .mrb and .shg File Formats, Windows/DOS Developer's Journal, Pete Davis, February 1994 (Vol 5, No 4), pp. 37-46. The BMP File Format, Dr. Dobb's Journal, Marv Luse, #219 September 1994 (Vol 9, Issue 10), pp. 18-22. The BMP File Format: Part I, Dr. Dobb's Journal, David Charlap, #228 March 1995 (Vol. 20, Issue 3). The BMP File Format: Part II, Dr. Dobb's Journal, David Charlap, #229 April 1995 (Vol. 20, Issue 4). PCX Graphics, C Users Journal, Ian Ashdown, Vol 9, Num 8, August 1991, pp. 89-96. Printing PCX Files, C Gazette, Marv Luse, Vol 5, Num 2, Winter 1990-91, pp. 11-22. Reading GIF Files, Dr. Dobb's Journal, Wilson MacGyver Liaw, #227 February 1995 (Vol 20, Issue 2), pp. 56-60. TIFF File Format, C Gazette, James Murray, Vol 5, Num 2, Winter 1990-91, pp. 27-42. Translating PCX Files, Dr. Dobb's Journal, K. Quirk, Vol 14, Num 8, August 1989, pp. 30-36, 105-108. Working with PCX files, Microcornucopia, Number 42, July-August 1988, p. 42. ------------------------------ Subject: 5. U.S. Government and Military Standards Sources The following organizations provide U.S. Government and Military documents concerning graphics formats and standards: Department of Defense Joint Interoperability Engineering Organization Center for Standards 10701 Parkridge Boulevard Reston, VA 22091-4398 USA Standardization Documents Ordering Desk 700 Robbins Avenue Building 4D Philadelphia, PA 19111-5094 USA Naval Publications & Forms Center Code 3051 5801 Tabot Ave. Philadelphia, PA 19120 USA Defense Information Systems Agency Center for Standards Attn: TBCE, Rm 3304 10701 Parkridge Blvd Reston, VA 22091 USA Voice: 703.487.3536 Email: edi@itsi.disa.mil Department of Defense Single Stock Point (DODSSP) Special Assistance Desk Open 7:30AM to 4PM EST Mon-Fri Voice: 215.697.2667 Voice: 215.697.2179 Department of Defense Single Stock Point (DODSSP) Subscription Services Desk 700 Robbins Avenue Building 4D Philadelphia, PA 19111-5094 USA Voice: 215.697.2569 Navy Print On Demand System (NPODS) Telespecs automated document ordering system Open 7AM to 10PM EST Mon-Fri Voice: 215.697.1187 thru .1198 Global Engineering Documents 2805 McGaw Avenue Irvine, CA 92714 USA Voice: 800.854.7179 Voice: 714.261.1455 Global Info Center 18201 McDurmott West Suite B Irvine, CA 92714 USA Voice: 714.474.5070 Fax: 714.474.4066 ------------------------------ Subject: 6. Other Standards Document Sources Many graphics file formats and graphical information transfer protocols are ANSI/ISO standards and may be obtained through the following offices: International Standards Organization (ISO) 1 rue de Varembe Case Postal 56 CH-1211 Geneva 20 Switzerland Voice: +41 22 749 01 11 Fax: +41 22 733 34 30 American National Standards Institute (ANSI) Sales Department 11 West 42nd Street New York, NY 10036 Voice: 212.642.4900 Canadian Standards Association (CSA) Sales Group 178 Rexdale Blvd. Rexdale, Ontario, M9W 1R3 Voice: 416.747.444 ------------------------------ Subject: V. Graphics Formats Misnomers, Misgivings, and Miscellany ------------------------------ Subject: 0. Why aren't JPEG, MPEG, LZW, and CCITT Group 3 & 4 file formats? One of the most commonly confused concepts found in file formats is the difference between the file format and the method(s) of data encoding that has been used to reduce the size of the data the file contains. JPEG, MPEG, LZW, and CCITT are all algorithms, or algorithm toolkits, which encode a stream of data to a physically smaller size. None of these data compression methods define a specific format used to store data. Several formats have become popular based on their use of one or more of these methods of compression, such as GIF (LZW), JFIF (JPEG), and TIFF (CCITT Group 3 and Group 4). So if you ask for a "CCITT Group 3" image file you will most likely get a file containing only CCITT Group 3 data and not a TIFF file containing bitmapped data compressed using the CCITT Group 3 algorithm, which might have been what you were expecting. ------------------------------ Subject: 1. Why aren't IGES, GKS, NAPLPS, PCL, and HPGL file formats either? IGES (Initial Graphics Exchange Specification), GKS (Graphics Kernel System), and NAPLPS (North American Presentation Layer Protocol Syntax) are not actually file formats. They are instead protocols which specify how graphical data should be transmitted over a communications link (such as a telephone line) to a remote device (such as a graphical workstation). HPGL (Hewlett-Packard Graphics Language) 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 (HPGL uses a raw or compressed bitmap). Occasionally the transmitted data stream may be stored to a file for buffering or archival purposes. This file is then often identified as using the "{IGES,GKS,NAPLPS,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. ------------------------------ Subject: 2. Is it "Tag" or "Tagged" Image File Format? Revision 5.0 of TIFF specification specifically states the acronym "TIFF" is "Tag Image File Format". The majority of people, however, intuitively say "Tagged" rather than "Tag". Interestingly enough, the TIFF 6.0 specification does not spell out the acronym TIFF. ------------------------------ Subject: 3. Whaddya mean there's no "Targa" file format? The popular "Targa" file format is really the "TGA format". "Targa" is the name of the Truevision graphics display adapter which first used the TGA format. Specifically, Revision 1.0 of TGA is designated the "Original TGA format" and Revision 2.0 is the "New TGA Format". ------------------------------ Subject: 4. Choosy programmers choose "gif" or "jif"? The pronunciation of "GIF" is specified in the GIF specification to be "jif", as in "jiffy", rather then "gif", which most people seem to prefer. This does seem strange because the "G" is from the word "Graphics" and not "Jraphics". ------------------------------ Subject: 5. Why are there so many ".PIC" and ".IMG" formats? Because people with very little imagination are allowed to choose file extensions for graphics files, that's why. But seriously, there does seem to be a proliferation of file formats with the file extension ".PIC" (for "picture") and ".IMG" (for "image"). Other popular extensions (in both upper and lower case) are ".RGB", ".RAW", ".ASC", and ".MAP". My advise to you is never assume the format of a data file based only on it's file extension. The name and the extension of any file are completely arbitrary and therefore could be anything. This is why the most graphics file conversion and display programs attempt to recognize graphics files based on their internal structure and not their file name or extension. ------------------------------ Subject: 6. Is it now illegal to use CompuServe's GIF format? 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 PS Level II I don't need to worry about obtaining a license agreement? A: That is correct. Only software that is capable of using the LZW algorithm requires an agreement. This includes all software that supports the GIF file format. Q: What about file compression programs such as compress, PKZIP, zoo, and lha? Don't they use LZW too? A: Most file compression programs use the LZ77 algorithm for compressing text. The LZ77 compression algorithms (and several of its derivatives) predates LZW by several years and is covered by its own series of patents. The predecessor to LZW, LZ78, is used primarily for compressing binary data and bitmaps. Any software that uses the LZ77 and/or LZ78 algorithms without the LZW improvement is not affected by the Unisys LZW patent. Of the mentioned software packages, the Unix compress utility does use LZW and therefore requires a license. Q: Doesn't IBM also hold a patent on LZW? A: IBM was granted a patent (4,814,746) for use of LZW in disk drive technology. This patent does not award ownership of LZW to IBM. Q: Is there a chance that the Unisys patent is actually invalid? A: In 1994, the U.S Patent Office reexamined the Welch patent and, on January 4th of that year, not only confirmed the patentability of the original 181 patent claims, but also confirmed that 51 claims added during the reexamination were also patentable. Q: But you can't patent a mathematical abstraction. Doesn't this also include algorithms implemented as computer software? A: A patent grants the exclusive rights, title, or license to produce, use, or sell an invention or process. One or more algorithms may be applied using software to create an invention. It is this invention whose use is restricted by the patent and not the algorithm(s) involved. In the case of software, it seems that it is not very easy to separate the algorithm(s) from the invention itself. Use of the algorithm(s) would seem to imply use of the invention as well. Q: I use LZW in my programs, but not for GIF or TIFF graphics. What should I do? A: If you are not a business, and the programs are for your own personal non-commercial or not-for-profit use, Unisys does not require you to obtain a license. If they are used as part of a business and/or you sell the programs for commercial or for-profit purposes, then you must contact the Welch Patent Licensing Department at Unisys and explain your circumstances. They will have a license agreement for your application of their LZW algorithm. Q: Where can I apply for a GIF-LZW, TIFF-LZW and GIF-LZW, PDF, PostScript Level II, or any other LZW license? A: You can write to: Welch Patent Licensing Department Unisys Corporation Mail Stop C1SW19 P.O. Box 500 Blue Bell, PA 19424 USA Or fax: 215.986.3090 Or email: lzw_info@unisys.com General licensing information may also be obtained from the home page of the Unisys Web Server: http://www.unisys.com Q: How much does a license cost? A: For a GIF-LZW license there is a $25US non-refundable registration fee to start. You will then pay 0.45% of the selling price of your software per unit sold per calendar quarter with a minimum of $0.10US and a maximum $10US per unit. For a TIFF-LZW and GIF-LZW license, the non-refundable registration fee is $50US and you will pay 0.65% of the selling price of your software per unit sold per calendar quarter, with a minimum of $0.20US and a maximum of $25US per unit. The license agreement contains various other terms and conditions, such as those which define the field of use. 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 and other related graphical newsgroups. The official newsgroup where much discussion takes place is alt.gif-agreement. You might also find information on the misc.legal.computing, misc.int-property, and comp.patents newsgroups. Q: Where can I get a copy of the Unisys patent? A: Copies of patents may be found in public libraries or be obtained directly from the U.S. Patent Office. The patent is also available at many Internet sites, including: ftp://cs.columbia.edu/archives/mirror2/world-info/obi/USPatents/lzw-patent.gz ftp://ftp.std.com/obi/USPatents/lzw-patent.Z ftp://ftp.uu.net/doc/literary/obi/USPatents/lzw-patent.Z ftp://gatekeeper.dec.com/.8/misc/lzw-patent.Z Q: What are my alternatives to GIF and TIFF-LZW file formats? A: The most popular alternative is JPEG compression and the JFIF file format. JFIF-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: 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. 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: VII. Kudos and Assertions ------------------------------ Subject: 0. Acknowledgments The following people have made this FAQ take just a little bit longer to read since the last time you looked at it (blame them and not me): Bruce Garner <garner@tis.llnl.gov> Oliver Grau <grau@tnt.uni-hannover.de> John T. Grieggs <grieggs@netcom.com> Lee Kimmelman <lee.kimmelman@twwde.com> David Kuo <dkuo@dabulls.kodak.com> Tom Lane <tgl@netcom.com> Angus Montgomery <angus@cgl.citri.edu.au> Glen Ozymok <oz@ludwig.virtualprototypes.ca> Daniel Sears <sears@netcom.com> Marc Soucy <msoucy@imetric.qc.ca> Bjoern Stabell <bjoerns@acm.org> Mark T. Starr <StarrMT@po4.bb.unisys.com> ------------------------------ Subject: 1. About The Author The author of this FAQ, James D. Murray, lives in the City of Orange, Orange County, California, USA. He is the co-author of the book Encyclopedia of Graphics File Formats published by O'Reilly and Associates, makes a passable living writing Microsoft Windows applications in C++, and may be reached as jdm@netcom.com, or via U.S. Snail at: P.O. Box 70, Orange, CA 92666-0070 USA. GCS d-- H++ s g- p? au+ a w+ v++ C+++(++++) US+++ p++>++++ L>++ 3 E--- N++ K- W---$ M-@ V-- po Y+ t++ 5-- j>x R+>-- G' tv-->! b+++ D++ B e- u* h- f r-->+++ n++ y*(**) ------------------------------ Subject: 2. Disclaimer While every effort has been taken to insure the accuracy of the information contained in this FAQ list compilation, the author and contributors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. ------------------------------ Subject: 3. Copyright Notice This FAQ is Copyright (C) 1994-95 by James D. Murray. All Rights Reserved. This work may be reproduced, in whole or in part, using any medium, including, but not limited to, electronic transmission, CD-ROM, or published in print, under the condition that this copyright notice remains intact.