home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / graphics / fileformats-faq / part1 next >
Encoding:
Internet Message Format  |  1997-01-20  |  92.9 KB

  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!cam-news-feed2.bbnplanet.com!amber.ora.com!not-for-mail
  2. From: jdm@ora.com
  3. Newsgroups: comp.graphics.misc,comp.answers,news.answers
  4. Subject: Graphics File Formats FAQ (Part 1 of 4): General Graphics Format Questions
  5. Supersedes: <graphics/fileformats-faq-1-849730784@ora.com>
  6. Followup-To: poster
  7. Date: 20 Jan 1997 00:13:01 -0800
  8. Organization: O'Reilly & Associates, Inc.
  9. Lines: 2150
  10. Sender: jdm@ruby.ora.com
  11. Approved: news-answers-request@MIT.EDU
  12. Distribution: world
  13. Expires: 02/24/97 00:13:00
  14. Message-ID: <graphics/fileformats-faq-1-853747980@ora.com>
  15. Reply-To: jdm@ora.com (James D. Murray)
  16. NNTP-Posting-Host: ruby.ora.com
  17. Summary: This document answers many of the most frequently asked 
  18.     questions about graphics file formats on Usenet.
  19. Keywords: FAQ, GRAPHICS, FORMAT, IMAGE, MULTIMEDIA, 3D
  20. Xref: senator-bedfellow.mit.edu comp.graphics.misc:18679 comp.answers:23815 news.answers:92564
  21.  
  22. Posted-By: auto-faq 3.1.1.2
  23. Archive-name: graphics/fileformats-faq/part1
  24. Posting-Frequency: monthly
  25. Last-modified: 20Jan97
  26.  
  27. Graphics File Formats FAQ (Part 1 of 4): General Graphics Format Questions
  28.  
  29. ------------------------------
  30.  
  31. his FAQ (Frequently Asked Questions) list contains information on
  32. graphics file formats, including, raster, vector, metafile, Page
  33. Description Language, 3D object, animation, and multimedia formats.
  34.  
  35. This FAQ is divided into four parts, each covering a different area of
  36. graphics file format information:
  37.  
  38.   Graphics File Formats FAQ (Part 1 of 4): General Graphics Format Questions
  39.   Graphics File Formats FAQ (Part 2 of 4): Image Conversion and Display Programs
  40.   Graphics File Formats FAQ (Part 3 of 4): Where to Get File Format Specifications
  41.   Graphics File Formats FAQ (Part 4 of 4): Tips and Tricks of the Trade
  42.  
  43. Please email contributions, corrections, and suggestions about this FAQ to
  44. jdm@ora.com. Relevant information posted to newsgroups will not
  45. automatically make it into this FAQ.
  46.  
  47. -- James D. Murray
  48.  
  49. ------------------------------
  50.  
  51. Subject: 0. Contents of General Graphics Format Questions
  52. Subjects marked with <NEW> are new to this FAQ. Subjects marked with <UPD>
  53. have been updated since the last release  of this FAQ.
  54.  
  55. I. General questions about this FAQ
  56.  
  57. 0. Maintainer's Comments
  58. 1. What's new in this latest FAQ release?
  59. 2. Why does a graphics formats FAQ exist?
  60. 3. Where can I get the latest copy of this FAQ?
  61. 4. Are there other related FAQs I should read as well?
  62. 5. I have a question, correction, or some information for
  63. this FAQ.
  64. 6. This FAQ doesn't contain enough detail!
  65. 7. Why isn't the XXX file format covered?
  66. 8. Why aren't audio file formats covered?
  67. 9. Why aren't word processing formats covered?
  68. 10. What about multimedia file formats?
  69. 11. What is an "Internet File Format?"
  70. 12. Which file formats should I and should I not use?
  71. 13. What is ray tracing?
  72. II. General Graphics File Questions
  73.  
  74. 0. Who cares about graphics file formats?
  75. 1. What is raster, vector, metafile, PDL, VRML, and so
  76. forth?
  77. 2. Why should I care about previous versions of a file
  78. format?
  79. 3. Can graphics files be infected with a virus?
  80. 4. Can graphics files be encrypted?
  81. 5. How can I convert the XXX format to the YYY format?
  82. 6. Do I really need the specification of the format I'm
  83. using?
  84. 7. How can I tell if a graphics file is corrupt?
  85. 8. What do I put in my own graphics file format
  86. specification?
  87. III. Working with Graphics Files on Usenet and the Internet
  88.  
  89. 0. How can I email a graphics file?
  90. 1. Where can I find graphics files on Usenet?
  91. 2. How do I decode a graphics file posted to Usenet?
  92. 3. How can I post a graphics file to Usenet?
  93. 4. How do I submit a file format specification to an
  94. archive?
  95. 5. How can I make transparent and interlaced GIFs for a Web
  96. page?
  97. 6. How do I combine still images to make animations?
  98. IV. Copyrights, Patents, and other Legalities of Graphics File Formats
  99.  
  100. 0. Can a graphics file be copyrighted?
  101. 1. Is it now illegal to use CompuServe's GIF format?
  102. V. Graphics Formats Misnomers, Misgivings, and Miscellany
  103.  
  104. 0. Why aren't JPEG, MPEG, LZW, and CCITT Group 3 & 4
  105. file formats?
  106. 1. Why aren't IGES, GKS, NAPLPS, PCL, and HPGL file formats
  107. either?
  108. 2. Is it "Tag" or "Tagged" Image File
  109. Format?
  110. 3. Whaddya mean there's no "Targa" file format?
  111. 4. Choosy programmers choose "gif" or "jif"?
  112. 5. Why are there so many ".PIC" and ".IMG"
  113. formats?
  114. 6. Where can I get the spec for the GIF24 format?
  115. 7. Is there an uncompressed GIF format?
  116. VI. Graphics File Resources
  117.  
  118. 0. File Format Specifications FTP Archives and WWW
  119. Pages
  120. 1. Graphics and Image File FTP Archives and WWW Pages
  121. 2. Internet Mailing Lists for Graphics and Imaging
  122. 3. Books on Graphics File Formats
  123. 4. Magazine Articles on Graphics File Formats
  124. VII. Kudos and Assertions
  125.  
  126. 0. Acknowledgments
  127. 1. About The Author
  128. 2. Disclaimer
  129. 3. Copyright Notice
  130.  
  131. ------------------------------
  132.  
  133.  
  134. Subject: I. General questions about this FAQ
  135.  
  136. ------------------------------
  137.  
  138. ubject: 0. Maintainer's Comments
  139.  
  140. The GFF FAQ is now included in the Sandy Bay Software PC Webopaedia
  141. at: 
  142.   http://www.sandybay.com/pc-web/graphics_file_format.htm
  143.  
  144. ------------------------------
  145.  
  146. ubject: 1. What's new in this latest FAQ release?
  147.   
  148.   o Add some new LZW information. Need to update this section more.
  149.   o Added section on uncompressed GIF files
  150.   o Several new file format book entries and one new journal article
  151.   o Updated many URLs
  152.  
  153. ------------------------------
  154.  
  155. ubject: 2. Why does a graphics formats FAQ exist?
  156.  
  157. The purpose of this FAQ is to answer many of the frequently asked questions
  158. about graphics file formats posted on Usenet. You will find definitions of
  159. terms, references to format information, very general descriptions of many
  160. formats, information on programs which read, write, convert, and display
  161. graphics files, and some handy programming tips for writing your own code. 
  162. This FAQ is not a substitute for actual file format specifications, nor can
  163. it possibly go into a great amount of specific detail on graphics file
  164. formats.
  165.  
  166. ------------------------------
  167.  
  168. ubject: 3. Where can I get the latest copy of this FAQ?
  169.  
  170. The latest revision of this FAQ is always available at
  171. http://www.ora.com/infocenters/gff/gff-faq/. This FAQ is also
  172. distributed monthly on the Usenet newsgroups comp.graphics.misc,
  173. comp.answers, and news.answers as four separate files. It may also
  174. be obtained via anonymous FTP from:
  175.  
  176.   ftp://rtfm.mit.edu/pub/usenet/news.answers/graphics/fileformats-faq
  177.   ftp://rtfm.mit.edu/pub/usenet/comp.graphics.misc
  178.  
  179. To receive a copy of this FAQ via email, send an email message to
  180. mail-server@rtfm.mit.edu with the body:
  181.  
  182.   send usenet/news.answers/graphics/fileformats-faq/part1
  183.   send usenet/news.answers/graphics/fileformats-faq/part2
  184.   send usenet/news.answers/graphics/fileformats-faq/part3
  185.   send usenet/news.answers/graphics/fileformats-faq/part4
  186.  
  187. or via UUCP:
  188.  
  189.   uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part1
  190.   uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part2
  191.   uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part3
  192.   uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part4
  193.  
  194. Other sites on the World Wide Web that archive this FAQ include:
  195.  
  196.   http://www.jazzie.com/ii/internet/faqs.html
  197.   http://www.cs.ruu.nl/wais/html/na-dir/graphics/fileformats-faq/.html
  198.   http://www.lib.ox.ac.uk/search/search_faqs.html
  199.  
  200. ------------------------------
  201.  
  202. ubject: 4. Are there other related FAQs I should read as well?
  203.  
  204. Information related to file formats not covered by this FAQ may be
  205. found in the following FAQs:
  206.  
  207.   Newsgroup                Archive-name
  208.  
  209.   alt.binaries.pictures       pictures-faq/part[1-3]
  210.   alt.graphics.pixutils       pixutils-faq
  211.   alt.image.medical           medical-image-faq/part[1-8]
  212.   alt.sci.astro.apis          astronomy/aips-faq
  213.   comp.compression            compression-faq/part[1-3]
  214.                               mpeg-faq/part[1-8]
  215.   comp.dsp                    dsp-faq/part[1-3]
  216.                               audio-fmts/part[1-2]
  217.   comp.fonts                  fonts-faq/part[1-2]
  218.   comp.graphics.misc          graphics/faq
  219.                               graphics/colorspace-faq
  220.                               graphics/resources-list/part[1-3]
  221.                               jpeg-faq/part[1-2]
  222.   comp.graphics.animation     graphics/animation-faq
  223.   comp.graphics.rendering.raytracing  graphics/raytrace-faq/part[1-2]
  224.   comp.infosystems.gis        geography/infosystems-faq/part[1-2]
  225.   comp.infosystems.www.authoring.images
  226.   comp.multimedia             comp-multimedia-faq
  227.   comp.speech                 comp-speech-faq/part[1-3]
  228.   comp.sys.sgi.misc           sgi/faq/graphics
  229.   sci.data.formats            sci-data-formats
  230.   sci.image.processing        image-processing/Macintosh
  231.                               sci/Satellite-Imagery-FAQ/part[1-5]
  232.  
  233. These FAQs may also be found the newsgroups alt.answers, comp.answers,
  234. sci.answers, and news.answers, and in the FAQ archives at rtfm.mit.edu and mirror sites.
  235. Please read the news.answers FAQ for a log listing of WWW, FTP, gopher, and
  236. mail server FAQ archives. This FAQ is housed at http://rtfm.mit.edu/pub/usenet/news.answers/news-answers/introduction
  237.  
  238. To FTP any of these FAQs use the listed Archive-name with the following
  239. FTP address:
  240.  
  241.   ftp://rtfm.mit.edu/pub/usenet/news.answers/ [Archive-name]
  242.  
  243. To receive a copy of these FAQs via email, send an email message to
  244. mail-server@rtfm.mit.edu with the body:
  245.  
  246.   send usenet/news.answers/[Archive-name]
  247.  
  248. ------------------------------
  249.  
  250. ubject: 5. I have a question, correction, or some information for this FAQ.
  251.  
  252. All questions, comments, additions, and corrections should be sent to the
  253. author of this FAQ at jdm@ora.com.
  254.  
  255. I don't always read the newsgroups this FAQ is posted to, so please contact
  256. me directly via email rather than attempting to reach me by posting to a
  257. newsgroup. All suggestions and contributions within the scope of this FAQ
  258. are welcome and contributors receive full credit in the Acknowledgments
  259. section of this FAQ.
  260.  
  261. ------------------------------
  262.  
  263. ubject: 6. This FAQ doesn't contain enough detail!
  264.  
  265. This FAQ only attempts to answer Frequently Asked Questions. It is not a
  266. book on graphics file formats. It is instead a thick source of information
  267. that will help you obtain more information that you need. Or perhaps even
  268. clear up a few of your misconceptions and thereby saving you from wasting
  269. some time.
  270.  
  271. ------------------------------
  272.  
  273. ubject: 7. Why isn't the XXX file format covered?
  274.  
  275. If you have read and/or grepped this FAQ and not found information on the
  276. format you need the reason might be that:
  277.  
  278.   * You are looking for the format under the wrong name.
  279.  
  280.   * This FAQ is new and the information you need hasn't been included yet.
  281.  
  282.   * I don't know about the format and I need you to email me information
  283.     on it (See Subject: 5).
  284.  
  285.   * The format is proprietary and its caretakers do not wish information
  286.     on the format distributed in this FAQ.
  287.  
  288. And let me make one thing perfectly clear: I have have not proposley
  289. omitted the reference to any file formats, books, or software applications
  290. that I see as within the scope of this FAQ. If you don't see information
  291. here that you consider relavent and necessary, then *tell me* and I will
  292. include it.
  293.  
  294. ------------------------------
  295.  
  296. ubject: 8. Why aren't audio file formats covered?
  297.  
  298. Information on file formats used specifically for storing audio data
  299. are already covered quite nicely by the Audio File Formats FAQ
  300. maintained by Guido van Rossum <guido@cnri.reston.va.us> or 
  301. <guido@python.org>.
  302.  
  303. You may obtain this FAQ from the Usenet newsgroups comp.dsp, 
  304. comp.answers, and news.answers, from the FTP archive sites:
  305.  
  306.   ftp://ftp.cwi.nl/pub/audio/
  307.   ftp://rtfm.mit.edu/pub/usenet/news.answers/comp.dsp/
  308.  
  309. or via the Web page:
  310.  
  311.   http://www.cwi.nl/ftp/audio/AudioFormats.part1
  312.   http://www.cwi.nl/ftp/audio/AudioFormats.part2
  313.  
  314. The FAQ for comp.speech may of also be of interest to audio people. It is
  315. available at:
  316.  
  317.   ftp://rtfm.mit.edu/pub/usenet/news.answers/comp-speech-faq/
  318.   ftp://svr-ftp.eng.cam.ac.uk/pub/comp.speech/FAQ-complete
  319.  
  320. ------------------------------
  321.  
  322. ubject: 9. Why aren't word processing formats covered?
  323.  
  324. It is true that there are many types of file formats that cannot store
  325. graphics data (older word processor and spreadsheet formats, and so forth).
  326. These formats are not within the scope of this FAQ and are therefore not
  327. covered. Perhaps someone who works in the biz of writing file translators
  328. for these formats will put together such a FAQ one day.
  329.  
  330. ------------------------------
  331.  
  332. ubject: 10. What about multimedia file formats?
  333.  
  334. Multimedia file formats store more than just graphics data. They may also
  335. contain audio, video, animation, and textual data in addition to bitmapped
  336. and vectored graphics. Such formats, although a superset of graphics
  337. formats, are considered to be within the scope of this FAQ and are
  338. therefore covered.  Also check the comp.multimedia FAQ for additional
  339. information you may require.
  340.  
  341. ------------------------------
  342.  
  343. ubject: 11. What is an "Internet File Format?"
  344.  
  345. If you have searched the Web lately using the key phrases "file format", 
  346. "data format", or "graphics format", you have most likely run across many
  347. Web pages claiming to have all the information you need on "Internet File
  348. Formats." In fact, there is no such thing.
  349.  
  350. The Internet is a global communications network used for one thing--to
  351. move data from one location to another. The data does not need to be in
  352. the format of a "file" to be moved, nor are file and data formats created
  353. originally for use on the Internet (e.g. MIME, X.400, uucode, and so
  354. forth) only found on the Internet.
  355.  
  356. There are many file formats you will constantly encounter while using the
  357. Internet. GIF and JPEG for still-images, MPEG, MOV, and AVI for video, WAV
  358. and AU for audio, Z and gz for compressed files, and ZIP, tar, and ARJ for
  359. file archives. And while these formats are found in great profusion on the
  360. Internet, they were by no means created to be specifically used on or by
  361. the Internet and its community. Therefore, the term "Internet File Format"
  362. is inaccurate and misleading.
  363.  
  364. ------------------------------
  365.  
  366. ubject: 12. Which file formats should I and should I not use?
  367.  
  368.   [ Still working on this ]
  369.  
  370.  
  371. ------------------------------
  372.  
  373. ubject: 13. What is ray tracing?
  374.  
  375. The following FTP sites and Web pages contain ray tracing information:
  376.  
  377.   http://www.cm.cf.ac.uk/Ray.Tracing/index.old.html
  378.     The Ray Tracing Home Page
  379.  
  380.   http://www.povray.org/rtn/
  381.     Ray Tracing News Guide
  382.  
  383. ------------------------------
  384.  
  385. Subject: II. General Graphics File Questions
  386.  
  387. ------------------------------
  388.  
  389. ubject: 0. Who cares about graphics file formats?
  390.  
  391. Well, programmers do mostly. But end-users (that is, non-programmers) do as
  392. well.
  393.  
  394. The typical end-user only cares about storing their graphics information
  395. using a format that most graphics programs and filters can read. End-users
  396. are typically not concerned with the internal arrangement of the data
  397. within the graphics file itself. They only want the format to do its job
  398. by representing their data correctly in a permanent form.
  399.  
  400. Programmers, on the other hand, are that rare breed of human that just
  401. can't leave information well enough alone. They need to know how every
  402. byte is arranged to see if someone knows something that they don't (and
  403. often snicker contentedly to themselves when they find that it is really
  404. they that know more). Programmers will then use this information to write
  405. code that may never see the light of distribution, but nevertheless, they
  406. will have had fun and gained enlightenment from writing it.
  407.  
  408. It doesn't matter which of these two types of people you are. If you have
  409. even the slightest interest in graphics file formats then you may be
  410. counted as one who cares.
  411.  
  412. ------------------------------
  413.  
  414. ubject: 1. What is raster, vector, metafile, PDL, VRML, and so forth?
  415.  
  416. These terms are used to classify the type of data a graphics file contains.
  417. Raster files (also called bitmapped files) contain graphics information
  418. described as pixels, such as photographic images. Vector files contain
  419. data described as mathematical equations and are typically used to store
  420. line art and CAD information. Metafiles are formats that may contain
  421. either raster or vector graphics data. Page Description Languages (PDL)
  422. are used to describe the layout of a printed page of graphics and text.
  423. Animation formats are usually collections of raster data that is displayed
  424. in a sequence. Multi-dimensional object formats store graphics data as a
  425. collection of objects (data and the code that manipulates it) that may be
  426. rendered (displayed) in a variety of perspectives. Virtual Reality
  427. Modeling Language (VRML) is a 3D, object-oriented language used for
  428. describing "virtual worlds"  networked via the Internet and hyperlinked
  429. within the World Wide Web. Multimedia file formats are capable of storing
  430. any of the previously mentioned types of data, including sound and video
  431. information. 
  432.  
  433. ------------------------------
  434.  
  435. ubject: 2. Why should I care about previous versions of a file format?
  436.  
  437. When version 2.0 of the XXX format is released all of the thousands of
  438. files created using version 1.0 of the XXX format don't magically
  439. disappear or transform to version 2.0 overnight. Although version 2.0
  440. might claim to be fully backwards compatible, the new specification may
  441. obfuscate or even omit details of the previous version of the format. In
  442. short, never throw away older information just because you have something
  443. newer. At one point in time that "out dated" format spec was
  444. state-of-the-art, and it may still contain a singular precious tid-bit of
  445. information that the caretakers of the format didn't carry over to the new
  446. spec (but Murphy will make sure you desperately need to know).
  447.  
  448. ------------------------------
  449.  
  450. ubject: 3. Can graphics files be infected with a virus?
  451.  
  452. For most types of graphics file formats currently available the answer is
  453. "no". A virus (or worm, Trojan horse, and so forth) is fundamentally a
  454. collection of code (that is, a program) that contains instructions which
  455. are executed by a CPU. Most graphics files, however, contain only static
  456. data and no executable code. The code that reads, writes, and displays
  457. graphics data is found in translation and display programs and not in the
  458. graphics files themselves. If reading or writing a graphics file caused a
  459. system malfunction is it most likely the fault of the program reading the
  460. file and not of the graphics file data itself.
  461.  
  462. With the introduction of multimedia we have seen new formats appear, and
  463. modifications to older formats made, that allow executable instructions to
  464. be stored within a file format. These instructions are used to direct
  465. multimedia applications to play sounds or music, prompt the user for
  466. information, or display other graphics and video information. And such
  467. multimedia display programs may perform these functions by interfacing
  468. with their environment via an API, or by direct interaction with the
  469. operating system. One might also imagine a truly object-oriented graphics
  470. file as containing the code required to read, write, and display itself.
  471.  
  472. Once again, any catastrophes that result from using these multimedia
  473. application is most like the result of unfound bugs in the software and
  474. not some sinister instructions in the graphics file data. Such "logic
  475. bombs" are typically exorcised through the use of testing using a wide
  476. variety of different image files for test cases.
  477.  
  478. If you have a virus scanning program that indicates a specific graphics
  479. file is infected by virus, then it is very possible that the file
  480. coincidentally contains a byte pattern that the scanning programming
  481. recognizes as a key byte signature identifying a virus. Contact the author
  482. (or even read the documentation!) of the virus scanning program to discuss
  483. the probability of the mis-identification of a clean file as being
  484. infected by a virus. Save the graphics file, as the author will most
  485. likely wish to examine it as well.
  486.  
  487. If you suspect a graphics file to be at the heart of a virus problem you
  488. are experiencing, then also consider the possibility that the graphics
  489. file's transport mechanism (floppy disk, tape or shell archive file,
  490. compressed archive file, and so forth) might be the original source of the
  491. virus and not the graphics file itself.
  492.  
  493. ------------------------------
  494.  
  495. ubject: 4. Can graphics files be encrypted?
  496.  
  497. Of course you can encrypt a graphics file. After all, most encryption
  498. algorithms don't care about the intellectual content of a file. All they
  499. chew on is a series of byte values. Therefore, most any encryption program
  500. that works on ordinary text files will work on graphics files as well.
  501.  
  502. Why would you want to encrypt a graphics file? Mostly to control who can
  503. view its contents. You can invent a proprietary file format and that might
  504. slow a file format hack down for, say, five or ten minutes. You could add
  505. a proprietary data compression scheme, possibly a twisted variation of an
  506. already public algorithm. But there are so many people out there with
  507. nothing better to do than hack at unknown data formats that your data
  508. would probably be exposed in little time. But suppose we top off all this
  509. effort by encrypting the graphics file itself as we would an ordinary text
  510. file. Would your data then be safe?
  511.  
  512. Realize that an encrypted graphics file still might not be very secure.
  513. For every data encryption algorithm there exists at least one method of
  514. getting around it, although it may take hundreds of computers and many
  515. years to fully employ and execute that method!
  516.  
  517. For example, one of the more popular methods used to encrypt data is the
  518. Vernam or XOR cipher. This cipher Exclusive ORs the plain-text data with a
  519. single, random, fixed-length key. The longer the key the harder it is to
  520. break the cipher. A totally random key the length of your data is
  521. impossible to break. Shorter and less-random keys are easier to break.
  522.  
  523. XOR is very simple and fast, which is a must for a graphics file
  524. translators/viewers that must decrypt a file on the fly. A problem,
  525. however, is that most graphics files contain fixed size headers which vary
  526. only slightly in content from file to file. If you knew the approximate
  527. contents of the header of an encrypted file you could XOR a "decrypted"
  528. header with the encrypted file and possibly produce the key used to
  529. encrypt the file. A short key might be very easily discovered in this way.
  530.  
  531. If you wish to use a public key/private key encryption method, then
  532. storing the public key in the file format header (usually as a 4-byte
  533. field) and only encrypting the image data would be the way to go. The
  534. SMPTE DPX file format supports such an encryption feature.
  535.  
  536. If you really need to make the contents of a graphics file secure, then
  537. I'd suggest not only using some form of data encryption, but also create
  538. an unconventional and proprietary file format and do not publish its
  539. format specification.
  540.  
  541. For more info on data encryption:
  542.  
  543.   Bruce Schneier, "Applied Cryptography: Protocols, Algorithms,
  544.     and Source Code in C", John Wiley & Sons, 1994.
  545.  
  546. ------------------------------
  547.  
  548. ubject: 5. How can I convert the XXX format to the YYY format?
  549.  
  550. With a file conversion program, of course! Without a doubt one of the
  551. most frequently asked categories of questions on comp.graphics.misc
  552. is how to convert one format to another. In every case the answer is
  553. some type of conversion program or filter, but which one?
  554.  
  555. Section IV of the FAQ is an attempt to list every known graphics file
  556. display and conversion program and application. Although far from
  557. complete, this list may contain the program you need. Go to the
  558. subsection of the particular operating system you are using and scan
  559. through Imports: and Exports: formats listed and see if the formats
  560. you needs to use are there.
  561.  
  562. In some cases the information in a listing may make the conversion
  563. capabilities of a program a bit misleading. For example, a program
  564. that can import a vector .DWG file and export a raster .BMP file may
  565. not necessarily be able to perform a .DWG->.BMP (vector->raster)
  566. conversion (AutoCAD R12 can, BTW). And just because a program can
  567. both import and export TIFF files doesn't mean it's capable of a
  568. TIFF(CMYK)->TIFF(RGB) conversion (as Adobe Photoshop can do). As
  569. always, read the documentation, contact and ask the author of the
  570. program, or find a user of the program and ask them.
  571.  
  572. ------------------------------
  573.  
  574. ubject: 6. Do I really need the specification of the format I'm using?
  575.  
  576. It depends upon the results you are trying to obtain. If you have code
  577. that supports the XXX format and you find it easy (and legal) to integrate
  578. that code into your program, then you may be tempted to do so. But realize
  579. that your program will support the XXX format in just the same way as the
  580. previous program did. In other words, your program will now work the same,
  581. but it will really be no better.
  582.  
  583. By obtaining the format specification you can make an attempt to fully
  584. support all of the features and capabilities a graphics or multimedia file
  585. format has to offer. If you use pre-written code that only supports a
  586. small subset of the format's features then you are not doing justice to
  587. the format and cheating your users out of functionality they might need.
  588.  
  589. Always strive to create the best programs possible within reason of time
  590. and money. Obtain the specs, look at code, and talk to programmers who
  591. have worked with the format before. You might gain some insight and save
  592. yourself some hair-pulling by supporting a feature that someone didn't
  593. think to include in the original requirements for your program.
  594.  
  595. ------------------------------
  596.  
  597. ubject: 7. How can I tell if a graphics file is corrupt?
  598.  
  599. The easiest way is to display the file and decide if what you see on the
  600. screen or the printer is correct. This method is not fool-proof, however,
  601. because not all information stored in a graphics file is used for
  602. displaying the data it contains. Textual comments, alternate color maps,
  603. and unused fields in the header might be munged and go undetected.
  604.  
  605. A frequent source of corruption occurs when 8-bit graphics data is
  606. transported via a 7-bit communications channel. The 8th bit of each byte
  607. is cleared (set to zero) and you are left with garbage. ASCII-mode file
  608. transfers may also translate carriage returns (0Dh) to line feeds (0Ah),
  609. or to CR/LF pairs depending upon if the file is being transferred to a
  610. Unix (LF-only), Macintosh (CR-only), or MS-DOS (CR/LF) system.
  611.  
  612. The PNG file format supports an elegant solution to the quick detection of
  613. this type of corruption. The first character of every PNG file is the
  614. 8-bit value 89h. If this value is read as 09h, the 8th bit has been zeroed
  615. and you know the file is corrupt.
  616.  
  617. Most graphics files do not contain any real, built-in error detection
  618. features. The standard way to check for corruption of any type of data
  619. file is to perform some sort of error-detection scheme on the file. Such
  620. schemes commonly used are Checksum calculations and the Cyclic Redundancy
  621. Check (CRC).  These algorithms are commonly used in the world of
  622. synchronous serial communications for detecting errors in data streams.
  623.  
  624. If you only wanted to provide error detection for the graphical data
  625. contained in a file, but not the header, then a 2- or 4-byte field in the
  626. header could be used to store the CRC-16 or CRC-32 value of the data. But
  627. what good is pure data if the header is possibly corrupt? 
  628.  
  629. If we calculate the CRC value of the entire file and then store that
  630. calculated value in the header we will have just "corrupted" the file! You
  631. could initialize the CRC field with zeros, calculate the value, store the
  632. value, and specify that the entire file need be read into memory and the
  633. CRC value field set to all zeros before the CRC calculation is made. 
  634.  
  635. File formats that segment their data into blocks or chunks would be able
  636. to perform a CRC on each section individually (another feature found in
  637. the PNG file format). Each section would store the CRC value as the last 2
  638. or 4 bytes of the block and the CRC value field would never be read for
  639. the purpose of the CRC calculation. This method makes it easier to find
  640. the location of the error(s) in a file. If the CRC error occured in an
  641. unnecessary block of data, the file might still be useful anyway. This
  642. block-style CRC checking also saves the reader from performing a
  643. time-consuming CRC calculation an entire, possibly very large, graphics
  644. file.
  645.  
  646. But all this can be quite a pain. Can't we avoid modifying a file and just
  647. store the CRC value externally to the file? Maybe using some sort of
  648. encapsulating "wrapper"?
  649.  
  650. If you want to make sure a graphics file (or any file for that matter) has
  651. been transported through a communications channel without sustaining any
  652. corruption, first store it using a file archiving program that supports
  653. error checking of the files contained in the archive. (Several good
  654. error-checking file archiving programs include PKZIP, gzip, and zoo. The
  655. ar and tar Unix archiving programs do not support error checking). When
  656. the graphics file is stored, the archival program calculates the CRC value
  657. of the file. If the CRC value does not match the file's calculated CRC
  658. after it is unarchived after transport, you know that the file has been
  659. corrupted.
  660.  
  661. Note: make sure you turn compression OFF when archiving many types of
  662. graphics files. File archival programs use compression by default and will
  663. attempt to make your compressed data even smaller (which usually results
  664. in larger data, unless the archiver is smart enough to detect the negative
  665. compression and not attempt to compress the file). ASCII-based files (such
  666. as PostScript and DXF) and some RLE-encoded files (such as PCX) will be
  667. compressed, while other formats supporting more advanced data compression
  668. methods (such as JPEG and LZW) will surely grow in size.
  669.  
  670. ------------------------------
  671.  
  672. ubject: 8. What do I put in my own graphics file format specification?
  673.  
  674. For people that are faced with the task of writing up a specification for
  675. their own format (or perhaps to better document someone else's), a few
  676. suggestions are hereby offered.
  677.  
  678.   A large spec needs a table of contents, bibliography, and an index.
  679.   Most specs do not fall into this category though.
  680.  
  681.   On the cover sheet give the full information of your company, products
  682.   associated with the format, the format version, date of release, 
  683.   where the latest copy of the spec may be obtained, and how developers
  684.   may get in contact with you to ask questions.
  685.  
  686.   Detail the full history of the spec (including the difference between the
  687.   current version and all previous versions) and not just the dates of its
  688.   revision. Tell why the format was created. Detail some insights of
  689.   how it was designed. Speculate on what features future version might
  690.   contain. And give the names of your developers and other people
  691.   involved. Show the human thought that exists behind the cold chunk of
  692.   data that is your format.
  693.  
  694.   List the features of your format and explain how you intend that it
  695.   should be used and not used (tell what your format is and is not).
  696.   Give the developer your reasons that they should use your format (and
  697.   why they should not bother with others).
  698.   
  699.   Include both block diagrams and ANSI C code examples of the format's
  700.   internal data structures. Illustrate actual examples of ASCII file
  701.   format data and hexadecimal dumps of binary format data (very useful
  702.   to programmers, I might say).
  703.  
  704.   If your format includes one or more forms of data compression, error
  705.   checking, encryption, etc., place this information in a separate
  706.   section and give plenty of examples (both written and code) of how
  707.   these algorithms work. Include mathematical formulas if you believe it
  708.   makes your concepts clearer.
  709.  
  710.   Make the specification available both in hardcopy and electronic
  711.   form. The hardcopy version should be formatted as a technical
  712.   document and using a font that won't degrade badly when the spec is
  713.   photocopied or faxed. Use a standard sized page layout so the spec
  714.   isn't a hassle to fit in an envelope when mailed. The electronic
  715.   version should be available as both ASCII text and PostScript files.
  716.   Making the spec available in a word processing format (such as
  717.   Microsoft Word or Framemaker) is nice, but not absolutely necessary.
  718.  
  719.   Consider making a developer's toolkit for your format. A collection
  720.   of benchmark graphics files (one of each flavor of your format), and
  721.   a parser written in ANSI C that reads and writes your format, is of
  722.   tremendous help to programmers. Such a kit will allow developers to
  723.   implement your format quickly in their products and helps minimize
  724.   the chances of numerous software packages appearing which create
  725.   graphics files that don't meet your spec. Examples of formats with
  726.   toolkits include TIFF, TGA (Truevision), WordPerfect Graphics (WPG),
  727.   and PNG.
  728.  
  729.   Submit your specification to every FTP/Gopher/WWW site and BBS that
  730.   archives file format specs. Notify the maintainers of related FAQs
  731.   (graphics, animation, multimedia, audio, medical, etc.) that your
  732.   format exists and ask for a mention. Send your literature to graphics
  733.   and imaging software companies to sell support of your format and/or
  734.   software products.
  735.  
  736. And a few guidelines on good technical writing in general:
  737.  
  738.   Write in a tutorial style with explanations and examples of your
  739.   topics. Don't just give a terse, dictionary description of a topic
  740.   which often leaves the readers confused and needing more.
  741.  
  742.   Write in simple terms. Don't assume your readers enjoy 70-word
  743.   sentences, or have advanced degrees in mathematics or computer
  744.   graphics. 
  745.  
  746.   Have other people read and attempt to understand your spec. Don't
  747.   assume that just because you understand what you've written that
  748.   every reader will too. You, as the file format specification's
  749.   author, understand the format inside and out. Your readers, however,
  750.   do not. An explanation that may seem clear to you may be just
  751.   another confusing paragraph to your readers.
  752.  
  753.   Write for a world-wide audience of programmers. Omit slang or regional
  754.   expressions that a developer living on the other side of the planet
  755.   might not understand.
  756.  
  757.   Programs that check spelling and grammar are our friends. Use them.
  758.  
  759. Examples of some well-written format specs include: TGA, TIFF, PNG, EPSF,
  760. and PostScript. Some specs are written well, but contain so much
  761. extraneous information that they are quite complex and very tedious to
  762. read. Most government and military formats are in this group (for example,
  763. CALS, NITF, NAPLPS, IGES, GKS, and CGM). Format specs such as PCX, GIF,
  764. JFIF, and Sun Raster definitely fall into the "don't let this happen to
  765. you" catagory.
  766.  
  767. ------------------------------
  768.  
  769. Subject: III. Working with Graphics Files on Usenet and the Internet
  770.  
  771. ------------------------------
  772.  
  773. ubject: 0. How can I email a graphics file?
  774.  
  775. Normally you would move a file around the Internet using a data transport
  776. program that handles binary data, such as UUCP and FTP. If you only have
  777. an ASCII-only data transport mechanism available to you, such as
  778. electronic mail, you will need to convert your binary graphics files to an
  779. ASCII format before sending them. This process is only necessary for
  780. binary files.  ASCII-based file formats, such as DXF and PostScript, do
  781. not require uuencoding before emailing.
  782.  
  783. On the Unix operating system you will use a program called uuencode to
  784. convert the 8-bit data of a graphics file to a 7-bit ASCII data file. The
  785. data file is then emailed and uudecoded on the receiving end.
  786.  
  787. To uuencode and email a file:
  788.  
  789.   % uuencode picture.img picture.img | Mail user@host.site
  790.  
  791. This command will pipe the output of the uuencode command to the input of
  792. an email program. Realize that if your email program is set up to keep a
  793. copy of all of the email you send, and you email a lot of uuencoded
  794. graphics files, your outgoing email folder will grow quite large. You can
  795. modify your .mailrc (or equivalent) file to route the copy of the outgoing
  796. graphics file to /dev/null, or you can write-protect your outgoing mail
  797. folder so the data can't be written:
  798.  
  799.   % chmod -w ~/Mail/mbox.out
  800.   % uuencode picture.img picture.img | Mail user@host.site
  801.   /home/Mail/mbox.out: Permission denied
  802.   % chmod +w ~/Mail/mbox.out
  803.  
  804. Once the emailed data is received, you will need to strip off the mailing
  805. header before you can uudecode it. The uuencoded data starts with the word
  806. "begin" and is followed by the file mode, file name, and a series of
  807. 61-character lines. The file is ASCII, so you can use an editor such as vi
  808. to do the stripping. Assuming the received data is saved to a file named
  809. "file", the uudecoing process is thus:
  810.  
  811.   % uudecode file
  812.  
  813. The original graphics file is now in the current directory. You may delete
  814. the uuencoded file if you wish to do so.
  815.  
  816. The uuencode and uudecode programs have been ported to other systems, such
  817. as MS-DOS, MS Windows, OS/2, Amiga, and the Macintosh (the BinHex program
  818. for the Mac does not produce the same ASCII data as uuencode), and may be
  819. used in the same way.
  820.  
  821. For more information on accessing the Internet via email, please refer to
  822. the FAQ "Accessing The Internet By E-Mail: Doctor Bob's Guide to Offline
  823. Internet Access", found on the news.answers and alt.internet.services Usenet
  824. newsgroups and your favorite FAQ archives.
  825.  
  826. ------------------------------
  827.  
  828. ubject: 1. Where can I find graphics files on Usenet?
  829.  
  830. The vast majority of graphics files posted to Usenet will be found in the
  831. alt.binaries.pictures.* newgroups. If you do not have access to Usenet,
  832. then you will not be able to retrieve files posted to these groups.
  833.  
  834. For much more information on the alt.binaries.pictures.* newsgroups, please
  835. consult the alt.binaries.pictures FAQ (pictures-faq/part[1-3]) posted to
  836. news.answers and alt.binaries.pictures.d.
  837.  
  838. ------------------------------
  839.  
  840. ubject: 2. How do I decode a graphics file posted to Usenet?
  841.  
  842. Graphics files are posted to Usenet as uuencoded binaries. Although you
  843. may see files posted using BinHex or someother ASCII format, the uuencode
  844. data format is the defacto standard of Usenet.
  845.  
  846. A graphics file may be contained in a single-part posting, which you will
  847. save to a file, strip off the mailing header using a text editor, and use
  848. the uudecode program to convert the data into the original graphics file.
  849. Many online news readers will perform this operation for you.
  850.  
  851. Graphics files are usually quite large and uuencoding will increase the
  852. file size by another 33%. For this reason, graphics files (and most binary
  853. files) are split into 1000 line or 60KB chunks (multi-part postings) for
  854. easier handling. If each chunk includes a shell wrapper (the string "[sh]"
  855. usually appears in the Subject:  line of such postings), online news
  856. readers, such as tin, can tag each part of the posting and decode it into
  857. the original file for you. 
  858.  
  859. The most labor-intensive way to decode a multi-part uuencoded posting is to
  860. save each part into a separate file, edit each file to remove the mailing
  861. headers, concatenate them all into a single file, uudecode the file, and
  862. delete the original parts:
  863.  
  864.   % vi picture.1 picture.2 picture.3
  865.   % cat picture.1 picture.2 picture.3 | uudecode
  866.   % rm picture.1 picture.2 picture.3
  867.  
  868. There are, of course, several utilities to decode single- and multi-part
  869. binary posting for you without all this bother. Please refer to the
  870. alt.binaries.pictures FAQ (pictures-faq/part[1-3]) posted to news.answers
  871. and alt.binaries.pictures.d for more information on decoding graphics files
  872. posted to Usenet.
  873.  
  874. ------------------------------
  875.  
  876. ubject: 3. How can I post a graphics file to Usenet?
  877.  
  878. Posting a graphics file to a Usenet newsgroup is very similar to emailing
  879. a graphics file, but there are some important extra steps you must take in
  880. order to do so.
  881.  
  882. First, a graphics file must be uuencoded. That is, converted from 8-bit
  883. binary data to 7-bit ASCII data. Second, the resulting uuencoded file must
  884. be split into 60K chunks (1000 lines) for posting. And lastly, each chunk
  885. posted must be given a description and a part number.
  886.  
  887. Under Unix we would use the uuencode, split, expr, and inews commands to
  888. post a graphics (or any binary) file as such:
  889.  
  890.   % uuencode picture.img picture.img > picture.img.uue
  891.   % split -1000 picture.img.uue picture.img.uue.
  892.   % ls
  893.   Total 535
  894.   picture.img        picture.img.uue    picture.img.uue.1  
  895.   picture.img.uue.2  picture.img.uue.3
  896.   % sh
  897.   $ i=1
  898.   $ for j in picture.img.uue.*; do
  899.   > (echo "Subject: picture.img [$i/3]"
  900.   > echo "Newsgroups: news.test
  901.   > echo
  902.   > cat $j) | /usr/lib/news/inews
  903.   > i=`expr "$i" + 1`
  904.   > done
  905.   $ rm picture.img.*
  906.   $ exit
  907.   %
  908.  
  909. In this example, we take a graphics file named picture.img, uuencode it,
  910. and place the output in a file names picture.img.uue. This file is then
  911. split into three chunks named picture.img.uue.1, picture.img.uue.2, and 
  912. picture.img.uue.3.  We then loop through each file and create a Subject:
  913. and Newsgroup: line for each of the file chunks and post them using inews.
  914.  
  915. There are, of course, programs which automate this process. One such
  916. program is xmitBin, written by Jim Howard and availble via FTP from:
  917.  
  918.   ftp://ftp.cadence.com/utils
  919.   http://mrcnext.cso.uiuc.edu/~deej/index.html
  920.  
  921. Refer to the alt.binaries.pictures FAQ (pictures-faq/part[1-3]) posted to
  922. news.answers and alt.binaries.pictures.d for more information on posting
  923. graphics files to Usenet.
  924.  
  925. ------------------------------
  926.  
  927. ubject: 4. How do I submit a file format specification to an archive?
  928.  
  929. There are several FTP and WWW sites which act as archives for graphics
  930. file format specifications (see the section "Graphics and Image File FTP
  931. Archives and WWW Pages"). If you have a file format specification that is
  932. legal to share with the rest of the world-wide Internet community, then
  933. you may wish to submit it to one or more of these archives.
  934.  
  935. There are generally two ways to submit a file format specification to an
  936. FTP archive:
  937.  
  938.   1) Upload (or "put") the file in the /incoming or /pub/incoming directory.
  939.   2) Email the file to the archive maintainer (the email address is usually
  940.      in the README or similar file in the root FTP directory).
  941.  
  942. Realize that most FTP sites don't allow unsolicited uploads and instead
  943. require you to contact the archive maintainer to make a submission. Many
  944. sites are simply mirrors for other archives and don't accepts any kind of
  945. submissions at all. 
  946.  
  947. In any case, it's usually good form to include a description file with
  948. your submission to describe in a few words what you have uploaded and
  949. where it originated. If your upload is named foo.doc then the description
  950. file should be named foo.txt. If your upload is named foo.txt, improvise.
  951.  
  952. ------------------------------
  953.  
  954. ubject: 5. How can I make transparent and interlaced GIFs for a Web page?
  955.  
  956. Transparent GIFs are used to eliminate the typical rectangular borders
  957. associated with most bitmapped images that appear on a Web page. The
  958. creator of a GIF image may set certain pixels within the bitmap to a color
  959. desiganted within the image file as "transparent". When this GIF image is
  960. displayed by a Web browser the transparent pixels take on the color of the
  961. user's display.  This is identical to the blue screen effect found in
  962. chromakeying.
  963.  
  964. GIF89a files are made transparent by the use of graphics file editing
  965. software (GIF87a files do not support transparency and must first be
  966. converted to the GIF89a format). Such software will set the transparency
  967. color flag and the transparent color index value of a Graphics Control
  968. Extension block within the GIF89a file. Any pixel set to the specified
  969. transparent color index value will take on the background color of the
  970. display device when displayed.
  971.  
  972. Interlaced GIFs are used to give the user a idea of that an image looks
  973. like before all of the bitmapped data has been received. Non-interlaced
  974. images paint in a linear fashion from the top to the bottom of the
  975. display. Over a slow link it make take several minutes for an image to
  976. paint. When 50% of the bitmapped data is received only the top half of the
  977. image is displayed.  The contents bottom half is still a mystery to the
  978. user.
  979.  
  980. Interlaced GIFs paint quickly over the entire display first as a very low
  981. resolution image. Only about 12.5% of the bitmap is displayed in this
  982. first pass. The GIF image is then repainted in three more passes, with
  983. each pass supplying more resolution until all of the data is received
  984. (12.5%, 25%, and 50% respectively). A user can usually get a good idea of
  985. what the entire image is when only 30-50% of the bitmapped data has been
  986. received. This is very useful for knowing when to abort an image being
  987. viewd via a slow link.
  988.  
  989. Interlacing is supported by both the GIF87a and GIF89a formats. Graphics
  990. file editing software that supports interlaced GIF should not only be able
  991. to display such GIF files, but also convert non-interlaced GIFs to the
  992. interlaced format (and back again as well). This involves reading in the
  993. GIF bitmap and writing it back out using the GIF 4-pass interlace scheme.
  994. In a non-interlaced GIF the pixel lines are displayed in consecutive
  995. order. For example, the lines of a 16-line non-interlaced GIF file are
  996. stored as 0, 1, 2, 3, 4, 5...15. The lines of the same 16-line bitmap in
  997. an interlaced GIF would be stored as 0, 8, 4, 12, 2, 6, 10, 14, 1, 3, 5,
  998. 7, 9, 11, 13, 15.
  999.  
  1000. Graphics file format software packages for Unix which handles both
  1001. trasparent and interlaced GIFs include NETPBM and giftool.  For the
  1002. Macintosh:  Transparency, Graphic Converter, Imagery, and clip2gif
  1003.  
  1004. The Visioneering image manipulation page will allow you to convert your
  1005. GIFs to transparent and interlaced without having special software on your
  1006. system. Your GIF files will be read, converted, and written using the Web.
  1007. Visioneering's page is at:
  1008.  
  1009.   http://www.vrl.com/Imaging/
  1010.  
  1011. More detailed information on images used in Web pages can be found in the
  1012. FAQ for the newsgroup comp.infosystems.www.authoring.images found at:
  1013.  
  1014.   http://www.island.net/help/faq/www_faq/
  1015.   http://www.io.org/faq/www/index.html
  1016.  
  1017. A collection of links to a number of Web and FTP resources that store
  1018. information on transparent and interlaced GIFs for Unix, Macintosh, and
  1019. MS-DOS/Windows, including executable programs and tutorials, may be found
  1020. at:
  1021.  
  1022.   http://members.aol.com/htmlguru/transparent_images.html
  1023.   http://dragon.jpl.nasa.gov/~adam/transparent.html
  1024.   ftp://csi.jpl.nasa.gov/pub/graphics/transparent.faq
  1025.  
  1026. ------------------------------
  1027.  
  1028. ubject: 6. How do I combine still images to make animations?
  1029.  
  1030. You might have a collection of imaes and drawings stored in a variety of
  1031. still-image formats (TIFF, BMP, IFF, and so forth) and want to combine them
  1032. into an animation or video file format that wil allow you to play them back.
  1033.  
  1034. Have a look at the following Web page:
  1035.  
  1036.   http://www.prism.uvsq.fr/public/wos/multimedia/
  1037.  
  1038. ------------------------------
  1039.  
  1040.  
  1041. Subject: IV. Copyrights, Patents, and other Legalities of Graphics File
  1042. Formats
  1043.  
  1044. ------------------------------
  1045.  
  1046. ubject: 0. Can a graphics file be copyrighted?
  1047.  
  1048. No. A graphics file cannot normally be copyrighted under United States
  1049. copyright laws (although the rulings of some judges may disagree on this).
  1050. The specification of a format and the contents of a graphics file,
  1051. however, are subject to copyright.
  1052.  
  1053. For anything to be copyrighted it must be:
  1054.  
  1055.   1) A work of authorship
  1056.   2) Fixed in a tangible medium of expression
  1057.  
  1058. The description of a graphics format does meet both of these criteria (it
  1059. is fixed in a medium and a work of authorship) and is therefore protected
  1060. under the copyright laws. A graphics file created using the format
  1061. description, however, meets the second criteria, but not the first (that
  1062. is, it is not considered to be a work of authorship). The format itself is
  1063. considered instead to be an idea or system, and is therefore not protected
  1064. by copyright.
  1065.  
  1066. So the description of a file format is copyrightable, but the format as it
  1067. exists in its medium is not. What about the graphics data that the file
  1068. contains?
  1069.  
  1070. If the graphical data written to a graphics file also meets the above two
  1071. criteria, then it is also protected by the copyright laws as intellectual
  1072. property. You will not wave your copyright protection by storing any
  1073. original information using a graphics file format.
  1074.  
  1075. For more information on copyright, please refer to the Copyright FAQ found
  1076. on the misc.legal, misc.legal.computing, misc.int-property, and
  1077. comp.patents newsgroups: 
  1078.  
  1079.   ftp://rtfm.mit.edu/pub/usenet/news.answers/law/Copyright-FAQ/
  1080.   ftp://rtfm.mit.edu/pub/usenet/news.answers/law/Copyright-FAQ/myths/
  1081.  
  1082. Apparently, quite a number of copyright discussions also occur on the
  1083. comp.infosystems.www.* newsgroups as well.
  1084.  
  1085. Information on patents, copyrights, and intellectual property may be found
  1086. at:
  1087.  
  1088.   http://www.questel.orbit.com/patents/readings.html
  1089.     Patent and trademark information
  1090.  
  1091.   http://www.uspto.gov
  1092.     U.S. Patent and Trademark Office
  1093.  
  1094.   http://www.spi.org
  1095.     Software Patent Institute
  1096.  
  1097. ------------------------------
  1098.  
  1099. ubject: 1. Is it now illegal to use CompuServe's GIF format?
  1100.  
  1101. It is not illegal to own, transmit, or receive GIF files (provided that no
  1102. unlicensed compression and/or decompression of the files occurs). You must
  1103. realize, however, that GIF files are not the issue. The issue is, in fact,
  1104. the LZW data compression algorithm.
  1105.  
  1106. In 1984, while working for Sperry Corporation, Terry Welch modified the
  1107. Lempel-Ziv 78 (LZ78) compression algorithm for greater efficiency for
  1108. implementation in high-performance disk controllers. The result was the
  1109. LZW algorithm. The world was informed of the existence of LZW by the
  1110. following journal article, published by Mr. Welch after he left the
  1111. employment of Sperry:
  1112.  
  1113.   Welch, T. A., "A Technique for High Performance Data Compression,"
  1114.   IEEE Computer, Volume 17, Number 6, June 1984.
  1115.  
  1116. In 1985, Sperry Corporation was granted a patent (4,558,302) for the Welch
  1117. invention and implementation of the LZW data compression algorithm. Since
  1118. that time, this LZW patent has been publicly available for all to see in
  1119. the US Patent Office and many public libraries, and is available through
  1120. many on-line services.
  1121.  
  1122. In 1987, CompuServe Corporation created the GIF (Graphical Interchange
  1123. Format) file format to be used for the storage and on-line retrieval of
  1124. bitmapped graphical data. The GIF specification required the use the LZW
  1125. algorithm to compress the data stored in each GIF file. It is very
  1126. possible that CompuServe did not check the patent files to determine
  1127. whether the GIF format infringed on any patents. Such a check would have
  1128. found the Welch LZW patent, which was then owned by Unisys as a result of
  1129. their having purchased Sperry in 1986. At that time, Unisys also did not
  1130. know that LZW was the method of compression used by the very popular GIF
  1131. file format.
  1132.  
  1133. In 1988, Aldus Corporation released Revision 5 the TIFF file format. This
  1134. revision added a new feature giving TIFF the ability to store RGB
  1135. bitmapped data using either a raw format, or a compressed format using the
  1136. LZW algorithm. (Although the LZW algorithm used by TIFF is considered to
  1137. be "broken", it is still covered by the Unisys patent). Since 1991, in
  1138. accordance with their agreement with Unisys, Aldus has been required to
  1139. place a notice regarding the Unisys patent and its applicability to TIFF,
  1140. in Aldus documentation. The 1992 release of Revision 6 of the TIFF
  1141. specification includes this notice of the Unisys patent regarding LZW. The
  1142. TIFF Revision 6 specification also recommends against using LZW to
  1143. compress RGB bitmaps stored using the TIFF format.
  1144.  
  1145. In 1990, Unisys licensed Adobe for the use of the Unisys LZW patent for
  1146. PostScript.
  1147.  
  1148. In 1991, Unisys licensed Aldus for the use of the Unisys LZW patent in
  1149. TIFF.
  1150.  
  1151. In 1994, Unisys and CompuServe came to an understanding whereby the use of
  1152. the LZW algorithm would be licensed for the application of the GIF file
  1153. format in software. 
  1154.  
  1155. In 1995, America Online Services and Prodigy Services Company also entered
  1156. license agreements with Unisys for the utilization of LZW.  Published
  1157. information indicates that Unisys' licensing policies are as follows:
  1158.  
  1159.  1) Unisys considers all software created or modified before January 1,
  1160.     1995 that supports the GIF and/or TIFF-LZW formats to be
  1161.     inadvertently infringing upon its patent; Unisys will therefore not
  1162.     require a license for GIF software products delivered before January
  1163.     1, 1995. Unisys will therefore not pursue legal actions against such
  1164.     pre-1995 software products.
  1165.  
  1166.  2) However, Unisys expects developers of commercial or for-profit
  1167.     software to obtain a GIF-LZW license agreement from Unisys if, after
  1168.     December 31, 1994, the developer creates new software or updates or
  1169.     modifies existing software, or issues a new release of software that
  1170.     supports the GIF file format.
  1171.  
  1172.  3) Unisys does not require licensing of non-commercial, not-for-profit
  1173.     software applications that support the GIF file format.
  1174.  
  1175.  4) With respect to TIFF, if a license is entered before July 1, 1995, 
  1176.     there will be no liability for pre-1995 software with respect to
  1177.     that software's support of TIFF which uses LZW.
  1178.  
  1179. Unisys has drafted licenses for several different applications of the LZW
  1180. algorithm. The two license agreements of most interest in this FAQ are
  1181. applicable to software supporting the GIF file format alone and the
  1182. agreement applicable to software supporting both GIF and the TIFF file
  1183. format's LZW compression feature.
  1184.  
  1185.  
  1186. Realizing that you have many questions about GIF-LZW and TIFF-LZW
  1187. licensing, the remainder of this section is arranged in a Question/Answer
  1188. format to help convey information about this subject more clearly.
  1189.  
  1190. Q: Just what is this all about?
  1191. A: Unisys has asserted its claim to the ownership of the LZW compression 
  1192.    and decompression algorithm. If you wish to implement LZW in a software
  1193.    or firmware application, you must arrange to pay a small royalty to
  1194.    Unisys for every software package that you sell. You do this by applying
  1195.    to Unisys for an LZW license agreement for your software.
  1196.  
  1197. Q: What file formats are effected?
  1198. A: GIF, TIFF, PDF, and PostScript Level II. All of these formats use, or
  1199.    can use, LZW compression. For example, a TIFF or PostScript Level II
  1200.    file may or may not use the LZW algorithm to compress the data it
  1201.    contains. GIF files, and most PDF files, always store bitmap data that
  1202.    is compressed using LZW.
  1203.  
  1204. Q: How does this agreement affect my use of GIF and TIFF files?
  1205. A: It does not affect the ownership, transmission, or reception of GIF
  1206.    and TIFF-LZW files themselves. Only the software that performs 
  1207.    compression and/or decompression of GIF may be effected in any way
  1208.    by license agreements. You are free to store and transport GIF and
  1209.    TIFF-LZW files without fear of legalities or cost from the Unisys
  1210.    licenses provided that any compression and/or decompression on GIF
  1211.    files is performed by licensed software, or by software products
  1212.    delivered prior to 1995.
  1213.  
  1214. Q: Which agreement do I need?
  1215. A: If your software supports only GIF then you need the GIF-LZW agreement.
  1216.    If it supports TIFF-LZW or both GIF and TIFF-LZW then you need the 
  1217.    TIFF-LZW and GIF-LZW agreement.
  1218.  
  1219. Q: My software supports TIFF-LZW, but not GIF.
  1220. A: You still need to obtain the TIFF-LZW and GIF-LZW agreement.
  1221.  
  1222. Q: So if my software only supports non-LZW versions of TIFF and PostScript
  1223.    Level II I don't need to worry about obtaining a license agreement?
  1224. A: That is correct. Only software that is capable of using the LZW 
  1225.    algorithm requires an agreement. This includes all software that 
  1226.    supports the GIF file format.
  1227.  
  1228. Q: What about file compression programs such as compress, PKZIP, zoo, and
  1229.    lha? Don't they use LZW too?
  1230.  
  1231. A: Most file compression programs use the LZ77 algorithm for compressing
  1232.    text. The LZ77 compression algorithms (and several of its
  1233.    derivatives) predates LZW by several years and is covered by its own
  1234.    series of patents.  The predecessor to LZW, LZ78, is used primarily
  1235.    for compressing binary data and bitmaps. Any software that uses the
  1236.    LZ77 and/or LZ78 algorithms without the LZW improvement is not
  1237.    affected by the Unisys LZW patent.  Of the mentioned software
  1238.    packages, the Unix compress utility does use LZW and therefore
  1239.    requires a license.
  1240.  
  1241. Q: Doesn't IBM also hold a patent on LZW?
  1242. A: IBM was granted a patent (4,814,746) for use of LZW in disk drive 
  1243.    technology. This patent does not award ownership of LZW to IBM.
  1244.  
  1245. Q: Is there a chance that the Unisys patent is actually invalid?
  1246. A: In 1994, the U.S Patent Office reexamined the Welch patent and, on
  1247.    January 4th of that year, not only confirmed the patentability of the
  1248.    original 181 patent claims, but also confirmed that 51 claims added
  1249.    during the reexamination were also patentable.
  1250.  
  1251. Q: I have heard that the Welch patent only covers LZW compression and 
  1252.    not decompression. Is this true?
  1253. A: Many people who have read the patent claim that this is true. Unisys,
  1254.    of course, strongly maintains that the patent does cover LZW decompression,
  1255.    and will pursue legal action against unlicensed software which only
  1256.    performs LZW decompression. It is not clear (to the author of this text)
  1257.    if the 1994 patent reexamination specifically asserted the existence
  1258.    of the description of LZW decompression in the original Welch patent.
  1259.  
  1260. Q: But you can't patent a mathematical abstraction. Doesn't this also
  1261.    include algorithms implemented as computer software?
  1262. A: A patent grants the exclusive rights, title, or license to produce,
  1263.    use, or sell an invention or process. One or more algorithms may be
  1264.    applied using software to create an invention. It is this invention
  1265.    whose use is restricted by the patent and not the algorithm(s) involved.
  1266.    In the case of software, it seems that it is not very easy to separate
  1267.    the algorithm(s) from the invention itself. Use of the algorithm(s)
  1268.    would seem to imply use of the invention as well.
  1269.  
  1270. Q: I use LZW in my programs, but not for GIF or TIFF graphics. What should
  1271.    I do?
  1272. A: If you are not a business, and the programs are for your own personal
  1273.    non-commercial or not-for-profit use, Unisys does not require you to 
  1274.    obtain a license. If they are used as part of a business and/or you
  1275.    sell the programs for commercial or for-profit purposes, then you must
  1276.    contact the Welch Patent Licensing Department at Unisys and explain your 
  1277.    circumstances. They will have a license agreement for your application
  1278.    of their LZW algorithm.
  1279.  
  1280. Q: Where can I apply for a GIF-LZW, TIFF-LZW and GIF-LZW, PDF, PostScript 
  1281.    Level II, or any other LZW license?
  1282. A: You can write to:
  1283.  
  1284.      Welch Patent Licensing Department
  1285.      Unisys Corporation 
  1286.      Mail Stop C1SW19
  1287.      P.O. Box 500
  1288.      Blue Bell, PA 19424 USA
  1289.  
  1290.    Or fax:    215.986.3090
  1291.  
  1292.    Or email:  lzw_info@unisys.com
  1293.  
  1294.    General licensing information may also be obtained from the home page
  1295.    of the Unisys Web Server:
  1296.  
  1297.      http://www.unisys.com/
  1298.      http://www.unisys.com/ServerInformation/contact/contact.html
  1299.      http://www.unisys.com/LeadStory/lzwfaq.html
  1300.  
  1301. Q: How much does a license cost?
  1302. A: The terms and cost of the license policy has changed since its
  1303.    introduction in 1995. Contact Unisys for the latest LZW licensing terms.
  1304.  
  1305. Q: Do I need a separate license for each GIF-using software product I sell?
  1306. A: If you sell three products that all use the GIF format, for example,
  1307.    then you will need only one license. License fees must be paid for
  1308.    each product sold.
  1309.  
  1310. Q: Do I need to obtain a new license if I release a new version of my
  1311.    software?
  1312. A: No. However, a license fee is required for each update, improvement,
  1313.    or enhancement of your software that is sold.
  1314.  
  1315. Q: What if I give my software away?
  1316. A: If you distribute for free your product directly to end-users for their
  1317.    personal use and your distributing the software is non-commercial and
  1318.    not-for-profit use and you receive no financial gain (such as Shareware
  1319.    donations, royalties for CD-ROM distributions, or as advertising to 
  1320.    attract for-profit business), then you do not need a license.
  1321.  
  1322. Q: But what about Shareware donations?
  1323. A: Each Shareware "payment" you receive is considered the selling price of
  1324.    that unit. Whatever a user pays to you for your GIF-using software is
  1325.    required to be included in your quarterly license fee payment to Unisys.
  1326.    However, minimum license fees per unit must be always paid.
  1327.  
  1328. Q: My Shareware GIF software is being sold for-profit on a CD-ROM, but I do
  1329.    not make any profit from its sale. Can I get in trouble? Do I need a 
  1330.    license?
  1331. A: The person/business that is selling your program for profit on their
  1332.    CD-ROM is responsible for obtaining the proper license. You would only
  1333.    need a license if you received any payments from the CD-ROM vendor or
  1334.    from users of your Shareware.
  1335.  
  1336. Q: I do not live in the United States and my software is not available
  1337.    there. Do I still need to obtain a license agreement?
  1338. A: Yes, you do. The Unisys patent has many foreign counterparts and the
  1339.    legalities of using LZW apply to most other countries in addition
  1340.    the US.
  1341.  
  1342. Q: What will happen to me if I continue to revise my GIF-using software,
  1343.    sell it for profit, and yet not bother to obtain a license?
  1344. A: Most likely, when your unlicensed program is discovered by Unisys,
  1345.    you will be notified of your need to obtain a license for your product.
  1346.    If you then fail to obtain the proper license, Unisys may seek an 
  1347.    injunction against your product including damages. You could also be 
  1348.    charged with willful infringement, which could result in treble damages.
  1349.  
  1350. Q: On what Usenet newsgroups is this LZW agreement being discussed?
  1351. A: You will find threads appearing on comp.graphics.misc and other related
  1352.    graphical newsgroups. The official newsgroup where much discussion
  1353.    takes place is alt.gif-agreement. You might also find information on
  1354.    the misc.legal.computing, misc.int-property, and comp.patents newsgroups.
  1355.  
  1356. Q: Where can I get a copy of the Unisys patent?
  1357. A: Copies of patents may be found in public libraries or be obtained
  1358.    directly from the U.S. Patent Office. The patent is also available
  1359.    at many Internet sites, including:
  1360.  
  1361.      ftp://ftp.std.com/obi/USPatents/lzw-patent.Z
  1362.      ftp://ftp.uu.net/doc/literary/obi/USPatents/lzw-patent.Z
  1363.  
  1364. Q: What are my alternatives to GIF and TIFF-LZW file formats?
  1365. A: A good alternative to LZW for compressing ASCII data is the LZ77
  1366.    algorithm used by the zip and PKZIP file archivers and the gzip
  1367.    (GNU zip) file compression program. The most popular alternative for
  1368.    multi-bit image data is the JPEG compression algorithm and the JFIF
  1369.    and SPIFF file formats. JFIF and SPIFF-JPEG files are smaller and
  1370.    store far more colors than GIF files.
  1371.  
  1372.    Another newer alternative is the PNG format, which is currently under
  1373.    development (see the section "PNG - Portable Network Graphics" in
  1374.    Part 3 of this FAQ). PNG is unencumbered by patent licenses and has
  1375.    much potential and promise in replacing GIF. But, most software that
  1376.    supports PNG will likely have been written after January 1, 1995, so
  1377.    make sure that your GIF-to-PNG conversion program has the proper
  1378.    Unisys license.
  1379.  
  1380. Q: Will Unisys' actions hurt the use of GIF?
  1381. A: Yes it will. People will continue to write software that supports GIF
  1382.    only if their customers demand it. The licensing will hasten the
  1383.    eventual demise of GIF, as both people and companies will be more
  1384.    motivated to standardize on "free" formats, such as JFIF, SPIFF, PNG, 
  1385.    BMP, and TGA.
  1386.  
  1387. Q: This agreement is bogus! I refuse to ever use GIF again!
  1388. A: As an end-user you are free never to read, write, or archive another
  1389.    LZW-encoded file as long as you live. As a developer you are only
  1390.    free of the legal implications of the Unisys patent if you remove any
  1391.    LZW code from your programs, including those shipped to your customers
  1392.    after 1994.
  1393.  
  1394. Q: Wait! I have more questions!
  1395. A: Contact the Welch Patent Licensing Department at the aforementioned
  1396.    addresses. I (the author of this FAQ) am not an employee nor legal
  1397.    representative of Unisys. You can also find this information on the
  1398.    Unisys web page:
  1399.  
  1400.    http://www.unisys.com/LeadStory/lzwfaq.html
  1401.  
  1402.    And in the following InfoWorld article:
  1403.  
  1404.    "Graphics file format patent Unisys seeks royalties from GIF developers",
  1405.    Karen Rodriguez, InfoWorld, Jan 09, 1995 (Vol.17, Issue 02, p3)
  1406.  
  1407.    And the following Web pages are devoted to this issue:
  1408.  
  1409.    http://www.lpf.org/Patents/Gif/unisys.html
  1410.    http://www.lpf.org/Patents/Gif/Gif.html
  1411.    http://www-cmpo.mit.edu/met_links/resources/LZW_patent.html
  1412.    http://www.webhaven.com/izivkov/scanfax/GIF.HTM
  1413.    http://rom.oit.gatech.edu/~willday/gif.html
  1414.  
  1415. Disclaimer: The information in this FAQ regarding the Unisys LZW
  1416. licensing agreement has been presented in an attempt to allow the
  1417. reader to understand some of the legalities they may face by the use
  1418. of the LZW algorithm. The author has rendered this explanation and
  1419. example questions using the most accurate information available to
  1420. him at the date of this FAQ. In no regard should this text be
  1421. considered an official publication of Unisys Corporation or a legal
  1422. representation of the policies of Unisys, or in any way obligating
  1423. Unisys to enter into a license agreement based upon the terms,
  1424. interpretations, and/or answers to question provided in this text.
  1425.  
  1426. ------------------------------
  1427.  
  1428. Subject: V. Graphics Formats Misnomers, Misgivings, and Miscellany
  1429.  
  1430. ------------------------------
  1431.  
  1432. ubject: 0. Why aren't JPEG, MPEG, LZW, and CCITT Group 3 & 4 file formats?
  1433.  
  1434. One of the most commonly confused concepts found in file formats is the
  1435. difference between the file format and the method(s) of data encoding that
  1436. has been used to reduce the size of the data the file contains. JPEG,
  1437. MPEG, LZW, and CCITT are all algorithms, or algorithm toolkits, which
  1438. encode a stream of data to a physically smaller size. None of these data
  1439. compression methods define a specific format used to store data. 
  1440.  
  1441. Several formats have become popular based on their use of one or more of
  1442. these methods of compression, such as GIF (LZW), JFIF (JPEG), and TIFF
  1443. (CCITT Group 3 and Group 4). So if you ask for a "CCITT Group 3" image
  1444. file you will most likely get a file containing only CCITT Group 3 data
  1445. and not a TIFF file containing bitmapped data compressed using the CCITT
  1446. Group 3 algorithm, which might have been what you were expecting.
  1447.  
  1448. ------------------------------
  1449.  
  1450. ubject: 1. Why aren't IGES, GKS, NAPLPS, PCL, and HPGL file formats either?
  1451.  
  1452. IGES (Initial Graphics Exchange Specification), GKS (Graphics Kernel
  1453. System), NAPLPS (North American Presentation Layer Protocol Syntax),
  1454. Xerox Sixel, DEC ReGIS, and Tecktronix vector graphics are not
  1455. actually file formats. They are instead protocols which specify how
  1456. text and graphical data should be transmitted over a communications
  1457. link (such as a serial cable or telephone line) to a remote device
  1458. (such as a graphical workstation). 
  1459.  
  1460. The X protocol is used by X Window System clients and servers to
  1461. communicatte over Ethernet. Although you can save X protocol-encoded
  1462. data to a file, this does not mean that there is an "X protocol file
  1463. format".
  1464.  
  1465. HPGL (Hewlett-Packard Graphics Language) and PCL (Printer Control
  1466. Language) are data stream definition standards used to transfer and 
  1467. manipulate data used by printers and plotters.
  1468.  
  1469. In most cases, each of these protocols define a previously existing
  1470. file format, such as CGM or JFIF, to be the actual format used to
  1471. store the graphics data (CGM and PCL use a raw or compressed bitmap).
  1472. Occasionally the transmitted data stream may be stored to a file for
  1473. buffering or archival purposes. This file is then often identified as
  1474. using the "{IGES,GKS,NAPLPS,PCL,HPGL} file format".
  1475.  
  1476. Descriptions of each of these standards may be found in Part 3 (Where
  1477. to Get File Format Specifications) of this FAQ. For more information
  1478. on graphical protocols, have a look at the following:
  1479.  
  1480.   http://www.cs.utk.edu/~shuford/terminal_index.html
  1481.     Video Terminal Information
  1482.  
  1483.  
  1484. ------------------------------
  1485.  
  1486. ubject: 2. Is it "Tag" or "Tagged" Image File Format?
  1487.  
  1488. Revision 5.0 of TIFF specification specifically states the acronym "TIFF"
  1489. is "Tag Image File Format". The majority of people, however, intuitively
  1490. say "Tagged" rather than "Tag". Interestingly enough, the TIFF 6.0
  1491. specification does not spell out the acronym TIFF.
  1492.  
  1493. ------------------------------
  1494.  
  1495. ubject: 3. Whaddya mean there's no "Targa" file format?
  1496.  
  1497. The popular "Targa" file format is really the "TGA format". "Targa" is the
  1498. name of the Truevision graphics display adapter which first used the TGA
  1499. format. Specifically, Revision 1.0 of TGA is designated the "Original TGA
  1500. format" and Revision 2.0 is the "New TGA Format".
  1501.  
  1502. ------------------------------
  1503.  
  1504. ubject: 4. Choosy programmers choose "gif" or "jif"?
  1505.  
  1506. The pronunciation of "GIF" is specified in the GIF specification to be
  1507. "jif", as in "jiffy", rather then "gif", which most people seem to prefer.
  1508. This does seem strange because the "G" is from the word "Graphics" and not
  1509. "Jraphics".
  1510.  
  1511. ------------------------------
  1512.  
  1513. ubject: 5. Why are there so many ".PIC" and ".IMG" formats?
  1514.  
  1515. Because people with very little imagination are allowed to choose file
  1516. extensions for graphics files, that's why.
  1517.  
  1518. But seriously, there does seem to be a proliferation of file formats with
  1519. the file extension ".PIC" (for "picture") and ".IMG" (for "image"). Other
  1520. popular extensions (in both upper and lower case) are ".RGB", ".RAW",
  1521. ".ASC", and ".MAP".
  1522.  
  1523. My advise to you is never assume the format of a data file based only on
  1524. its file extension. The name and the extension of any file are completely
  1525. arbitrary and therefore could be anything. This is why the most graphics
  1526. file conversion and display programs attempt to recognize graphics files
  1527. based on their internal structure and not their file name or extension.
  1528.  
  1529. ------------------------------
  1530.  
  1531. ubject: 6. Where can I get the spec for the GIF24 format?
  1532.  
  1533. A GIF24 standard file format has never been officially introduced or
  1534. released to the public. The original effort by CompuServe and others, 
  1535. to create a 24-bit revision of the GIF format was never completed.
  1536. The problems create by Unisys' LZW patent restrictions and the subsequent
  1537. disdainment of GIF by many developers is probably mostly to blame.
  1538.  
  1539. It has been said that CompuServe abandoned GIF24 in favor of PNG
  1540. format, who developers hope that one day will completely replace GIF. 
  1541. But it is not evident that CompuServe contributes in any remarkable way 
  1542. to the ongoing development of PNG.
  1543.  
  1544. ------------------------------
  1545.  
  1546. ubject: 7. Is there an uncompressed GIF format?
  1547.  
  1548. Realizing that the heart of the GIF patent controversy is the LZW 
  1549. data compression algorithm itself, you may ask if there is a raw or
  1550. uncompressed version of GIF that can be read and written without
  1551. using the LZW alogrithm. Officially, the answer is no.
  1552.  
  1553. The GIF specification does not defined a way to store uncompressed
  1554. bitmap data. All bitmap data stored in a GIF file is compressed using
  1555. the LZW algorithm. If you did write a program that stored
  1556. uncompressed data using the GIF format, no other GIF reader would be
  1557. able to decode the GIF files it created.
  1558.  
  1559. So is there a way to modify the compressed data in a GIF file so it is 
  1560. no longer in a format described by the LZW patent, but still readable
  1561. by GIF decoders? They answer to this is yes!
  1562.  
  1563. When a GIF file is compressed, an initial LZW code table is created
  1564. based on the bit-depth of the raw image data being LZW-encoded. For
  1565. example, a bitmap with 4-bit pixels will be encoded with an LZW code
  1566. table initially containing 18 entries: 16 color indicies ranging from
  1567. 00000 to 01111, a clear code (10000), and a end-of-data code (10001).
  1568.  
  1569. As LZW encoding proceedes, color codes from the data are used to form
  1570. new table entries, and its the formation of these new entries that is
  1571. the heart of LZW encoding. If an encoder only used the initial table
  1572. and did not create any new table entry codes, then all of the
  1573. resulting encoded data will be codes representing the indicies of the
  1574. colors stored the in the GIF file's active color table.
  1575.  
  1576. This process is explained in a post made to comp.graphics.misc by
  1577. Dr. Tom Lane on 05 Dec 1996:
  1578.  
  1579.     ...the idea is to emit only single-symbol string codes, plus a Clear
  1580.     code every so often to keep the decoder from jacking up the code
  1581.     width. In this mode your encoder is simply packing N-bit pixel
  1582.     values into N+1-bit fields and keeping count; nothing patentable
  1583.     there. Note that the data is not merely not compressed, it's
  1584.     *expanded*: you need 9 bits per pixel for an 8-bit GIF. I wouldn't
  1585.     care to use this trick for low-depth data. The worst case is for
  1586.     1-bit (black and white) data; not only do you need 2 bits/pixel, but
  1587.     every other symbol has to be a Clear to keep the code width down to 2
  1588.     bits ... net result, 4:1 expansion.
  1589.  
  1590. Because this encoder ends up storing N+1 bits for every N bits of
  1591. data, plus a clear code every 2^N-2 codes, an 8-bit "non-compressed"
  1592. GIF image will be 1/8th larger than the same bitmap stored as an
  1593. LZW-compressed GIF.
  1594.  
  1595. Tom explained this a few days later:
  1596.  
  1597.     Note, however, that you have to insert "clear" codes often enough to
  1598.     prevent the decoder from ratcheting up the symbol width, or else
  1599.     keep track of what the current symbol width should be.  It's been a
  1600.     while since I looked at this in detail, but I think you need a clear
  1601.     every 2^N-2 codes, where N is the underlying data depth, if you want
  1602.     the symbol width to stay at N+1 bits.
  1603.  
  1604. [Note: Thanks to Tom Lane of the Independant JPEG Group and Neil
  1605. Aggarwal of Bellcore for provising the Usenet discussion that
  1606. contained this material]
  1607. ------------------------------
  1608.  
  1609. Subject: VI. Graphics File Resources
  1610.  
  1611. ------------------------------
  1612.  
  1613. ubject: 0. File Format Specifications FTP Archives and WWW Pages
  1614.  
  1615. The following anonymous FTP and WWW sites are known to archive file format
  1616. specifications and information. These documents may be official releases
  1617. of specifications by the creator/caretaker of the formats, or information
  1618. transcribed by people from various sources and released onto the net,
  1619. possibly without permission from the format's owner.
  1620.  
  1621.   ftp://avalon.viewpoint.com/pub/format_specs
  1622.   ftp://ftp.cc.monash.edu.au/pub/graphics.formats
  1623.   ftp://ftp.ncsa.uiuc.edu/misc/file.formats/graphics.formats
  1624.   ftp://ftp.std.com/obi/Standards/Graphics/Formats
  1625.   ftp://ftp.switch.ch/mirror/simtel/msdos/graphics/
  1626.   ftp://ftp.uu.net/doc/literary/obi/Standards/Graphics/Formats
  1627.   ftp://ftp.wustl.edu/doc/graphic-formats
  1628.   ftp://mirrors.aol.com/pub/pc_games/programming/formats
  1629.   ftp://peipa.essex.ac.uk/ipa/info/file.formats
  1630.   ftp://titan.cs.rice.edu/pubic/graphics/graphics.formats
  1631.   ftp://wuarchive.wustl.edu/graphics/graphics/mirrors/avalon/format_specs
  1632.   ftp://x2ftp.oulu.fi/pub/msdos/programming/formats
  1633.  
  1634.   http://ac.dal.ca/~dong/appen.html
  1635.   http://dao.gsfc.nasa.gov/data_stuff/dataFormats.html
  1636.   http://erau.db.erau.edu/~gonzalec/html/image.html
  1637.   http://killy.shinshu-u.ac.jp/mawatar/dv/develop.html
  1638.   http://sckb.ucssc.indiana.edu/kb/data/aamt.html
  1639.   http://speckle.ncsl.nist.gov/~lst/cgm_std.htm
  1640.   http://sslab.colorado.edu:2222/datastandards.html
  1641.   http://topaz.sensor.com/work/fmt/
  1642.   http://www.agocg.ac.uk:8080/agocg/cgm.html
  1643.   http://www.cica.indiana.edu/graphics/3D.objects.html
  1644.   http://www.cica.indiana.edu/graphics/image.formats.html
  1645.   http://www.dcs.ed.ac.uk/~mxr/gfx
  1646.   http://www.echo.lu/impact/oii/raster.html
  1647.   http://www.hq.nasa.gov/office/oss/aisr/results/formats.html
  1648.   http://www.matisse.net/files/formats.html
  1649.   http://www.mcad.edu/guests/ericb/xplat.html
  1650.   http://www.mediatel.lu/mmedia/render/h_formats.html
  1651.   http://www.myo.inst.keio.ac.jp/FAQ/formats/image-formats.html
  1652.   http://www.pi.net/~ayr/filefor1.htm
  1653.   http://www.ru/gisa/english/cssitr/format/
  1654.   http://www.soften.ktu.lt/~marius/graphics.html
  1655.   http://www.tnt.uni-hannover.de/data/info/www/tnt/soft/sci/sig/image/fileformats/overview.html
  1656.   http://www.tnt.uni-hannover.de/data/info/www/tnt/soft/sci/vis/compgraph/fileformats/overview.html
  1657.   http://www.w3.org/hypertext/WWW/Graphics/Overview.html
  1658.   http://www-ocean.tamu.edu/~baum/graphics-formats.html
  1659.  
  1660. ------------------------------
  1661.  
  1662. ubject: 1. Graphics and Image File FTP Archives and WWW Pages
  1663.  
  1664. The following anonymous FTP sites are known to archive image, graphics,
  1665. and multimedia files and information:
  1666.  
  1667.   ftp://ames.arc.nasa.gov/pub/SPACE
  1668.     NASA/Ames Archives. Space images in GIF format.
  1669.  
  1670.   ftp://amiga.physik.unizh.ch/amiga/gfx/misc
  1671.     VistaPro graphics
  1672.  
  1673.   ftp://asterix.inescn.pt/pub/PC/flidemos
  1674.     FLI and FLC animations
  1675.  
  1676.   ftp://ftp.catt.ncsu.edu/pub/graphics
  1677.     FLIC and QuickTime movies and many GIF and JPG images
  1678.       
  1679.   ftp://ftp.cnam.fr/Fractals/anim
  1680.     Fractal animation files
  1681.  
  1682.   ftp://edcftp.cr.usgs.gov/pub/data/DEM/250
  1683.   ftp://edcftp.cr.usgs.gov/pub/data/DLG/{2M,100K}
  1684.     Digital Elevation Model (DEM) and Digital Line Graph (DLG) archives
  1685.  
  1686.   ftp://ftp.photodex.com/PNG/images
  1687.     PNG images
  1688.  
  1689.   ftp://ftp.povray.org/pub/povray/images
  1690.   ftp://ftp.povray.org/pub/povray/scenes
  1691.     GIF, JPEG, and POV scene files rendered using PovRAY
  1692.  
  1693.   ftp://ftp.sdsc.edu/pub/sdsc/images
  1694.   ftp://ftp.sdsc.edupub/sdsc/sound
  1695.     San Diego Supercomputer Center sound and image file archives
  1696.  
  1697.   ftp://ftp.sunet.se/pub/graphics
  1698.   ftp://ftp.sunet.se/pub/multimedia
  1699.     MPEG, JPEG, FLC, HDF, AF, VR, and GIF files.
  1700.     Also /pub/pictures and /pub/comics contain many images
  1701.  
  1702.   ftp://ftp.tcp.com/pub/anime
  1703.   ftp://ftp.tcp.com/pub/anime-manga/anim
  1704.     Animation and multimedia files in MPEG, QuickTime, AVI, and FLI formats
  1705.  
  1706.   ftp://ftp.netcom.com://pub/sjledet/illustrator/
  1707.     Adobe Illustrator resources and tips
  1708.  
  1709.   ftp://omicron.cs.unc.edu/pub/softlab/CHVRTD
  1710.     MRI and CT scan volume data of human anatomy
  1711.  
  1712.   ftp://photo1.si.edu/images
  1713.     Smithsonian Institution photoimage archives
  1714.  
  1715.   ftp://ftp.povray.org
  1716.     POV animation files
  1717.  
  1718.   ftp://src.doc.ic.ac.uk:/pub/packages/faces
  1719.     USENIX faces archive (contains thousands of different faces)
  1720.  
  1721.   ftp://ftp.uni-erlangen.de/pub/pictures/mpeg/LOCAL/RedsNightmare.tar
  1722.     Red's Nightmare (a ray-traced animation)
  1723.  
  1724.   ftp://ftp.univ-rennes1.fr/Images/ASTRO/anim
  1725.     Space animation files
  1726.  
  1727.   ftp://ftp.wustl.edu/pub/aminet/gfx/anim
  1728.     Various Amiga anims (also on other aminet sites)
  1729.  
  1730.   ftp://ftp.wustl.edu/multimedia/images/
  1731.     GIF and JPEG files
  1732.  
  1733.   ftp://nic.funet.fi/pub/graphics/misc/test-images/
  1734.     JBIG, CCITT, and other test images
  1735.  
  1736.   ftp://ftp.povray.org/pub/povray/Official/
  1737.     POV-Ray Hall Of Fame ray tracing graphics archive
  1738.  
  1739.   ftp://pubinfo.jpl.nasa.gov/images
  1740.     Space images in GIF format
  1741.  
  1742.   ftp://spectrum.xerox.com/pub/map/dem
  1743.   ftp://spectrum.xerox.compub/map/dlg
  1744.     Digital Elevation Model (DEM) and Digital Line Graph (DLG) archives
  1745.  
  1746.   ftp://src.doc.ic.ac.uk/gfx/misc
  1747.     Digital Elevation Model (DEM) and Digital Line Graph (DLG) archives
  1748.  
  1749.   ftp://sunsite.unc.edu/pub/multimedia/pictures
  1750.   ftp://sunsite.unc.edu/pub/multimedia/animation
  1751.     Graphics and MPEG file collection
  1752.  
  1753.   ftp://toybox.gsfc.nasa.gov/pub/images
  1754.     NASA images in GIF, JPEG, PostScript, Sun Raster, and X Bitmap formats
  1755.  
  1756. The following WWW sites are known to archive image, graphics, and
  1757. multimedia files:
  1758.  
  1759.   http://afrodite.lira.dist.unige.it/
  1760.     European Network of Excellence in Computer Vision
  1761.  
  1762.   http://archpropplan.auckland.ac.nz/People/Mat/gallery/animations.html
  1763.     Mat Carr's animations
  1764.  
  1765.   http://ccf.arc.nasa.gov/dx/
  1766.   http://ccf.arc.nasa.gov/galileo_probe/
  1767.     Galileo Mission to Jupiter Images
  1768.  
  1769.   http://www.cm.cf.ac.uk/Ray.Tracing/
  1770.     Links to many site with ray-traced graphics
  1771.  
  1772.   http://cui_www.unige.ch:80/OSG/MultimediaInfo/
  1773.     Index to Multimedia Information Resources
  1774.  
  1775.   http://found.cs.nyu.edu/
  1776.     NYU State Center for Advanced Technology
  1777.  
  1778.   http://fuzine.mt.cs.cmu.edu/im/informedia.html
  1779.     Informedia Digital Video Library Project
  1780.  
  1781.   http://jasper.ora.com:80/comp.fonts/Internet-Font-Archive/
  1782.     Internet Font Archive (IFA)
  1783.  
  1784.   http://mambo.ucsc.edu:80/psl/thant/thant.html
  1785.     Thant's Animation index
  1786.  
  1787.   http://netlab.itd.nrl.navy.mil/imaging.html
  1788.     Listings of imaging resources and archive sites
  1789.  
  1790.   http://www.povray.org/pub/povray/Official/
  1791.     POV-Ray Hall Of Fame ray tracing graphics archive
  1792.  
  1793.   http://scorch.doc.ic.ac.uk/~np2/multimedia/
  1794.  
  1795.   http://sunsite.unc.edu/louvre/about/tech.html
  1796.   http://mistral.enst.fr/louvre/about/tech.html
  1797.     WebLouvre - Using and troubleshooting the web
  1798.  
  1799.   http://the-tech.mit.edu/KPT/
  1800.     Kai's Power Tips and Tricks for Photoshop
  1801.  
  1802.   http://w3.eeb.ele.tue.nl/mpeg/index.html
  1803.     Various MPEG animations
  1804.  
  1805.   http://web.msi.umn.edu/WWW/SciVis/umnscivis.html
  1806.     Scientific visualization and graphics
  1807.  
  1808.   http://www.cs.purdue.edu/homes/gwp/dtp/dtp.html
  1809.     DTP Internet Jumplist. Links to many desktop publishing pages.
  1810.  
  1811.   http://www.cs.ubc.ca/nest/imager/imager.html
  1812.     MPEG animations done using hierarchical b-splines
  1813.  
  1814.   http://www.demon.co.uk/
  1815.     Demon Internet 
  1816.  
  1817.   http://www.dfrc.nasa.gov/PhotoServer/photoServer.html
  1818.     NASA Dryden Research Aircraft Photo Archive
  1819.  
  1820.   http://www.infomedia.com:8600
  1821.     Liquid Mercury's new WWW Site designed for "New Media" professionals.
  1822.     Current industry data and product profiles. Email: info@infomedia.com
  1823.  
  1824.   http://www.jpl.nasa.gov/galileo/
  1825.     Galileo Mission to Jupiter Images
  1826.  
  1827.   http://www.kodak.com/digitalImages/samples/samples.shtml
  1828.     Kodak Sample Digital Images archive
  1829.              
  1830.   http://www.kodak.com/digitalImaging/cyberScene/sites.shtml
  1831.     Kodak Image Archive Sites
  1832.  
  1833.   http://www.lightside.com/~dani/cgi/images-index.html
  1834.     3DWEB - World Wide Web site for 3D Computer Graphics
  1835.  
  1836.   http://www.picker.com/pgw
  1837.     Picker Graphic Workstations
  1838.  
  1839.   http://www.sd.tgs.com/~template
  1840.     Web3D - World Wide Web site for 3D Graphics
  1841.  
  1842.   http://www.seas.gwu.edu/faculty/musgrave/art_gallery.html
  1843.     A gallery collection of fractal artwork by Ken Musgrave
  1844.  
  1845.   http://www.state51.co.uk/state51/
  1846.     State51 Interactive Media
  1847.  
  1848.   http://www.viewpoint.com
  1849.     Large collection of 3D models
  1850.  
  1851.   http://www.webcity.co.jp/info/andoh/vrml/geom_trans.html
  1852.     VRML Repository
  1853.  
  1854.   http://www.wimsey.com/PhotoModeler/
  1855.     Many links to 3D Technology topics
  1856.  
  1857. ------------------------------
  1858.  
  1859. ubject: 2. Internet Mailing Lists for Graphics and Imaging
  1860.  
  1861. This section contains a listing of Internet mailing lists that often
  1862. contain discussions and information on graphics and image file formats.
  1863. Mailing lists are a good alternative form of communication for those
  1864. netters that do not have Usenet access.
  1865.  
  1866.   agocg-ip@mailbase.ac.uk
  1867.     Discussion of all aspects of image processing. To subscribe:
  1868.     send an email message to mailbase@mailbase.ac.uk with the body
  1869.     "join agocg-ip yourfirstname yourlastname".
  1870.  
  1871.   digvid-l@ucdavis.edu
  1872.     Discussion of digital video, mostly of the desktop variety.
  1873.     To subscribe: send an email message to listserv@ucdavis.edu
  1874.     with the body: "subscribe digvid-l yourfirstname yourlastname".
  1875.  
  1876.   geotiff@tazboy.jpl.nasa.gov.
  1877.     Discussion regarding the establishment of a set of TIFF tags for
  1878.     storing geographic map projection information, such as UTM zones,
  1879.     Lambert Standard parallels, etc. Participants include
  1880.     representatives from SPOT, Intergraph, ERDAS, ESRI, and USGS. To
  1881.     subscribe: send an email message to geotiff-request@tazboy.jpl.nasa.gov.
  1882.  
  1883.   graphuk@cs.man.ac.uk
  1884.     GraphUK mailing list. Discussion of graphics systems such as PHIGS 
  1885.     and GKS, and training in the area of graphics. To subscribe: send an
  1886.     email message to graphuk-request@cs.man.ac.uk with the body "subscribe
  1887.     graphuk".
  1888.  
  1889.   illstrtr-l@netcom.com
  1890.     Adobe Illustrator mailing list. Discussion of the Adobe Illustrator 
  1891.     application and issues related to its use. To subscribe: send an email
  1892.     message to listserv@netcom.com with the body "subscribe illstrtr-l".
  1893.  
  1894.   info-ei@spie.org
  1895.     SPIE's Electronic Imaging Listserver. Discussion of electronic imaging.
  1896.     To subscribe: send an email message to info-ei-request@spie.org with
  1897.     the body "SUBSCRIBE INFO-EI". A complete listing of SPIE's online
  1898.     services may be obtained by sending email to info-optolink-request@spie.org
  1899.     with the word HELP in the message body.
  1900.  
  1901.   lexicor@lexicor.com
  1902.     Discussion of Atari computer graphics, hardware, software, programming,
  1903.     and formats for graphics and animation (2D and 3D). To subscribe: send
  1904.     an email message to lexicor-list-request@lexicor.com with the body
  1905.     "subscribe youremailaddress".
  1906.  
  1907.   listserv@info.kodak.com
  1908.     Information on the Kodak Photo-CD format. To subscribe: send an
  1909.     email message to listserv@info.kodak.com with the body:
  1910.     "INFO PHOTO-CD".
  1911.  
  1912.   listserv@soils.umn.edu
  1913.     NIH image processing discussion. To subscribe: send an email message
  1914.     to listserv@soils.umn.edu with the body "subscribe nih-image 
  1915.     yourfirstname yourlastname". You may seach past messages of this list
  1916.     by using http://rsb.info.nih.gov/nih-image/faq.html#Searching
  1917.  
  1918.   medimage@polygraf
  1919.     Medical imaging discussion. To subscribe: send an email message
  1920.     to listserv%polygraf.bitnet@mitvma.mit.edu with the body
  1921.     "subscribe medimage".
  1922.  
  1923.   nucmed@uwovax.uwo.ca
  1924.     Nuclear medicine and medical imaging discussion. To subscribe: 
  1925.     send an email message to nucmed-request@uwovax.uwo.ca with the
  1926.     body "subscribe nucmed".
  1927.  
  1928.   PhotoForum@listserver.isc.rit.edu
  1929.     Photographic and imaging discussions of aesthetics, processes
  1930.     instructional strategies, techniques, criticism, equipment, history,
  1931.     electronic imaging, ethics, and educational topics. To subscribe: send
  1932.     an email message to LISTSERV@LISTSERVER.ISC.RIT.EDU with the body
  1933.     "SUBSCRIBE PhotoForum yourfirstname yourlastname".
  1934.  
  1935.   pixel@essex.ac.uk
  1936.     British Machine Vision Association newsletter for machine vision,
  1937.     image processing, pattern recognition, remote sensing, etc. To
  1938.     subscribe: send an email message to pixel-request@essex.ac.uk.
  1939.  
  1940.   png-list@dworkin.wustl.edu     
  1941.   png-announce@dworkin.wustl.edu 
  1942.   png-implement@dworkin.wustl.edu
  1943.     PNG file format mailing lists. These lists contain a general discussion
  1944.     of PNG, announcements related to PNG, and discussions regarding PNG
  1945.     PNG implementation. To subscribe: send an email message to
  1946.     png-list-request@dworkin.wustl.edu with "help" in the body.
  1947.  
  1948.   ximage@expo.lcs.mit.edu
  1949.     Discussion of image processing using The X Window System. To 
  1950.     subscribe send an email message to ximage-request@expo.lcs.mit.edu
  1951.     with the body "subscribe ximage".
  1952.  
  1953. ------------------------------
  1954.  
  1955. ubject: 3. Books on Graphics File Formats
  1956.  
  1957. This section contains bibliographical listing of books containing
  1958. information on graphics file formats and closely related topics. This list
  1959. is alphabetized by title and information on how to order each book is
  1960. included where known.
  1961.  
  1962. And check out http://www.books.com and http://www.amazon.com to search for books using the Web.
  1963.  
  1964.   3D Graphics File Formats : A Programmer's Reference, Keith Rule,
  1965.     Addison-Wesley, 1996, ISBN 0-201488-35-3.
  1966.  
  1967.   The AutoCAD Database Book, F.H. Jones and L. Martin, Ventana Press,
  1968.     ISBN 0-940087-04-9. Order: 919.490.0062 voice.
  1969.  
  1970.   Bit-mapped graphics (2nd ed.), Steve Rimmer, Windcrest/McGraw-Hill
  1971.     1993. 484 pages.
  1972.  
  1973.   Bitmapped Graphics Programming in C++, Marv Luse, Addison Wesley 
  1974.     1993. ISBN 0-201632-09-8, $37.95 softcover and disk.
  1975.  
  1976.   CGM and CGI: Metafile and Interface Standards for Computer 
  1977.     Graphics, David B. Arnold and Peter R. Bono, Springer-Verlag
  1978.     1988. ISBN 3-540-18950-5, 279 pages.
  1979.  
  1980.   The CGM Handbook, Lofton R. Henderson and Anne M. Mumford,
  1981.     Academic Press 1993. ISBN 0-12-510560-6, $59.95 hardcover, 
  1982.     446 pages.
  1983.  
  1984.   Encyclopedia of Graphics File Formats, James D. Murray and 
  1985.     William vanRyper, 2nd ed., O'Reilly & Associates Inc. 1996.
  1986.     ISBN 1-56592-161-5, $79.95 softcover, 1154 pages.
  1987.     Order: order@ora.com, 800.998.9938 voice, 707.829.014 fax.
  1988.     Visit http://www.ora.com/www/item/gffcd.html for more information.
  1989.  
  1990.   File Formats for Popular PC Software: A Programmer's Reference,
  1991.     Walden, Jeff, John Wiley & Sons, Inc. 1986. ISBN 0-471-83671-0, 
  1992.     287 pages.
  1993.  
  1994.   File Formats on the Internet: A Guide for PC Users, Allison B. Zhang,
  1995.     Special Libraries Assn., 1996, ISBN: 0-871114-41-0.
  1996.  
  1997.   File Format Handbook, Allen G. Taylor, Microtrend Books 1992.
  1998.  
  1999.   The File Format Handbook, Guenter Born, International Thomson Computer
  2000.     Press 1995. ISBN 1-850-32128-0, 1-85032-117-5, $79.95 hardcover,
  2001.     1274 pages. Order: sales@clbooks.com, http://www.clbooks.com
  2002.  
  2003.   Graphical Treasures on the Internet, Bridget Mintz Testa, AP Profesional.
  2004.     ISBN 0-12-685375-4, $29.95US softcover, 428 pages.
  2005.     Order: mailto:app@acad.com or http://www.apnet.com/approfessional
  2006.  
  2007.   Graphics File Formats (2nd ed.), David C. Kay and John R. Levine, 
  2008.     Windcrest Books/McGraw-Hill 1995. ISBN 0-07-034025-0, $26.95 
  2009.     softcover, 476 pages.
  2010.     Order: Tab Software Department, Blue Ridge Summit, PA 17294-0850.
  2011.  
  2012.   Graphics File Formats: Reference and Guide, C. Wayne Brown and 
  2013.     Barry J. Shepherd, Manning Publications 1994.
  2014.  
  2015.   The Graphic File Toolkit: Converting and Using Graphic Files,
  2016.     Steve Rimmer, Addison-Wesley, 1992. 335 pages.
  2017.  
  2018.   High-Resolution Graphics Display Systems, Jon Peddie,
  2019.     Windcrest Books/McGraw-Hill 1994. ISBN 0-8306-4292-7, 
  2020.     ISBN 0-8306-4291-9 $34.95 softcover
  2021.  
  2022.   Inside Windows File Formats, Tom Swan, Sams Publishing 1993.
  2023.     ISBN 0-672-30338-8 $24.95 softcover, 337 pages and 1 disk (3.5 in.).               
  2024.     Order: Sams Publishing, 2201 West 103rd Street, Indianapolis,
  2025.     IN 46290
  2026.  
  2027.   Internet File Formats, Tim Kientzle, The Coriolis Group 1995.
  2028.     ISBN 1-883577-56-X $39.99 softcover, 398 pages and one CD.
  2029.     Order: 7339 E. Acoma Drive, Suite 7, Scottsdale, AZ 85260.
  2030.     800.410.0192, 602.483.0192
  2031.  
  2032.   The Internet Voyeur, Jim Howard, Sybex, 1995. ISBN 0-7821-1655-8.
  2033.     369 pages, $19.99 softcover + PC/Windows disk. More info at
  2034.     http://infolane.com/infolane/deej/voyeur.html
  2035.  
  2036.   More File Formats for Popular PC Software: A Programmer's Reference,
  2037.     Jeff Walden, John Wiley and Sons 1987. 369 pages.
  2038.  
  2039.   Multimedia File Formats on the Internet: A Beginner's Guide for PC Users,
  2040.     Allison Zhang, Special Libraries Association 1995.
  2041.  
  2042.   PC File Formats & Conversions, Ralf Kussmann, Abacus 1990. 287 pages
  2043.     and 1 disk (5.25 in.).
  2044.     
  2045.   PC Graphics with GKS, P.R. Bono, J.L. Encarnacao and W.R. Herzner,
  2046.     Prentice-Hall 1990.
  2047.  
  2048.   PostScript Language Reference Manual, Adobe Systems Inc. (2nd ed.), 
  2049.     Ed Taft and Jeff Walden, Addison-Wesley 1990.
  2050.  
  2051.   The Programmer's PC Sourcebook, Thom Hogan, Microsoft Press, 1988.
  2052.  
  2053.   Programming for Graphics Files in C and C++, by John R. Levine, 
  2054.     John Wiley & Sons 1994. ISBN 0-471-59854-2, $29.95 softcover,
  2055.     494 pages. 
  2056.  
  2057.   Using Pcx Graphics Files: The Programmer's Definitive Guide to Pcx
  2058.     File Formats, Roger Stevens, Miller Freeman, 1996, ISBN 0-879304-32-4.
  2059.  
  2060.   Windows Undocumented File Formats: Working Inside Windows 3.X and Win 95,
  2061.     Pete Davis, Miller Freeman, 1997, ISBN 0879304375. 
  2062.  
  2063. ------------------------------
  2064.  
  2065. ubject: 4. Magazine Articles on Graphics File Formats
  2066.  
  2067. This section contains bibliographical listings of periodicals containing
  2068. information on graphics file formats. This list is alphabetized by title.
  2069.  
  2070.   .mrb and .shg File Formats, Windows/DOS Developer's Journal, Pete Davis,
  2071.     February 1994 (Vol 5, No 4), pp. 37-46.
  2072.  
  2073.   The BMP File Format, Dr. Dobb's Journal, Marv Luse, #219 September
  2074.     1994 (Vol 19, Issue 10), pp. 18-22.
  2075.  
  2076.   The BMP File Format: Part I, Dr. Dobb's Journal, David Charlap, #228
  2077.     March 1995 (Vol. 20, Issue 3).
  2078.  
  2079.   The BMP File Format: Part II, Dr. Dobb's Journal, David Charlap, #229
  2080.     April 1995 (Vol. 20, Issue 4).
  2081.  
  2082.   Inside the RIFF Specification, Dr. Dobb's Journal, Hamish Hubbard, #219
  2083.     September 1994 (Vol 19, Issue 10), pp. 38-45.
  2084.  
  2085.   PCX Graphics, C Users Journal, Ian Ashdown, Vol 9, Num 8, August 1991,
  2086.     pp. 89-96.
  2087.  
  2088.   PNG: The Portable Network Graphic Format, Dr. Dobb's Journal, 
  2089.     Lee Daniel Crocker, #232 July 1995 (Vol 20, Issue 7), pp. 36-44.
  2090.  
  2091.   Portable Network Graphics, Web Techniques, Paul Atzberger and 
  2092.     Andrew Zolli, Vol 1. Issue 9, December 1996, pp. 65-70.
  2093.  
  2094.   Printing PCX Files, C Gazette, Marv Luse, Vol 5, Num 2, Winter 1990-91,
  2095.     pp. 11-22.
  2096.  
  2097.   Reading GIF Files, Dr. Dobb's Journal, Wilson MacGyver Liaw, #227 
  2098.     February 1995 (Vol 20, Issue 2), pp. 56-60.
  2099.  
  2100.   SPIFF: Still Picture Interchange File Format, Dr. Dobb's Journal, 
  2101.     James D. Murray, #249 July 1996 (Vol 21, Issue 7), pp. 34-41.
  2102.      
  2103.   TIFF File Format, C Gazette, James Murray, Vol 5, Num 2, Winter 1990-91,
  2104.     pp. 27-42.
  2105.  
  2106.   Translating PCX Files, Dr. Dobb's Journal, K. Quirk, Vol 14, Num 8, 
  2107.     August 1989, pp. 30-36, 105-108.
  2108.  
  2109.   Working with PCX files, Microcornucopia, Number 42, July-August 1988,
  2110.     p. 42.
  2111.  
  2112. ------------------------------
  2113.  
  2114. Subject: VII. Kudos and Assertions
  2115.  
  2116. ------------------------------
  2117.  
  2118. ubject: 0. Acknowledgments
  2119.  
  2120. The following people have made this FAQ take just a little bit longer to
  2121. read since the last time you looked at it (blame them and not me):
  2122.  
  2123.   Bruce Garner <garner@tis.llnl.gov>
  2124.   Oliver Grau <grau@tnt.uni-hannover.de>
  2125.   John T. Grieggs <grieggs@netcom.com>
  2126.   Lee Kimmelman <lee.kimmelman@twwde.com>
  2127.   David Kuo <dkuo@dabulls.kodak.com>
  2128.   Tom Lane <tgl@netcom.com>
  2129.   Angus Montgomery <angus@cgl.citri.edu.au>
  2130.   Glen Ozymok <oz@ludwig.virtualprototypes.ca>
  2131.   Greg Roelofs <newt@uchicago.edu>
  2132.   Rsiw <rsiw@aol.com>
  2133.   Daniel Sears <sears@netcom.com>
  2134.   Marc Soucy <msoucy@imetric.qc.ca>
  2135.   Bjoern Stabell <bjoerns@acm.org>
  2136.   Mark T. Starr <StarrMT@po4.bb.unisys.com>
  2137.  
  2138. ------------------------------
  2139.  
  2140. ubject: 1. About The Author
  2141.  
  2142. The author of this FAQ, James D. Murray, lives in the City of Orange,
  2143. Orange County, California, USA. He is the co-author of the book
  2144. Encyclopedia of Graphics File Formats published by O'Reilly and
  2145. Associates, makes a living writing books for O'Reilly, writing
  2146. telecommuncations network management software in C++ and Visual Basic,
  2147. and may be reached as jdm@ora.com,
  2148. or via U.S. Snail at: P.O. Box 70, Orange, CA 92666-0070 USA.
  2149.  
  2150.  
  2151. ------------------------------
  2152.  
  2153. Subject: 2. Disclaimer
  2154.  
  2155. While every effort has been taken to insure the accuracy of the
  2156. information contained in this FAQ list compilation, the author and
  2157. contributors assume no responsibility for errors or omissions, or for
  2158. damages resulting from the use of the information contained herein.
  2159.  
  2160. ------------------------------
  2161.  
  2162. ubject: 3. Copyright Notice
  2163.  
  2164. This FAQ is Copyright 1994-96 by James D. Murray. This work may be
  2165. reproduced, in whole or in part, using any medium, including, but not
  2166. limited to, electronic transmission, CD-ROM, or published in print,
  2167. under the condition that this copyright notice remains intact.
  2168.  
  2169. ------------------------------
  2170.