Part1 - Part2 - Part3 - Part4

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

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. Sender: jdm@ruby.ora.com Expires: 02/24/97 00:13:00 Message-ID: <graphics/fileformats-faq-1-853747980@ora.com> Reply-To: jdm@ora.com (James D. Murray) Summary: This document answers many of the most frequently asked questions about graphics file formats on Usenet. Keywords: FAQ, GRAPHICS, FORMAT, IMAGE, MULTIMEDIA, 3D 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. ------------------------------

Part1 - Part2 - Part3 - Part4

Send corrections/additions to the FAQ Maintainer:
jdm@ora.com (James D. Murray)

Last Update April 18 1999 @ 03:29 AM

faq-admin@faqs.org