home *** CD-ROM | disk | FTP | other *** search
/ PC Online 1996 December / PCO1296.ISO / filesbbs / content / compress.txt < prev    next >
Encoding:
Text File  |  1996-10-17  |  270.9 KB  |  5,943 lines
  1.  
  2. Article: 79060 in news.answers
  3. Path: Dortmund.Germany.EU.net!main.Germany.EU.net!EU.net!enews.sgi.com!news.mathworks.com!bloom-beacon.mit.edu!ai-lab!jloup
  4. From: gzip@prep.ai.mit.edu (Jean-loup Gailly)
  5. Newsgroups: comp.compression,comp.compression.research,news.answers,comp.answers
  6. Subject: comp.compression Frequently Asked Questions (part 1/3)
  7. Supersedes: <compr1_29jul96@prep.ai.mit.edu>
  8. Followup-To: comp.compression
  9. Date: 20 Aug 1996 23:27:35 GMT
  10. Organization: none
  11. Lines: 3274
  12. Approved: news-answers-request@mit.edu
  13. Distribution: world
  14. Expires: 15 Oct 1996 16:17:20 GMT
  15. Message-ID: <compr1_20aug96@prep.ai.mit.edu>
  16. Reply-To: gzip@prep.ai.mit.edu
  17. NNTP-Posting-Host: spiff.gnu.ai.mit.edu
  18. Summary: *** READ THIS BEFORE POSTING ***
  19. Keywords: data compression, FAQ
  20. Originator: jloup@spiff.gnu.ai.mit.edu
  21. Xref: Dortmund.Germany.EU.net comp.compression:28118 comp.compression.research:2194 news.answers:79060 comp.answers:20624
  22.  
  23. Archive-name: compression-faq/part1
  24. Last-modified: Aug 20th, 1996
  25.  
  26.         "I've already explained this once, but repetition is
  27.         the very soul of the net."        (from alt.config)
  28.  
  29. This file is part 1 of a set of Frequently Asked Questions (FAQ) for
  30. the groups comp.compression and comp.compression.research.  If you
  31. can't find part 2 or 3, see item 53 below. A copy of this FAQ is available
  32. by ftp in ftp://rtfm.mit.edu/pub/usenet/news.answers/compression-faq/
  33. files part1 to part3. This FAQ is also accessible in the World Wide Web at
  34. http://www.cs.ruu.nl/wais/html/na-dir/compression-faq/.html
  35.  
  36. Certain questions get asked time and again, and this is an attempt to
  37. reduce the bandwidth taken up by these posts and their associated
  38. replies.  If you have a question, *please* check this file before you
  39. post.  It may save a lot of peoples time.
  40.  
  41. If you have not already read the overall Usenet introductory material
  42. posted to "news.announce.newusers", please do. It is also available by
  43. ftp in ftp://garbo.uwasa.fi/pc/doc-net/usenews.zip (see item 2 below
  44. about .zip).
  45.  
  46. If you don't want to see this FAQ regularly, please add the subject
  47. line to your kill file.  If you don't know what a kill file is, get
  48. by ftp the file ftp://rtfm.mit.edu/pub/usenet/news.answers/killfile-faq
  49. If you have corrections or suggestions for this FAQ, send them to
  50. Jean-loup Gailly <gzip@prep.ai.mit.edu>.  Thank you.
  51.  
  52. Part 1 is oriented towards practical usage of compression programs.
  53. Part 2 is more intended for people who want to know how compression works.
  54. Part 3 is a long (but somewhat obsolete) list of image compression hardware.
  55.  
  56. Main changes relative to the previous version:
  57.  
  58. - fixed ftp locations of rar and tar for MSDOS [item 2]
  59. - major rewrite of item 9, which is now renamed as
  60.   "Compression of random data (WEB, Gilbert and others)"
  61. - new item 10 "Fake compression programs (OWS, WIC)"
  62. - new item 78 "The Burrows-Wheeler block sorting algorithm"
  63.  
  64. Contents
  65. ========
  66.  
  67. General questions:
  68.  
  69. [1]  What are these newsgroups about?
  70. [2]  What is this .xxx file type?
  71.      Where can I find the corresponding compression program?
  72. [3]  What is the latest pkzip version?
  73. [4]  What is an archiver?
  74. [5]  What is the best general purpose compression program?
  75. [7]  Which books should I read?
  76. [8]  What about patents on data compression algorithms?
  77. [9]  Compression of random data (WEB, Gilbert and others)
  78. [10] Fake compression programs (OWS, WIC)
  79. [11] What is the V.42bis standard?
  80. [12] I need source for the winners of the Dr Dobbs compression contest
  81. [13] I need source for arithmetic coding
  82.  
  83. Image and audio compression:
  84.  
  85. [15] Where can I get image compression programs?
  86. [16] What is the state of the art in lossless image compression?
  87. [17] What is the state of fractal compression?
  88. [18] I need specs and source for TIFF and CCITT group 4 Fax.
  89. [19] What is JPEG?
  90. [20] I am looking for source of an H.261/H.263 codec and MPEG
  91. [25] Fast DCT (Discrete Cosine Transform) algorithms
  92. [26] Are there algorithms and standards for audio compression?
  93.  
  94. Common problems:
  95.  
  96. [30] My archive is corrupted!
  97. [31] pkunzip reports a CRC error!
  98. [32] VMS zip is not compatible with pkzip!
  99. [33] I have a problem with Stacker or DoubleSpace!
  100.  
  101. Questions which do not really belong to comp.compression:
  102.  
  103. [50] What is this 'tar' compression program?
  104. [51] I need a CRC algorithm
  105. [52] What about those people who continue to ask frequently asked questions?
  106. [53] Where are FAQ lists archived?
  107. [54] I need specs for graphics formats
  108. [55] Where can I find Lenna and other images?
  109. [56] I am looking for a message digest algorithm
  110. [57] I have lost my password on a .zip file
  111.  
  112.  
  113. Part 2: (Long) introductions to data compression techniques
  114.  
  115. [70] Introduction to data compression (long)
  116.        Huffman and Related Compression Techniques
  117.        Arithmetic Coding
  118.        Substitutional Compressors
  119.           The LZ78 family of compressors
  120.           The LZ77 family of compressors
  121.  
  122. [71] Introduction to MPEG (long)
  123.        What is MPEG?
  124.        Does it have anything to do with JPEG?
  125.        Then what's JBIG and MHEG?
  126.        What has MPEG accomplished?
  127.        So how does MPEG I work?
  128.        What about the audio compression?
  129.        So how much does it compress?
  130.        What's phase II?
  131.        When will all this be finished?
  132.        How do I join MPEG?
  133.        How do I get the documents, like the MPEG I draft?
  134.  
  135. [72] What is wavelet theory?
  136. [73] What is the theoretical compression limit?
  137. [74] Introduction to JBIG
  138. [75] Introduction to JPEG
  139. [76] What is Vector Quantization?
  140. [77] Introduction to Fractal compression
  141. [78] The Burrows-Wheeler block sorting algorithm
  142.  
  143.  
  144. Part 3: (Long) list of image compression hardware
  145.  
  146. [85] Image compression hardware
  147. [99] Acknowledgments
  148.  
  149.  
  150. Search for "Subject: [#]" to get to question number # quickly. Some news
  151. readers can also take advantage of the message digest format used here.
  152.  
  153. If you know very little about data compression, read question 70 in
  154. part 2 first.
  155.  
  156. ------------------------------------------------------------------------------
  157.  
  158. Subject: [1] What are these newsgroups about?
  159.  
  160.  
  161. comp.compression is the place to discuss about data compression, both
  162. lossless (for text or data) and lossy (for images, sound, etc..).
  163. comp.compression.research was created later to provide a forum for
  164. current research on data compression and data compression algorithms;
  165. this group is now moderated. If you are not experienced in data compression,
  166. please post in comp.compression only.
  167.  
  168. An archive of this newsgroup since Oct 1993 is available in
  169. ftp://spib.rice.edu/pub/news/comp.compression/*
  170.  
  171. If you only want to find a particular compression program for a
  172. particular operating system, please read first this FAQ and the
  173. article "How to find sources" which is regularly posted in
  174. news.answers.
  175.  
  176. If you can't resist posting such a request, other groups are probably
  177. more appropriate (comp.binaries.ibm.pc.wanted, comp.os.msdos.apps,
  178. comp.sources.wanted, comp.sys.mac.wanted, comp.archives.msdos.d, comp.dsp,
  179. alt.graphics.pixutils). Please post your request in comp.compression
  180. only as a last resource.
  181.  
  182. If your question is about graphics only (no compression), please
  183. post to comp.graphics.misc, *after* reading the comp.graphics FAQ (see
  184. item 54 below). For some unknown reason, many questions about
  185. graphics are incorrectly posted to comp.compression.
  186. For questions related to audio compression, check also comp.dsp.
  187.  
  188. Please do not post any program in binary form to comp.compression.
  189. Very short sources can be posted, but long sources should be be posted
  190. to the specialized source groups, such as comp.sources.* or alt.sources.
  191. If the program is already available by ftp, just give the name of the
  192. ftp site and the full path name of the file.
  193.  
  194. As for any newsgroups, do not post the same message separately to
  195. comp.compression and comp.compression.research.
  196.  
  197. A collection of compression based information is provided at
  198. http://www.cs.waikato.ac.nz/~singlis/compression-pointers.html
  199.  
  200. ------------------------------------------------------------------------------
  201.  
  202. Subject: [2] What is this .xxx file type?
  203.              Where can I find the corresponding compression program?
  204.  
  205.  
  206. All the programs mentioned in this section are lossless.  For most
  207. programs, one US and one European ftp site are given.  (ftp.coast.net
  208. & garbo.uwasa.fi) Many other sites (in particular wuarchive.wustl.edu)
  209. have the same programs.
  210.  
  211. To keep this list to a reasonable size, many programs are not
  212. mentioned here. Additional information can be found in the file
  213. ftp://ftp.cso.uiuc.edu/pub/doc/pcnet/compression maintained by
  214. David Lemson (lemson@uiuc.edu). When several programs can handle
  215. the same archive format, only one of them is given. If you don't
  216. find a particular MSDOS archiver here, look also in
  217. ftp://ftp.cs.tu-berlin.de/pub/msdos/mirrors/ftp.elf.stuba.sk/pc/
  218.  
  219. Sources for additional lossless data compressors can be found in
  220.   ftp://garbo.uwasa.fi/pc/programming/lds_11.zip
  221.   ftp://ftp.coast.net/mirrors/SimTel/msdos/archivers/lz-comp2.zip
  222.   http://wwwvms.utexas.edu/~cbloom/index.html
  223.   ftp://ftp.imag.fr/pub/archive/compression/codecs/codecs.tgz
  224.   ftp://garbo.uwasa.fi/pc/turbopas/preskit2.zip (sources in Pascal)
  225.   ftp://ftp.cs.uiowa.edu/pub/jones/compress/ (Splay tree compression)
  226.  
  227. For Macintosh programs, look on ftp://sumex-aim.stanford.edu/info-mac
  228. For VM/CMS, look on ftp://vmd.cso.uiuc.edu/public.477
  229. For Atari, look on ftp://atari.archive.umich.edu
  230. For Amiga, look on ftp://ftp.wustl.edu/pub/aminet/
  231.  
  232. A general purpose lossless data compression library is available in
  233. ftp://ftp.uu.net/pub/archiving/zip/zlib/zlib-1.0.4.tar.gz or zlib104.zip;
  234. see http://quest.jpl.nasa.gov/zlib/ for more information.
  235.  
  236. If you don't know how to use ftp or don't have ftp access, read the
  237. article "How to find sources" which is regularly posted in news.answers.
  238.  
  239. If you can't find a program given below, it is likely that a newer
  240. version exists in the same directory. (Tell me <gzip@prep.ai.mit.edu>)
  241.  
  242. A very short description of the compression algorithm is given for
  243. most programs. For the meaning of LZ77, LZ78 and LZW, see question 70
  244. in part 2 of the FAQ.  If you are looking for the file format of a
  245. specific compression program, get the sources of the decompressor.
  246. For the format of uuencode, do "man 5 uuencode" on a Unix box.
  247.  
  248. ext:  produced by or read by
  249.  
  250. ..arc, .ark: arc, pkarc for MSDOS. (LZW algorithm)
  251.     ftp://wuarchive.wustl.edu/mirrors/msdos/starter/pk361.exe
  252.     ftp://garbo.uwasa.fi/pc/arcers/pk361.exe
  253.  
  254.       arc for Unix
  255.         ftp://wuarchive.wustl.edu/mirrors/misc/unix/arc521e.tar-z
  256.     ftp://garbo.uwasa.fi/unix/arcers/arc.tar.Z
  257.         Contact: Howard Chu <hyc@umix.cc.umich.edu>
  258.  
  259.       arc for VMS
  260.     ftp://wuarchive.wustl.edu/packages/compression/vax-vms/arc.exe
  261.  
  262.       for Mac
  263.     ftp://wuarchive.wustl.edu/systems/mac/info-mac/cmp/stuffit-expander-352.hqx
  264.  
  265.       arc for Amiga
  266.     ftp.funet.fi:pub/amiga/fish/001-100/ff070/arc.lha
  267.  
  268. ..arj: arj for MSDOS (LZ77 with hashing, plus secondary static Huffman
  269.           encoding on a block basis)
  270.         Contact: Robert K Jung <robjung@world.std.com>
  271.         ftp://ftp.coast.net/mirrors/SimTel/msdos/archiver/arj242b.exe
  272.     ftp://garbo.uwasa.fi/pc/arcers/arj250a.exe
  273.  
  274.       unarj for Unix. Decompresses only. (There is no arj compressor for Unix.
  275.         Don't post a request.)
  276.         ftp://wuarchive.wustl.edu/mirrors/misc/unix/unarj241.tar-z
  277.     ftp://garbo.uwasa.fi/unix/arcers/unarj241.tar.Z
  278.  
  279.       unarj for Mac
  280.         ftp://mac.archive.umich.edu/mac/util/compression/unarjmac.cpt.hqx      
  281.  
  282.       unarj for Amiga
  283.     ftp.funet.fi:pub/amiga/utilities/archivers/unarj-0.5.lha
  284.  
  285. base64 (MIME encoding): This is *not* a compression issue but it keeps
  286.        coming as a question on comp.compression. So:
  287.           ftp://ftp.andrew.cmu.edu/pub/mpack/mpack-1.5-src.tar.Z (source)
  288.           ftp://ftp.andrew.cmu.edu/pub/mpack/mpack15d.zip        (MSDOS exe)
  289.           ftp://wuarchive.wustl.edu/systems/mac/info-mac/cmp/mpack-15.hqx (Mac)
  290.  
  291. ..bck: VMS BACKUP. BACKUP is *not* a compression program. Do "help backup".
  292.  
  293. ..cpt: Compact Pro for Mac and Power PC
  294.          ftp://wuarchive.wustl.edu/systems/mac/info-mac/cmp/compact-pro-151.hqx
  295.  
  296.       For Unix:
  297.     ftp://sumex-aim.stanford.edu/info-mac/unix/macutil-20b1.shar
  298.         ftp://ftp.cwi.nl/pub/dik/macutil2.0b3.shar.Z
  299.  
  300.       For DOS:
  301.         ftp://ftp.scruz.net/users/aladdin/public/SITEX10.EXE
  302.     ftp://garbo.uwasa.fi/pc/arcers/ext-pc.zip
  303.  
  304. ..ddi:  files made by DiskDupe (Pro)
  305.      ftp://ftp.tem.nctu.edu.tw/Msdos/arcutil/unddi11u.zip
  306.      ftp://ftp.tem.nctu.edu.tw/Msdos/arcutil/x2file15.zip
  307.  
  308. ..exe: self-extracting MSDOS executable (creates files on disk when run)
  309.       Run the file, or try unzip, lha or arj on it.
  310.  
  311. ..exe: compressed MSDOS executable (decompresses itself in memory then runs
  312.       the decompressed code). To get the original uncompressed .exe:
  313.         ftp://garbo.uwasa.fi/pc/execomp/unp411.zip
  314.       To create such files:
  315.         ftp://ftp.coast.net/mirrors/SimTel/msdos/execomp/lzexe91e.zip
  316.     ftp://nic.funet.fi/pub/msdos/windows/util/winlite1.zip (for Windows)
  317.  
  318. ..gif: gif files are images compressed with the LZW algorithm. See the
  319.       comp.graphics FAQ list for programs manipulating .gif files. See
  320.       suffix .Z below for source of LZW.
  321.  
  322. ..gz, .z: gzip (or pack, see .z below). gzip uses the same algorithm as
  323.          zip 2.0x (see below); it can also extract packed and compressed files.
  324.     Contact: Jean-loup Gailly <gzip@prep.ai.mit.edu>
  325.                  http://www.teaser.fr/~jlgailly/
  326.  
  327.       For Unix, MSDOS, OS/2, VMS, Atari, Amiga, Primos:
  328.     ftp://prep.ai.mit.edu/pub/gnu/gzip-1.2.4.tar (.shar or .tar.gz: source)
  329.     ftp://prep.ai.mit.edu/pub/gnu/gzip-1.2.4.msdos.exe (MSDOS self-extract)
  330.     ftp://ftp.coast.net/mirrors/SimTel/msdos/compress/gzip124.zip (MSDOS)
  331.     ftp://garbo.uwasa.fi/unix/arcers/gzip-1.2.4.tar.Z       (source)
  332.     ftp://garbo.uwasa.fi/pc/unix/gzip124.zip                (MSDOS exe)
  333.     ftp://ftp.uu.net/pub/archiving/zip/WIN32/gzip124xN.zip  (WIN95 & NT)
  334.     ftp://ftp.uu.net/pub/archiving/zip/VMS/gzip124x.vax_exe (VMS exe)
  335.         ftp://ftp.uu.net/pub/archiving/zip/UNIX/SUN/gzip124x.tar.Z (Solaris 2)
  336.         ftp://quest.jpl.nasa.gov/beta/vmcms_mvs/gzip123-mvs.exe (MVS)
  337.  
  338.       For Mac:
  339.        ftp://ivo.cps.unizar.es//Graficos/Public/SPDsoft/MacGzip_FAT_1.0.cpt.hqx
  340.        http://persephone.cps.unizar.es/general/gente/spd/gzip/ (MacGzip page)
  341.  
  342. ..ha: ha 0.99 (improved PPMC - 4th order Markov modeling)
  343.     Contact: Harri Hirvola <harri.hirvola@vaisala.infonet.com>
  344.     ftp://garbo.uwasa.fi/pc/arcers/ha098.zip
  345.     ftp://ftp.nl.net/gopher/NLnet-connected/aipnl/ha0999.exe
  346.         ftp://sunsite.unc.edu/pub/Linux/utils/compress/ha0999p-linux.tar.gz
  347.  
  348. ..hap: Hamarsoft HAP archiver (Markov modeling + arithmetic coding)
  349.       Contact: feldmann@xs4all.nl or feldmann@pi.net
  350.         ftp://garbo.uwasa.fi/pc/arcers/hap305bp.com
  351.         http://www.xs4all.nl/~feldmann
  352.  
  353. ..hpk: hpack (archiver with strong encryption)
  354.       Contact: Peter Gutmann <pgut1@cs.aukuni.ac.nz>
  355.         ftp://src.doc.ic.ac.uk/computing/archiving/compress/hpack/
  356.  
  357. ..hqx: Macintosh BinHex format.. (BinHex is *not* a compression program,
  358.       it is similar to uuencode but handles multiple forks.)
  359.        for Mac:
  360.     ftp://mac.archive.umich.edu/mac/utilities/compressionapps/binhex4.0.bin
  361.  
  362.        for Unix:
  363.          ftp://sumex-aim.stanford.edu/info-mac/cmp/mcvert-216.shar
  364.  
  365.        for MSDOS:
  366.      ftp://ftp.coast.net/mirrors/SimTel/msdos/mac/xbin23.zip
  367.          ftp://garbo.uwasa.fi/pc/unix/xbin23.zip
  368.  
  369. ..jam: JAM real-time compressor for MSDOS
  370.        ftp://garbo.uwasa.fi/pc/arcers/jam125sw.zip
  371.        ftp://ftp.coast.net/mirrors/SimTel/msdos/archiver/jam125sw.zip
  372.  
  373. ..lha:
  374. ..lzh: lha for MSDOS (LZ77 with a trie data structure, plus secondary static
  375.           Huffman coding on a block basis)
  376.     ftp://ftp.coast.net/mirrors/SimTel/msdos/archiver/lha213.exe   (exe)
  377.     ftp://ftp.coast.net/mirrors/SimTel/msdos/archiver/lha211sr.zip (source)
  378.     ftp://garbo.uwasa.fi/pc/arcers/lha255b.exe
  379.  
  380.       lharc for Unix. (LZ77 with hash table and binary trees, plus secondary
  381.           Huffman coding)
  382.            Warning: lharc can extract .lzh files created by
  383.            lharc 1.xx but not those created by lha. See lha for Unix below.
  384.         ftp://wuarchive.wustl.edu/mirrors/misc/unix/lharc102a.tar-z
  385.     ftp://garbo.uwasa.fi/unix/arcers/lha101u.tar.Z
  386.  
  387.       lharc for VMS. Same warning as for Unix lharc.
  388.     ftp://wuarchive.wustl.edu/packages/compression/vax-vms/lharc.exe
  389.  
  390.       lha for Unix. Warning: all doc is in Japanese.
  391.     ftp://wuarchive.wustl.edu/mirrors/misc/unix/lha101u.tar-z
  392.     ftp://garbo.uwasa.fi/unix/arcers/lha-1.00.tar.Z
  393.           Contact: lha-admin@oki.co.jp or oki@fs.telcom.oki.ac.jp
  394.       lha for Mac
  395.     ftp://mac.archive.umich.edu/mac/utilities/compressionapps/maclha2.0.cpt.hqx
  396.       lha for Amiga
  397.     ftp://ftp.funet.fi/pub/amiga/utilities/archivers/LhA_e138.run
  398.       lha for OS/2:
  399.     ftp://hobbes.nmsu.edu/os2/16bit/archiver/lh2_222.zip
  400.  
  401. MIME: see base64 above
  402.  
  403. ..pak: pak for MSDOS (LZW algorithm)
  404.         ftp://wuarchive.wustl.edu/mirrors/msdos/archivers/pak251.exe
  405.     ftp://garbo.uwasa.fi/pc/arcers/pak251.exe
  406.  
  407. ..pit: PackIt (Macintosh)
  408.        for Mac:
  409.          ftp://sumex-aim.stanford.edu/info-mac/cmp/stuffit-lite-35.hqx
  410.  
  411.        for Unix:
  412.          ftp://sumex-aim.stanford.edu/info-mac/cmp/mcvert-215.shar.gz
  413.          ftp://garbo.uwasa.fi/mac/arcers/mcvert-215.shar
  414.  
  415. ..pp: PowerPacker (Amiga)
  416.     ftp.funet.fi:pub/amiga/fish/501-600/ff561/PPLib.lha
  417.  
  418. ..rar: RAR (MSDOS) Contact: Eugene_Roshal@p0.f23.n5010.z2.fidonet.org
  419.           or Andrey Spasibozhko <as@hq.icb.chel.su>
  420.         ftp://ftp.coast.net/mirrors/SimTel/msdos/archiver/rar155.exe
  421.         ftp://garbo.uwasa.fi/pc/arcers/rar200.exe
  422.         ftp://ftp.kiae.su/msdos/arcers/rar*.exe
  423.         ftp://ftp.elf.stuba.sk/pub/pc/pack/*rar2*.exe
  424.  
  425. ..sea: self-extracting archive (Macintosh)
  426.          Run the file to extract it. The self-extraction code can be
  427.          removed with:
  428.     ftp://mac.archive.umich.edu/mac/utilities/compressionapps/desea1.11.cpt.hqx
  429.     ftp://ftp.scruz.net/users/aladdin/public/SITEX10.EXE (MS Windows)
  430.  
  431. ..sdn: used by the Shareware Distribution Network.
  432.       Try the decompressors for .pak or .arj (see above)
  433.  
  434. ..shar:  Shell archive. This is not a compression program. Use "sh foo.shar"
  435.         to extract on Unix. For MSDOS, use:
  436.     ftp://garbo.uwasa.fi/pc/unix/unshar.zip
  437.  
  438. ..sit: Stuffit for Macintosh
  439.        for Mac:
  440.          ftp://sumex-aim.stanford.edu/info-mac/cmp/stuffit-lite-35.hqx
  441.  
  442.        for Unix:
  443.          ftp://sumex-aim.stanford.edu/info-mac/cmp/unsit-15-unix.shar
  444.  
  445.        for Amiga:
  446.      ftp.funet.fi:pub/amiga/utilities/archivers/unsit-1.5c2.lha
  447.  
  448.        for MSDOS:
  449.      ftp://ftp.scruz.net/users/aladdin/public/SITEX10.EXE
  450.      ftp://garbo.uwasa.fi/pc/arcers/unsit30.zip
  451.  
  452. ..?q?: Squeeze for MSDOS (do not confuse with other 'squeeze' below).
  453.       Static Huffman coding.
  454.        ftp://ftp.coast.net/mirrors/SimTel/msdos/starter/sqpc12a.com (squeeze)
  455.        ftp://ftp.coast.net/mirrors/SimTel/msdos/starter/nusq110.com (unsqueeze)
  456.  
  457. ..sqz: Squeeze for MSDOS (do not confuse with other 'squeeze' above)
  458.       LZ77 with hashing.
  459.     ftp://wuarchive.wustl.edu/mirrors/msdos/archivers/sqz1083e.exe
  460.         ftp://garbo.uwasa.fi/pc/arcers/sqz1083e.exe
  461.  
  462. ..tar: tar is *not* a compression program. However, to be kind for you:
  463.       for MSDOS
  464.     ftp://ftp.coast.net/mirrors/SimTel/msdos/starter/tarread.exe
  465.     ftp://garbo.uwasa.fi/pc/unix/tar4dos.zoo
  466.  
  467.       for Unix
  468.         tar (you have it already. To extract: tar xvf file.tar)
  469.  
  470.       for VMS
  471.     ftp://wuarchive.wustl.edu/packages/compression/vax-vms/tar.exe
  472.  
  473.       for Macintosh
  474.         ftp://sumex-aim.stanford.edu/info-mac/util/tar-30.hqx
  475.  
  476.       for Amiga:
  477.     ftp.funet.fi:pub/amiga/fish/401-500/ff445/Tar.lha
  478.  
  479. ..tar.Z, .tar-z, .taz: tar + compress
  480.       For Unix:     zcat file.tar.Z | tar xvf -
  481.       with GNU tar: tar xvzf file.tar.Z
  482.       for MSDOS:
  483.         ftp://garbo.uwasa.fi/pc/unix/tar320g.zip  (MSDOS exe)
  484.         ftp://ftp.kiae.su/msdos/arcers/tar*sr.zip (sources)
  485.         ftp://ftp.kiae.su/msdos/arcers/tar*_p.zip (MSDOS exe)
  486.       Other OS: first uncompress (see .Z below) then untar (see .tar above)
  487.  
  488. ..tar.gz, .tgz, .tar-gz, .tar.z: tar + gzip
  489.       For Unix: gzip -cd file.tar.gz | tar xvf -
  490.       with GNU tar: tar xvzf file.tar.gz
  491.       for MSDOS: ftp://ftp.coast.net/mirrors/SimTel/msdos/archiver/tar320c-.zip
  492.                  ftp://garbo.uwasa.fi/pc/unix/tar320g.zip
  493.       Other OS: first uncompress (see .gz above) then untar (see .tar above)
  494.  
  495. ..td0: (compressed MS-DOS floppy image produced by TeleDisk)
  496.       ftp://ftp.coast.net/mirrors/SimTel/msdos/diskutil/teled212.zip
  497.  
  498. ..uc2: UC2 for MSDOS and OS/2. (LZ77 with secondary static Huffman encoding on
  499.      a block basis, and dynamic dictionaries shared among files.)
  500.     Contact: desk@aip.nl
  501.       ftp://garbo.uwasa.fi/pc/arcers/uc2r3.exe  (or uc2pro.exe)
  502.  
  503. ..z:   pack or gzip (see .gz above). pack uses static Huffman coding.
  504.       To extract, see .gz above.
  505.  
  506. ..zip: pkzip 2.04g for MSDOS. (LZ77 with hashing, plus secondary static
  507.            Huffman coding on a block basis). Contact: support@pkware.com
  508.            or http://www.pkware.com/
  509.      ftp://ftp.coast.net/mirrors/SimTel/msdos/zip/pkz204g.exe
  510.          ftp://garbo.uwasa.fi/pc/arcers/pkz204g.exe
  511.          ftp://garbo.uwasa.fi/windows/util/pkzws201.exe (Windows version)
  512.  
  513.       arcutil 2.0 for VM/CMS (unzip only, not yet compatible with pkzip 2.04)
  514.          ftp://vmd.cso.uiuc.edu/public.477/arcutil.*
  515.  
  516.       zip 1.1 for Unix, MSDOS, VMS, OS/2, ... (compatible with pkzip 1.10.
  517.      For corresponding unzip, see unzip 5.12 below).
  518.      ftp://ftp.uu.net/pub/archiving/zip/zip11.zip
  519.  
  520.       zip 2.1 and unzip 5.20 for Unix, MSDOS, VMS, OS/2, Amiga, ...
  521.           Compatible with pkzip 2.04g (LZ77 with hashing, plus secondary static
  522.           Huffman coding on a block basis). Contact: zip-bugs@lists.wku.edu
  523.           See also http://quest.jpl.nasa.gov/Info-ZIP/
  524.           (On SGI, do not confuse with the editor also named 'zip'.)
  525.  
  526.      ftp://ftp.uu.net/pub/archiving/zip/zip21.zip          (source)
  527.      ftp://ftp.uu.net/pub/archiving/zip/unzip52.*          (source)
  528.      ftp://ftp.uu.net/pub/archiving/zip/MSDOS/zip21x.zip   (MSDOS exe)
  529.      ftp://ftp.uu.net/pub/archiving/zip/MSDOS/unz520x*.exe (MSDOS exe)
  530.      ftp://ftp.uu.net/pub/archiving/zip/WIN32/zip21xN.zip  (Win95 & NT)
  531.      ftp://ftp.uu.net/pub/archiving/zip/WIN32/unz520xN.exe (Win95 & NT)
  532.          [The Win95 version supports long file names; MSDOS version doesn't]
  533.      ftp://ftp.uu.net/pub/archiving/zip/OS2/*          (OS/2 exe 16&32 bit)
  534.           See also AMIGA, ATARI, MAC, UNIX, RISCOS, VMS... subdirectories.
  535.       If ftp.uu.net not available, use ftp://nic.switch.ch/mirror/Info-Zip/
  536.  
  537.      ftp://ftp.uu.net/pub/archiving/zip/zcrypt26.zip    (encryption source)
  538.          Non US residents must get the crypt versions from garbo:
  539.          ftp://garbo.uwasa.fi/unix/arcers/zcrypt*.zip       (encryption source)
  540.  
  541.        for Macintosh:
  542.          ftp://mac.archive.umich.edu/mac/util/compression/unzip2.01.cpt.hqx
  543.      ftp://mac.archive.umich.edu/mac/util/compression/zipit1.31.cpt.hqx
  544.      ftp://ftp.uu.net/pub/archiving/zip/MAC/unz512x.hqx
  545.     ftp://wuarchive.wustl.edu/systems/mac/info-mac/cmp/stuffit-expander-352.hqx
  546.  
  547.        WinZip by Nico Mak <support@winzip.com> (uses Info-ZIP compress. code):
  548.          ftp://ftp.winzip.com/winzip/                    (MS Windows)
  549.  
  550. ..zoo: zoo 2.10 for MSDOS (algorithm copied from that of lha, see lha above)
  551.       Contact: Rahul Dhesi <dhesi@cirrus.com>
  552.      ftp://wuarchive.wustl.edu/mirrors/msdos/zoo/zoo210.exe
  553.      ftp://garbo.uwasa.fi/pc/arcers/zoo210.exe
  554.  
  555.       zoo 2.10 for Unix, VMS
  556.          ftp://oak.oakland.edu/pub/misc/unix/zoo210.tar.Z
  557.      ftp://garbo.uwasa.fi/unix/arcers/zoo210.tar.Z
  558.  
  559.       zoo for Mac
  560.        ftp://mac.archive.umich.edu/mac/utilities/compressionapps/maczoo.sit.hqx
  561.  
  562.       zoo for Amiga
  563.     ftp://ftp.funet.fi/pub/amiga/utilities/archivers/Zoo-2.1.lha
  564.  
  565. ..??_: Microsoft compress.exe and expand.exe. compress.exe is available
  566.     in the Windows SDK (Software Development Kit) and in
  567.        ftp://ftp.microsoft.com/softlib/mslfiles/CP0982.EXE
  568.  
  569. ..F: freeze for Unix (LZ77 with hashing, plus secondary dynamic Huffman
  570.          encoding)
  571. ftp://wuarchive.wustl.edu/usenet/comp.sources.misc/volume35/freeze/part0[1-3].Z
  572.      ftp://ftp.inria.fr/system/arch-compr/freeze-2.5.tar.Z
  573.      Contact: Leonid A. Broukhis <leo@zycad.com>
  574.  
  575. ..Y: yabba for Unix, VMS, ... (Y coding, a variant of LZ78)
  576.   ftp://wuarchive.wustl.edu/usenet/comp.sources.unix/volume24/yabbawhap/part*.Z
  577.   ftp://ftp.inria.fr/system/arch-compr/yabba.tar.Z
  578.   Contact: Dan Bernstein <djb@silverton.berkeley.edu>
  579.  
  580. ..Z: compress for Unix ('the' LZW algorithm)
  581.       It is likely that your Unix system has 'compress' already. Otherwise:
  582.     ftp://wuarchive.wustl.edu/packages/compression/compress-4.1.tar
  583.         (not in .Z format to avoid chicken and egg problem)
  584.  
  585.     compress for MSDOS
  586.     ftp://ftp.coast.net/mirrors/SimTel/msdos/compress/comp430d.zip
  587.     ftp://garbo.uwasa.fi/pc/unix/comp430d.zip
  588.     ftp://garbo.uwasa.fi/pc/source/comp430s.zip
  589.  
  590.     compress for Macintosh
  591.     ftp://wuarchive.wustl.edu/systems/mac/info-mac/cmp/stuffit-expander-352.hqx
  592.         ftp://sumex-aim.stanford.edu/info-mac/cmp/maccompress-32.hqx
  593.  
  594.     compress for Amiga
  595.     ftp.funet.fi:pub/amiga/utilities/archivers/compress-4.1.lha
  596.  
  597.     compress for VAX/VMS
  598.     ftp://wuarchive.wustl.edu/packages/compression/vax-vms/lzcomp.exe
  599.     ftp://wuarchive.wustl.edu/packages/compression/vax-vms/lzdcmp.exe
  600.  
  601. ------------------------------------------------------------------------------
  602.  
  603. Subject: [3]  What is the latest PKZIP version?
  604.  
  605. The latest official DOS version is 2.04g. Release 2.04c had serious bugs,
  606. corrected in 2.04e and 2.04g. The latest Windows version is pkzws201.exe.
  607.  
  608. Be warned that there are countless bogus PKZIP 1.20, 2.0, 2.02, 3.00B,
  609. 3.05, 4.1 and whatever scams floating around.  They usually are hacks
  610. of PKZIP 1.93A beta test version.  Some of them are trojans and / or
  611. carry computer virii.
  612.  
  613. Note about pkzip 2.06 from a PKware employee:
  614.  
  615.     Version 2.06 was released as an INTERNAL use only IBM version.
  616.     It is identical to 2.04G, but it has IBM names in the help
  617.     screens and such. That release is meant for IBM only.
  618.  
  619. If pkunzip indicates that you need version 2.8 to extract an
  620. archive, your archive has been corrupted by a transfer not
  621. made in binary mode (see item 30 below).
  622. ------------------------------------------------------------------------------
  623.  
  624. Subject: [4] What is an archiver?
  625.  
  626.  
  627. There is a distinction between archivers and other compression
  628. programs:
  629.  
  630. - an archiver takes several input files, compresses them and produces
  631.   a single archive file. Examples are arc, arj, lha, zip, zoo.
  632.  
  633. - other compression programs create one compressed file for each
  634.   input file. Examples are freeze, yabba, compress, gzip. Such programs
  635.   are often combined with tar to create compressed archives (see
  636.   question 50: "What is this tar compression program?").
  637.  
  638. For a comparison of zip and gzip, see the gzip README file. (In short:
  639. zip is an archiver, gzip is not; only zip is compatible with pkzip.)
  640.  
  641. ------------------------------------------------------------------------------
  642.  
  643. Subject: [5] What is the best general purpose compression program?
  644.  
  645.  
  646. The answer is: it depends. (You did not expect a definitive answer,
  647. did you?)
  648.  
  649. It depends whether you favor speed, compression ratio, a standard and
  650. widely used archive format, the number of features, etc...  Just as
  651. for text editors, personal taste plays an important role. compress has
  652. 4 options, arj 2.30 has about 130 options; different people like
  653. different programs. *Please* do not start or continue flame wars on
  654. such matters of taste.
  655.  
  656. Several benchmarks of MSDOS archivers are available:
  657. - ftp://ftp.coast.net/mirrors/SimTel/msdos/archiver/actest*.zip
  658.   and http://www.mi.net/act/act.html by Jeff Gilchrist <jeffg@mi.net>
  659. - ftp://garbo.uwasa.fi/pc/arcers/act-*.zip
  660.   by Jonathan Burt <jonathan@jaburt.demon.co.uk>
  661. - ftp://ftp.coast.net/mirrors/SimTel/msdos/info/arctst*.zip
  662.  
  663. Please do not post your own benchmarks made on your own files that
  664. nobody else can access. If you think that you must absolutely post yet
  665. another benchmark, make sure that your test files are available by
  666. anonymous ftp.
  667.  
  668. Since all other benchmarks are for MSDOS only, here is one mainly for
  669. Unix, on a 33Mhz Compaq 386.  All programs have been run on Unix SVR4,
  670. except pkzip and arj which only run on MSDOS.
  671.  
  672. The programs compared here were chosen because they are the most
  673. popular or because they run on Unix and source is available.  For ftp
  674. information, see above. Three programs (hpack, comp-2 and ha) have
  675. been added because they achieve better compression (at the expense of
  676. speed) and one program (lzrw3-a) has been added because it favors
  677. speed at the expense of compression:
  678.  
  679. - comp-2 is in ftp://wuarchive.wustl.edu/mirrors/msdos/ddjmag/ddj9102.zip
  680.   (inner zip file nelson.zip),
  681. - hpack is in ftp://garbo.uwasa.fi/unix/arcers/hpack78src.tar.Z
  682. - ha 0.98 is in ftp://garbo.uwasa.fi/pc/arcers/ha098.zip
  683. - lzrw3-a is no longer in ftp://ftp.adelaide.edu.au/pub/compression/lzrw3-a.c
  684.  
  685. The 14 files used in the comparison are from the standard Calgary
  686. Text Compression Corpus, available in
  687. ftp://ftp.cpsc.ucalgary.ca/pub/projects/text.compression.corpus/
  688.  
  689. The whole corpus includes 18 files, but the 4 files paper[3-6] are
  690. generally omitted in benchmarks. It contains several kinds of file
  691. (ascii, binary, image, etc...) but has a bias towards large files.
  692. You may well get different ratings on the typical mix of files that
  693. you use daily, so keep in mind that the comparisons given below are
  694. only indicative.
  695.  
  696. The programs are ordered by decreasing total compressed size. For a
  697. fair comparison between archivers and other programs, this size is
  698. only the size of the compressed data, not the archive size.
  699.  
  700. The programs were run on an idle machine, so the elapsed time
  701. is significant and can be used to compare Unix and MSDOS programs.
  702.  
  703. [Note: I did not have time to run again all benchmarks with more
  704. recent versions of zip, freeze, arj, hpack and ha. To be done for some
  705. future revision of this FAQ.]
  706.  
  707.        size     lzrw3a   compress    lharc    yabba     pkzip    freeze 
  708. version:                   4.0       1.02      1.0       1.10     2.3.5
  709. options:                                    -m300000                    
  710.        ------    -----    ------    ------    ------    ------   ------
  711. bib    111261    49040     46528     46502     40456     41354    41515 
  712. book1  768771   416131    332056    369479    306813    350560   344793 
  713. book2  610856   274371    250759    252540    229851    232589   230861 
  714. geo    102400    84214     77777     70955     76695     76172    68626 
  715. news   377109   191291    182121    166048    168287    157326   155783 
  716. obj1    21504    12647     14048     10748     13859     10546    10453 
  717. obj2   246814   108040    128659     90848    114323     90130    85500 
  718. paper1  53161    24522     25077     21748     22453     20041    20021 
  719. paper2  82199    39479     36161     35275     32733     32867    32693 
  720. pic    513216   111000     62215     61394     65377     63805    53291 
  721. progc   39611    17919     19143     15399     17064     14164    14143 
  722. progl   71646    24358     27148     18760     23512     17255    17064 
  723. progp   49379    16801     19209     12792     16617     11877    11686 
  724. trans   93695    30292     38240     28092     31300     23135    22861 
  725.     3,141,622  1,400,105 1,259,141 1,200,580 1,159,340 1,141,821 1,109,290
  726. real             0m35s     0m59s     5m03s     2m40s              5m27s
  727. user             0m25s     0m29s     4m29s     1m46s              4m58s
  728. sys              0m05s     0m10s     0m07s     0m18s              0m08s
  729. MSDOS:                                                   1m39s
  730.                         
  731.  
  732.          zoo       lha       arj      pkzip    zip      hpack   comp-2    ha
  733.         2.10    1.0(Unix)   2.30      2.04g    1.9      0.75a            0.98
  734.          ah    2.13(MSDOS)   -jm       -ex      -6                        a2
  735.        ------    ------    ------    ------  -------   ------   ------  ------
  736. bib     40742     40740     36090    35126    34950    35619    29840   26927
  737. book1  339076    339074    318382   312490   312619   306876   237380  235733
  738. book2  228444    228442    210521   206513   206306   208486   174085  163535
  739. geo     68576     68574     69209    68706    68418    58976    64590   59356
  740. news   155086    155084    146855   144545   144395   141608   128047  123335
  741. obj1    10312     10310     10333    10306    10295    10572    10819    9799
  742. obj2    84983     84981     82052    81132    81336    80806    85465   80381
  743. paper1  19678     19676     18710    18531    18525    18607    16895   15675
  744. paper2  32098     32096     30034    29568    29674    29825    25453   23956
  745. pic     52223     52221     53578    52409    55051    51778    55461   51639
  746. progc   13943     13941     13408    13341    13238    13475    12896   11795
  747. progl   16916     16914     16408    16122    16175    16586    17354   15298
  748. progp   11509     11507     11308    11200    11182    11647    11668   10498
  749. trans   22580     22578     20046    19462    18879    20506    21023   17927
  750.     1,096,166 1,096,138 1,036,934 1,019,451 1,021,043 1,005,367 890,976 845,854
  751. real    4m07s     6m03s                        1m49s   1h22m17s  27m05s
  752. user    3m47s     4m23s                        1m43s   1h20m46s  19m27s
  753. sys     0m04s     0m08s                        0m02s      0m12s   2m03s
  754. MSDOS:            1m49s     2m41s     1m43s                              14m43s
  755.  
  756. Notes:
  757.  
  758. - the compressed data for 'zoo ah' is always two bytes longer than for
  759.   lha. This is simply because both programs are derived from the same
  760.   source (ar002, written by Haruhiko Okumura, available by ftp in
  761.   ftp://ftp.coast.net/mirrors/SimTel/msdos/archiver/ar002.zip).
  762.  
  763. - hpack 0.75a gives slightly different results on SunOS. (To be checked
  764.   with latest version of hpack).
  765.  
  766. - the MSDOS versions are all optimized with assembler code and were run
  767.   on a RAM disk. So it is not surprising that they often go faster than
  768.   their Unix equivalent.
  769.  
  770. ------------------------------------------------------------------------------
  771.  
  772. Subject: [7] Which books should I read?
  773.  
  774.  
  775. [BWC 1989] Bell, T.C, Cleary, J.G. and Witten, I.H, "Text Compression",
  776.     Prentice-Hall 1989. ISBN: 0-13-911991-4. Price: approx. US$60
  777.     The reference on text data compression.
  778.  
  779. [Nel 1996] Mark Nelson & Jean-loup Gailly, "The Data Compression Book",
  780.     2nd edition. M&T Books, New York, NY 1996. ISBN 1-55851-434-1
  781.     541 pages. List price in the US is $39.95 including one PC-compatible
  782.     disk bearing all the source code printed in the book.
  783.     A practical introduction to data compression.
  784.     The book is targeted at a person who is comfortable reading C code but
  785.     doesn't know anything about data compression.  Its stated goal is to get
  786.     you up to the point where you are competent to program standard
  787.     compression algorithms.
  788.  
  789. [Will 1990] Williams, R.  "Adaptive Data Compression", Kluwer Books, 1990.
  790.     ISBN: 0-7923-9085-7. Price: US$75.
  791.     Reviews the field of text data compression and then addresses the
  792.     problem of compressing rapidly changing data streams.
  793.  
  794. [Stor 1988] Storer, J.A.  "Data Compression: Methods and Theory", Computer
  795.     Science Press, Rockville, MD. ISBN: 0-88175-161-8.
  796.     A survey of various compression techniques, mainly statistical
  797.     non-arithmetic compression and LZSS compression.  Includes complete Pascal
  798.     code for a series of LZ78 variants.
  799.  
  800. [Stor 1992] Storer, J.A. "Image and Text Compression", Kluwer Academic
  801.     Publishers, 1992, ISBN 0-7923-9243-4
  802.  
  803. [Say 1996] Sayood, Khalid. "Introduction to Data Compression",
  804.   San Francisco:  Morgan Kaufmann Publishers, 1996. ISBN 1-55860-346-8;
  805.   US&Canada $64.95. More info in http://www.mkp.com/pages/3468/index.html
  806.   The book covers both lossy and lossless compression techniques and their
  807.   applications to image, speech, text, audio, and video compression.
  808.  
  809. [BK 95] Bhaskaran V. and Konstantinides K., "Image and Video Compression
  810.     Standards: Algorithms and Architectures", Kluwer Academic Publishers, 1995.
  811.     ISBN 0-7923-9591-3
  812.  
  813. [ACG 1991] Advances in Speech Coding, edited by Atal, Cuperman, and Gersho,
  814.     Kluwer Academic Press, 1991.
  815.  
  816. [GG 1991] Vector Quantization and Signal Compression, by Gersho and Gray,
  817.     Kluwer Acad. Press, 1991, ISBN 0-7923-9181-0.
  818.  
  819. [CT 1991] Elements of Information Theory, by T.M.Cover and J.A.Thomas
  820.      John Wiley & Sons, 1991. ISBN 0-471-06259-6.
  821.  
  822. Review papers:
  823.  
  824. [BWC 1989] Bell, T.C, Witten, I.H, and Cleary, J.G.  "Modeling for Text
  825.     Compression", ACM Computing Surveys, Vol.21, No.4 (December 1989), p.557
  826.     A good general overview of compression techniques (as well as modeling for
  827.     text compression); the condensed version of "Text Compression".
  828.  
  829. [Lele 1987] Lelewer, D.A, and Hirschberg, D.S.  "Data Compression", ACM
  830.     Computing Surveys, Vol.19, No.3 (September 1987), p.261.
  831.     A survey of data compression techniques which concentrates on Huffman
  832.     compression and makes only passing mention of other techniques.
  833.  
  834.  
  835. ------------------------------------------------------------------------------
  836.  
  837. Subject: [8] What about patents on data compression algorithms?
  838.  
  839.  
  840. [Note: the appropriate group for discussing software patents is
  841. comp.patents (or misc.legal.computing), not comp.compression.]
  842.  
  843. All patents mentioned here are US patents, and thus probably
  844. not applicable outside the US. See item 70, "Introduction to data
  845. compression" for the meaning of LZ77, LZ78 or LZW.
  846.  
  847.  
  848. (a) Run length encoding
  849.  
  850. - Tsukiyama has two patents on run length encoding: 4,586,027 and 4,872,009
  851.   granted in 1986 and 1989 respectively. The first one covers run length
  852.   encoding in its most primitive form: a length byte followed by the
  853.   repeated byte. The second patent covers the 'invention' of limiting the
  854.   run length to 16 bytes and thus the encoding of the length on 4 bits.
  855.   Here is the start of claim 1 of patent 4,872,009, just for pleasure:
  856.  
  857.     1. A method of transforming an input data string comprising a plurality
  858.     of data bytes, said plurality including portions of a plurality of
  859.     consecutive data bytes identical to one another, wherein said data
  860.     bytes may be of a plurality of types, each type representing different
  861.     information, said method comprising the steps of: [...]
  862.  
  863. - O'Brien has patented (4,988,998) run length encoding followed by LZ77.
  864.  
  865.  
  866. (b) LZ77
  867.  
  868. - Waterworth patented (4,701,745) the algorithm now known as LZRW1,
  869.   because Ross Williams reinvented it later and posted it on
  870.   comp.compression on April 22, 1991. (See item 5 for the ftp site
  871.   with all LZRW derivatives.) The *same* algorithm has later been
  872.   patented by Gibson & Graybill (see below). The patent office failed
  873.   to recognize that the same algorithm was patented twice, even though
  874.   the wording used in the two patents is very similar.
  875.  
  876.   The Waterworth patent is now owned by Stac Inc, which won a lawsuit
  877.   against Microsoft, concerning the compression feature of MSDOS 6.0.
  878.   Damages awarded were $120 million. (Microsoft and Stac later
  879.   settled out of court.)
  880.  
  881. - Fiala and Greene obtained in 1990 a patent (4,906,991) on all
  882.   implementations of LZ77 using a tree data structure. Claim 1 of the
  883.   patent is much broader than the algorithms published by Fiala and
  884.   Greene in Comm.ACM, April 89. The patent covers the algorithm
  885.   published by Rodeh and Pratt in 1981 (J. of the ACM, vol 28, no 1,
  886.   pp 16-24).  It also covers the algorithms used in lharc, lha and zoo.
  887.  
  888. - Notenboom (from Microsoft) 4,955,066 uses three levels of
  889.   compression, starting with run length encoding.
  890.  
  891. - The Gibson & Graybill patent 5,049,881 covers the LZRW1 algorithm
  892.   previously patented by Waterworth and reinvented by Ross Williams.
  893.   Claims 4 and 12 are very general and could be interpreted as
  894.   applying to any LZ algorithm using hashing (including all variants
  895.   of LZ78):
  896.  
  897.      4. A compression method for compressing a stream of input data into
  898.      a compressed stream of output data based on a minimum number of
  899.      characters in each input data string to be compressed, said
  900.      compression method comprising the creation of a hash table, hashing
  901.      each occurrence of a string of input data and subsequently searching
  902.      for identical strings of input data and if such an identical string
  903.      of input data is located whose string size is at least equal to the
  904.      minimum compression size selected, compressing the second and all
  905.      subsequent occurrences of such identical string of data, if a string
  906.      of data is located which does not match to a previously compressed
  907.      string of data, storing such data as uncompressed data, and for each
  908.      input strings after each hash is used to find a possible previous
  909.      match location of the string, the location of the string is stored
  910.      in the hash table, thereby using the previously processed data to
  911.      act as a compression dictionary.
  912.  
  913.   Claim 12 is identical, with 'method' replaced with 'apparatus'.  Since
  914.   the 'minimal compression size' can be as small as 2, the claim could
  915.   cover any dictionary technique of the LZ family. However the text of the
  916.   patent and the other claims make clear that the patent should cover the
  917.   LZRW1 algorithm only. (In any case the Gibson & Graybill patent is likely
  918.   to be invalid because of the prior art in the Waterworth patent.)
  919.  
  920. - Phil Katz, author of pkzip, also has a patent on LZ77 (5,051,745)
  921.   but the claims only apply to sorted hash tables, and when the hash
  922.   table is substantially smaller than the window size.
  923.  
  924. - IBM patented (5,001,478) the idea of combining a history buffer (the
  925.   LZ77 technique) and a lexicon (as in LZ78).
  926.  
  927. - Stac Inc patented (5,016,009 and 5,126,739) yet another variation of LZ77
  928.   with hashing. The '009 patent was used in the lawsuit against Microsoft
  929.   (see above). Stac also has a patent on LZ77 with parallel lookup in
  930.   hardware (5,003,307).
  931.  
  932. - Robert Jung, author of 'arj', has been granted patent 5,140,321
  933.   for one variation of LZ77 with hashing.  This patent covers the LZRW3-A
  934.   algorithm, also previously discovered by Ross Williams. LZRW3-A was posted
  935.   on comp.compression on July 15, 1991. The patent was filed two months later
  936.   on Sept 4, 1991. (The US patent system allows this because of the
  937.   'invention date' rule.)
  938.  
  939. - Chambers 5,155,484 is yet another variation of LZ77 with hashing.
  940.   The hash function is just the juxtaposition of two input bytes,
  941.   this is the 'invention' being patented. The hash table is named
  942.   'direct lookup table'.
  943.  
  944.  
  945. (c) LZ78
  946.  
  947. - One form of the original LZ78 algorithm was patented (4,464,650) by
  948.   its authors Lempel, Ziv, Cohn and Eastman. This patent is owned
  949.   by Unisys.
  950.  
  951.  
  952. - The LZW algorithm used in 'compress' is patented by IBM (4,814,746)
  953.   and Unisys (4,558,302). It is also used in the V.42bis compression
  954.   standard (see question 11 on V.42bis below), in Postscript Level 2, in
  955.   GIF and TIFF.  Unisys sells the license to modem manufacturers for a
  956.   onetime fee (contact: Welch Patent Desk, Unisys Corp., P.O. Box 500,
  957.   Bluebell, PA 19424 Mailcode C SW 19). CompuServe is licensing the
  958.   usage of LZW in GIF products for 1.5% of the product price, of which
  959.   1% goes to Unisys; usage of LZW in non-GIF products must be licensed
  960.   directly from Unisys. For more information, see http://www.unisys.com/
  961.   or email to lzw_info@unisys.com.
  962.  
  963.      The IBM patent application was first filed three weeks before that of
  964.   Unisys, but the US patent office failed to recognize that they
  965.   covered the same algorithm. (The IBM patent is more general, but its
  966.   claim 7 is exactly LZW.)
  967.  
  968. - Klaus Holtz also claims that patent 4,366,551 for his "autosophy"
  969.   data compression method covers LZ78 and LZW. According to Holtz, most of
  970.   the largest V.42bis modem manufacturers have paid for patent licenses.
  971.  
  972. - AP coding is patented by Storer (4,876,541). (Get the yabba package
  973.   for source code, see question 2 above, file type .Y) Storer also
  974.   claims that his patent covers V.42bis.
  975.  
  976.  
  977. (d) arithmetic coding
  978.  
  979. - IBM holds many patents on arithmetic coding (4,286,256 4,295,125 4,463,342
  980.   4,467,317 4,633,490 4,652,856 4,891,643 4,905,297 4,935,882).  It has
  981.   patented in particular the Q-coder implementation of arithmetic coding.
  982.   The JBIG standard, and the arithmetic coding option of the JPEG standard
  983.   requires use of the patented algorithm.  No JPEG-compatible method is
  984.   possible without infringing the patent, because what IBM actually claims
  985.   rights to is the underlying probability model (the heart of an arithmetic
  986.   coder). (See item 75 for details.)
  987.  
  988.   AT&T has 3 patents on arithmetic coding (4,973,961, 5,023,611, 5,025,258).
  989.  
  990. (e) predictor
  991.  
  992. - The 'predictor' algorithm was first described in the paper
  993.  
  994.     Raita, T. and Teuhola, J. (1987), "Predictive text compression by hashing",
  995.     ACM Conference on Information Retrieval
  996.  
  997.   This algorithm has been patented (5,229,768) by K. Thomas in 1993. It
  998.   is used in the Internet Draft "PPP Predictor Compression Protocol" (see
  999.   ftp://venera.isi.edu/internet-drafts/draft-ietf-pppext-predictor-00.txt).
  1000.  
  1001.  
  1002. As can be seen from the above list, some of the most popular compression
  1003. programs (compress, pkzip, zoo, lha, arj) are now covered by patents.
  1004. (This says nothing about the validity of these patents.)
  1005.  
  1006. Here are some references on data compression patents. A number of them are
  1007. taken from the list ftp://prep.ai.mit.edu/pub/lpf/patent-list.
  1008.  
  1009. 3,914,586
  1010. Data compression method and apparatus
  1011. filed 10/25/73, granted 10/21/75
  1012. General Motors Corporation, Detroit MI
  1013. Duane E. McIntosh, Santa Ynez CA
  1014. Data compression apparatus is disclosed is operable in either a bit
  1015. pair coding mode of a word coding mode depending on the degree of
  1016. redundancy of the data to be encoded.
  1017.  
  1018. 3,976,844
  1019. Data communication system for transmitting data in compressed form
  1020. filed Apr. 4, 1975, granted Aug. 24, 1976
  1021. inventor  Bernard K. Betz, assignee Honeywell Information Systems, Inc.
  1022. [encode differences with previous line]
  1023.  
  1024. 4,021,782
  1025. Data compaction system and apparatus
  1026. inventor Hoerning
  1027. filed 04/30/1975, granted 05/03/1977
  1028. [A primitive form of LZ77 with implicit offsets (compare with previous record)]
  1029.  
  1030. 4,054,951
  1031. Data expansion apparatus
  1032. inventor R.D. Jackson, assignee IBM
  1033. filed Jun. 30, 1976, granted Oct. 18, 1977
  1034. [Covers only decompression of data compressed with a variant of LZ77.]
  1035.  
  1036. 4,087,788
  1037. Data compression system
  1038. filed 1/14/77, granted 5/2/78
  1039. NCR Canada LTD - NCR Canada Ltee, Mississauga CA
  1040. Brian J. Johannesson, Waterloo CA
  1041. A data compression system is disclosed in which the left hand boundary
  1042. of a character is developed in the form of a sequence of Freeman
  1043. direction codes, the codes being stored in digital form within a
  1044. processor.
  1045.  
  1046. 4,286,256
  1047. Method and means for arithmetic coding using a reduced number of operations.
  1048. granted Aug 25, 1981
  1049. assignee IBM
  1050.  
  1051. 4,295,125
  1052. A method and means for pipeline decoding of the high to low order pairwise
  1053. combined digits of a decodable set of relatively shifted finite number of
  1054. strings
  1055. granted Oct 13, 1981
  1056. assignee IBM
  1057.  
  1058. 4,366,551
  1059. Associative Memory Search System
  1060. filed June 16, 1975, granted Dec. 28, 1982.
  1061. inventor Klaus Holtz, assignee Omni Dimensional Networks.
  1062.  
  1063. 4,412,306
  1064. System for minimizing space requirements for storage and transmission of
  1065. digital signals
  1066. filed May 14, 1981, granted Oct. 25, 1983
  1067. inventor  Edward W. Moll
  1068.  
  1069. 4,463,342
  1070. A method and means for carry-over control in a high order to low order
  1071. combining of digits of a decodable set of relatively shifted finite number
  1072. strings.
  1073. granted Jul 31, 1984
  1074. assignee IBM
  1075.  
  1076. 4,491,934
  1077. Data compression process
  1078. filed May 12, 1982, granted Jan. 1, 1985
  1079. inventor  Karl E. Heinz
  1080.  
  1081. 4,464,650
  1082. Apparatus and method for compressing data signals and restoring the
  1083. compressed data signals
  1084. inventors Lempel, Ziv, Cohn, Eastman
  1085. assignee Sperry Corporation (now Unisys)
  1086. filed 8/10/81, granted 8/7/84
  1087. A compressor parses the input data stream into segments where each
  1088. segment comprises a prefix and the next symbol in the data stream
  1089. following the prefix. [This is the original LZ78 algorithm.]
  1090.  
  1091. 4,467,317
  1092. High-speed arithmetic compression using using concurrent value updating.
  1093. granted Aug 21, 1984
  1094. assignee IBM
  1095.  
  1096. 4,494,108
  1097. Adaptive source modeling for data file compression within bounded memory
  1098. filed Jun. 5, 1984, granted Jan. 15, 1985
  1099. invntors Glen G. Langdon, Jorma J. Rissanen
  1100. assignee IBM
  1101. order 1 Markov modeling
  1102.  
  1103. 4,558,302
  1104. High speed data compression and decompression apparatus and method
  1105. inventor Welch
  1106. assignee Sperry Corporation (now Unisys)
  1107. filed 6/20/83, granted 12/10/85
  1108. re-examined: filed 12/14/92, granted 4/1/94.
  1109. The text for the original patent can be ftped from ftp.uni-stuttgart.de
  1110. in /pub/doc/comp-patents/US4558302.Z.
  1111. There is also a European Patent 0,129,439  1/2/89 for DE, FR, GB, IT
  1112. and patent pending for Japan.
  1113.  
  1114. 4,560,976
  1115. Data compression
  1116. filed 6/5/84, granted 12/24/85
  1117. Codex Corporation, Mansfield MA
  1118. Steven G. Finn, Framingham, MA
  1119. A stream of source characters, which occur with varying relative
  1120. frequencies, is encoded into a compressed stream of codewords, each
  1121. having one, two or three subwords, by ranking the source characters by
  1122. their current frequency of appearance, encoding the source characters
  1123. having ranks no higher than a first number as one subword codewords,
  1124. source characters having ranks higher than the first number but no
  1125. higher than a second number as two subword codewords, and the
  1126. remaining source characters as three subword codewords.
  1127.  
  1128. 4,586,027
  1129. Method and system for data compression and restoration
  1130. inventor Tsukimaya et al.
  1131. assignee Hitachi
  1132. filed 08/07/84, granted 04/29/86
  1133. patents run length encoding
  1134.  
  1135. 4,597,057
  1136. System for compressed storate of 8-bit ascii bytes using coded strings
  1137. of 4-bit nibbles.
  1138. inventor Snow, assignee System Development corporation.
  1139. filed 12/31/1981, granted 06/24/1986.
  1140. Compression using static dictionary of common words, prefixes and suffixes.
  1141.  
  1142. 4,612,532
  1143. Data compression apparatus and method
  1144. inventor Bacon, assignee Telebyte Corportion
  1145. filed Jun. 19, 1984, granted Sep. 16, 1986
  1146. [Uses followsets as in the pkzip 0.92 'reduce' algorithm, but the
  1147. followsets are dynamically updated. This is in effect a sort of order-1
  1148. Markov modeling.]
  1149.  
  1150. 4,622,545
  1151. Method and apparatus for image compression and Manipulation
  1152. inventor William D. Atkinson
  1153. assignee Apple computer Inc.
  1154. filed 9/30/82
  1155. granted 11/11/86
  1156.  
  1157. 4,633,490
  1158. Symmetrical adaptive data compression/decompression system.
  1159. granted Dec 30, 1985
  1160. assignee IBM
  1161.  
  1162. 4,652,856
  1163. A multiplication-free multi-alphabet arithmetic code.
  1164. granted Feb  4, 1986
  1165. assignee IBM
  1166.  
  1167. 4,667,649
  1168. Data receiving apparatus
  1169. filed 4/18/84, granted 6/30/87
  1170. inventors Kunishi et al.
  1171. assignee Canon Kabushiki Kaisha, Tokyo Japan
  1172. compression of Fax images.
  1173.  
  1174. 4,682,150
  1175. Data compression method and apparatus
  1176. inventors Mathes and Protheroe, 
  1177. assignee NCR Corporation, Dayton OH
  1178. A system and apparatus for compressing redundant and nonredundant
  1179. binary data generated as part of an operation of a time and attendance
  1180. terminal in which the data represents the time an employee is present
  1181. during working hours.
  1182.  
  1183. 4,701,745
  1184. Data compression system
  1185. inventor Waterworth John R
  1186. assignee Ferranti PLC GB, patent rights now acquired by Stac Inc.
  1187. filed 03/03/1986 (03/06/1985 in GB), granted 10/20/1987
  1188. Algorithm now known as LZRW1 (see above)
  1189. I claim:
  1190. 1. A data compression system comprising an input store for receiving
  1191. and storing a plurality of bytes of uncompressed data from an outside
  1192. source, and data processing means for processing successive bytes of
  1193. data from the input store;
  1194. the data processing means including circuit means operable to check
  1195. whether a sequence of successive bytes to be processed identical with
  1196. a sequence of bytes already processed, and including hash generating
  1197. means responsive to the application of a predetermined number of
  1198. bytes in sequence to derive a hash code appropriate to those bytes, a
  1199. temporary store in which the hash code may represent the address of a
  1200. storage location, and a pointer counter operable to store in the
  1201. temporary store at said address a pointer indicative of the position
  1202. in the input store of one of the predetermined number of bytes;
  1203. output means operable to apply to a transfer medium each byte of data
  1204. not forming part of such an identical sequence; and
  1205. encoding means responsive to the identification of such a sequence to
  1206. apply to the transfer medium an identification signal which identifies
  1207. both the location in the input store of the previous occurrence of the
  1208. sequence of bytes and the number of bytes contained in the sequence.
  1209.  
  1210. 4,730,348
  1211. Adaptive data compression system
  1212. inventor MacCrisken, assignee Adaptive Computer Technologies
  1213. filed Sep. 19, 1986, granted Mar. 8, 1988
  1214. [order-1 Markov modeling + Huffman coding + LZ77]
  1215.  
  1216. 4,758,899
  1217. Data compression control device
  1218. inventor Tsukiyama, assignee Hitachi
  1219. filed 11/20/1985, granted 07/19/1988
  1220. Limits compression to ensure that tape drive stays busy.
  1221.  
  1222. 4,809,350
  1223. Data compression system
  1224. filed Jan. 30, 1987, granted Feb. 28, 1989
  1225. inventor Yair Shimoni & Ron Niv
  1226. assignee Elscint Ltd., Haifa, Israel
  1227. [Image compression via variable length encoding of differences with
  1228. predicted data.]
  1229.  
  1230. 4,814,746
  1231. Data compression method
  1232. inventors Victor S. Miller, Mark N. Wegman
  1233. assignee IBM
  1234. filed 8/11/86, granted 3/21/89
  1235. A previous application was filed on 6/1/83, three weeks before the
  1236. application by Welch (4,558,302)
  1237. Communications between a Host Computing System and a number of remote
  1238. terminals is enhanced by a data compression method which modifies the
  1239. data compression method of Lempel and Ziv by addition of new character
  1240. and new string extensions to improve the compression ratio, and
  1241. deletion of a least recently used routine to limit the encoding tables
  1242. to a fixed size to significantly improve data transmission efficiency.
  1243.  
  1244. 4,841,092
  1245. continued in 5,003,307
  1246.  
  1247. 4,853,696
  1248. Code converter for data compression/decompression
  1249. filed 4/13/87, granted 8/1/89
  1250. inventor Amar Mukherjee, Maitland FL
  1251. assignee University of Central Florida, Orlando FL
  1252. Another hardware Huffman encoder:
  1253. A code converter has a network of logic circuits connected in reverse
  1254. binary tree fashion with logic paths between leaf nodes and a common
  1255. root node.
  1256.  
  1257. 4,872,009
  1258. Method and apparatus for data compression and restoration
  1259. inventor Tsukimaya et al.
  1260. assignee Hitachi
  1261. filed 12/07/87, granted 10/03/89
  1262. This patent on run length encoding covers the 'invention' of limiting
  1263. the run length to 16 bytes and thus the encoding of the length on 4 bits.
  1264.  
  1265. 4,876,541
  1266. Stem [sic] for dynamically compressing and decompressing electronic data
  1267. filed 10/15/87, granted 10/24/89
  1268. inventor James A. Storer
  1269. assignee Data Compression Corporation
  1270. A data compression system for encoding and decoding textual data,
  1271. including an encoder for encoding the data and for a decoder for
  1272. decoding the encoded data.
  1273.  
  1274. 4,891,643
  1275. Arithmetic coding data compression/de-compression by selectively
  1276. employed, diverse arithmetic encoders and decoders.
  1277. granted Jan  2, 1990
  1278. assignee IBM
  1279.  
  1280. 4,905,297
  1281. granted Feb 27, 1990
  1282. assignee IBM
  1283. Arithmetic coding encoder and decoder system.
  1284.  
  1285. 4,906,991
  1286. Textual substitution data compression with finite length search window
  1287. filed 4/29/1988, granted 3/6/1990
  1288. inventors Fiala,E.R., and Greene,D.H.
  1289. assignee Xerox Corporation
  1290.  
  1291. 4,935,882
  1292. Probability adaptation for arithmetic coders.
  1293. granted Jun 19, 1990
  1294. assignee IBM
  1295.  
  1296. 4,941,193
  1297. Barnsley, fractal compression.
  1298.  
  1299. 4,943,869
  1300. Compression Method for Dot Image Data
  1301. filed 1988-05-04, granted 1990-07-24
  1302. assignee Fuji Photo Film Co.
  1303. Lossy and lossless image compression schemes.
  1304.  
  1305. 4,955,066
  1306. Compressing and Decompressing Text Files
  1307. filed  10/13/89, granted 09/04/90
  1308. inventor Notenboom, L.A.
  1309. assignee Microsoft
  1310. Now extended as 5,109,433
  1311. [Noted in signon screen of Word 5.5 and on the outside of the MS-DOS 5.0
  1312. Upgrade.]
  1313. A method of compressing a text file in digital form is disclosed.
  1314. A full text file having characters formed into phrases is provided by an
  1315. author.  The characters are digitally represented by bytes.  A first pass
  1316. compression is sequentially followed by a second pass compression of the
  1317. text which has previously been compressed.  A third or fourth level of
  1318. compression is serially performed on the compressed text.  For example, in
  1319. a first pass, the text is run-length compressed.  In a second pass, the
  1320. compressed text is further compressed with key phrase compression.  In a
  1321. third pass, the compressed text is further compressed with Huffman
  1322. compression.  The compressed text is stored in a text file having a Huffman
  1323. decode tree, a key phrase table, and a topic index.  The data is
  1324. decompressed in a single pass and provided one line at a time as an output.
  1325. Sequential compressing of the text minimizes the storage space required for
  1326. the file.  Decompressing of the text is performed in a single pass.  As a
  1327. complete line is decompressed, it is output rapidly, providing full text to
  1328. the user.
  1329.  
  1330. 4,973,961
  1331. Method and apparatus for carry-over control in arithmetic coding.
  1332. granted Nov 27, 1990
  1333. assignee AT&T
  1334.  
  1335. 4,988,998
  1336. Data compression system for successively applying at least two data
  1337. compression methods to an input data stream.
  1338. inventor O'Brien
  1339. assignee Storage Technology Corporation, Louisville, Colorado
  1340. filed Sep 5, 1989, granted Jan 29, 1991.
  1341. Run length encoding followed by LZ77.
  1342.  
  1343. 5,001,478
  1344. Method of Encoding Compressed Data
  1345. filed 12/28/89, granted 03/19/91
  1346. inventor Michael E. Nagy
  1347. assignee IBM
  1348. 1. A method of encoding a compressed data stream made up of a sequence of
  1349. literal references, lexicon references and history references, which
  1350. comprises the steps of:
  1351. assigning to each literal reference a literal identifier;
  1352. assigning to each history reference a history identifier;
  1353. assigning to each lexicon reference a lexicon identifier;
  1354. and emitting a data stream with said identifiers assigned to said references.
  1355. Gordon Irlam <gordoni@cs.adelaide.edu.au> says:
  1356. The invention can probably be best understood by considering the
  1357. decompressor.  It consists of a history buffer, and a lexicon buffer, both
  1358. of which are initially empty.  The history buffer contains the last n
  1359. symbols emitted.  Whenever a history buffer reference is to be output the
  1360. string so referenced is subsequently moved to the lexicon buffer for future
  1361. reference.  Thus the history buffer keeps track of strings that may be
  1362. repeated on a very short term basis, while the lexicon buffer stores items
  1363. for a longer time.  Furthermore a history reference involves specifying
  1364. both the offset and length within the history buffer, whereas a lexicon
  1365. reference simply specifies a number denoting the string.  Both buffers have
  1366. a finite size.
  1367.  
  1368. 5,003,307
  1369. Data compression apparatus with shift register search means
  1370. filed Oct. 6, 1989, granted Mar. 26, 1991
  1371. inventors George Glen A, Ivey Glen E, Whiting Douglas L
  1372. assignee Stac Inc
  1373. continuation of 4,841,092
  1374.  
  1375. 5,016,009
  1376. Data compression apparatus and method
  1377. filed 01/13/1989, granted 05/14/1991
  1378. inventors George Glen A, Ivey Glen E, Whiting Douglas L
  1379. assignee Stac Inc
  1380. LZ77 with offset hash table (extended in 5,126,739)
  1381.  
  1382. 5,023,611
  1383. Entropy encoder/decoder including a context extractor.
  1384. granted Jun 11, 1991
  1385. assignee AT&T
  1386.  
  1387. 5,025,258
  1388. Adaptive probability estimator for entropy encoder/decoder.
  1389. granted Jun 18, 1991
  1390. assignee AT&T
  1391.  
  1392. 5,049,881
  1393. Apparatus and method for very high data rate-compression incorporating
  1394. lossless data compression and expansion utilizing a hashing technique
  1395. inventors Dean K. Gibson, Mark D. Graybill
  1396. assignee Intersecting Concepts, Inc.
  1397. filed 6/18/90, granted 9/17/91
  1398. [covers lzrw1, almost identical with Waterworth 4,701,745]
  1399.  
  1400. 5,051,745
  1401. String searcher, and compressor using same
  1402. filed  8/21/90, granted 9/24/91
  1403. inventor  Phillip W. Katz (author of pkzip)
  1404. In the string search method and apparatus pointers to the string to be
  1405. searched are indexed via a hashing function and organized according to the
  1406. hashing values of the string elements pointed to. The hashing function is
  1407. also run on the string desired to be found, and the resulting hashing value
  1408. is used to access the index. If the resulting hashing value is not in the
  1409. index, it is known that the target string does not appear in the string
  1410. being searched. Otherwise the index is used to determine the pointers which
  1411. correspond to the target hashing value, these pointers pointing to likely
  1412. candidates for matching the target string. The pointers are then used to
  1413. sequentially compare each of the locations in the string being searched to
  1414. the target string, to determine whether each location contains a match to
  1415. the target string.
  1416. In the method and apparatus for compressing a stream of data symbols, a
  1417. fixed length search window, comprising a predetermined contiguous portion
  1418. of the symbol stream, is selected as the string to be searched by the
  1419. string searcher. If a string to be compressed is found in the symbol
  1420. stream, a code is output designating the location within the search window
  1421. of the matching string and the length of the matching string.
  1422.  
  1423. 5,065,447 (continued in 5,347,600)
  1424. Method and apparatus for processing digital data
  1425. filed Jul. 5, 1989, granted Nov. 12, 1991
  1426. inventors Michael F. Barnsley and Alan D. Sloan
  1427. [Patents image compression with the "Fractal Transform"]
  1428.  
  1429. 5,109,433
  1430. Compressing and decompressing text files
  1431. inventor Notenboom
  1432. assignee Microsoft
  1433. extension of 4,955,066
  1434.  
  1435. 5,126,739
  1436. Data Compression Apparatus and Method
  1437. filed Nov. 27, 1990, granted June 30, 1992.
  1438. inventor Whiting et. al
  1439. assignee Stac Inc
  1440. LZ77 with offset hash table (extension of 5,016,009)
  1441.  
  1442. 5,140,321
  1443. Data compression/decompression method and apparatus
  1444. filed 9/4/91, granted 8/18/92
  1445. inventor Robert Jung
  1446. assignee Prime Computer
  1447.  
  1448. 5,155,484
  1449. Fast data compressor with direct lookup table indexing into history buffer
  1450. filed 9/13/1991, granted 10/13/1992
  1451. inventor Chambers, IV, Lloyd L., Menlo Park, California
  1452. assignee Salient Software, Inc., Palo Alto, California (02)
  1453. Uses a 64K hash table indexed by the first two characters of
  1454. the input string. Includes several claims on the LZ77 file format
  1455. (literal or pair offset,length).
  1456.  
  1457. 5,179,378
  1458. file Jul. 30, 1991, granted Jan. 12, 1993
  1459. inventor Ranganathan
  1460. assignee University of South Florida
  1461. Method and apparatus for the compression and decompression of data
  1462. using Lempel-Ziv based techniques.
  1463. [This covers LZ77 hardware compression with a systolic array of
  1464. processors working in parallel.]
  1465.  
  1466. 5,229,768
  1467. Adaptive data compression system
  1468. granted Jul. 20, 1993
  1469. inventor Kasman E. Thomas
  1470. assignee Traveling Software, Inc. 
  1471.   A system for data compression and decompression is disclosed. A series of
  1472. fixed length overlapping segments, called hash strings, are formed from an
  1473. input data sequence. A retrieved character is the next character in the input
  1474. data sequence after a particular hash string. A hash function relates a
  1475. particular hash string to a unique address in a look-up table (LUT). An
  1476. associated character for the particular hash string is stored in the LUT at
  1477. the address. When a particular hash string is considered, the content of the
  1478. LUT address associated with the hash string is checked to determine whether
  1479. the associated character matches the retrieved character following the hash
  1480. string. If there is a match, a Boolean TRUE is output; if there is no match,
  1481. a Boolean FALSE along with the retrieved character is output. Furthermore, if
  1482. there is no match, then the LUT is updated by replacing the associated
  1483. character in the LUT with the retrieved character. [...]
  1484. [This algorithm is used in the Internet Draft "PPP Predictor
  1485. Compression Protocol".]
  1486.  
  1487. 5,347,600 (continuation of 5,065,447)
  1488. Method and apparatus for compression and decompression of digital image
  1489. filed 10/23/1991, granted 09/13/1994
  1490. inventors Barnsley and Sloan
  1491.  
  1492. 5,384,867 (continued in 5,430,812)
  1493. filed 10/23/1991, granted 01/24/1995
  1494. Fractal transform compression board
  1495. inventors Barnsley et al.
  1496.  
  1497. 5,416,856
  1498. Method of encoding a digital image using iterated image transformations
  1499.   to form an eventually contractive map
  1500. filed 1992/03/30, granted 1995/05/16
  1501. inventors Jacobs, Boss and Fisher
  1502.  
  1503. 5,430,812 (continuation of 5,384,867)
  1504. Fractal transform compression board
  1505. filed 1994/05/18, granted 1995/07/04
  1506. inventors Barnsley et al.
  1507.  
  1508. Japan 2-46275
  1509. Coding system
  1510. granted Feb 26, 1990
  1511. [Patents one form of arithmetic coding.]
  1512.  
  1513.  
  1514. ------------------------------------------------------------------------------
  1515.  
  1516. Subject: [9]  Compression of random data (WEB, Gilbert and others)
  1517.  
  1518.  
  1519. [Note from the FAQ maintainer: this topic has generated and is still generating
  1520. the greatest volume of news in the history of comp.compression. Read this
  1521. before posting on this subject.
  1522.  
  1523. I intended to remove the WEB story from the FAQ, but similar affairs come up
  1524. regularly on comp.compression.  The advertized revolutionary methods have all
  1525. in common their supposed ability to compress random or already compressed data.
  1526. I will keep this item in the FAQ to encourage people to take such claims with
  1527. great precautions.]
  1528.  
  1529.  
  1530. 9.1 Introduction
  1531.  
  1532. It is mathematically impossible to compress without loss truly random data (see
  1533. below and also item 73 in part 2 of this FAQ). Yet from time to time some
  1534. people claim to have invented a new algorithm for doing so. Such algorithms are
  1535. claimed to be applicable recursively, that is, applying the compressor to the
  1536. compressed output of the previous run, possibly multiple times. Fantastic
  1537. compression ratios of over 100:1 on random data are claimed to be actually
  1538. obtained.
  1539.  
  1540. Such claims inevitably generate a lot of activity on comp.compression, which
  1541. can last for several months. The two largest bursts of activity were generated
  1542. by WEB Technologies and by Jules Gilbert. Premier Research Corporation
  1543. (with a compressor called MINC) made only a brief appearance. David C. James
  1544. is a new contender with a patent obtained in July 96.
  1545.  
  1546. Other people have also claimed incredible compression ratios, but the programs
  1547. (OWS, WIC) were quickly shown to be fake (not compressing at all). This topic
  1548. is covered in item 10 of this FAQ.
  1549.  
  1550.  
  1551. 9.2 The counting argument
  1552.  
  1553. The WEB compressor (see details in section 9.3 below) was claimed to compress
  1554. without loss *all* files of greater than 64KB in size to about 1/16th their
  1555. original length. A very simple counting argument shows that this is impossible,
  1556. regardless of the compression method. It is even impossible to guarantee
  1557. lossless compression of all files by at least one bit. (Many other proofs have
  1558. been posted on comp.compression, please do not post yet another one.)
  1559.  
  1560. Assume that the program can compress without loss all files of size >= N bits.
  1561. Compress with this program all the 2^N files which have exactly N bits.  All
  1562. compressed files have at most N-1 bits, so there are at most (2^N)-1 different
  1563. compressed files [2^(N-1) files of size N-1, 2^(N-2) of size N-2, and so on,
  1564. down to 1 file of size 0]. So at least two different input files must compress
  1565. to the same output file.  Hence the compression program cannot be
  1566. lossless. (Much stronger results about the number of incompressible files can
  1567. be obtained, but the proofs are a little more complex.)
  1568.  
  1569. This argument applies of course to WEB's case (take N = 64K*8 bits).  Note that
  1570. no assumption is made about the compression algorithm.  The proof applies to
  1571. *any* algorithm, including those using an external dictionary, or repeated
  1572. application of another algorithm, or combination of different algorithms, or
  1573. representation of the data as formulas, etc... All schemes are subject to the
  1574. counting argument.  There is no need to use information theory to provide a
  1575. proof, just basic mathematics. [People interested in more elaborate proofs can
  1576. consult http://wwwvms.utexas.edu/~cbloom/news/nomagic.html ]
  1577.  
  1578. This assumes of course that the information available to the decompressor is
  1579. only the bit sequence of the compressed data. If external information such as a
  1580. file name, a number of iterations, or a bit length is necessary to decompress
  1581. the data, the bits necessary to provide the extra information must be included
  1582. in the bit count of the compressed data.  Otherwise, it would be sufficient to
  1583. consider any input data as a number, use this as the file name, iteration count
  1584. or bit length, and pretend that the compressed size is zero.  For an example of
  1585. storing information in the file name, see the program lmfjyh in the 1993
  1586. International Obfuscated C Code Contest, available on all comp.sources.misc
  1587. archives (Volume 39, Issue 104).
  1588.  
  1589. A common flaw in the algorithms claimed to compress all files is to assume that
  1590. arbitrary bit strings can be sent to the decompressor without actually
  1591. transmitting their bit length. If the decompressor needs such bit lengths
  1592. to decode the data (when the bit strings do not form a prefix code), the
  1593. number of bits needed to encode those lengths must be taken into account
  1594. in the total size of the compressed data.
  1595.  
  1596. Another common (but still incorrect) argument is to assume that for any file,
  1597. some still to be discovered algorithm might find a seed for a pseudo-random
  1598. number generator which would actually generate the whole sequence of bytes
  1599. contained in the file. However this idea still fails to take into account the
  1600. counting argument. For example, if the seed is limited to 64 bits, this
  1601. algorithm can generate at most 2^64 different files, and thus is unable to
  1602. compress *all* files longer than 8 bytes.
  1603.  
  1604. Steve Tate <srt@cs.unt.edu> suggests a good challenge for programs
  1605. that are claimed to compress random data by a significant amount:
  1606.  
  1607.     Here's a wager for you: First, send me the DEcompression algorithm.  Then I
  1608.     will send you a file of whatever size you want, but at least 100k.  If you
  1609.     can send me back a compressed version that is even 20% shorter (80k if the
  1610.     input is 100k) I'll send you $100.  Of course, the file must be able to be
  1611.     decompressed with the program you previously sent me, and must match
  1612.     exactly my original file.  Now what are you going to provide
  1613.     when... er... if you can't demonstrate your compression in such a way?
  1614.  
  1615. So far no one has accepted this challenge (for good reasons).
  1616.  
  1617.  
  1618. 9.3 The WEB 16:1 compressor
  1619.  
  1620. 9.3.1 What the press says
  1621.  
  1622. April 20, 1992  Byte Week Vol 4. No. 25:
  1623.  
  1624.    "In an announcement that has generated high interest - and more than a
  1625.    bit of skepticism - WEB Technologies (Smyrna, GA) says it has
  1626.    developed a utility that will compress files of greater than 64KB in
  1627.    size to about 1/16th their original length.  Furthermore, WEB says its
  1628.    DataFiles/16 program can shrink files it has already compressed."
  1629.    [...]
  1630.    "A week after our preliminary test, WEB showed us the program successfully
  1631.    compressing a file without losing any data.  But we have not been able
  1632.    to test this latest beta release ourselves."
  1633.    [...]
  1634.    "WEB, in fact, says that virtually any amount of data can be squeezed 
  1635.    to under 1024 bytes by using DataFiles/16 to compress its own output
  1636.    multiple times."
  1637.  
  1638. June 1992 Byte, Vol 17 No 6:
  1639.  
  1640.    [...] According to Earl Bradley, WEB Technologies' vice president of
  1641.    sales and marketing, the compression algorithm used by DataFiles/16
  1642.    is not subject to the laws of information theory. [...]
  1643.       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  1644.  
  1645. 9.3.2 First details, by John Wallace <buckeye@spf.trw.com>
  1646.  
  1647. I called WEB at (404)514-8000 and they sent me some product
  1648. literature as well as chatting for a few minutes with me on the phone.
  1649. Their product is called DataFiles/16, and their claims for it are
  1650. roughly those heard on the net.
  1651.  
  1652. According to their flier:
  1653.  
  1654. "DataFiles/16 will compress all types of binary files to approximately
  1655. one-sixteenth of their original size ... regardless of the type of
  1656. file (word processing document, spreadsheet file, image file,
  1657. executable file, etc.), NO DATA WILL BE LOST by DataFiles/16."
  1658. (Their capitalizations; 16:1 compression only promised for files >64K
  1659. bytes in length.)
  1660.  
  1661. "Performed on a 386/25 machine, the program can complete a
  1662. compression/decompression cycle on one megabyte of data in less than
  1663. thirty seconds"
  1664.  
  1665. "The compressed output file created by DataFiles/16 can be used as the 
  1666. input file to subsequent executions of the program.  This feature of 
  1667. the utility is known as recursive or iterative compression, and will 
  1668. enable you to compress your data files to a tiny fraction of the 
  1669. original size.  In fact, virtually any amount of computer data can 
  1670. be compressed to under 1024 bytes using DataFiles/16 to compress its 
  1671. own output files muliple times.  Then, by repeating in reverse the 
  1672. steps taken to perform the recusive compression, all original data 
  1673. can be decompressed to its original form without the loss of a single 
  1674. bit."
  1675.  
  1676. Their flier also claims: 
  1677.  
  1678. "Constant levels of compression across ALL TYPES of FILES"
  1679. "Convenient, single floppy DATA TRANSPORTATION"
  1680.  
  1681. From my telephone conversation, I was assured that this is an
  1682. actual compression program.  Decompression is done by using only the 
  1683. data in the compressed file; there are no hidden or extra files.
  1684.  
  1685.  
  1686. 9.3.3 More information, by Rafael Ramirez <rafael.ramirez@channel1.com>:
  1687.  
  1688.    Today (Tuesday, 28th) I got a call from Earl Bradley of Web
  1689. who now says that they have put off releasing a software version of
  1690. the algorithm because they are close to signing a major contract with
  1691. a big company to put the algorithm in silicon.  He said he could not
  1692. name the company due to non-disclosure agreements, but that they had
  1693. run extensive independent tests of their own and verified that the
  1694. algorithm works. [...]
  1695.  
  1696. He said the algorithm is so simple that he doesn't want anybody
  1697. getting their hands on it and copying it even though he said they
  1698. have filed a patent on it. [...] Mr. Bradley said the silicon version
  1699. would hold up much better to patent enforcement and be harder to copy.
  1700.  
  1701.    He claimed that the algorithm takes up about 4K of code, uses only
  1702. integer math, and the current software implementation only uses a 65K
  1703. buffer.  He said the silicon version would likely use a parallel
  1704. version and work in real-time. [...]
  1705.  
  1706.  
  1707. 9.3.4 No software version
  1708.  
  1709. Appeared on BIX, reposted by Bruce Hoult <Bruce.Hoult@actrix.gen.nz>:
  1710.  
  1711. tojerry/chaos #673, from abailey, 562 chars, Tue Jun 16 20:40:34 1992
  1712. Comment(s). 
  1713. ----------
  1714. TITLE: WEB Technology
  1715. I promised everyone a report when I finally got the poop on WEB's
  1716. 16:1 data compression. After talking back and forth for a year
  1717. and being put off for the past month by un-returned phone calls,
  1718. I finally got hold of Marc Spindler who is their sales manager.
  1719.  
  1720. _No_ software product is forth coming, period!
  1721.  
  1722. He began talking about hardware they are designing for delivery
  1723. at the end of the year. [...]
  1724.  
  1725.  
  1726. 9.3.5 Product cancelled
  1727.  
  1728. Posted by John Toebes <toebes@bnr.ca> on Aug 10th, 1992:
  1729.  
  1730. [Long story omitted, confirming the reports made above about the
  1731. original WEB claims.]
  1732.  
  1733. 10JUL92 - Called to Check Status.  Was told that testing had uncovered a
  1734.           new problem where 'four numbers in a matrix were the same
  1735.           value' and that the programmers were off attempting to code a
  1736.           preprocessor to eliminate this rare case.  I indicated that he
  1737.           had told me this story before.  He told me that the
  1738.           programmers were still working on the problem.
  1739.  
  1740. 31JUL92 - Final Call to Check Status.  Called Earl in the morning and
  1741.           was told that he still had not heard from the programmers. [...]
  1742.           Stated that if they could not resolve the problem then there would
  1743.           probably not be a product.
  1744.  
  1745. 03AUG92 - Final Call.  Earl claims that the programmers are unable to
  1746.           resolve the problem.  I asked if this meant that there would
  1747.           not be a product as a result and he said yes.
  1748.  
  1749.  
  1750. 9.4 Jules Gilbert
  1751.  
  1752. As opposed to WEB Technologies, Jules Gilbert <coffee@spock.ici.net> does not
  1753. claim to compress *all* files, but only "random or random-appearing" files.
  1754. Here are some of his articles posted to compr.compression; to keep this section
  1755. to a reasonable size, some parts marked with [...] have been removed.  The demo
  1756. mentioned in the first article has been canceled 6 days later.  No comments or
  1757. conclusion are given here since this thread is still going on in
  1758. comp.compression at the time of writing.
  1759.  
  1760.   From: coffee@spock.ici.net (Jules Gilbert)
  1761.   Newsgroups: comp.compression
  1762.   Subject: Re: No Magic Compressors, No Factoring Compressors, Jules Gilbert
  1763.     is a liar
  1764.   Date: 14 May 1996 03:13:31 -0400
  1765.   Message-ID: <4n9bqr$89k@spock.ici.net>
  1766.  
  1767.   [...]
  1768.   I will, in front of several Boston area computer scientists ('monitors'),
  1769.   people I choose but generally known to be fair and competent, under
  1770.   conditions which are sufficient to prevent disclosure of the method and fully
  1771.   protect the algorithm and other aspects of the underlying method from
  1772.   untoward discovery, use two computers, (which I am permitted to examine but
  1773.   not alter) with both machine's running Linux, and with the file-systems and
  1774.   Linux OS freshly restored from commercial CD-ROM's do the following:
  1775.  
  1776.   On one machine (the 'src-CPU') will be loaded a copy of the CALGARY-CORPUS.
  1777.   (Or other agreed on '.ZIP' or '.ARJ' file.)
  1778.  
  1779.   I will compress the CALGARY-CORPUS for transfer from the src-CPU onto 3.5"
  1780.   disks and transfer it (by sneaker-net) to the other machine for decompression
  1781.   and produce a perfect copy of the CORPUS file on the 'dst-CPU'.
  1782.  
  1783.   The CORPUS archive contents will not be 'cracked', ie', the original CORPUS
  1784.   can be encrypted and the password kept from me.  All I care about is that the
  1785.   input file is highly random-aprearing.
  1786.  
  1787.   I claim that I can perform this process several times, and each iteration
  1788.   will reduce the overall file by at least 50%, ie., a ratio of 2:1.  An
  1789.   'iteration' will constitute copying, using compression, from the src-CPU to
  1790.   the dst-CPU, and then reversing the direction to achieve another iteration.
  1791.  
  1792.   For example, for say a 4M input file, it is reasonable to expect an
  1793.   approximately 1M output file, after two complete iterations.
  1794.   [...]
  1795.   ONLY RANDOM OR RANDOM-APPEARING DATA INPUT CAN BE COMPRESSED BY MY METHOD.
  1796.   [...]
  1797.   If one iteration (of the compression 'sandwich') consists of two parts, say
  1798.   an LZ phase followed by a JG phase, the LZ method will compression by
  1799.   perhaps a ration of 2:1 (at the first iteration), perhaps much better if the
  1800.   input is text, and the JG phase will do 3-4:1, but slowly!!  During
  1801.   subsequent iterations, the LZ phase will do perhaps 1.25:1 and the JG phase
  1802.   will continue to do about 3-4:1.
  1803.  
  1804.   Experimentally, I have achieved compression results of nearly 150:1, overall,
  1805.   ^^^^^^^^^^^^^^                                                ^^^^^
  1806.   for a 60M file.  (I started with a '.arj' archive of a large DOS partition.)
  1807.   [...]
  1808.   ----------------------------------------------------------------------------
  1809.   From: coffee@spock.ici.net (Jules Gilbert)
  1810.   Newsgroups: comp.compression
  1811.   Subject: Re: Explanation: that uh, alg thing...
  1812.   Date: 15 May 1996 16:38:18 -0400
  1813.   Message-ID: <4ndfbq$cf3@spock.ici.net>
  1814.  
  1815.   [...]
  1816.   One more thing, I am preparing a short technical note to deal with the reason
  1817.   most programmers' and computer scientists' think it's impossible to (further)
  1818.   compress random input.  (Many people think that because you can't get more
  1819.   than 2^N messages from a N-bit compressed msg, that it means that you can't
  1820.   compress random input.  (Lot's of folks have told me that.)  The short story
  1821.   is:
  1822.  
  1823.   I agree that you can not get more than 2^N messages from N bits.  No question
  1824.   about it.  BUT THAT STATMENT HAS NOTHING TO DO WHATSOEVER WITH THE
  1825.   INTERPRETATION OF WHAT THOSE BITS 'MEAN'.
  1826.   [...]
  1827.   ----------------------------------------------------------------------------
  1828.   From: coffee@spock.ici.net (Jules Gilbert)
  1829.   Newsgroups: comp.compression
  1830.   Subject: Seeing is believing!
  1831.   Date: 9 Jun 1996 03:20:52 -0400
  1832.   Message-ID: <4pdu0k$otg@spock.ici.net>
  1833.  
  1834.   [...]
  1835.   If your firm needs industrial-strength compression, contact 'coffee@ici.net'
  1836.   and ask us for an on-site demonstration of our MR2 compressors.  Each can
  1837.   compress large files of 'random-appearing' information, whether RSA-encrypted
  1838.   blocks, or files already compressed using LZ-techniques.
  1839.  
  1840.   Our demonstration will give you the opportunity to observe compression of
  1841.   'random-appearing' files of at least 100MB by at least 3:1 per iteration.
  1842.   Usually, several iterations are possible.  (These are minimum figures easily
  1843.   exceeded.)
  1844.   [...]
  1845.   ----------------------------------------------------------------------------
  1846.   From: coffee@spock.ici.net (Jules Gilbert)
  1847.   Newsgroups: comp.compression
  1848.   Subject: Re: My remarks on Jules Gilbert
  1849.   Date: 24 Jul 1996 18:05:44 -0400
  1850.   Message-ID: <4t66no$9qq@spock.ici.net>
  1851.  
  1852.   [...]
  1853.   My claims can not possibly be true IF I'M PLAYING BY THE 'RULES' THAT YOU
  1854.   ASSUME APPLY TO ME.  (Sorry to shout).
  1855.  
  1856.   Clearly, anyone sending a signal (in the Shannon context), is constrained by
  1857.   limits which make it impossible to compress RAD ('random-appearing data')
  1858.   input.
  1859.   [...]
  1860.   1)  I can't compress bits any better than the next guy.  Maybe not as well,
  1861.       in fact.  
  1862.  
  1863.   2)  I have designed an engine that accepts RAD input and emits far too little
  1864.       data to reconstitute the original data, based on conventional
  1865.       assumptions. Okay!   I know this.
  1866.  
  1867.   3)  But, I none-the-less reconstitute the original data.
  1868.   [...]
  1869.   ----------------------------------------------------------------------------
  1870.   From: coffee@soran.ici.net (Jules Gilbert)
  1871.   Newsgroups: comp.compression
  1872.   Subject: Re: Jules Gilbert's New Compresssion Technology
  1873.   Date: 12 Aug 1996 08:11:10 -0400
  1874.   Message-ID: <4un70u$a2r@soran.ici.net>
  1875.  
  1876.   I have multiple methods for compressing RAD.  Watch carefully:
  1877.  
  1878.   MR1 does 3:1, on large buffers and is repeatable until the volume of input
  1879.   data falls below 128k or so.  (This figure is under user control, but
  1880.   compreesion quality will suffer as the buffer size is decreased).  Recent
  1881.   changes make this method about as fast as any conventional compressor.
  1882.  
  1883.   MR2 does at least 6:1, with a minimum buffer size of perhaps 32k.  It is also
  1884.   repeatable.  MR2 does not actually compress, though.  Instead, it translates
  1885.   an input buffer into an output buffer of roughly equivalent size.  This
  1886.   output buffer contains mostly constants, and other things, such as simple
  1887.   sequences: 28,29,31,32,33,35,40,41,42,43,44,45.  (An actual sequence of
  1888.   bytes).  Obviously, this kind of information is readily compressed, and that
  1889.   is why I claim that MR2 can achieve a minimum of 6:1.  Again, like MR1, this
  1890.   process can be re-applied over it's own output.
  1891.  
  1892.   When, I've said, "No, it's impossible to compress by 100:1" I was trying to
  1893.   get this audience to see this as realistic.  But I can compress RAD files
  1894.   100:1 if allowed to re-process the output through the same process.  I first
  1895.   actually achieved a 100:1 compression level in March of this year using tools
  1896.   ^^^^^^^^^^^^^^^^^^^^^^^^^
  1897.   designed for experimenting in RAD issues.  But now I have C programs which
  1898.   have been written to be easy to understand and are intended to be part of my
  1899.   technology transfer process for clients.
  1900.   [...]
  1901.   So, can someone compress by 100:1 or even 1000:1?  Yes! But ONLY if the input
  1902.   file is sufficiently large.  A 1000:1 compression ratio would require a very
  1903.   large input file, and, at least for PC users, archive files of this size are
  1904.   almost never produced.
  1905.   ----------------------------------------------------------------------------
  1906.   From: coffee@soran.ici.net (Jules Gilbert)
  1907.   Newsgroups: comp.compression
  1908.   Subject: Re: Gilbert's RAD compression product
  1909.   Date: 18 Aug 1996 08:40:28 -0400
  1910.   Message-ID: <4v72vs$quc@soran.ici.net>
  1911.  
  1912.   [...]
  1913.   (In my original remarks), I am quoted above as claiming that a 3,152,896 byte
  1914.   'tar 'file (conventionally compressed to 1,029,790 bytes) can be compressed
  1915.   to 50*1024 bytes.  It's an accurate quote.
  1916.  
  1917.   Now how can that be possible?
  1918.  
  1919.   If a gzip compressed version of the Corpus requires roughly a 1MB, what do I
  1920.   do with the 950k bytes I don't store in the compressed intermediate file?
  1921.  
  1922.   Well, that's certainly a puzzler!
  1923.  
  1924.   For now, all I will say is that it does not go into the compressed
  1925.   intermediate file.  And because it doesn't, Shannons' channel capacity axioms
  1926.   apply only to the 50k component.
  1927.  
  1928.  
  1929. 9.5 David C. James
  1930.  
  1931. In July 96, David C. James was granted patent 5,533,051 "Method for data
  1932. compression" for a method claimed to be effective even on random data.  No
  1933. comments or conclusion are given here since this thread is still going on in
  1934. comp.compression at the time of writing.
  1935.  
  1936.   From: u137@aol.com (Peter J. Cranstone)
  1937.   Newsgroups: comp.compression
  1938.   Subject: Re: Jules Gilbert's Compression Technology
  1939.   Date: Sun Aug 18 12:48:11 EDT 1996
  1940.  
  1941.   Wh have just been issued a patent (US. #5,533,051) and have several more
  1942.   pending on a new method for data compression. It will compess all types of
  1943.   data, including "random", and data containing a uniform distribution of
  1944.   "0's" and "1's".
  1945.   [...]
  1946.  
  1947. Here is the abstract for patent 5,533,051:
  1948.  
  1949.   Methods for compressing data including methods for compressing highly
  1950.   randomized data are disclosed. Nibble encode, distribution encode, and direct
  1951.   bit methods are disclosed for compressing data which is not highly
  1952.   randomized. A randomized data compression routine is also disclosed and is
  1953.   very effective for compressing data which is highly randomized. All the
  1954.   compression methods disclosed operate on a bit level and accordingly are
  1955.   insensitive to the nature or origination of the data sought to be compressed.
  1956.   Accordingly the methods of the present invention are universally applicable
  1957.   to any form of data regardless of its source of origination. 
  1958.  
  1959. ------------------------------------------------------------------------------
  1960.  
  1961. Subject: [10] Fake compression programs (OWS, WIC)
  1962.  
  1963.  
  1964. Some programs claimed to achieve incredible compression ratios are completely
  1965. fake: they do not compress at all but just stored the uncompressed data in
  1966. hidden files on the hard disk or keep it in unused clusters. Needless to say,
  1967. such programs are dangerous and should never be used because there is a
  1968. significant risk of losing all the data.
  1969.  
  1970. The OWS program just remembers which clusters contained the data on the hard
  1971. disk. The data can be recovered only if those clusters are not used again for
  1972. another file.
  1973.  
  1974. The WIC program searches for the first directory in drive C: and creates a
  1975. hidden file called WINFILE.DLL containing a copy of all the original files.
  1976. If you copy the compressed file to another computer (which doesn't have the
  1977. file WINFILE.DLL), WIC reports a CRC error.
  1978.  
  1979. ------------------------------------------------------------------------------
  1980.  
  1981. Subject: [11] What is the V.42bis standard?
  1982.  
  1983.  
  1984. A description of the V.42bis standard is given in "The V.42bis
  1985. standard for data-compressing modems," by Clark Thomborson
  1986. <cthombor@theory.lcs.mit.edu>, IEEE Micro, Oct 1992, pp. 41-53. 
  1987.  
  1988. Short introduction, by Alejo Hausner <hausner@qucis.queensu.ca>:
  1989.  
  1990.   The V.42bis Compression Standard was proposed by the International
  1991.   Consultative Committee on Telephony and Telegraphy (CCITT, now ITU-T) as
  1992.   an addition to the v.42 error-correction protocol for modems. Its purpose
  1993.   is to increase data throughput, and uses a variant of the
  1994.   Lempel-Ziv-Welch (LZW) compression method.  It is meant to be
  1995.   implemented in the modem hardware, but can also be built into the
  1996.   software that interfaces to an ordinary non-compressing modem.
  1997.  
  1998.   V.42bis can send data compressed or not, depending on the
  1999.   data.  There are some types of data that cannot be
  2000.   compressed.  For example, if a file was compressed first,
  2001.   and then sent through a V.42bis modem, the modem would not
  2002.   likely reduce the number of bits sent.  Indeed it is likely
  2003.   that the amount of data would increase somewhat.
  2004.  
  2005.   To avoid this problem, the algorithm constantly monitors the
  2006.   compressibility of the data, and if it finds fewer bits
  2007.   would be necessary to send it uncompressed, it switches to
  2008.   transparent mode.  The sender informs the receiver of this
  2009.   transition through a reserved code word.  Henceforth the
  2010.   data is passed as plain bytes.
  2011.  
  2012.   While transmitting in transparent mode, the sender maintains
  2013.   the LZW trees of strings, and expects the receiver to do
  2014.   likewise.  If it finds an advantage in returning to
  2015.   compressed mode, it will do so, first informing the receiver
  2016.   by a special escape code.  Thus the method allows the
  2017.   hardware to adapt to the compressibility of the data.
  2018.  
  2019.   The choice of escape code is clever.  Initially, it is a
  2020.   zero byte.  Any occurrence of the escape code is replaced,
  2021.   as is customary, by two escape codes.  In order to prevent a
  2022.   string of escape codes from temporarily cutting throughput
  2023.   in half, the escape code is redefined by adding 51 mod 256
  2024.   each time it is used.
  2025.  
  2026.  
  2027. A note from Peter Gutman <pgut01@cs.auckland.ac.nz> about V.42bis
  2028. implementations:
  2029.  
  2030.   V.42bis is covered by patents, and the licensing terms are rather complex
  2031.   because you need to license it from multiple organisations.  At one point
  2032.   British Telecom were charging something like 30,000 pounds for a license
  2033.   (this was a few years ago, things may have changed since then). Because of
  2034.   this, noone has ever implemented a freely-available version of V.42bis as
  2035.   you'd find in a modem.  There is a Unix implementation (called "compact") of
  2036.   a V.42bis-like algorithm which comes with a great many disclaimers that it
  2037.   can only be used for research purposes. [Note from FAQ maintainer: "compact"
  2038.   is available in
  2039.      http://ftp.sunet.se/ftp/pub/usenet/comp.sources.misc/volume15/compact_sv/
  2040.   The 'shrink' method of zip 1.1 (see item 2 above) is also similar to V.42bis]
  2041.  
  2042.   If you've ever wondered why noone other than modem manufacturers ever use
  2043.   V.42bis for anything, this is it.  
  2044.  
  2045.  
  2046. The CCITT (ITU-T) standards documents used to be available by ftp on
  2047. ftp.uu.net in /doc/standards/ccitt, but this service has been
  2048. discontinued. If you ftp to digital.resource.org, in directory
  2049. pub/standards there is a file that says that making the standards
  2050. available in the first place was just an experiment.
  2051.  
  2052. The documents are now on src.doc.ic.ac.uk, but the directory name
  2053. keeps changing. Check one of:
  2054.   /computing/ccitt/ccitt-standards/ccitt/
  2055.   /computing/ccitt/standards/ccitt
  2056.   /doc/ccitt-standards/ccitt
  2057. in this order. The v42bis standard is in *standards/ccitt/1992/v/v42bis.asc.Z.
  2058.  
  2059. See also item 20 below for other sites with standards documents.
  2060.  
  2061. A mail server for CCITT (ITU-T) documents is available at teledoc@itu.arcom.ch
  2062. or itudoc@itu.ch. A Gopher server is also available at gopher://info.itu.ch
  2063.  
  2064. See also the Standards FAQ posted to news.answers or get it by ftp in
  2065. ftp://rtfm.mit.edu/pub/usenet/news.answers/standards-faq
  2066.  
  2067. For ISO documents, try http://www.iso.ch/
  2068.  
  2069. ------------------------------------------------------------------------------
  2070.  
  2071. Subject: [12] I need source for the winners of the Dr Dobbs compression contest
  2072.  
  2073.  
  2074. The source of the top 6 programs of the Feb 91 Dr Dobbs data compression
  2075. contest are available by ftp on
  2076.   ftp://ftp.coast.net/mirrors/SimTel/msdos/compress/ddjcompr.zip
  2077.   ftp://garbo.uwasa.fi/pc/source/ddjcompr.zip
  2078.  
  2079. The sources are in MSDOS end-of-line format, one directory per
  2080. program.  Unix or VMS users, use "unzip -a ddjcompr" to get correct
  2081. end-of-lines (add -d to recreate the directory structure if you are
  2082. using an obsolete version of unzip such as 4.1). Three of the 6
  2083. programs are not portable and only run on MSDOS. compact and urban
  2084. work on Unix, sixpack only requires minor modifications.
  2085.  
  2086. ------------------------------------------------------------------------------
  2087.  
  2088. Subject: [13] I need source for arithmetic coding
  2089.  
  2090.  
  2091. (See question 70 for an introduction to arithmetic coding.)
  2092.  
  2093. The source for the arithmetic coder described in Chap.5 of Bell,
  2094. Cleary, and Witten's book "Text Compression" (see question 7 above)
  2095. (or, equivalently, in: Witten, Neal, and Cleary's article "Arithmetic
  2096. Coding for data Compression" from Communications of the Association
  2097. for Computing Machinery, 30 (6), pp.520-540, June, 1987) is available
  2098. via anonymous ftp from ftp.cpsc.ucalgary.ca (136.159.7.18) in directory
  2099. /pub/projects/ar.cod.  It only comes with a simple order-0 model
  2100. but it's set up so that adding your own more sophisticated one is
  2101. straightforward. Look also in ftp://munnari.mu.oz.au/pub/arith_coder
  2102.  
  2103. A low precision arithmetic coding implementation avoiding hardware
  2104. division is available on the same site (ftp.cpsc.ucalgary.ca) in
  2105. /pub/projects/arithmetic.coding/low.precision.version, file
  2106. low.precision.version.shar.
  2107.  
  2108. Kris Popat <popat@image.mit.edu> has worked on "Scalar Quantization
  2109. with Arithmetic Coding."  It describes an arithmetic coding technique
  2110. which is quite general and computationally inexpensive.  The
  2111. documentation and example C code are available via anonymous ftp from
  2112. media-lab.media.mit.edu (18.85.0.2), in /pub/k-arith-code.
  2113.  
  2114. The program 'urban' in ddjcompr.zip (see item 12 above) is a high order
  2115. arithmetic coder working at the bit level. It is written by Urban Koistinen
  2116. <md85-epi@nada.kth.se>.
  2117.  
  2118. The DMC program is available in ftp://plg.uwaterloo.ca/pub/dmc/*.c. It
  2119. implements the algorithm described in "Data Compression using Dynamic
  2120. Markov Modelling", by Gordon Cormack and Nigel Horspool, Computer
  2121. Journal 30:6 (December 1987).  This program uses Guazzo's version of
  2122. arithmetic coding.
  2123.  
  2124. ------------------------------------------------------------------------------
  2125.  
  2126. Subject: [15] Where can I get image compression programs?
  2127.  
  2128.  
  2129. JPEG:
  2130.     Source code for most any machine:
  2131.     ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6a.tar.gz
  2132.     ftp://nic.funet.fi/pub/graphics/packages/jpeg/jpegsrc.v6.tar.gz
  2133.     Contact: jpeg-info@uunet.uu.net (Independent JPEG Group)
  2134.  
  2135.     havefun.stanford.edu:pub/jpeg/JPEGv1.2.1.tar.Z (supports lossless mode)
  2136.     Contact: Andy Hung <achung@cs.stanford.edu> (see item 20 below)
  2137.  
  2138.     ftp://ftp.cs.cornell.edu/pub/multimed/ljpg.tar.Z (lossless jpeg)
  2139.  
  2140.     xv, an image viewer which can read JPEG pictures, is available in
  2141.     ftp://ftp.cis.upenn.edu/pub/xv/xv-3.10a.tar.Z
  2142.  
  2143. MPEG:
  2144.     ftp://havefun.stanford.edu/pub/mpeg/MPEGv1.2.1.tar.Z
  2145.     Contact: Andy Hung <achung@cs.stanford.edu> (see item 20 below)
  2146.  
  2147.     ftp://mm-ftp.cs.berkeley.edu/pub/multimedia/mpeg/play/
  2148.                                                mpeg_play-2.3-patched-src.tar.gz
  2149.     Contact: mpeg-bugs@cs.berkeley.edu
  2150.  
  2151.     ftp://flash.bu.edu/pub/code/mpeg_system/mpeg_system_source_v1.0.tar.gz
  2152.     (MPEG-I Multi-Stream System Layer encoder/player; includes an
  2153.      enhanced version of mpeg_play)
  2154.     Contact: Jim Boucher <jboucher@spiderman.bu.edu> or Ziv Yaar <zyaar@bu.edu>
  2155.  
  2156.     ftp://ftp.mni.mcgill.ca/pub/mpeg/mpeg_lib-1.2.tar.gz [MPEG library]
  2157.     Contact: Gregory Ward <greg@pet.mni.mcgill.ca>
  2158.  
  2159.     ftp://ftp.netcom.com/pub/cfogg/mpeg/vmpeg/vmpeg17.exe
  2160.       Contact: Stefan Eckart <stefan@lis.e.technik.tu-muenchen.de>
  2161.     ftp://decel.ecel.uwa.edu.au/users/michael/mpegw32f.zip (for Windows and NT)
  2162.  
  2163.     ftp://nvr.com/pub/NVR-software/Product-1.0.4.tar.Z
  2164.     (free demo copy of NVR's software toolkit for SPARCstations)
  2165.     Contact: Todd Brunhoff <toddb@nvr.com>
  2166.  
  2167.     ftp://ftp.netcom.com/pub/cfogg/mpeg2/* (MPEG-2 encoder and decoder)
  2168.     Contact: MPEG-L@netcom.com (MPEG Software Simulation Group)
  2169.  
  2170. H.261(P*64):
  2171.     havefun.stanford.edu:pub/p64/P64v1.2.tar.Z
  2172.     Contact: Andy Hung <achung@cs.stanford.edu> (see item 20 below)
  2173.  
  2174.     ftp://zenon.inria.fr/rodeo/ivs/last_version/ivs*-src.tar.gz
  2175.     (Inria videoconference system)
  2176.     Contact: Thierry Turletti <turletti@sophia.inria.fr> (see item 20 below).
  2177.  
  2178. H.263: (by Telenor Research)
  2179.     http://www.nta.no/brukere/DVC/h263_software
  2180.  
  2181. JBIG:
  2182.     ftp://nic.funet.fi/pub/graphics/misc/test-images/jbig.tar.gz.
  2183.  
  2184.     ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/JBIG/jbigkit-0.9.tar.gz
  2185.     Contact: Markus Kuhn <mskuhn@cip.informatik.uni-erlangen.de>
  2186.  
  2187. PNG: For code and sample images, see:
  2188.     http://quest.jpl.nasa.gov/PNG/
  2189.     ftp://ftp.uu.net/graphics/png/
  2190.     ftp://swrinde.nde.swri.edu/pub/png/
  2191.  
  2192. mg: (the MG system for compressing and indexing text and images, see item 16)
  2193.     ftp://munnari.oz.au/pub/mg/*
  2194.     Contact: Stuart Inglis <singlis@cs.waikato.ac.nz>
  2195.  
  2196. BTPC: Binary Tree Predictive Coding
  2197.     ftp://monet.uwaterloo.ca/pub/john/btpcv3.tar.Z
  2198.     Contact: John Robinson <john@monet.uwaterloo.ca>
  2199.  
  2200. epic: (pyramid wavelet coder, see item 72)
  2201.     ftp://whitechapel.media.mit.edu/pub/epic.tar.Z
  2202.     Contact: Eero P. Simoncelli <eero@media.mit.edu>
  2203.     The "Lenna" test image is available as part of the EPIC package,
  2204.     where it is named "test_image".
  2205.  
  2206. hcompress: (wavelet image compression, see item 72)
  2207.     ftp://stsci.edu/software/hcompress/hcompress.tar.Z
  2208.  
  2209. wavethresh: (wavelet software for the language S)
  2210.     ftp://gdr.bath.ac.uk/pub/masgpn/wavethresh2.2.Z
  2211.     Contact: gpn@maths.bath.ac.uk
  2212.  
  2213. rice-wlet: (wavelet software, see item 72)
  2214.     ftp://cml.rice.edu/pub/dsp/software/rice-wlet-tools.tar.Z
  2215.  
  2216. scalable: (2 & 3 dimensional subband transformation)
  2217.     ftp://robotics.eecs.berkeley.edu/pub/multimedia/scalable2.tar.Z
  2218.     Contact: scalable@robotics.eecs.berkeley.edu
  2219.  
  2220. compfits:
  2221.     ftp://uwila.cfht.hawaii.edu/pub/compfits/compfits.tar.Z
  2222.     Contact: Jim Wright <jwright@cfht.hawaii.edu>
  2223.  
  2224. fitspress:
  2225.     ftp://cfata4.harvard.edu/pub/fitspress08.tar.Z
  2226.  
  2227. tiff:
  2228.     For source and sample images, see question 18 below.
  2229.  
  2230. DCT algorithms:
  2231.     ftp://etro.vub.ac.be/pub/DCT_ALGORITHMS/*
  2232.     Contact: Charilos Christopoulos <chchrist@etro2.vub.ac.be>
  2233.  
  2234. xanim: (X11 animation viewer, supports Quicktime and several other formats)
  2235.     ftp://ftp.x.org/contrib/applications/xanim2683.tar.Z
  2236.     ftp://ftp.shell.portal.com/pub/podlipec/xanim26978.tar.gz
  2237.  
  2238. ppm2pz: (lossless 24-bit image compression)
  2239.     http://www.jyu.fi/~kuru/compression.html
  2240.  
  2241. A demo of image compression using neural networks is available in
  2242. http://www.ee.duke.edu/~cec/index.html.
  2243.  
  2244. For fractal compression programs, see item 17 below.
  2245. For Vector Quantization software, see item 76 in part 2 of this FAQ.
  2246. For image compression hardware, see item 85 in part 3 of this FAQ.
  2247.  
  2248. ------------------------------------------------------------------------------
  2249.  
  2250. Subject: [16] What is the state of the art in lossless image compression?
  2251.  
  2252.  
  2253. The current state-of-the-art is the JBIG algorithm.  For an
  2254. introduction to JBIG, see question 74 in part 2.
  2255.  
  2256. JBIG works best on bi-level images (like faxes) and also works well on
  2257. Gray-coded grey scale images up to about six or so bits per pixel.  You
  2258. just apply JBIG to the bit planes individually.  For more bits/pixel,
  2259. lossless JPEG provides better performance, sometimes. (For JPEG, see
  2260. question 19 below.)
  2261.  
  2262. You can find the specification of JBIG in International Standard
  2263. ISO/IEC 11544 or in ITU-T Recommendation T.82. You can order a copy
  2264. directly from ISO (www.iso.ch) or ITU (www.itu.ch) or from your
  2265. National Standards Body. In the USA, call ANSI at (212) 642-4900.
  2266.  
  2267. See also the MG system containing an implementation of the 'FELICS'
  2268. algorithm of P.G. Howard and J.S. Vitter.  FELICS usually gives better
  2269. and faster compression than lossless JPEG, at least for 8-bit
  2270. grayscale images. (See item 15 above for ftp location). From the MG
  2271. README file:
  2272.  
  2273.   The MG system is a suite of programs for compressing and
  2274.   indexing text and images. Most of the functionality implemented
  2275.   in the suite is as described in the book ``Managing Gigabytes:
  2276.   Compressing and Indexing Documents and Images'', I.H. Witten, A.
  2277.   Moffat, and T.C. Bell; Van Nostrand Reinhold, New York, 1994, ISBN
  2278.   0-442-01863-0; US $54.95; call 1 (800) 544-0550 to order.
  2279.  
  2280.   These features include:
  2281.  
  2282.   -- text compression using a Huffman-coded semi-static word-based
  2283.      scheme
  2284.   -- two-level context-based compression of bi-level images
  2285.   -- FELICS lossless compression of gray-scale images
  2286.   -- combined lossy/lossless compression for textual images
  2287.   -- indexing algorithms for large volumes of text in limited main
  2288.      memory
  2289.   -- index compression
  2290.   -- a retrieval system that processes Boolean and ranked queries
  2291.   -- an X windows interface to the retrieval system
  2292.  
  2293. Paul Howard's PhD thesis, which among other things describes FELICS,
  2294. is available in ftp://ftp.cs.brown.edu/pub/techreports/93/cs93-28.ps.Z
  2295.  
  2296. ------------------------------------------------------------------------------
  2297.  
  2298. Subject: [17] What is the state of fractal compression?
  2299.  
  2300. You may want to read first item 77 in part 2 of this FAQ:
  2301. "Introduction to Fractal compression".
  2302.  
  2303.  
  2304. from Tal Kubo <kubo@zariski.harvard.edu>:
  2305.  
  2306. According to Barnsley's book 'Fractals Everywhere', this method is
  2307. based on a measure of deviation between a given image and its
  2308. approximation by an IFS code.  The Collage Theorem states that there is
  2309. a convergent process to minimize this deviation.  Unfortunately,
  2310. according to an article Barnsley wrote for BYTE a few years ago, this
  2311. convergence was rather slow, about 100 hours on a Cray, unless assisted by
  2312. a person.
  2313.  
  2314. Barnsley et al are not divulging any technical information beyond the
  2315. meager bit in 'Fractals Everywhere'.  The book explains the idea of IFS
  2316. codes at length, but is vague about the application of the Collage theorem
  2317. to specific compression problems.
  2318.  
  2319. There is reason to believe that Barnsley's company has
  2320. *no algorithm* which takes a given reasonable image and achieves
  2321. the compression ratios initially claimed for their fractal methods.
  2322. The 1000-to-1 compression advertised was achieved only for a 'rigged'
  2323. class of images, with human assistance. The best unaided
  2324. performance I've heard of is good lossy compression of about 80-1.
  2325.  
  2326. Steve Tate <srt@duke.cs.duke.edu> confirms:
  2327.  
  2328. Compression ratios (unzoomed) seem to range from 20:1 to 60:1...  The
  2329. quality is considerably worse than wavelets or JPEG on most of the
  2330. non-contrived images I have seen.
  2331.  
  2332. But Yuval Fisher <fisher@inls1.ucsd.edu> disagrees:
  2333.  
  2334. Their performance has improved dramatically beyond what they were
  2335. talking about in BYTE a few years ago.  Human assistance to the
  2336. compression is no longer needed and the compression time is
  2337. reasonable, although the more time and compute power you throw at the
  2338. compression, the smaller the resulting file for the same level of
  2339. quality.
  2340.  
  2341. Geoffrey A Stephenson <ketlux@ketlux.demon.co.uk> adds:
  2342.  
  2343. Iterated systems are shipping a general purpose compressor at about
  2344. 300 Pounds in the UK that claims "640x480 24 bit colour compression of
  2345. about 1 min at 922k -> 10k on a 486/50 software only, decomp. to 8
  2346. bits in 3 secs, etc." At a recent multimedia conference in London they
  2347. handed out free demo disks that show the decomp. in action. The
  2348. package runs under both DOS anf WIN (DLLs provided for use in
  2349. applications). They also sell a board to speed up compression and
  2350. offer versions supporting full motion video (but not apparently at all
  2351. SVGA sizes like the static picture version). I have not yet got my
  2352. hands on a full version to test different types of pictures, but
  2353. friends have a and claim it looks good.
  2354.  
  2355.  
  2356. Thomas W. Colthurst <thomasc@athena.mit.edu> clarifies the distinction
  2357. between IFS and the Fractal Transform:
  2358.  
  2359. It is time, once and for all, to put to death the Barnsley myth that
  2360. IFSs are good for image compression.  They are not.  Various algorithms
  2361. have been proposed for this "inverse problem" ranging from the trendy
  2362. (genetic algorithms) to the deep (moment methods) to the ad hoc (the
  2363. hungry algorithm) to the absurd (the so-called "graduate student
  2364. algorithm", consisting of locking up a grad student in a tiny office
  2365. with a SGI workstation and not letting them out until they come up
  2366. with a good IFS for your image).  They are all useless for practical
  2367. image compression.
  2368.  
  2369. In fact, there are even good theoretical reasons for believing that
  2370. IFSs will never be useful for image compression.  For example, even
  2371. if you have an IFS for object A and an IFS for object B, there is no
  2372. way to combine these IFSs to get an IFS for object A union B or
  2373. object A intersect B.
  2374.  
  2375. Even Barnsley himself admits, in his latest book, that he doesn't use
  2376. IFS image compression.  Instead, he uses the so-called "fractal
  2377. transform," which is really just a variant of vector quantization
  2378. where you use the image itself, sampled at a higher scale, as the
  2379. VQ codebook.  To be fair, the fractal transform can be analyzed using
  2380. local IFSs, but local IFSs are immensely more complicated and general
  2381. than normal IFSs, to the point where one feels suspect even using the
  2382. word "IFS" to describe them.
  2383.  
  2384. It should be emphasized that the fractal transform is a real, working
  2385. method that performs about as well as other existing methods like VQ
  2386. or the discrete cosine transform. The fractal transform will probably
  2387. never beat vector quantization (VQ) as for size of the compressed
  2388. image, but does have the advantage that you don't need to carry your
  2389. codebook around.  The latest results have it slightly winning over
  2390. the discrete cosine transform; only time and more research will tell
  2391. if this advantage persists.  Just like VQ, the fractal transform
  2392. takes a while to compress, but is quick at decompression (Barnsley's
  2393. company has hardware to do this in realtime).
  2394.  
  2395. In short, IFSs are good for just about everything fractals are (and
  2396. more!), but are absolutely horrid for image compression.
  2397.  
  2398.  
  2399. Programs:
  2400.  
  2401. Check http://links.uwaterloo.ca/ for pointers to some fractal compression
  2402. programs and lots of papers on fractal compression.
  2403.  
  2404. The Waterloo BragZone (http://links.uwaterloo.ca/bragzone.base.html
  2405. or ftp://links.uwaterloo.ca/pub/BragZone/ ) compares the results of
  2406. various image compression schemes against a 32 element test suite.
  2407. Numerous rate-distortion graphs, data tables, and sample images are available.
  2408.  
  2409. A fractal image compression program is available by ftp in
  2410. ftp://inls.ucsd.edu/pub/young-fractal/yuvpak20.zip ; it contains source for
  2411. compression and decompression, source for X-windows decompression,
  2412. MSDOS executables and images. [Note from FAQ maintainer: Fisher's
  2413. program (see below) implements the same algorithm but is more general;
  2414. see http://inls.ucsd.edu/y/Fractals/ for the source code.]
  2415.  
  2416. A fractal image decompression program (note: decompression only) is
  2417. available in ftp://inls.ucsd.edu/pub/inls-ucsd/fractal-2.0.tar
  2418. In the same directory, fractal_paper.ps.Z is the paper "Fractal image
  2419. compression" by Yuval Fisher, Siggraph 92.  Reading this paper is
  2420. required to understand how the Young compression programs (see above) works.
  2421.  
  2422. A note from Yuval Fisher <yfisher@ucsd.edu>:
  2423.  
  2424.     Connect to http://inls.ucsd.edu/y/Fractals/ .  There is
  2425.     information there on my new book of contributed articles on
  2426.     fractal image compression, as well as the book's table of
  2427.     contents, some C code to encode and decode raw byte files of any
  2428.     size using a quadtree method, a manual explaining the use of the
  2429.     code, a fractal image compression bibliography (not guaranteed to
  2430.     be complete or close to it), some better executable code with
  2431.     sample encodings, and the SIGGRAPH '92 course notes on fractal
  2432.     image compression (these are based on appendix A of Chaos and
  2433.     Fractals by Peitgen et al., Springer Verlag). [The C code is also
  2434.     available in ftp://inls.ucsd.edu/pub/inls-ucsd/frac_comp.tar.Z ]
  2435.  
  2436. Another fractal compression program is available by ftp in
  2437. ftp://vision.auc.dk/pub/Limbo/Limbo*.tar.Z. It is also based on quadtrees,
  2438. as yuvpak20 and frac_comp.
  2439.  
  2440. The source code for the program published in the Oct 93 issue of
  2441. Byte is in ftp://ftp.uu.net/published/byte/93oct/fractal.exe. This is
  2442. a self-extractible arc file (must be run on MSDOS for extraction).
  2443. The source code is for a TARGA video board. [Note from FAQ maintainer:
  2444. this code is taken from Barnsley's book "Fractal Image Compression";
  2445. it implements the brute force method and is thus very slow.]
  2446.  
  2447. Iterated Systems have released a beta version of their fractal imager.
  2448. It will let you view a number of formats including JPG and do
  2449. conversions to their fractal format.  The program can be downloaded
  2450. from http://www.iterated.com
  2451.  
  2452. "The Data Compression Book" (see [NEL 1996] in item 7 above) contains
  2453. a chapter on fractal compression; it includes source code for a simple
  2454. fractal compression program.
  2455.  
  2456. Several papers on fractal image compression are available on
  2457. ftp.informatik.uni-freiburg.de in directory /documents/papers/fractal . A
  2458. biliography is in ftp://schmance.uwaterloo.ca/pub/Fractal/fractal.biblio.ps.Z
  2459.  
  2460. References:
  2461.   A. Jacquin, 'Fractal image coding based on a theory of iterated
  2462.     contractive image transformations', Proc. SPIE Visual Communications
  2463.     and Image Processing, 1990, pages 227-239.  (The best paper that explains
  2464.     the concept in a simple way.)
  2465.  
  2466.   A. Jacquin, "A Fractal Theory of Iterated Markov Operators with
  2467.     Applications to Digital Image Coding", PhD Thesis, Georgia Tech, 1989.
  2468.   It can be obtained from university microfilms for $35, phone 1-800-521-0600.
  2469.  
  2470.   M. Barnsley, L. Anson, "Graphics Compression Technology, SunWorld,
  2471.     October 1991, pp. 42-52.
  2472.   M.F. Barnsley, A. Jacquin, F. Malassenet, L. Reuter & A.D. Sloan,
  2473.     'Harnessing chaos for image synthesis', Computer Graphics,
  2474.     vol 22 no 4 pp 131-140, 1988.
  2475.   M.F. Barnsley, A.E. Jacquin, 'Application of recurrent iterated
  2476.     function systems to images', Visual Comm. and Image Processing,
  2477.     vol SPIE-1001, 1988.
  2478.   A. Jacquin, "Image Coding Based on a Fractal Theory of Iterated Contractive
  2479.     Image Transformations" p.18, January 1992 (Vol 1 Issue 1) of IEEE Trans
  2480.     on Image Processing.
  2481.   A.E. Jacquin, 'A novel fractal block-coding technique for digital
  2482.     images', Proc. ICASSP 1990.
  2483.   G.E. Oien, S. Lepsoy & T.A. Ramstad, 'An inner product space
  2484.     approach to image coding by contractive transformations',
  2485.     Proc. ICASSP 1991, pp 2773-2776.
  2486.   D.S. Mazel, Fractal Modeling of Time-Series Data, PhD Thesis,
  2487.     Georgia Tech, 1991.    (One dimensional, not pictures)
  2488.   S. A. Hollatz, "Digital image compression with two-dimensional affine
  2489.     fractal interpolation functions", Department of Mathematics and
  2490.     Statistics, University of Minnesota-Duluth, Technical Report 91-2.
  2491.     (a nuts-and-bolts how-to-do-it paper on the technique)
  2492.   Stark, J., "Iterated function systems as neural networks",
  2493.     Neural Networks, Vol 4, pp 679-690, Pergamon Press, 1991.
  2494.   Monro D M and Dudbridge F, "Fractal block coding of images",
  2495.     Electronics Letters 28(11):1053-1054 (1992)
  2496.   Beaumont J M, "Image data compression using fractal techniques",
  2497.     British Telecom Technological Journal 9(4):93-108 (1991)
  2498.   Fisher Y, "Fractal image compression", Siggraph 92
  2499.   Graf S, "Barnsley's Scheme for the Fractal Encoding of Images",
  2500.     Journal Of Complexity, V8, 72-78 (1992).
  2501.   Monro D.M. 'A hybrid fractal transform', Proc ICASSP 93, pp. V: 169-72
  2502.   Monro D.M. & Dudbridge F. 'Fractal approximation of image blocks',
  2503.     Proc ICASSP 92, pp. III: 485-488
  2504.   Monro D.M., Wilson D., Nicholls J.A. 'High speed image coding with the Bath
  2505.     Fractal Transform', IEEE International Symposium on Multimedia Technologies
  2506.     Southampton, April 1993
  2507.   Jacobs, E.W., Y. Fisher and R.D. Boss.  "Image Compression:  A study
  2508.     of the Iterated Transform Method."  _Signal Processing 29_  (1992) 25-263
  2509.   Vrscay, Edward R.  "Iterated Function Systems:  Theory, Applications,
  2510.     and the Inverse Problem."  _Fractal Geometry and Analysis_,
  2511.     J. Belair and S. Dubuc (eds.)  Kluwer Academic, 1991.  405-468.
  2512.  
  2513. Books:
  2514.     Fractal Image Compression: Theory and Application, Yuval Fisher (ed.),
  2515.     Springer Verlag, New York, 1995.
  2516.     To order the book, call 1-800-SPRINGER and ask for the book with
  2517.     ISBN number 0-387-94211-4 or check http://www.springer-ny.com/
  2518.  
  2519.     Fractal Image Compression
  2520.     Michael F. Barnsley and Lyman P. Hurd
  2521.     ISBN 0-86720-457-5, ca. 250 pp., $49.95
  2522.     Copies can be ordered directly from the publisher by sending a message
  2523.     to kpeters@math.harvard.edu with name, address and a Mastercard or
  2524.     Visa card number with expiration date.
  2525.  
  2526. Barnsley's company is:
  2527.  
  2528. Iterated Systems, Inc.
  2529. 5550A Peachtree Parkway, Suite 650
  2530. Norcross, GA  30092
  2531. tel: 404-840-0310 or 1-800-4FRACTL
  2532. fax: 404-840-0806
  2533. In UK: Phone (0734) 880261, Fax (0734) 880360
  2534.  
  2535. ------------------------------------------------------------------------------
  2536.  
  2537. Subject: [18] I need specs and source for TIFF and CCITT group 4 Fax
  2538.  
  2539.  
  2540. Specs for Group 3 and 4 image coding (group 3 is very similar to group 4)
  2541. are in CCITT (1988) volume VII fascicle VII.3. They are recommendations
  2542. T.4 and T.6 respectively. There is also an updated spec contained in 1992
  2543. recommendations T.1 to T.6.
  2544.  
  2545. CCITT (now ITU-T) specs are available by anonymous ftp (see above answer on
  2546. V.42bis).  The T.4 and T.6 specs are on src.doc.ic.ac.uk in directory
  2547. /computing/ccitt/ccitt-standards/ccitt/1988/ascii, files 7_3_01.txt.Z and
  2548. 7_3_02.txt.Z respectively.
  2549.  
  2550. The following paper covers T.4, T.6 and JBIG:
  2551.  
  2552.   "Review of standards for electronic imaging for facsimile systems"
  2553.   in Journal of Electronic Imaging, Vol. 1, No. 1, pp. 5-21, January 1992.
  2554.  
  2555.  
  2556. Source code can be obtained as part of a TIFF toolkit - TIFF image
  2557. compression techniques for binary images include CCITT T.4 and T.6:
  2558.  
  2559.     ftp://ftp.sgi.com/graphics/tiff/tiff-v3.4beta035-tar.gz
  2560.     Contact: sam@engr.sgi.com
  2561.  
  2562. There is also a companion compressed tar file (v3.0pics.tar.Z) that
  2563. has sample TIFF image files. A draft of TIFF 6.0 is in TIFF6.ps.Z.
  2564. Concerning JPEG compression in TIFF 6.0, Tom Lane <tgl@sss.pgh.pa.us> adds:
  2565.  
  2566.   TIFF 6.0's scheme for incorporating JPEG compression (spec section 22) has
  2567.   a bunch of serious deficiencies.  Don't use it.  A revised design is given
  2568.   by TIFF Technical Note #2, ftp://ftp.sgi.com/graphics/tiff/TTN2.draft.txt
  2569.   The revised design will replace section 22 in TIFF 7.0, and is implemented
  2570.   in Sam Leffler's libtiff.  See also item 75 of this FAQ for more JPEG info.
  2571.  
  2572. Software for reading and writing CCITT Group 3 and 4 images is
  2573. also available in directory ftp://merry.cs.monash.edu.au/pub/alanf/TIFF_FAX
  2574. Contact: Alan Finlay <alanf@bruce.cs.monash.edu.au>.
  2575.  
  2576.  
  2577. See also question 54 below.
  2578.  
  2579. ------------------------------------------------------------------------------
  2580.  
  2581. Subject: [19] What is JPEG?
  2582.  
  2583.  
  2584. JPEG (pronounced "jay-peg") is a standardized image compression mechanism.
  2585. JPEG stands for Joint Photographic Experts Group, the original name of the
  2586. committee that wrote the standard.  JPEG is designed for compressing either
  2587. full-color or gray-scale digital images of "natural", real-world scenes.
  2588. It does not work very well on non-realistic images, such as cartoons or
  2589. line drawings.
  2590.  
  2591. JPEG does not handle black-and-white (1-bit-per-pixel) images, nor does it
  2592. handle motion picture compression.  Related standards for compressing those
  2593. types of images exist, and are called JBIG and MPEG respectively.
  2594.  
  2595. Regular JPEG is "lossy", meaning that the image you get out of decompression
  2596. isn't quite identical to what you originally put in.  The algorithm achieves
  2597. much of its compression by exploiting known limitations of the human eye,
  2598. notably the fact that small color details aren't perceived as well as small
  2599. details of light-and-dark.  Thus, JPEG is intended for compressing images that
  2600. will be looked at by humans.  If you plan to machine-analyze your images, the
  2601. small errors introduced by JPEG may be a problem for you, even if they are
  2602. invisible to the eye.  The JPEG standard includes a separate lossless mode,
  2603. but it is rarely used and does not give nearly as much compression as the
  2604. lossy mode.
  2605.  
  2606. Question 75 "Introduction to JPEG" (in part 2 of this FAQ) gives an overview
  2607. of how JPEG works and provides references for further reading.  Also see the
  2608. JPEG FAQ article, which covers JPEG software and usage hints.  The JPEG FAQ is
  2609. posted regularly in news.answers by Tom Lane <tgl@netcom.com>.  (See question
  2610. 53 "Where are FAQ lists archived" if this posting has expired at your site.)
  2611.  
  2612. For JPEG software, see item 15 above.
  2613. For JPEG hardware, see item 85 in part 3 of this FAQ.
  2614.  
  2615. ------------------------------------------------------------------------------
  2616.  
  2617. Subject: [20] I am looking for source of an H.261/H.263 codec and MPEG
  2618.  
  2619. Many standards and draft recommendations (including H.261, H.263,
  2620. H.320, H.324), are available in http://www.imtc.org/imtc/
  2621.  
  2622. The H.261 spec is also available on src.doc.ic.ac.uk in
  2623. /computing/ccitt/standards/ccitt-standards/1992/h/h261.doc.Z (or h261.rtf.Z).
  2624.  
  2625. For H.261 hardware, see item 85 in part 3 of this FAQ.
  2626.  
  2627. Current drafts of H.324 and related recommendations including H.263 are
  2628. available in ftp://ftp.std.com/vendors/PictureTel/h324
  2629.  
  2630. Telenor Research have made available a complete simulation of
  2631. H.263. See http://www.nta.no/brukere/DVC/h263_software
  2632.  
  2633. from Thierry TURLETTI <turletti@sophia.inria.fr>:
  2634.  
  2635.      IVS (INRIA VIDEOCONFERENCING SYSTEM)
  2636.       - X11-based videoconferencing tool for SPARC, HP,  DEC  and
  2637.      Silicon Graphic workstations.
  2638.  
  2639.      ivs allows users  to  conduct  multi-host  audio  and  video
  2640.      conferences  over  the  Internet. ivs requires a workstation
  2641.      with a screen with 1, 4, 8 or  24  bits  depth.   Multi-host
  2642.      conferences  require  that  the  kernel support multicast IP
  2643.      extensions (RFC 1112).
  2644.  
  2645.      On video input, video frames are grabbed  by  the  VideoPix,
  2646.      SunVideo or Parallax boards for SparcStations or Raster Rops
  2647.      board for HP stations or the IndigoVideo board for SGI  IRIS
  2648.      Indigo workstations.  or the VIDEOTX board for DEC stations.
  2649.      No special hardware apart from  the  workstation's  build-in
  2650.      audio hardware is required for audio conference.
  2651.  
  2652.      Video encoding is done according to the H.261 standard.
  2653.      The video stream can be encoded in either Super CIF 
  2654.      (704x576 pixels) format or  CIF  (352x288  pixels) format or 
  2655.      QCIF (176x144 pixels). Default format is CIF.
  2656.  
  2657.      Sources, binaries & manuals are freely available by anonymous 
  2658.      ftp from zenon.inria.fr in the rodeo/ivs directory. An INRIA
  2659.      report describing this application is also available in the 
  2660.      same directory.
  2661.  
  2662.      If you ftp & use this package, please send all remarks or 
  2663.      modifications made to <turletti@sophia.inria.fr>. If you want 
  2664.      to be added or deleted to the ivs-users mailing list, please send 
  2665.      e-mail to ivs-users-request@sophia.inria.fr.
  2666.  
  2667.  
  2668. from Andy Hung <achung@cs.stanford.edu>:
  2669.  
  2670. Public domain UNIX C source code to do both image and image sequence
  2671. compression and decompression is available by anonymous ftp:
  2672.  
  2673. MPEG-I            ftp://havefun.stanford.edu/pub/mpeg/MPEGv*.tar.Z
  2674. CCITT H.261(P*64)    ftp://havefun.stanford.edu/pub/p64/P64v*.tar.Z
  2675. JPEG            ftp://havefun.stanford.edu/pub/jpeg/JPEGv*.tar.Z
  2676.  
  2677. These codecs operate on raw raster scanned images.
  2678.  
  2679. A software program to display raw raster-scanned YUV images and image
  2680. sequences on X grayscale or color monitors is provided by a program in
  2681. ftp://havefun.stanford.edu/pub/cv/CVv*.tar.Z
  2682. If you are using the codecs above, we recommend that you ftp this file
  2683. over as well.
  2684.  
  2685. The source code has been compiled on DEC and SUN workstations.
  2686. Caution: the P64 codec has not been tested compliant (any available
  2687. p64 video streams would be much appreciated - please let us know at
  2688. achung@cs.stanford.edu).  The other codecs have been tested with
  2689. streams from other encoders.
  2690.  
  2691. We also have some IPB MPEG-I video coded streams in pub/mpeg/*.mpg;
  2692. and P64 video streams in pub/p64/*.p64 that we have generated using
  2693. our codecs.
  2694.  
  2695. For a more complete description see the file
  2696. havefun.stanford.edu:pub/README.
  2697.  
  2698. ------------------------------------------------------------------------------
  2699.  
  2700. Subject: [25] Fast DCT (Discrete Cosine Transform) algorithms
  2701.  
  2702.  
  2703. Many image compression methods, including the JPEG, MPEG, and H.261 standards,
  2704. are based on the discrete cosine transform.  A good overall introduction to
  2705. DCT is the book "Discrete Cosine Transform---Algorithms, Advantages,
  2706. Applications" by K.R. Rao and P. Yip (Academic Press, London, 1990),
  2707. ISBN 0-12-580203-X. This has an extensive, though already dated, bibliography.
  2708.  
  2709. Here are some references mostly provided by Tom Lane <tgl@sss.pgh.pa.us>.
  2710. (This list is now rather dated.)
  2711. Most of these are in IEEE journals or conference proceedings, notably
  2712. ICASSP = IEEE Intl. Conf. on Acoustics, Speech, and Signal Processing.
  2713. ICCAS = IEEE Intl. Conf. on Circuits and Systems.
  2714. DCC = Data Compression Conference.
  2715.  
  2716. Polynomial Transform Computation of the 2-D DCT, Duhamel & Guillemot,
  2717.   ICASSP '90 p. 1515.
  2718. A Forward-Mapping Realization of the Inverse DCT, McMillan & Westover,
  2719.   DCC '92 p. 219.
  2720. A Fast Algorithm for 2-D DCT, Cho, Yun & Lee, ICASSP '91 p. 2197.
  2721. Fast Algorithm and Implementation of 2-D DCT, Cho & Lee, Tr. CAS v38 p. 297.
  2722. A DCT Chip based on a new Structured and Computationally Efficient DCT
  2723.   Algorithm, Duhamel, Guillemot & Carlach, ICCAS '90 p. 77.
  2724. Trade-offs in the Computation of Mono- and Multi-dimensional DCTs,
  2725.   Vetterli, Duhamel & Guillemot, ICASSP '89 p. 999.
  2726. Practical Fast 1-D DCT Algorithms with 11 Multiplications,
  2727.   Loeffler, Ligtenberg & Moschytz, ICASSP '89 p. 988.
  2728. New Scaled DCT Algorithms for Fused Multiply/Add Architectures,
  2729.   Linzer & Feig, ICASSP '91 p. 2201.
  2730. Fast Algorithms for the 2-D Discrete Cosine Transform, Kamangar & Rao,
  2731.   IEEE Tr. Computers, v C-31 p. 899.
  2732. Fast 2-D Discrete Cosine Transform, Vetterli, ICASSP '85 p. 1538.
  2733. A Two-Dimensional Fast Cosine Transform, Haque, Tr. ASSP v ASSP-33 p. 1532.
  2734. Real-Time Parallel and Fully Pipelined 2-D DCT Lattice Structures with
  2735.   Application to HDTV Systems, Chiu & Liu, Tr. CAS for Video Tech, v 2 p. 25.
  2736. J.F. Blinn, "What's the Deal with the DCT", IEEE Computer Graphics and
  2737.   Applications, July 1993, pp.78-83.
  2738. A C Hung and TH-Y Meng, "A Comparison of fast DCT algorithms, Multimedia 
  2739.   Systems, No. 5 Vol. 2, Dec 1994
  2740.  
  2741. For actual implementations, try the JPEG and MPEG software listed
  2742. in item 15.
  2743.  
  2744. ------------------------------------------------------------------------------
  2745.  
  2746. Subject: [26] Are there algorithms and standards for audio compression?
  2747.  
  2748.  
  2749. Yes. See the introduction to MPEG given in part 2 of this FAQ.
  2750.  
  2751. A lossless compressor for 8bit and 16bit audio data (.au) is available
  2752. in ftp://svr-ftp.eng.cam.ac.uk/pub/comp.speech/coding/shorten.tar.gz
  2753. Shorten works by using Huffman coding of prediction residuals.
  2754. Compression is generally better than that obtained by applying general
  2755. purpose compression utilities to audio files. Also supports lossy
  2756. compression.  Contact: Tony Robinson <ajr@eng.cam.ac.uk>.
  2757.  
  2758. Audio software is available on sunsite.unc.edu in subdirectories of
  2759. /pub/electronic-publications/IUMA/audio_utils:
  2760. - An MPEG audio player is in mpeg_players/Workstations/maplay1_2.tar.Z.
  2761. - The sources of the XING MPEG audio player for Windows is in
  2762.   mpeg_players/Windows/mpgaudio.zip.
  2763. - An encoder/decoder is in converters/source/mpegaudio.tar.Z.
  2764.  
  2765. MSDOS audio software is available in
  2766. ftp://ftp.coast.net/mirrors/SimTel/msdos/sound/
  2767. In particular, MPEG-2 audio software is in ampegsrc.zip and ampeg43.zip.
  2768.  
  2769. MPEG audio files are available in ftp.iuma.com and http://www.iuma.com/
  2770.  
  2771. Copied from the comp.dsp FAQ posted by guido@cwi.nl (Guido van Rossum):
  2772.  
  2773.   Strange though it seems, audio data is remarkably hard to compress
  2774.   effectively.  For 8-bit data, a Huffman encoding of the deltas between
  2775.   successive samples is relatively successful.  For 16-bit data,
  2776.   companies like Sony and Philips have spent millions to develop
  2777.   proprietary schemes.
  2778.  
  2779.   Public standards for voice compression are slowly gaining popularity,
  2780.   e.g. CCITT G.721 and G.723 (ADPCM at 32 and 24 kbits/sec).  (ADPCM ==
  2781.   Adaptive Delta Pulse Code Modulation.)  Free source code for a *fast*
  2782.   32 kbits/sec ADPCM (lossy) algorithm is available by ftp from ftp.cwi.nl
  2783.   as /pub/audio/adpcm.shar.  (** NOTE: if you are using v1.0, you should get
  2784.   v1.1, released 17-Dec-1992, which fixes a serious bug -- the quality
  2785.   of v1.1 is claimed to be better than uLAW **)
  2786.  
  2787.   (Note that U-LAW and silence detection can also be considered
  2788.   compression schemes.)
  2789.  
  2790. Information and source code for adpcm are available in
  2791. http://www.nb.rockwell.com/ref/adpcm.html
  2792.  
  2793. Source for Sun's free implementation of CCITT compression types G.711,
  2794. G.721 and G.723 is in ftp://ftp.cwi.nl/pub/audio/ccitt-adpcm.tar.gz
  2795.  
  2796. You can get a G.721/722/723 package by email to teledoc@itu.arcom.ch, with
  2797. GET ITU-3022
  2798. as the *only* line in the body of the message.
  2799.  
  2800.  
  2801. A note on u-law from Markus Kuhn <mskuhn@immd4.informatik.uni-erlangen.de>:
  2802.  
  2803.   u-law (more precisely (greek mu)-law or 5-law if you have an 8-bit
  2804.   ISO terminal) is more an encoding then a compression method,
  2805.   although a 12 to 8 bit reduction is normally part of the encoding.
  2806.   The official definition is CCITT recommendation G.711. If you want
  2807.   to know how to get CCITT documents, check the Standards FAQ
  2808.   posted to news.answers or get the file standards-faq by ftp in
  2809.   directory ftp://rtfm.mit.edu/pub/usenet/news.answers/
  2810.  
  2811.  
  2812. See also the comp.dsp FAQ for more information on:
  2813.  
  2814. - The U.S. DoD's Federal-Standard-1016 based 4800 bps code excited linear
  2815.   prediction voice coder version 3.2a (CELP 3.2a)
  2816. - The U.S. DoD's Federal-Standard-1015/NATO-STANAG-4198 based 2400 bps
  2817.   linear prediction coder version 53 (LPC-10e v53)
  2818. - Realtime DSP code and hardware for FS-1015 and FS-1016
  2819.  
  2820. The comp.dsp FAQ is in comp.dsp with subject "FAQ: Audio File Formats" and in
  2821. ftp://rtfm.mit.edu/pub/usenet/news.answers/audio-fmts/part1
  2822.  
  2823.  
  2824. CELP C code for Sun SPARCs is in ftp://ftp.super.org/pub/speech/celp_3.2a.tar.Z
  2825. An LPC10 speech coder is in ftp://ftp.super.org/pub/speech/lpc10-1.0.tar.gz ;
  2826. a derived version is in http://www.arl.wustl.edu/~jaf/lpc/lpc10-1.1.tar.gz
  2827.  
  2828. Source code for ITU-T (CCITT) G.728 Low Delay CELP speech compression
  2829. is in ftp://svr-ftp.eng.cam.ac.uk/pub/comp.speech/sources/ldcelp-2.0.tar.gz
  2830.  
  2831.  
  2832. Recommended reading:
  2833.   Digital Coding of Waveforms: Principles and Applications to Speech and
  2834.   Video.  N. S. Jayant and Peter Noll.  Prentice-Hall, 1984, ISBN
  2835.   0-13-211913-7.
  2836.  
  2837. Information on GSM sound compression is available at
  2838. http://ccnga.uwaterloo.ca/~jscouria/gsm.html
  2839.  
  2840.  
  2841. from Markus Kuhn <mskuhn@immd4.informatik.uni-erlangen.de>:
  2842.  
  2843.   One highest quality sound compression format is called ASPEC and has
  2844.   been developed by a team at the Frauenhofer Institut in Erlangen (Germany)
  2845.   and others.
  2846.  
  2847.   ASPEC produces CD like quality and offers several bitrates, one is
  2848.   128 kbit/s. It is a lossy algorithm that throws away frequencies that
  2849.   aren't registered in the human cochlea in addition to sophisticated
  2850.   entropy coding. The 64 kbit/s ASPEC variant might soon bring hifi
  2851.   quality ISDN phone connections. It has been implemented on standard DSPs.
  2852.  
  2853.   The Layer 3 MPEG audio compression standard now contains what is officially
  2854.   called the best parts of the ASPEC and MUSICAM algorithms. A reference is:
  2855.  
  2856.     K.Brandenburg, G.Stoll, Y.F.Dehery, J.D.Johnston, L.v.d.Kerkhof,
  2857.     E.F.Schroeder: "The ISO/MPEG-Audio Codec: A Generic Standard for Coding
  2858.     of High Quality Digital Audio",
  2859.     92nd. AES-convention, Vienna 1992, preprint 3336
  2860.  
  2861.  
  2862. from Jutta Degener <jutta@cs.tu-berlin.de> and Carsten Bormann
  2863. <cabo@cs.tu-berlin.de>:
  2864.  
  2865.   GSM 06.10 13 kbit/s RPE/LTP speech compression available
  2866.   --------------------------------------------------------
  2867.  
  2868.   The Communications and Operating Systems Research Group (KBS) at the
  2869.   Technische Universitaet Berlin is currently working on a set of
  2870.   UNIX-based tools for computer-mediated telecooperation that will be
  2871.   made freely available.
  2872.  
  2873.   As part of this effort we are publishing an implementation of the
  2874.   European GSM 06.10 provisional standard for full-rate speech
  2875.   transcoding, prI-ETS 300 036, which uses RPE/LTP (residual pulse
  2876.   excitation/long term prediction) coding at 13 kbit/s.
  2877.  
  2878.   GSM 06.10 compresses frames of 160 13-bit samples (8 kHz sampling
  2879.   rate, i.e. a frame rate of 50 Hz) into 260 bits; for compatibility
  2880.   with typical UNIX applications, our implementation turns frames of 160
  2881.   16-bit linear samples into 33-byte frames (1650 Bytes/s).
  2882.   The quality of the algorithm is good enough for reliable speaker
  2883.   recognition; even music often survives transcoding in recognizable 
  2884.   form (given the bandwidth limitations of 8 kHz sampling rate).
  2885.  
  2886.   Version 1.0 of the implementation is available per anonymous ftp from
  2887.   ftp.cs.tu-berlin.de in the directory /pub/local/kbs/tubmik/gsm/ ;
  2888.   more information about the library can be found on the World-Wide Web
  2889.   at http://www.cs.tu-berlin.de/~jutta/toast.html .
  2890.   Questions and bug reports should be directed to jutta@cs.tu-berlin.de
  2891.   and cabo@informatik.uni-bremen.de .
  2892.  
  2893.  
  2894. from Bob Kimball <rkimball@qualcomm.com>:
  2895.  
  2896.   I work for Qualcomm Inc. and we are designing a digital cellular telephone
  2897.   system.  Our phone uses our variable rate vocoder (QCELP) which is designed
  2898.   for speach and compresses 64Kb/s speach to 8Kb/s through 1Kb/s with 8Kb/s
  2899.   being full rate and 1Kb/s for 1/8 rate speach.  It works great for speach.
  2900.  
  2901.   The QCELP process is documented in our Common Air Interface (CAI) which is
  2902.   available for anonymous ftp from lorien.qualcomm.com in /pub/cdma
  2903.   each chapter is a postscript file.  The vocoder is described in appendix A.
  2904.   The whole document is quite large.  This is the document which is currently
  2905.   going through the TIA standard committee so it is not a final version.  The
  2906.   appendix on the vocoder should be almost identical to the final version...
  2907.   whenever that comes out.
  2908.  
  2909.  
  2910. from Nicola Ferioli <ser1509@cdc835.cdc.polimi.it>:
  2911.  
  2912.   ftp://ftp.coast.net/mirrors/SimTel/msdos/sound/vocpak20.zip
  2913.     Lossless 8-bit sound file compressor
  2914.  
  2915.   VOCPACK is a compressor/decompressor for 8-bit digital sound using a
  2916.   lossless algorithm; it is useful to save disk space without degrading
  2917.   sound quality.  It can compress signed and unsigned data, sampled at any
  2918.   rate, mono or stereo.  Since the method used is not lossy, it isn't
  2919.   necessary to strip file headers before compressing.
  2920.  
  2921.   VOCPACK was developed for use with .VOC (SoundBlaster) and .WAV (Windows)
  2922.   files, but any 8-bit sound can be compressed since the program takes no
  2923.   assumptions about the file structure.
  2924.  
  2925.   The typical compression ratio obtained goes from 0,8 for files sampled at
  2926.   11 KHz to 0,4 for 44 Khz files.  The best results are obtained with 44 KHz
  2927.   sounds (mono or stereo): general-purpose archivers create files that can be
  2928.   twice longer than the output of VOCPACK.  You can obtain smaller values
  2929.   using lossy compressors but if your goal is to keep the sound quality
  2930.   unaltered you should use a lossless program like VOCPACK.
  2931.  
  2932. from Harald Popp <popp@iis.fhg.de>:
  2933.  
  2934.   new version 1.0 of ISO/MPEG1 Audio Layer 3 Shareware available
  2935.  
  2936.   major improvements of the new version:
  2937.        - encoder works twice as fast
  2938.        - improved file handling for encoder including .WAV files
  2939.  
  2940.   You may download the shareware from fhginfo.fhg.de (153.96.1.4)
  2941.   from the directory /pub/layer3
  2942.  
  2943.   The source code for the MPEG1 audio decoder layer 1, 2 and 3 is
  2944.   now available on fhginfo.fhg.de (153.96.1.4) in /pub/layer3/public_c.
  2945.  
  2946.   There are two files:
  2947.      mpeg1_iis.tar.Z     (Unix: lines seperated by line feed only)
  2948.      mpeg1iis.zip        (PC: lines seperated by carriage return and line feed)
  2949.  
  2950. For more information about this product and MPEG Audio Layer 3, see
  2951. the document "Informations about MPEG Audio Layer-3" maintained by
  2952. Juergen Zeller <zeller@iis.fhg.de>, available in
  2953. ftp://fhginfo.fhg.de/pub/layer3/MPEG_Audio_L3_FAQ.html
  2954.  
  2955. from Monty <xiphmont@athena.mit.edu>:
  2956.  
  2957.   A beta release of the OggSquish audio compression/decompression utility is
  2958.   available at http://deskfish.cs.titech.ac.jp:8001/squish/squish_index.html
  2959.  
  2960.   OggSquish is a compression package designed to reduce the file size of
  2961.   digitized 8 and 16 bit audio samples (or samples of any periodic
  2962.   data).  OggSquish will operate on files sampled at any speed, but it is
  2963.   designed to work with very high quality samples, for example, CD
  2964.   quality samples.
  2965.  
  2966. ------------------------------------------------------------------------------
  2967.  
  2968. Subject: [30] My archive is corrupted!
  2969.  
  2970.  
  2971. The two most common reasons for this are
  2972.  
  2973. (1) failing to use the magic word "tenex" (when connected to SIMTEL20 and
  2974.     other TOPS20 systems) or "binary" (when connected to UNIX systems) when
  2975.     transferring the file from an ftp site to your host machine.  The
  2976.     reasons for this are technical and boring.  A synonym for "tenex" is
  2977.     "type L 8", in case your ftp doesn't know what "tenex" means.
  2978.  
  2979. (2) failing to use an eight-bit binary transfer protocol when transferring
  2980.     the file from the host to your PC.  Make sure to set the transfer type
  2981.     to "binary" on both your host machine and your PC.
  2982.  
  2983. gopher is also known to corrupt binary files. In particular, if gzip
  2984. complains about a multi-part file, it's likely that the .gz file
  2985. has been corrupted by gopher. Use ftp in binary mode instead.
  2986.  
  2987. ------------------------------------------------------------------------------
  2988.  
  2989. Subject: [31] pkunzip reports a CRC error!
  2990.  
  2991.  
  2992. The portable zip 1.1 contains many workarounds for undocumented restrictions
  2993. in pkunzip. Compatibility is ensured for pkunzip 1.10 only. All previous
  2994. versions (pkunzip 1.0x) have too many bugs and cannot be supported. This
  2995. includes Borland unzip.
  2996.  
  2997. So if your pkunzip reports a CRC error, check that you are not using
  2998. an obsolete version. Get either pkzip 2.04g or unzip 5.12 (see question
  2999. 2 above for ftp sites). To generate zip files compatible with pkunzip 1.10,
  3000. use zip 1.1 (see item 2 above for ftp site).
  3001.  
  3002. ------------------------------------------------------------------------------
  3003.  
  3004. Subject: [32] VMS zip is not compatible with pkzip!
  3005.  
  3006.  
  3007. The problem is most likely in the file transfer program.
  3008.  
  3009. Many use kermit to transfer zipped files between PC and VMS VAX.  The
  3010. following VMS kermit settings make VMS-ZIP compatible with PKZIP:
  3011.  
  3012.                                              VMS kermit        PC kermit
  3013.                                            ---------------   --------------
  3014.  
  3015. Uploading PKZIPped file to be UNZIPped:    set fi ty fixed    set fi ty bi
  3016. Downloading ZIPped file to be PKUNZIPped:  set fi ty block    set fi ty bi
  3017.  
  3018. If you are not using kermit, transfer a file created by pkzip on MSDOS
  3019. to VMS, transfer it back to your PC and check that pkunzip can extract it.
  3020.  
  3021. ------------------------------------------------------------------------------
  3022.  
  3023. Subject: [33] I have a problem with Stacker or DoubleSpace!
  3024.  
  3025.  
  3026. The newsgroup comp.compression is *not* the appropriate place to
  3027. discuss about one specific program on one specific operating system.
  3028. Since you have bought a legal copy of Stacker or MSDOS 6.x, you have
  3029. the documentation of your product; please read it. If you can't find
  3030. the answer in the documentation, please report the problem to the Stac
  3031. or Microsoft customer support. (For Stac, use one of StacTec@aol.com,
  3032. StacMacTec@aol.com or StacOS2tec@aol.com.)  If you really feel that the
  3033. net has to know about your problem, please post in one of the MSDOS
  3034. newsgroups, such as comp.os.msdos.apps or comp.binaries.ibm.pc.d.
  3035.  
  3036. ------------------------------------------------------------------------------
  3037.  
  3038. Subject: [50] What is this 'tar' compression program?
  3039.  
  3040.  
  3041. tar is not a compression program. It just combines several files
  3042. into one, without compressing them. tar file are often compressed with
  3043. 'compress', resulting in a .tar.Z file. See question 2, file type .tar.Z.
  3044. GNU tar has the capability to (de)compress files as well.
  3045.  
  3046. When you have to archive a lot of very small files, it is often
  3047. preferable to create a single .tar file and compress it, than to
  3048. compress the individual files separately. The compression program can
  3049. thus take advantage of redundancy between separate files.  The
  3050. disadvantage is that you must uncompress the whole .tar file to
  3051. extract any member. You can also improve compression by grouping
  3052. files by type, as in:
  3053.  
  3054.   tar cvf - `ls | sort -t. +1` | gzip > file.tar.gz
  3055.  
  3056. ------------------------------------------------------------------------------
  3057.  
  3058. Subject: [51] I need a CRC algorithm
  3059.  
  3060.  
  3061. As its name implies (Cyclic Redundancy Check) a crc adds redundancy whereas
  3062. the topic of this group is to remove it. Yet this question comes up often in
  3063. comp.compression.
  3064.  
  3065. The file ftp://ftp.rocksoft.com/clients/rocksoft/papers/crc_v3.txt is a pretty
  3066. comprehensive description of the whole CRC concept, including a C program.
  3067.  
  3068. See also:
  3069. - Schwaderer W.D., "CRC Calculation", April 85 PC Tech Journal, pp.118-133.
  3070. - "Calculating CRCs by Bits and Bytes", BYTE Magazine, September 1986
  3071. - Ramabadran T.V., Gaitonde S.S., "A tutorial on CRC computations", IEEE
  3072.   Micro, Aug 1988.
  3073. - ftp://ftp.uni-erlangen.de/pub/doc/ISO/english/async-HDLC
  3074. - the source of all archivers, such as the file makecrc.c in the sources of
  3075.   zip 2.0.1 (see item 2).
  3076.  
  3077.  
  3078. The following C code (by Rob Warnock <rpw3@sgi.com>) does CRC-32 in
  3079. BigEndian/BigEndian byte/bit order.  That is, the data is sent most
  3080. significant byte first, and each of the bits within a byte is sent most
  3081. significant bit first, as in FDDI. You will need to twiddle with it to do
  3082. Ethernet CRC, i.e., BigEndian/LittleEndian byte/bit order. [Left as an
  3083. exercise for the reader.]
  3084.  
  3085. The CRCs this code generates agree with the vendor-supplied Verilog models
  3086. of several of the popular FDDI "MAC" chips.
  3087.  
  3088. u_long crc32_table[256];
  3089. /* Initialized first time "crc32()" is called. If you prefer, you can
  3090.  * statically initialize it at compile time. [Another exercise.]
  3091.  */
  3092.  
  3093. u_long crc32(u_char *buf, int len)
  3094. {
  3095.         u_char *p;
  3096.         u_long  crc;
  3097.  
  3098.         if (!crc32_table[1])    /* if not already done, */
  3099.                 init_crc32();   /* build table */
  3100.         crc = 0xffffffff;       /* preload shift register, per CRC-32 spec */
  3101.         for (p = buf; len > 0; ++p, --len)
  3102.                 crc = (crc << 8) ^ crc32_table[(crc >> 24) ^ *p];
  3103.         return ~crc;            /* transmit complement, per CRC-32 spec */
  3104. }
  3105.  
  3106. /*
  3107.  * Build auxiliary table for parallel byte-at-a-time CRC-32.
  3108.  */
  3109. #define CRC32_POLY 0x04c11db7     /* AUTODIN II, Ethernet, & FDDI */
  3110.  
  3111. init_crc32()
  3112. {
  3113.         int i, j;
  3114.         u_long c;
  3115.  
  3116.         for (i = 0; i < 256; ++i) {
  3117.                 for (c = i << 24, j = 8; j > 0; --j)
  3118.                         c = c & 0x80000000 ? (c << 1) ^ CRC32_POLY : (c << 1);
  3119.                 crc32_table[i] = c;
  3120.         }
  3121. }
  3122.  
  3123. ------------------------------------------------------------------------------
  3124.  
  3125. Subject: [52] What about those people who continue to ask frequently asked
  3126.               questions in spite of the frequently asked questions document?
  3127.  
  3128.  
  3129. Just send them a polite mail message, referring them to this document.
  3130. There is no need to flame them on comp.compression.  That would just
  3131. add more noise to this group.  Posted answers that are in the FAQ are
  3132. just as annoying as posted questions that are in the FAQ.
  3133.  
  3134. ------------------------------------------------------------------------------
  3135.  
  3136. Subject: [53] Where are FAQ lists archived?
  3137.  
  3138.  
  3139. Many are crossposted to news.answers.  That newsgroup should have a
  3140. long expiry time at your site; if not, talk to your sysadmin.
  3141.  
  3142. FAQ lists are available by anonymous FTP from rtfm.mit.edu.
  3143. The comp.compression FAQ that you are reading is in directory
  3144.    /pub/usenet/news.answers/compression-faq
  3145.  
  3146. This FAQ is also accessible in the World Wide Web at
  3147. http://www.cis.ohio-state.edu/hypertext/faq/usenet/compression-faq/top.html
  3148. All FAQs are available on this site.
  3149.  
  3150. If you don't have FTP access, you can access the archives by mail
  3151. server.  Send an email message to mail-server@rtfm.mit.edu
  3152. containing the commands
  3153.     send usenet/news.answers/compression-faq/part1
  3154.     send usenet/news.answers/compression-faq/part2
  3155.     send usenet/news.answers/compression-faq/part3
  3156. For instructions, send an email message to the same address with the
  3157. words "help" and "index" (no quotes) on separate lines. If you don't
  3158. get a reply, check your return address, or add a line such as
  3159.     path myname@foo.edu
  3160.  
  3161. ------------------------------------------------------------------------------
  3162.  
  3163. Subject: [54] I need specs for graphics formats
  3164.  
  3165. Get the book by Murray & vanRyper "Encyclopedia of graphics file formats",
  3166. O'Reilly & associates, ISBN 1-56592-058-9. Or have a look in directory
  3167. /pub/graphics.formats on zamenhof.cs.rice.edu; it contains descriptions of
  3168. gif, tiff, fits, etc...
  3169.  
  3170. See also the comp.graphics FAQ and the Graphics Formats FAQ. The latter is in
  3171. ftp://rtfm.mit.edu/pub/usenet/news.answers/graphics/fileformats-faq/
  3172. http://www.cis.ohio-state.edu/hypertext/faq/usenet/graphics/fileformats-faq/top.html
  3173.  
  3174. ------------------------------------------------------------------------------
  3175.  
  3176. Subject: [55] Where can I find Lenna and other images?
  3177.  
  3178. The Waterloo BragZone (http://links.uwaterloo.ca/bragzone.base.html
  3179. or ftp://links.uwaterloo.ca:/pub/BragZone/ ) compares the results of
  3180. various image compression schemes against a 32 element test suite.
  3181. Sample images are available.
  3182.  
  3183. The Computer Vision Home Page has many links to test images in
  3184. http://www.cs.cmu.edu:80/afs/cs/project/cil/ftp/html/v-images.html
  3185.  
  3186. A bunch of standard images (lenna, baboon, cameraman, crowd, moon
  3187. etc..) used to be in ftp://eedsp.gatech.edu/database/images . The
  3188. images are in 256-level grayshades (256x256 pixels, 256 "colors").
  3189.  
  3190. [Note: the site ipl.rpi.edu mentioned below keeps changing. Images
  3191. stay there for a while then disappear. They are again available at
  3192. the time of writing (27 Dec 93).]
  3193.  
  3194. The site ipl.rpi.edu (128.113.14.50) has standard images in two
  3195. directories:
  3196.    ftp://ipl.rpi.edu/pub/image/still/usc 
  3197.    ftp://ipl.rpi.edu/pub/image/still/canon
  3198.  
  3199. (The directory /pub/image/sequence was taken offline because of
  3200. possible copyright problems, but has come back again. In particular,
  3201. Miss America is in subdirectories of /pub/image/sequence/missa.)
  3202.  
  3203. In each of those directories are (usually) the following directories:
  3204.    bgr     - 24 bit blue, green, red
  3205.    color   - 24 bit red, green, blue
  3206.    gray    - 8 bit grayscale uniform weighted
  3207.    gray601 - 8 bit grayscale CCIR-601 weighted
  3208.  
  3209. And in these directories are the actual images.  
  3210.  
  3211. For example, the popular lena image is in
  3212.    ftp://ipl.rpi.edu/pub/image/still/usc/bgr/lena        # 24 bit BGR
  3213.    ftp://ipl.rpi.edu/pub/image/still/usc/gray/lena-y.ras # 8 bit gray
  3214.  
  3215. All of the images are in Sun rasterfile format.  You can use the pbm
  3216. utilities to convert them to whatever format is most convenient.
  3217. [pbm is available in ftp://ftp.ee.lbl.gov/pbmplus*.tar.Z ].
  3218. Questions about the ipl archive should be sent to help@ipl.rpi.edu.
  3219.  
  3220.  
  3221. There are few gray-scale still images and some raw data of test results
  3222. available in directory ftp://nic.funet.fi/pub/graphics/misc/test-images/
  3223. There are lots of .gif images in ftp://nic.funet.fi/pub/pics/
  3224.  
  3225. Medical images can be found in:
  3226.   ftp://decaf.stanford.edu/pub/images/medical/mri
  3227.   ftp://eedsp.gatech.edu/database/images/wchung/medical
  3228.   ftp://omicron.cs.unc.edu/pub/projects/softlab/CHVRTD
  3229.  
  3230. The WWW address for the National Library of Medicine is http://www.nlm.nih.gov
  3231. A list of health and medical related Internet resources is available ftp://in
  3232. ftp.sura.net/pub/nic/HealthResources/medical.resources.3-94
  3233.  
  3234. Rodney Peck <rodney@balltown.cma.com> is interested in some method
  3235. of establishing a canonical ftp database of images but does not have
  3236. the resources to provide an ftp site for that database. Send suggestions to
  3237. rodney@balltown.cma.com.
  3238.  
  3239.  
  3240. Beware: the same image often comes in many different forms, at
  3241. different resolutions, etc... The original lenna image is 512 wide,
  3242. 512 high, 8 bits per pel, red, green and blue fields.  Gray-scale
  3243. versions of Lenna have been obtained in two different ways from the
  3244. original:
  3245.  (1) Using the green field as a gray-scale image, and
  3246.  (2) Doing an RGB->YUV transformation and saving the Y component.
  3247. Method (1) makes it easier to compare different people's results since
  3248. everyone's version should be the same using that method.  Method (2)
  3249. produces a more correct image.
  3250.  
  3251. For the curious: 'lena' or 'lenna' is a digitized Playboy centerfold,
  3252. from November 1972. (Lenna is the spelling in Playboy, Lena is the
  3253. Swedish spelling of the name.) Lena Soderberg (ne Sjooblom) was last
  3254. reported living in her native Sweden, happily married with three kids
  3255. and a job with the state liquor monopoly.  In 1988, she was
  3256. interviewed by some Swedish computer related publication, and she was
  3257. pleasantly amused by what had happened to her picture.  That was the
  3258. first she knew of the use of that picture in the computer business.
  3259.  
  3260. The editorial in the January 1992 issue of Optical Engineering (v. 31
  3261. no. 1) details how Playboy has finally caught on to the fact that
  3262. their copyright on Lena Sjooblom's photo is being widely infringed.
  3263. It sounds as if you will have to get permission from Playboy to
  3264. publish it in the future.
  3265.  
  3266. The CCITT (ITU-T) test images are in ftp://ftp.cs.waikato.ac.nz/pub/ccitt/
  3267. and http://www.cs.waikato.ac.nz/~singlis/ccitt.html
  3268. [The images in ftp://nic.funet.fi/pub/graphics/misc/test-images/ccitt*.tif are
  3269. corrupted.] This set is commonly used to compare binary image compression
  3270. techniques. The images are 1728x2376 pixels.
  3271.  
  3272. ------------------------------------------------------------------------------
  3273.  
  3274. Subject: [56] I am looking for a message digest algorithm
  3275.  
  3276.  
  3277. Look on the ftp site rsa.com, in directory /pub. MD4 and MD5 are there.
  3278. This question would be more appropriate on sci.crypt.
  3279.  
  3280. ------------------------------------------------------------------------------
  3281.  
  3282. Subject: [57] I have lost my password on a .zip file
  3283.  
  3284. This question would be more appropriate on sci.crypt.
  3285. Try the following:
  3286. ftp://idea.sec.dsi.unimi.it/pub/security/crypt/code/zipcrack.c.gz
  3287. ftp://idea.sec.dsi.unimi.it/pub/security/crypt/rpub.cl.msu.edu/crypt/msdos/zipcrack*
  3288. ftp://idea.sec.dsi.unimi.it/pub/security/crypt/rpub.cl.msu.edu/crypt/other/zipcrack.c
  3289. ftp://ftp.ox.ac.uk/pub/crypto/cryptanalysis/fzc100.zip
  3290. ftp://ftp.ox.ac.uk/pub/crypto/cryptanalysis/pkcrack.zip
  3291. ftp://ftp.ox.ac.uk/pub/crypto/cryptanalysis/zipcrk20.zip
  3292.  
  3293. These are brute force crackers. A known plaintext attack is also possible,
  3294. see ftp://ripem.msu.edu/pub/crypt/docs/kocher-pkzip-attack.ps.gz
  3295.  
  3296.           End of part 1 of the comp.compression faq.
  3297.  
  3298.  
  3299. Part 2: (Long) introductions to data compression techniques
  3300.  
  3301. [70] Introduction to data compression (long)
  3302.        Huffman and Related Compression Techniques
  3303.        Arithmetic Coding
  3304.        Substitutional Compressors
  3305.           The LZ78 family of compressors
  3306.           The LZ77 family of compressors
  3307.  
  3308. [71] Introduction to MPEG (long)
  3309.        What is MPEG?
  3310.        Does it have anything to do with JPEG?
  3311.        Then what's JBIG and MHEG?
  3312.        What has MPEG accomplished?
  3313.        So how does MPEG I work?
  3314.        What about the audio compression?
  3315.        So how much does it compress?
  3316.        What's phase II?
  3317.        When will all this be finished?
  3318.        How do I join MPEG?
  3319.        How do I get the documents, like the MPEG I draft?
  3320.  
  3321. [72] What is wavelet theory?
  3322. [73] What is the theoretical compression limit?
  3323. [74] Introduction to JBIG
  3324. [75] Introduction to JPEG
  3325. [76] What is Vector Quantization?
  3326. [77] Introduction to Fractal compression
  3327.  
  3328. Part 3: (Long) list of image compression hardware
  3329.  
  3330. [85] Image compression hardware
  3331. [99] Acknowledgments
  3332.  
  3333.  
  3334. Search for "Subject: [#]" to get to question number # quickly. Some news
  3335. readers can also take advantage of the message digest format used here.
  3336.  
  3337. ------------------------------------------------------------------------------
  3338.  
  3339. Subject: [70] Introduction to data compression (long)
  3340.  
  3341.  
  3342. Written by Peter Gutmann <pgut1@cs.aukuni.ac.nz>.
  3343.  
  3344.  Huffman and Related Compression Techniques
  3345.  ------------------------------------------
  3346.  
  3347.   *Huffman compression* is a statistical data compression technique which 
  3348. gives a reduction in the average code length used to represent the symbols of 
  3349. a alphabet.  The Huffman code is an example of a code which is optimal in the 
  3350. case where all symbols probabilities are integral powers of 1/2.  A Huffman 
  3351. code can be built in the following manner:
  3352.  
  3353.   (1) Rank all symbols in order of probability of occurrence.
  3354.     
  3355.   (2) Successively combine the two symbols of the lowest probability to form
  3356.       a new composite symbol; eventually we will build a binary tree where
  3357.       each node is the probability of all nodes beneath it.
  3358.  
  3359.   (3) Trace a path to each leaf, noticing the direction at each node.
  3360.  
  3361.   For a given frequency distribution, there are many possible Huffman codes,
  3362. but the total compressed length will be the same. It is possible to
  3363. define a 'canonical' Huffman tree, that is, pick one of these alternative
  3364. trees. Such a canonical tree can then be represented very compactly, by
  3365. transmitting only the bit length of each code. This technique is used
  3366. in most archivers (pkzip, lha, zoo, arj, ...).
  3367.  
  3368.  
  3369.   A technique related to Huffman coding is *Shannon-Fano coding*, which
  3370. works as follows:
  3371.  
  3372.   (1) Divide the set of symbols into two equal or almost equal subsets
  3373.       based on the probability of occurrence of characters in each
  3374.       subset.  The first subset is assigned a binary zero, the second
  3375.       a binary one.
  3376.  
  3377.   (2) Repeat step (1) until all subsets have a single element.
  3378.  
  3379. The algorithm used to create the Huffman codes is bottom-up, and the
  3380. one for the Shannon-Fano codes is top-down. Huffman encoding always
  3381. generates optimal codes, Shannon-Fano sometimes uses a few more bits.
  3382.  
  3383.  
  3384.  Arithmetic Coding
  3385.  -----------------
  3386.  
  3387.   It would appear that Huffman or Shannon-Fano coding is the perfect
  3388. means of compressing data.  However, this is *not* the case.  As
  3389. mentioned above, these coding methods are optimal when and only when
  3390. the symbol probabilities are integral powers of 1/2, which is usually
  3391. not the case.
  3392.  
  3393.   The technique of *arithmetic coding* does not have this restriction:
  3394. It achieves the same effect as treating the message as one single unit
  3395. (a technique which would, for Huffman coding, require enumeration of
  3396. every single possible message), and thus attains the theoretical
  3397. entropy bound to compression efficiency for any source.
  3398.  
  3399.   Arithmetic coding works by representing a number by an interval of real 
  3400. numbers between 0 and 1.  As the message becomes longer, the interval needed 
  3401. to represent it becomes smaller and smaller, and the number of bits needed to 
  3402. specify that interval increases.  Successive symbols in the message reduce 
  3403. this interval in accordance with the probability of that symbol. The more
  3404. likely symbols reduce the range by less, and thus add fewer bits to the   
  3405. message.
  3406.  
  3407.      1                                             Codewords
  3408.     +-----------+-----------+-----------+           /-----\
  3409.     |           |8/9 YY     |  Detail   |<- 31/32    .11111
  3410.     |           +-----------+-----------+<- 15/16    .1111
  3411.     |    Y      |           | too small |<- 14/16    .1110
  3412.     |2/3        |    YX     | for text  |<- 6/8      .110
  3413.     +-----------+-----------+-----------+
  3414.     |           |           |16/27 XYY  |<- 10/16    .1010
  3415.     |           |           +-----------+
  3416.     |           |    XY     |           |
  3417.     |           |           |   XYX     |<- 4/8      .100
  3418.     |           |4/9        |           |
  3419.     |           +-----------+-----------+
  3420.     |           |           |           |
  3421.     |    X      |           |   XXY     |<- 3/8      .011
  3422.     |           |           |8/27       |
  3423.     |           |           +-----------+
  3424.     |           |    XX     |           |
  3425.     |           |           |           |<- 1/4      .01
  3426.     |           |           |   XXX     |
  3427.     |           |           |           |
  3428.     |0          |           |           |
  3429.     +-----------+-----------+-----------+
  3430.  
  3431.   As an example of arithmetic coding, lets consider the example of two
  3432. symbols X and Y, of probabilities 0.66 and 0.33. To encode this message, we
  3433. examine the first symbol: If it is a X, we choose the lower partition; if
  3434. it is a Y, we choose the upper partition.  Continuing in this manner for
  3435. three symbols, we get the codewords shown to the right of the diagram above
  3436. - they can be found by simply taking an appropriate location in the
  3437. interval for that particular set of symbols and turning it into a binary
  3438. fraction. In practice, it is also necessary to add a special end-of-data
  3439. symbol, which is not represented in this simpe example.
  3440.         
  3441.   In this case the arithmetic code is not completely efficient, which is due 
  3442. to the shortness of the message - with longer messages the coding efficiency 
  3443. does indeed approach 100%.
  3444.  
  3445.   Now that we have an efficient encoding technique, what can we do with it? 
  3446. What we need is a technique for building a model of the data which we can 
  3447. then use with the encoder.  The simplest model is a fixed one, for example a 
  3448. table of standard letter frequencies for English text which we can then use 
  3449. to get letter probabilities.  An improvement on this technique is to use an 
  3450. *adaptive model*, in other words a model which adjusts itself to the data 
  3451. which is being compressed as the data is compressed.  We can convert the 
  3452. fixed model into an adaptive one by adjusting the symbol frequencies after 
  3453. each new symbol is encoded, allowing the model to track the data being 
  3454. transmitted.  However, we can do much better than that.
  3455.  
  3456. Using the symbol probabilities by themselves is not a particularly good
  3457. estimate of the true entropy of the data: We can take into account
  3458. intersymbol probabilities as well.  The best compressors available today
  3459. take this approach: DMC (Dynamic Markov Coding) starts with a zero-order
  3460. Markov model and gradually extends this initial model as compression
  3461. progresses; PPM (Prediction by Partial Matching) looks for a match of the
  3462. text to be compressed in an order-n context.  If no match is found, it
  3463. drops to an order n-1 context, until it reaches order 0.  Both these
  3464. techniques thus obtain a much better model of the data to be compressed,
  3465. which, combined with the use of arithmetic coding, results in superior
  3466. compression performance.
  3467.  
  3468.   So if arithmetic coding-based compressors are so powerful, why are they not 
  3469. used universally?  Apart from the fact that they are relatively new and 
  3470. haven't come into general use too much yet, there is also one major concern:  
  3471. The fact that they consume rather large amounts of computing resources, both 
  3472. in terms of CPU power and memory.  The building of sophisticated models for 
  3473. the compression can chew through a fair amount of memory (especially in the 
  3474. case of DMC, where the model can grow without bounds); and the arithmetic 
  3475. coding itself involves a fair amount of number crunching.
  3476. There is however an alternative approach, a class of compressors generally 
  3477. referred to as *substitutional* or *dictionary-based compressors*.
  3478.  
  3479.  Substitutional Compressors
  3480.  --------------------------
  3481.  
  3482.   The basic idea behind a substitutional compressor is to replace an 
  3483. occurrence of a particular phrase or group of bytes in a piece of data with a 
  3484. reference to a previous occurrence of that phrase.  There are two main 
  3485. classes of schemes, named after Jakob Ziv and Abraham Lempel, who first 
  3486. proposed them in 1977 and 1978.
  3487.  
  3488. <The LZ78 family of compressors>
  3489.  
  3490.   LZ78-based schemes work by entering phrases into a *dictionary* and then, 
  3491. when a repeat occurrence of that particular phrase is found, outputting the 
  3492. dictionary index instead of the phrase.  There exist several compression 
  3493. algorithms based on this principle, differing mainly in the manner in which 
  3494. they manage the dictionary.  The most well-known scheme (in fact the most 
  3495. well-known of all the Lempel-Ziv compressors, the one which is generally (and 
  3496. mistakenly) referred to as "Lempel-Ziv Compression"), is Terry Welch's LZW 
  3497. scheme, which he designed in 1984 for implementation in hardware for high- 
  3498. performance disk controllers.
  3499.  
  3500. Input string: /WED/WE/WEE/WEB
  3501.  
  3502. Character input:    Code output:    New code value and associated string:
  3503.     /W                  /                   256 = /W
  3504.     E                   W                   257 = WE
  3505.     D                   E                   258 = ED
  3506.     /                   D                   259 = D/
  3507.     WE                  256                 260 = /WE
  3508.     /                   E                   261 = E/
  3509.     WEE                 260                 262 = /WEE
  3510.     /W                  261                 263 = E/W
  3511.     EB                  257                 264 = WEB
  3512.     <END>               B
  3513.     
  3514.   LZW starts with a 4K dictionary, of which entries 0-255 refer to individual 
  3515. bytes, and entries 256-4095 refer to substrings.  Each time a new code is 
  3516. generated it means a new string has been parsed.  New strings are generated 
  3517. by appending the current character K to the end of an existing string w.  The 
  3518. algorithm for LZW compression is as follows:
  3519.  
  3520.   set w = NIL
  3521.   loop
  3522.       read a character K
  3523.       if wK exists in the dictionary
  3524.           w = wK
  3525.       else
  3526.           output the code for w
  3527.           add wK to the string table
  3528.           w = K
  3529.   endloop
  3530.  
  3531.   A sample run of LZW over a (highly redundant) input string can be seen in 
  3532. the diagram above.  The strings are built up character-by-character starting 
  3533. with a code value of 256.  LZW decompression takes the stream of codes and 
  3534. uses it to exactly recreate the original input data.  Just like the 
  3535. compression algorithm, the decompressor adds a new string to the dictionary 
  3536. each time it reads in a new code.  All it needs to do in addition is to 
  3537. translate each incoming code into a string and send it to the output.  A 
  3538. sample run of the LZW decompressor is shown in below.
  3539.  
  3540. Input code: /WED<256>E<260><261><257>B
  3541.  
  3542. Input code:        Output string:     New code value and associated string:
  3543.     /                  /            
  3544.     W                  W                      256 = /W
  3545.     E                  E                      257 = WE
  3546.     D                  D                      258 = ED
  3547.     256                /W                     259 = D/
  3548.     E                  E                      260 = /WE
  3549.     260                /WE                    261 = E/
  3550.     261                E/                     262 = /WEE
  3551.     257                WE                     263 = E/W
  3552.     B                  B                      264 = WEB
  3553.            
  3554.   The most remarkable feature of this type of compression is that the entire 
  3555. dictionary has been transmitted to the decoder without actually explicitly 
  3556. transmitting the dictionary.  At the end of the run, the decoder will have a 
  3557. dictionary identical to the one the encoder has, built up entirely as part of 
  3558. the decoding process.
  3559.     LZW is more commonly encountered today in a variant known as LZC, after 
  3560. its use in the UNIX "compress" program.  In this variant, pointers do not 
  3561. have a fixed length.  Rather, they start with a length of 9 bits, and then 
  3562. slowly grow to their maximum possible length once all the pointers of a 
  3563. particular size have been used up.  Furthermore, the dictionary is not frozen 
  3564. once it is full as for LZW - the program continually monitors compression 
  3565. performance, and once this starts decreasing the entire dictionary is 
  3566. discarded and rebuilt from scratch.  More recent schemes use some sort of 
  3567. least-recently-used algorithm to discard little-used phrases once the 
  3568. dictionary becomes full rather than throwing away the entire dictionary.  
  3569.  
  3570. Finally, not all schemes build up the dictionary by adding a single new 
  3571. character to the end of the current phrase. An alternative technique is to 
  3572. concatenate the previous two phrases (LZMW), which results in a faster 
  3573. buildup of longer phrases than the character-by-character buildup of the 
  3574. other methods.  The disadvantage of this method is that a more sophisticated 
  3575. data structure is needed to handle the dictionary.
  3576.  
  3577. [A good introduction to LZW, MW, AP and Y coding is given in the yabba
  3578. package. For ftp information, see question 2 in part one, file type .Y]
  3579.  
  3580.  
  3581. <The LZ77 family of compressors>
  3582.  
  3583.   LZ77-based schemes keep track of the last n bytes of data seen, and when a 
  3584. phrase is encountered that has already been seen, they output a pair of 
  3585. values corresponding to the position of the phrase in the previously-seen 
  3586. buffer of data, and the length of the phrase.  In effect the compressor moves 
  3587. a fixed-size *window* over the data (generally referred to as a *sliding 
  3588. window*), with the position part of the (position, length) pair referring to 
  3589. the position of the phrase within the window.  The most commonly used 
  3590. algorithms are derived from the LZSS scheme described by James Storer and 
  3591. Thomas Szymanski in 1982.  In this the compressor maintains a window of size 
  3592. N bytes and a *lookahead buffer* the contents of which it tries to find a 
  3593. match for in the window:
  3594.  
  3595.   while( lookAheadBuffer not empty )
  3596.       {
  3597.       get a pointer ( position, match ) to the longest match in the window
  3598.           for the lookahead buffer;
  3599.  
  3600.       if( length > MINIMUM_MATCH_LENGTH )
  3601.           {
  3602.           output a ( position, length ) pair;
  3603.           shift the window length characters along;
  3604.           }
  3605.       else
  3606.           {
  3607.           output the first character in the lookahead buffer;
  3608.           shift the window 1 character along;
  3609.           }
  3610.       }
  3611.         
  3612.   Decompression is simple and fast:  Whenever a ( position, length ) pair is 
  3613. encountered, go to that ( position ) in the window and copy ( length ) bytes 
  3614. to the output.
  3615.  
  3616.   Sliding-window-based schemes can be simplified by numbering the input text
  3617. characters mod N, in effect creating a circular buffer.  The sliding window
  3618. approach automatically creates the LRU effect which must be done explicitly in
  3619. LZ78 schemes.  Variants of this method apply additional compression to the
  3620. output of the LZSS compressor, which include a simple variable-length code
  3621. (LZB), dynamic Huffman coding (LZH), and Shannon-Fano coding (ZIP 1.x)), all
  3622. of which result in a certain degree of improvement over the basic scheme,
  3623. especially when the data are rather random and the LZSS compressor has little
  3624. effect.
  3625.   Recently an algorithm was developed which combines the ideas behind LZ77 and
  3626. LZ78 to produce a hybrid called LZFG.  LZFG uses the standard sliding window,
  3627. but stores the data in a modified trie data structure and produces as output
  3628. the position of the text in the trie.  Since LZFG only inserts complete
  3629. *phrases* into the dictionary, it should run faster than other LZ77-based
  3630. compressors.
  3631.  
  3632. All popular archivers (arj, lha, zip, zoo) are variations on the LZ77 theme.
  3633.  
  3634. ------------------------------------------------------------------------------
  3635.  
  3636. Subject: [71] Introduction to MPEG (long)
  3637.  
  3638.  
  3639. For MPEG players, see item 15 in part 1 of the FAQ.  Frank Gadegast
  3640. <phade@cs.tu-berlin.de> also posts a FAQ specialized in MPEG, available in
  3641. ftp://ftp.cs.tu-berlin.de/pub/msdos/dos/graphics/mpegfa*.zip and
  3642. http://www.powerweb.de/mpeg/mpegfaq/
  3643.  
  3644. The site ftp.crs4.it dedicated to the MPEG compression standard,
  3645. see the directory mpeg and subdirectories. Another MPEG FAQ is available
  3646. in http://www.crs4.it/~luigi/MPEG/mpegfaq.html
  3647. See also http://www-plateau.cs.berkeley.edu/mpeg
  3648.  
  3649. A description of MPEG can be found in: "MPEG: A Video Compression
  3650. Standard for Multimedia Applications" Didier Le Gall, Communications
  3651. of the ACM, April 1991, Vol 34. No.4, pp.46-58.
  3652.  
  3653. The MPEG book (ISBN 0-442-01920-3) was originally scheduled for August
  3654. 1994 by Van Nostrand publishing (phone 800-842-3636) then later for
  3655. December 1995 (anyone got more recent info?).
  3656.  
  3657. MPEG-2 bitstreams are available on wuarchive.wustl.edu in directory
  3658. /graphics/x3l3/pub/bitstreams. MPEG-2 Demultiplexer source code is
  3659. in /graphics/x3l3/pub/bitstreams/systems/munsi_v13.tar.gz
  3660.  
  3661. Public C source encoder for all 3 layers for mpeg2 including mpeg1 is in
  3662. ftp://ftp.tnt.uni-hannover.de/pub/MPEG/audio/mpeg2/public_software/
  3663. technical_report/dist08.tar.gz
  3664.  
  3665.  
  3666. Introduction to MPEG originally written by Mark Adler 
  3667. <madler@cco.caltech.edu> around January 1992; modified and updated by 
  3668. Harald Popp <layer3@iis.fhg.de> in March 94:
  3669.  
  3670. Q: What is MPEG, exactly?
  3671.  
  3672. A: MPEG is the "Moving Picture Experts Group", working under the 
  3673.    joint direction of the International Standards Organization (ISO) 
  3674.    and the International Electro-Technical Commission (IEC). This 
  3675.    group works on standards for the coding of moving pictures and 
  3676.    associated audio.
  3677.  
  3678. Q: What is the status of MPEG's work, then? What's about MPEG-1, -2, 
  3679.    and so on?
  3680.  
  3681. A: MPEG approaches the growing need for multimedia standards step-by-
  3682.    step. Today, three "phases" are defined:
  3683.    
  3684.    MPEG-1: "Coding of Moving Pictures and Associated Audio for 
  3685.            Digital Storage Media at up to about 1.5 MBit/s"  
  3686.  
  3687.    Status: International Standard IS-11172, completed in 10.92
  3688.    
  3689.    MPEG-2: "Generic Coding of Moving Pictures and Associated Audio"
  3690.    
  3691.    Status: Comittee Draft CD 13818 as found in documents MPEG93 / 
  3692.            N601, N602, N603 (11.93)   
  3693.  
  3694.    MPEG-3: no longer exists (has been merged into MPEG-2)
  3695.    
  3696.    MPEG-4: "Very Low Bitrate Audio-Visual Coding"
  3697.    
  3698.    Status: Call for Proposals 11.94, Working Draft in 11.96 
  3699.  
  3700. Q: MPEG-1 is ready-for-use. How does the standard look like?
  3701.  
  3702. A: MPEG-1 consists of 4 parts:
  3703.  
  3704.    IS 11172-1: System
  3705.    describes synchronization and multiplexing of video and audio
  3706.  
  3707.    IS 11172-2: Video
  3708.    describes compression of non-interlaced video signals
  3709.    
  3710.    IS 11172-3: Audio
  3711.    describes compression of audio signals 
  3712.    
  3713.    CD 11172-4: Compliance Testing
  3714.    describes procedures for determining the characteristics of coded 
  3715.    bitstreams and the decoding porcess and for testing compliance 
  3716.    with the requirements stated in the other parts
  3717.  
  3718. Q. Does MPEG have anything to do with JPEG? 
  3719.  
  3720. A. Well, it sounds the same, and they are part of the same 
  3721.    subcommittee of ISO along with JBIG and MHEG, and they usually meet 
  3722.    at the same place at the same time.  However, they are different 
  3723.    sets of people with few or no common individual members, and they 
  3724.    have different charters and requirements.  JPEG is for still image 
  3725.    compression.
  3726.  
  3727. Q. Then what's JBIG and MHEG?
  3728.  
  3729. A. Sorry I mentioned them. Ok, I'll simply say that JBIG is for binary
  3730.    image compression (like faxes), and MHEG is for multi-media data
  3731.    standards (like integrating stills, video, audio, text, etc.).
  3732.    For an introduction to JBIG, see question 74 below.
  3733.  
  3734. Q. So how does MPEG-1 work? Tell me about video coding!
  3735.  
  3736. A. First off, it starts with a relatively low resolution video
  3737.    sequence (possibly decimated from the original) of about 352 by
  3738.    240 frames by 30 frames/s (US--different numbers for Europe),
  3739.    but original high (CD) quality audio.  The images are in color,
  3740.    but converted to YUV space, and the two chrominance channels
  3741.    (U and V) are decimated further to 176 by 120 pixels.  It turns
  3742.    out that you can get away with a lot less resolution in those
  3743.    channels and not notice it, at least in "natural" (not computer
  3744.    generated) images.
  3745.  
  3746.    The basic scheme is to predict motion from frame to frame in the
  3747.    temporal direction, and then to use DCT's (discrete cosine
  3748.    transforms) to organize the redundancy in the spatial directions.
  3749.    The DCT's are done on 8x8 blocks, and the motion prediction is
  3750.    done in the luminance (Y) channel on 16x16 blocks.  In other words,
  3751.    given the 16x16 block in the current frame that you are trying to
  3752.    code, you look for a close match to that block in a previous or
  3753.    future frame (there are backward prediction modes where later
  3754.    frames are sent first to allow interpolating between frames).
  3755.    The DCT coefficients (of either the actual data, or the difference
  3756.    between this block and the close match) are "quantized", which
  3757.    means that you divide them by some value to drop bits off the
  3758.    bottom end.  Hopefully, many of the coefficients will then end up
  3759.    being zero.  The quantization can change for every "macroblock"
  3760.    (a macroblock is 16x16 of Y and the corresponding 8x8's in both
  3761.    U and V).  The results of all of this, which include the DCT
  3762.    coefficients, the motion vectors, and the quantization parameters
  3763.    (and other stuff) is Huffman coded using fixed tables.  The DCT
  3764.    coefficients have a special Huffman table that is "two-dimensional"
  3765.    in that one code specifies a run-length of zeros and the non-zero
  3766.    value that ended the run.  Also, the motion vectors and the DC
  3767.    DCT components are DPCM (subtracted from the last one) coded.
  3768.  
  3769. Q. So is each frame predicted from the last frame?
  3770.  
  3771. A. No.  The scheme is a little more complicated than that.  There are
  3772.    three types of coded frames.  There are "I" or intra frames.  They
  3773.    are simply a frame coded as a still image, not using any past
  3774.    history.  You have to start somewhere.  Then there are "P" or
  3775.    predicted frames.  They are predicted from the most recently
  3776.    reconstructed I or P frame.  (I'm describing this from the point
  3777.    of view of the decompressor.)  Each macroblock in a P frame can
  3778.    either come with a vector and difference DCT coefficients for a
  3779.    close match in the last I or P, or it can just be "intra" coded
  3780.    (like in the I frames) if there was no good match.
  3781.  
  3782.    Lastly, there are "B" or bidirectional frames.  They are predicted
  3783.    from the closest two I or P frames, one in the past and one in the
  3784.    future.  You search for matching blocks in those frames, and try
  3785.    three different things to see which works best.  (Now I have the
  3786.    point of view of the compressor, just to confuse you.)  You try 
  3787.    using the forward vector, the backward vector, and you try 
  3788.    averaging the two blocks from the future and past frames, and 
  3789.    subtracting that from the block being coded.  If none of those work 
  3790.    well, you can intracode the block.
  3791.  
  3792.    The sequence of decoded frames usually goes like:
  3793.  
  3794.    IBBPBBPBBPBBIBBPBBPB...
  3795.  
  3796.    Where there are 12 frames from I to I (for US and Japan anyway.)
  3797.    This is based on a random access requirement that you need a
  3798.    starting point at least once every 0.4 seconds or so.  The ratio
  3799.    of P's to B's is based on experience.
  3800.  
  3801.    Of course, for the decoder to work, you have to send that first
  3802.    P *before* the first two B's, so the compressed data stream ends
  3803.    up looking like:
  3804.  
  3805.    0xx312645...
  3806.  
  3807.    where those are frame numbers.  xx might be nothing (if this is
  3808.    the true starting point), or it might be the B's of frames -2 and
  3809.    -1 if we're in the middle of the stream somewhere.
  3810.  
  3811.    You have to decode the I, then decode the P, keep both of those
  3812.    in memory, and then decode the two B's.  You probably display the
  3813.    I while you're decoding the P, and display the B's as you're
  3814.    decoding them, and then display the P as you're decoding the next
  3815.    P, and so on.
  3816.  
  3817. Q. You've got to be kidding.
  3818.  
  3819. A. No, really!
  3820.  
  3821. Q. Hmm.  Where did they get 352x240?
  3822.  
  3823. A. That derives from the CCIR-601 digital television standard which
  3824.    is used by professional digital video equipment.  It is (in the US)
  3825.    720 by 243 by 60 fields (not frames) per second, where the fields
  3826.    are interlaced when displayed.  (It is important to note though
  3827.    that fields are actually acquired and displayed a 60th of a second
  3828.    apart.)  The chrominance channels are 360 by 243 by 60 fields a
  3829.    second, again interlaced.  This degree of chrominance decimation
  3830.    (2:1 in the horizontal direction) is called 4:2:2.  The source
  3831.    input format for MPEG I, called SIF, is CCIR-601 decimated by 2:1
  3832.    in the horizontal direction, 2:1 in the time direction, and an
  3833.    additional 2:1 in the chrominance vertical direction.  And some
  3834.    lines are cut off to make sure things divide by 8 or 16 where
  3835.    needed.
  3836.  
  3837. Q. What if I'm in Europe?
  3838.  
  3839. A. For 50 Hz display standards (PAL, SECAM) change the number of lines
  3840.    in a field from 243 or 240 to 288, and change the display rate to
  3841.    50 fields/s or 25 frames/s.  Similarly, change the 120 lines in
  3842.    the decimated chrominance channels to 144 lines.  Since 288*50 is
  3843.    exactly equal to 240*60, the two formats have the same source data
  3844.    rate.
  3845.  
  3846. Q. What will MPEG-2 do for video coding?
  3847.  
  3848. A. As I said, there is a considerable loss of quality in going from
  3849.    CCIR-601 to SIF resolution.  For entertainment video, it's simply
  3850.    not acceptable.  You want to use more bits and code all or almost
  3851.    all the CCIR-601 data.  From subjective testing at the Japan
  3852.    meeting in November 1991, it seems that 4 MBits/s can give very
  3853.    good quality compared to the original CCIR-601 material.  The
  3854.    objective of MPEG-2 is to define a bit stream optimized for 
  3855.    these resolutions and bit rates.
  3856.  
  3857. Q. Why not just scale up what you're doing with MPEG-1?
  3858.  
  3859. A. The main difficulty is the interlacing.  The simplest way to extend
  3860.    MPEG-1 to interlaced material is to put the fields together into
  3861.    frames (720x486x30/s).  This results in bad motion artifacts that
  3862.    stem from the fact that moving objects are in different places
  3863.    in the two fields, and so don't line up in the frames.  Compressing
  3864.    and decompressing without taking that into account somehow tends to
  3865.    muddle the objects in the two different fields.
  3866.  
  3867.    The other thing you might try is to code the even and odd field
  3868.    streams separately.  This avoids the motion artifacts, but as you
  3869.    might imagine, doesn't get very good compression since you are not
  3870.    using the redundancy between the even and odd fields where there
  3871.    is not much motion (which is typically most of image).
  3872.  
  3873.    Or you can code it as a single stream of fields.  Or you can
  3874.    interpolate lines.  Or, etc. etc.  There are many things you can
  3875.    try, and the point of MPEG-2 is to figure out what works well.
  3876.    MPEG-2 is not limited to consider only derivations of MPEG-1.
  3877.    There were several non-MPEG-1-like schemes in the competition in
  3878.    November, and some aspects of those algorithms may or may not
  3879.    make it into the final standard for entertainment video 
  3880.    compression.
  3881.  
  3882. Q. So what works?
  3883.  
  3884. A. Basically, derivations of MPEG-1 worked quite well, with one that
  3885.    used wavelet subband coding instead of DCT's that also worked very
  3886.    well.  Also among the worked-very-well's was a scheme that did not
  3887.    use B frames at all, just I and P's.  All of them, except maybe 
  3888.    one, did some sort of adaptive frame/field coding, where a decision 
  3889.    is made on a macroblock basis as to whether to code that one as 
  3890.    one frame macroblock or as two field macroblocks.  Some other 
  3891.    aspects are how to code I-frames--some suggest predicting the even 
  3892.    field from the odd field.  Or you can predict evens from evens and 
  3893.    odds or odds from evens and odds or any field from any other field, 
  3894.    etc.
  3895.  
  3896. Q. So what works?
  3897.  
  3898. A. Ok, we're not really sure what works best yet.  The next step is
  3899.    to define a "test model" to start from, that incorporates most of
  3900.    the salient features of the worked-very-well proposals in a
  3901.    simple way.  Then experiments will be done on that test model,
  3902.    making a mod at a time, and seeing what makes it better and what
  3903.    makes it worse.  Example experiments are, B's or no B's, DCT vs.
  3904.    wavelets, various field prediction modes, etc.  The requirements,
  3905.    such as implementation cost, quality, random access, etc. will all
  3906.    feed into this process as well.
  3907.  
  3908. Q. When will all this be finished?
  3909.  
  3910. A. I don't know.  I'd have to hope in about a year or less.
  3911.  
  3912. Q: Talking about MPEG audio coding, I heard a lot about "Layer 1, 2 
  3913.    and 3". What does it mean, exactly?   
  3914.  
  3915. A: MPEG-1, IS 11172-3, describes the compression of audio signals 
  3916.    using high performance perceptual coding schemes. It specifies a 
  3917.    family of three audio coding schemes, simply called Layer-1,-2,-3, 
  3918.    with increasing encoder complexity and performance (sound quality 
  3919.    per bitrate). The three codecs are compatible in a hierarchical 
  3920.    way, i.e. a Layer-N decoder is able to decode bitstream data 
  3921.    encoded in Layer-N and all Layers below N (e.g., a Layer-3 
  3922.    decoder may accept Layer-1,-2 and -3, whereas a Layer-2 decoder 
  3923.    may accept only Layer-1 and -2.)
  3924.  
  3925. Q: So we have a family of three audio coding schemes. What does the 
  3926.    MPEG standard define, exactly?
  3927.    
  3928. A: For each Layer, the standard specifies the bitstream format and 
  3929.    the decoder. To allow for future improvements, it does *not* 
  3930.    specify the encoder , but an informative chapter gives an example 
  3931.    for an encoder for each Layer.    
  3932.  
  3933. Q: What have the three audio Layers in common?
  3934.  
  3935. A: All Layers use the same basic structure. The coding scheme can be  
  3936.    described as "perceptual noise shaping" or "perceptual subband / 
  3937.    transform coding". 
  3938.  
  3939.    The encoder analyzes the spectral components of the audio signal 
  3940.    by calculating a filterbank or transform and applies a 
  3941.    psychoacoustic model to estimate the just noticeable noise-
  3942.    level. In its quantization and coding stage, the encoder tries 
  3943.    to allocate the available number of data bits in a way to meet 
  3944.    both the bitrate and masking requirements.
  3945.  
  3946.    The decoder is much less complex. Its only task is to synthesize 
  3947.    an audio signal out of the coded spectral components.
  3948.    
  3949.    All Layers use the same analysis filterbank (polyphase with 32 
  3950.    subbands). Layer-3 adds a MDCT transform to increase the frequency 
  3951.    resolution.
  3952.    
  3953.    All Layers use the same "header information" in their bitstream, 
  3954.    to support the hierarchical structure of the standard.
  3955.    
  3956.    All Layers use a bitstream structure that contains parts that are 
  3957.    more sensitive to biterrors ("header", "bit allocation", 
  3958.    "scalefactors", "side information") and parts that are less 
  3959.    sensitive ("data of spectral components").  
  3960.  
  3961.    All Layers may use 32, 44.1 or 48 kHz sampling frequency.
  3962.    
  3963.    All Layers are allowed to work with similar bitrates:
  3964.    Layer-1: from 32 kbps to 448 kbps
  3965.    Layer-2: from 32 kbps to 384 kbps
  3966.    Layer-3: from 32 kbps to 320 kbps
  3967.  
  3968. Q: What are the main differences between the three Layers, from a 
  3969.    global view?
  3970.  
  3971. A: From Layer-1 to Layer-3,
  3972.    complexity increases (mainly true for the encoder),
  3973.    overall codec delay increases, and
  3974.    performance increases (sound quality per bitrate).
  3975.  
  3976. Q: Which Layer should I use for my application?
  3977.  
  3978. A: Good Question. Of course, it depends on all your requirements. But 
  3979.    as a first approach, you should consider the available bitrate of 
  3980.    your application as the Layers have been designed to support 
  3981.    certain areas of bitrates most efficiently, i.e. with a minimum 
  3982.    drop of sound quality.
  3983.  
  3984.    Let us look a little closer at the strong domains of each Layer.
  3985.     
  3986.    Layer-1: Its ISO target bitrate is 192 kbps per audio channel.
  3987.  
  3988.    Layer-1 is a simplified version of Layer-2. It is most useful for 
  3989.    bitrates around the "high" bitrates around or above 192 kbps. A 
  3990.    version of Layer-1 is used as "PASC" with the DCC recorder.
  3991.  
  3992.    Layer-2: Its ISO target bitrate is 128 kbps per audio channel.
  3993.    
  3994.    Layer-2 is identical with MUSICAM. It has been designed as trade-
  3995.    off between sound quality per bitrate and encoder complexity. It 
  3996.    is most useful for bitrates around the "medium" bitrates of 128 or 
  3997.    even 96 kbps per audio channel. The DAB (EU 147) proponents have 
  3998.    decided to use Layer-2 in the future Digital Audio Broadcasting 
  3999.    network.      
  4000.  
  4001.    Layer-3: Its ISO target bitrate is 64 kbps per audio channel.
  4002.    
  4003.    Layer-3 merges the best ideas of MUSICAM and ASPEC. It has been 
  4004.    designed for best performance at "low" bitrates around 64 kbps or 
  4005.    even below. The Layer-3 format specifies a set of advanced 
  4006.    features that all address one goal: to preserve as much sound 
  4007.    quality as possible even at rather low bitrates. Today, Layer-3 is 
  4008.    already in use in various telecommunication networks (ISDN, 
  4009.    satellite links, and so on) and speech announcement systems. 
  4010.  
  4011. Q: Tell me more about sound quality. How do you assess that?
  4012.  
  4013. A: Today, there is no alternative to expensive listening tests. 
  4014.    During the ISO-MPEG-1 process, 3 international listening tests 
  4015.    have been performed, with a lot of trained listeners, supervised 
  4016.    by Swedish Radio. They took place in 7.90, 3.91 and 11.91. Another 
  4017.    international listening test was performed by CCIR, now ITU-R, in 
  4018.    92.      
  4019.    
  4020.    All these tests used the "triple stimulus, hidden reference" 
  4021.    method and the CCIR impairment scale to assess the audio quality.
  4022.    The listening sequence is "ABC", with A = original, BC = pair of 
  4023.    original / coded signal with random sequence, and the listener has 
  4024.    to evaluate both B and C with a number between 1.0 and 5.0. The 
  4025.    meaning of these values is:
  4026.    
  4027.    5.0 = transparent (this should be the original signal)
  4028.    4.0 = perceptible, but not annoying (first differences noticable)  
  4029.    3.0 = slightly annoying   
  4030.    2.0 = annoying
  4031.    1.0 = very annoying
  4032.  
  4033.    With perceptual codecs (like MPEG audio), all traditional 
  4034.    parameters (like SNR, THD+N, bandwidth) are especially useless. 
  4035.    Fraunhofer-IIS works on objective quality assessment tools, like 
  4036.    the NMR meter (Noise-to-Mask-Ratio), too. BTW: If you need more 
  4037.    informations about NMR, please contact nmr@iis.fhg.de.
  4038.  
  4039. Q: Now that I know how to assess quality, come on, tell me the 
  4040.    results of these tests.
  4041.    
  4042. A: Well, for low bitrates, the main result is that at 60 or 64 kbps 
  4043.    per channel), Layer-2 scored always between 2.1 and 2.6, whereas 
  4044.    Layer-3 scored between 3.6 and 3.8. This is a significant increase 
  4045.    in sound quality, indeed! Furthermore, the selection process for 
  4046.    critical sound material showed that it was rather difficult to 
  4047.    find worst-case material for Layer-3 whereas it was not so hard to 
  4048.    find such items for Layer-2.
  4049.   
  4050. Q: OK, a Layer-2 codec at low bitrates may sound poor today, but 
  4051.    couldn't that be improved in the future? I guess you just told me 
  4052.    before that the encoder is not fixed in the standard.
  4053.    
  4054. A: Good thinking! As the sound quality mainly depends on the encoder 
  4055.    implementation, it is true that there is no such thing as a "Layer-
  4056.    N"- quality. So we definitely only know the performance of the 
  4057.    reference codecs during the international tests. Who knows what 
  4058.    will happen in the future? What we do know now, is:
  4059.    
  4060.    Today, Layer-3 already provides a sound quality that comes very 
  4061.    near to CD quality at 64 kbps per channel. Layer-2 is far away 
  4062.    from that.
  4063.    
  4064.    Tomorrow, both Layers may improve. Layer-2 has been designed as a 
  4065.    trade-off between quality and complexity, so the bitstream format 
  4066.    allows only limited innovations. In contrast, even the current
  4067.    reference Layer-3-codec exploits only a small part of the powerful 
  4068.    mechanisms inside the Layer-3 bitstream format.  
  4069.  
  4070. Q: All in all, you sound as if anybody should use Layer-3 for low 
  4071.    bitrates. Why on earth do some vendors still offer only Layer-2 
  4072.    equipment for these applications?
  4073.    
  4074. A: Well, maybe because they started to design and develop their 
  4075.    system rather early, e.g. in 1990. As Layer-2 is identical with 
  4076.    MUSICAM, it has been available since summer of 90, at latest. In 
  4077.    that year, Layer-3 development started and could be successfully 
  4078.    finished in spring 92. So, for a certain time, vendors could only 
  4079.    exploit the existing part of the new MPEG standard.   
  4080.    
  4081.    Now the situation has changed. All Layers are available, the 
  4082.    standard is completed, and new systems need not limit themselves, 
  4083.    but may capitalize on the full features of MPEG audio.
  4084.  
  4085. Q: How do I get the MPEG documents?
  4086.  
  4087. A: You may order it from your national standards body.
  4088.  
  4089.    E.g., in Germany, please contact:
  4090.    DIN-Beuth Verlag, Auslandsnormen
  4091.    Mrs. Niehoff, Burggrafenstr. 6, D-10772 Berlin, Germany
  4092.    Phone: 030-2601-2757, Fax: 030-2601-1231
  4093.  
  4094.    E.g., in USA, you may order it from ANSI [phone (212) 642-4900] or 
  4095.    buy it from companies like OMNICOM phone +44 438 742424
  4096.                                       FAX   +44 438 740154
  4097.  
  4098. Q. How do I join MPEG?
  4099.  
  4100. A. You don't join MPEG.  You have to participate in ISO as part of a
  4101.    national delegation.  How you get to be part of the national
  4102.    delegation is up to each nation.  I only know the U.S., where you
  4103.    have to attend the corresponding ANSI meetings to be able to
  4104.    attend the ISO meetings.  Your company or institution has to be
  4105.    willing to sink some bucks into travel since, naturally, these
  4106.    meetings are held all over the world.  (For example, Paris,
  4107.    Santa Clara, Kurihama Japan, Singapore, Haifa Israel, Rio de
  4108.    Janeiro, London, etc.)
  4109.  
  4110. ------------------------------------------------------------------------------
  4111.  
  4112. Subject: [72] What is wavelet theory?
  4113.  
  4114.  
  4115. Preprints and software are available by anonymous ftp from the
  4116. Yale Mathematics Department computer ftp://ceres.math.yale.edu/pub/wavelets/
  4117. and /pub/software/ .
  4118.  
  4119. For source code of several wavelet coders, see item 15 in part one of
  4120. this FAQ.
  4121.  
  4122. A list of pointers, covering theory, papers, books, implementations,
  4123. resources and more can be found at
  4124. http://www.amara.com/current/wavelet.html#Wavelinks
  4125.  
  4126. Bill Press of Harvard/CfA has made some things available on
  4127. ftp://cfata4.harvard.edu/pub/ There is a short TeX article on wavelet
  4128. theory (wavelet.tex, to be included in a future edition of Numerical
  4129. Recipes), some sample wavelet code (wavelet.f, in FORTRAN - sigh), and
  4130. a beta version of an astronomical image compression program which he
  4131. is currently developing (FITS format data files only, in
  4132. fitspress08.tar.Z).
  4133.  
  4134. The Rice Wavelet Toolbox Release 2.0 is available in
  4135. ftp://cml.rice.edu/pub/dsp/software/ and /pub/dsp/papers/ .  This is a
  4136. collection of MATLAB of "mfiles" and "mex" files for twoband and
  4137. M-band filter bank/wavelet analysis from the DSP group and
  4138. Computational Mathematics Laboratory (CML) at Rice University,
  4139. Houston, TX.  This release includes application code for Synthetic
  4140. Aperture Radar despeckling and for deblocking of JPEG decompressed
  4141. Images.  Contact: Ramesh Gopinath <ramesh@rice.edu>.
  4142.  
  4143. A mailing list dedicated to research on wavelets has been set up at the
  4144. University of South Carolina. To subscribe to this mailing list, send a
  4145. message with "subscribe" as the subject to wavelet@math.sc.edu.
  4146. For back issues and other information, check the WWW home page at
  4147. http://www.math.sc.edu/~wavelet/
  4148.  
  4149. A tutorial by M. Hilton, B. Jawerth, and A. Sengupta, entitled
  4150. "Compressing Still and Moving Images with Wavelets" is available in
  4151. ftp://ftp.math.sc.edu/pub/wavelet/papers/varia/tutorial/ . The
  4152. files are "tutorial.ps.Z" and "fig8.ps.Z".  fig8 is a comparison of
  4153. JPEG and wavelet compressed images and could take several hours to
  4154. print. The tutorial is also available at
  4155. http://www.mathsoft.com/wavelets.html
  4156.  
  4157. A page on wavelet-based HARC-C compression technology is available at
  4158. http://www.harc.edu/HARCC.html
  4159.  
  4160. Commercial wavelet image compression software:
  4161.   http://www.aware.com
  4162.   http://www.summus.com
  4163.  
  4164. Details of the wavelet transform can be found in
  4165. ftp://ftp.isds.duke.edu/pub/brani/papers/wav4kidsA.ps.Z
  4166. ftp://ftp.isds.duke.edu/pub/brani/papers/wav4kidsB.ps.Z
  4167.  
  4168.  
  4169. A 5 minute course in wavelet transforms, by Richard Kirk <rak@crosfield.co.uk>:
  4170.  
  4171. Do you know what a Haar transform is? Its a transform to another orthonormal
  4172. space (like the DFT), but the basis functions are a set of square wave bursts
  4173. like this...
  4174.  
  4175.    +--+                         +------+
  4176.    +  |  +------------------    +      |      +--------------
  4177.       +--+                             +------+
  4178.  
  4179.          +--+                                 +------+
  4180.    ------+  |  +------------    --------------+      |      +
  4181.             +--+                                     +------+
  4182.  
  4183.                +--+             +-------------+
  4184.    ------------+  |  +------    +             |             +
  4185.                   +--+                        +-------------+
  4186.  
  4187.                      +--+       +---------------------------+
  4188.    ------------------+  |  +    +                           +
  4189.                         +--+
  4190.  
  4191. This is the set of functions for an 8-element 1-D Haar transform. You
  4192. can probably see how to extend this to higher orders and higher dimensions
  4193. yourself. This is dead easy to calculate, but it is not what is usually
  4194. understood by a wavelet transform.
  4195.  
  4196. If you look at the eight Haar functions you see we have four functions
  4197. that code the highest resolution detail, two functions that code the
  4198. coarser detail, one function that codes the coarser detail still, and the 
  4199. top function that codes the average value for the whole `image'.
  4200.  
  4201. Haar function can be used to code images instead of the DFT. With bilevel
  4202. images (such as text) the result can look better, and it is quicker to code.
  4203. Flattish regions, textures, and soft edges in scanned images get a nasty
  4204. `blocking' feel to them. This is obvious on hardcopy, but can be disguised on
  4205. color CRTs by the effects of the shadow mask. The DCT gives more consistent
  4206. results.
  4207.  
  4208. This connects up with another bit of maths sometimes called Multispectral
  4209. Image Analysis, sometimes called Image Pyramids.
  4210.  
  4211. Suppose you want to produce a discretely sampled image from a continuous 
  4212. function. You would do this by effectively `scanning' the function using a
  4213. sinc function [ sin(x)/x ] `aperture'. This was proved by Shannon in the 
  4214. `forties. You can do the same thing starting with a high resolution
  4215. discretely sampled image. You can then get a whole set of images showing 
  4216. the edges at different resolutions by differencing the image at one
  4217. resolution with another version at another resolution. If you have made this
  4218. set of images properly they ought to all add together to give the original 
  4219. image.
  4220.  
  4221. This is an expansion of data. Suppose you started off with a 1K*1K image.
  4222. You now may have a 64*64 low resolution image plus difference images at 128*128
  4223. 256*256, 512*512 and 1K*1K. 
  4224.  
  4225. Where has this extra data come from? If you look at the difference images you 
  4226. will see there is obviously some redundancy as most of the values are near 
  4227. zero. From the way we constructed the levels we know that locally the average
  4228. must approach zero in all levels but the top. We could then construct a set of
  4229. functions out of the sync functions at any level so that their total value 
  4230. at all higher levels is zero. This gives us an orthonormal set of basis 
  4231. functions for a transform. The transform resembles the Haar transform a bit,
  4232. but has symmetric wave pulses that decay away continuously in either direction
  4233. rather than square waves that cut off sharply. This transform is the
  4234. wavelet transform ( got to the point at last!! ).
  4235.  
  4236. These wavelet functions have been likened to the edge detecting functions
  4237. believed to be present in the human retina.
  4238.  
  4239.  
  4240. Loren I. Petrich <lip@s1.gov> adds that order 2 or 3 Daubechies
  4241. discrete wavelet transforms have a speed comparable to DCT's, and
  4242. usually achieve compression a factor of 2 better for the same image
  4243. quality than the JPEG 8*8 DCT. (See item 25 in part 1 of this FAQ for
  4244. references on fast DCT algorithms.)
  4245.  
  4246. ------------------------------------------------------------------------------
  4247.  
  4248. Subject: [73] What is the theoretical compression limit?
  4249.  
  4250.  
  4251. This question can be understood in two different ways:
  4252.  
  4253. (a) For a given compressor/decompressor, what is the best possible
  4254.     lossless compression for an arbitrary string (byte sequence)
  4255.     given as input?
  4256.  
  4257. (b) For a given string, what is the best possible lossless
  4258.     compressor/decompressor?
  4259.  
  4260. For case (a), the question is generally meaningless, because a
  4261. specific compressor may compress one very large input file down to a
  4262. single bit, and enlarge all other files by only one bit.  There is no
  4263. lossless compressor that is guaranteed to compress all possible input
  4264. files. If it compresses some files, then it must enlarge some others.
  4265. This can be proven by a simple counting argument (see item 9).  In
  4266. case (a), the size of the decompressor is not taken into account for
  4267. the determination of the compression ratio since the decompressor is
  4268. fixed and it may decompress an arbitrary number of files of arbitrary
  4269. length.
  4270.  
  4271. For case (b), it is of course necessary to take into account the size
  4272. of the decompressor. The problem may be restated as "What is the
  4273. shortest program p which, when executed, produces the input string s?".
  4274. The size of this program is known as the Kolmogorov complexity
  4275. of the string s.  Strings that are truly random are not compressible:
  4276. the smallest representation of the string is the string itself.
  4277. On the other hand, the output of a pseudo-random number generator
  4278. can be extremely compressible, since it is sufficient to know the
  4279. parameters and seed of the generator to reproduce an arbitrary
  4280. long sequence.
  4281.  
  4282. References: "An Introduction to Kolmogorov Complexity and its Applications",
  4283.       Ming Li and Paul Vitanyi, Springer-Verlag, 1992
  4284.  
  4285. ------------------------------------------------------------------------------
  4286.  
  4287. Subject: [74] Introduction to JBIG
  4288.  
  4289.  
  4290. JBIG software and the JBIG specification are available on nic.funet.fi
  4291. in /pub/graphics/misc/test-images/jbig.tar.gz.
  4292.  
  4293.  
  4294. A short introduction to JBIG, written by Mark Adler <madler@cco.caltech.edu>:
  4295.  
  4296.   JBIG losslessly compresses binary (one-bit/pixel) images.  (The B stands
  4297.   for bi-level.)  Basically it models the redundancy in the image as the
  4298.   correlations of the pixel currently being coded with a set of nearby
  4299.   pixels called the template.  An example template might be the two
  4300.   pixels preceding this one on the same line, and the five pixels centered
  4301.   above this pixel on the previous line.  Note that this choice only
  4302.   involves pixels that have already been seen from a scanner.
  4303.  
  4304.   The current pixel is then arithmetically coded based on the eight-bit
  4305.   (including the pixel being coded) state so formed.  So there are (in this
  4306.   case) 256 contexts to be coded.  The arithmetic coder and probability
  4307.   estimator for the contexts are actually IBM's (patented) Q-coder.  The
  4308.   Q-coder uses low precision, rapidly adaptable (those two are related)
  4309.   probability estimation combined with a multiply-less arithmetic coder.
  4310.   The probability estimation is intimately tied to the interval calculations
  4311.   necessary for the arithmetic coding.
  4312.  
  4313.   JBIG actually goes beyond this and has adaptive templates, and probably
  4314.   some other bells and whistles I don't know about.  You can find a
  4315.   description of the Q-coder as well as the ancestor of JBIG in the Nov 88
  4316.   issue of the IBM Journal of Research and Development.  This is a very
  4317.   complete and well written set of five articles that describe the Q-coder
  4318.   and a bi-level image coder that uses the Q-coder.
  4319.  
  4320.   You can use JBIG on grey-scale or even color images by simply applying
  4321.   the algorithm one bit-plane at a time.  You would want to recode the
  4322.   grey or color levels first though, so that adjacent levels differ in
  4323.   only one bit (called Gray-coding).  I hear that this works well up to
  4324.   about six bits per pixel, beyond which JPEG's lossless mode works better.
  4325.   You need to use the Q-coder with JPEG also to get this performance.
  4326.  
  4327.   Actually no lossless mode works well beyond six bits per pixel, since
  4328.   those low bits tend to be noise, which doesn't compress at all.
  4329.  
  4330.   Anyway, the intent of JBIG is to replace the current, less effective
  4331.   group 3 and 4 fax algorithms.
  4332.  
  4333.  
  4334. Another introduction to JBIG, written by Hank van Bekkem <jbek@oce.nl>:
  4335.  
  4336.   The following description of the JBIG algorithm is derived from
  4337.   experiences with a software implementation I wrote following the
  4338.   specifications in the revision 4.1 draft of September 16, 1991. The
  4339.   source will not be made available in the public domain, as parts of
  4340.   JBIG are patented.
  4341.  
  4342.   JBIG (Joint Bi-level Image Experts Group) is an experts group of ISO,
  4343.   IEC and CCITT (JTC1/SC2/WG9 and SGVIII). Its job is to define a
  4344.   compression standard for lossless image coding ([1]). The main
  4345.   characteristics of the proposed algorithm are:
  4346.   - Compatible progressive/sequential coding. This means that a
  4347.     progressively coded image can be decoded sequentially, and the
  4348.     other way around.
  4349.   - JBIG will be a lossless image compression standard: all bits in
  4350.     your images before and after compression and decompression will be
  4351.     exactly the same.
  4352.  
  4353.   In the rest of this text I will first describe the JBIG algorithm in
  4354.   a short abstract of the draft. I will conclude by saying something
  4355.   about the value of JBIG.
  4356.  
  4357.  
  4358.   JBIG algorithm.
  4359.   --------------
  4360.  
  4361.   JBIG parameter P specifies the number of bits per pixel in the image.
  4362.   Its allowable range is 1 through 255, but starting at P=8 or so,
  4363.   compression will be more efficient using other algorithms. On the
  4364.   other hand, medical images such as chest X-rays are often stored with
  4365.   12 bits per pixel, while no distorsion is allowed, so JBIG can
  4366.   certainly be of use in this area. To limit the number of bit changes
  4367.   between adjacent decimal values (e.g. 127 and 128), it is wise to use
  4368.   Gray coding before compressing multi-level images with JBIG. JBIG
  4369.   then compresses the image on a bitplane basis, so the rest of this
  4370.   text assumes bi-level pixels.
  4371.  
  4372.   Progressive coding is a way to send an image gradually to a receiver
  4373.   instead of all at once. During sending, more detail is sent, and the
  4374.   receiver can build the image from low to high detail. JBIG uses
  4375.   discrete steps of detail by successively doubling the resolution. The
  4376.   sender computes a number of resolution layers D, and transmits these
  4377.   starting at the lowest resolution Dl. Resolution reduction uses
  4378.   pixels in the high resolution layer and some already computed low
  4379.   resolution pixels as an index into a lookup table. The contents of
  4380.   this table can be specified by the user.
  4381.  
  4382.   Compatibility between progressive and sequential coding is achieved
  4383.   by dividing an image into stripes. Each stripe is a horizontal bar
  4384.   with a user definable height. Each stripe is separately coded and
  4385.   transmitted, and the user can define in which order stripes,
  4386.   resolutions and bitplanes (if P>1) are intermixed in the coded data.
  4387.   A progressive coded image can be decoded sequentially by decoding
  4388.   each stripe, beginning by the one at the top of the image, to its
  4389.   full resolution, and then proceeding to the next stripe. Progressive
  4390.   decoding can be done by decoding only a specific resolution layer
  4391.   from all stripes.
  4392.  
  4393.   After dividing an image into bitplanes, resolution layers and
  4394.   stripes, eventually a number of small bi-level bitmaps are left to
  4395.   compress. Compression is done using a Q-coder. Reference [2]
  4396.   contains a full description, I will only outline the basic principles
  4397.   here.
  4398.  
  4399.   The Q-coder codes bi-level pixels as symbols using the probability of
  4400.   occurrence of these symbols in a certain context. JBIG defines two
  4401.   kinds of context, one for the lowest resolution layer (the base
  4402.   layer), and one for all other layers (differential layers).
  4403.   Differential layer contexts contain pixels in the layer to be coded,
  4404.   and in the corresponding lower resolution layer.
  4405.  
  4406.   For each combination of pixel values in a context, the probability
  4407.   distribution of black and white pixels can be different. In an all
  4408.   white context, the probability of coding a white pixel will be much
  4409.   greater than that of coding a black pixel. The Q-coder assigns, just
  4410.   like a Huffman coder, more bits to less probable symbols, and so
  4411.   achieves compression. The Q-coder can, unlike a Huffmann coder,
  4412.   assign one output codebit to more than one input symbol, and thus is
  4413.   able to compress bi-level pixels without explicit clustering, as
  4414.   would be necessary using a Huffman coder.
  4415.  
  4416.   Maximum compression will be achieved when all probabilities (one set
  4417.   for each combination of pixel values in the context) follow the
  4418.   probabilities of the pixels. The Q-coder therefore continuously
  4419.   adapts these probabilities to the symbols it sees.
  4420.  
  4421.  
  4422.   JBIG value.
  4423.   ----------
  4424.  
  4425.   In my opinion, JBIG can be regarded as two combined devices:
  4426.   - Providing the user the service of sending or storing multiple
  4427.     representations of images at different resolutions without any
  4428.     extra cost in storage. Differential layer contexts contain pixels
  4429.     in two resolution layers, and so enable the Q-coder to effectively
  4430.     code the difference in information between the two layers, instead
  4431.     of the information contained in every layer. This means that,
  4432.     within a margin of approximately 5%, the number of resolution
  4433.     layers doesn't effect the compression ratio.
  4434.   - Providing the user a very efficient compression algorithm, mainly
  4435.     for use with bi-level images. Compared to CCITT Group 4, JBIG is
  4436.     approximately 10% to 50% better on text and line art, and even
  4437.     better on halftones. JBIG is however, just like Group 4, somewhat
  4438.     sensitive to noise in images. This means that the compression ratio
  4439.     decreases when the amount of noise in your images increases.
  4440.  
  4441.   An example of an application would be browsing through an image
  4442.   database, e.g. an EDMS (engineering document management system).
  4443.   Large A0 size drawings at 300 dpi or so would be stored using five
  4444.   resolution layers. The lowest resolution layer would fit on a
  4445.   computer screen. Base layer compressed data would be stored at the
  4446.   beginning of the compressed file, thus making browsing through large
  4447.   numbers of compressed drawings possible by reading and decompressing
  4448.   just the first small part of all files. When the user stops browsing,
  4449.   the system could automatically start decompressing all remaining
  4450.   detail for printing at high resolution.
  4451.  
  4452.   [1] "Progressive Bi-level Image Compression, Revision 4.1", ISO/IEC
  4453.       JTC1/SC2/WG9, CD 11544, September 16, 1991
  4454.   [2] "An overview of the basic principles of the Q-coder adaptive
  4455.       binary arithmetic coder", W.B. Pennebaker, J.L. Mitchell, G.G.
  4456.       Langdon, R.B. Arps, IBM Journal of research and development,
  4457.       Vol.32, No.6, November 1988, pp. 771-726 (See also the other
  4458.       articles about the Q-coder in this issue)
  4459.  
  4460. ------------------------------------------------------------------------------
  4461.  
  4462. Subject: [75] Introduction to JPEG
  4463.  
  4464. Here is a brief overview of the inner workings of JPEG, plus some references
  4465. for more detailed information, written by Tom Lane <tgl@sss.pgh.pa.us>.
  4466. Please read item 19 in part 1 first.
  4467.  
  4468. JPEG works on either full-color or gray-scale images; it does not handle
  4469. bilevel (black and white) images, at least not well.  It doesn't handle
  4470. colormapped images either; you have to pre-expand those into an unmapped
  4471. full-color representation.  JPEG works best on "continuous tone" images.
  4472. Images with many sudden jumps in color values will not compress well.
  4473.  
  4474. There are a lot of parameters to the JPEG compression process.  By adjusting
  4475. the parameters, you can trade off compressed image size against reconstructed
  4476. image quality over a *very* wide range.  You can get image quality ranging
  4477. from op-art (at 100x smaller than the original 24-bit image) to quite
  4478. indistinguishable from the source (at about 3x smaller).  Usually the
  4479. threshold of visible difference from the source image is somewhere around 10x
  4480. to 20x smaller than the original, ie, 1 to 2 bits per pixel for color images.
  4481. Grayscale images do not compress as much.  In fact, for comparable visual
  4482. quality, a grayscale image needs perhaps 25% less space than a color image;
  4483. certainly not the 66% less that you might naively expect.
  4484.  
  4485. JPEG defines a "baseline" lossy algorithm, plus optional extensions for
  4486. progressive and hierarchical coding.  There is also a separate lossless
  4487. compression mode; this typically gives about 2:1 compression, ie, about 12
  4488. bits per color pixel.  Most currently available JPEG hardware and software
  4489. handles only the baseline mode.
  4490.  
  4491.  
  4492. Here's the outline of the baseline compression algorithm:
  4493.  
  4494. 1. Transform the image into a suitable color space.  This is a no-op for
  4495. grayscale, but for color images you generally want to transform RGB into a
  4496. luminance/chrominance color space (YCbCr, YUV, etc).  The luminance component
  4497. is grayscale and the other two axes are color information.  The reason for
  4498. doing this is that you can afford to lose a lot more information in the
  4499. chrominance components than you can in the luminance component: the human eye
  4500. is not as sensitive to high-frequency chroma info as it is to high-frequency
  4501. luminance.  (See any TV system for precedents.)  You don't have to change the
  4502. color space if you don't want to, since the remainder of the algorithm works
  4503. on each color component independently, and doesn't care just what the data
  4504. is.  However, compression will be less since you will have to code all the
  4505. components at luminance quality.  Note that colorspace transformation is
  4506. slightly lossy due to roundoff error, but the amount of error is much smaller
  4507. than what we typically introduce later on.
  4508.  
  4509. 2. (Optional) Downsample each component by averaging together groups of
  4510. pixels.  The luminance component is left at full resolution, while the chroma
  4511. components are often reduced 2:1 horizontally and either 2:1 or 1:1 (no
  4512. change) vertically.  In JPEG-speak these alternatives are usually called 2h2v
  4513. and 2h1v sampling, but you may also see the terms "411" and "422" sampling.
  4514. This step immediately reduces the data volume by one-half or one-third.
  4515. In numerical terms it is highly lossy, but for most images it has almost no
  4516. impact on perceived quality, because of the eye's poorer resolution for chroma
  4517. info.  Note that downsampling is not applicable to grayscale data; this is one
  4518. reason color images are more compressible than grayscale.
  4519.  
  4520. 3. Group the pixel values for each component into 8x8 blocks.  Transform each
  4521. 8x8 block through a discrete cosine transform (DCT).  The DCT is a relative of
  4522. the Fourier transform and likewise gives a frequency map, with 8x8 components.
  4523. Thus you now have numbers representing the average value in each block and
  4524. successively higher-frequency changes within the block.  The motivation for
  4525. doing this is that you can now throw away high-frequency information without
  4526. affecting low-frequency information.  (The DCT transform itself is reversible
  4527. except for roundoff error.)  See question 25 for fast DCT algorithms.
  4528.  
  4529. 4. In each block, divide each of the 64 frequency components by a separate
  4530. "quantization coefficient", and round the results to integers.  This is the
  4531. fundamental information-losing step.  The larger the quantization
  4532. coefficients, the more data is discarded.  Note that even the minimum possible
  4533. quantization coefficient, 1, loses some info, because the exact DCT outputs
  4534. are typically not integers.  Higher frequencies are always quantized less
  4535. accurately (given larger coefficients) than lower, since they are less visible
  4536. to the eye.  Also, the luminance data is typically quantized more accurately
  4537. than the chroma data, by using separate 64-element quantization tables.
  4538. Tuning the quantization tables for best results is something of a black art,
  4539. and is an active research area.  Most existing encoders use simple linear
  4540. scaling of the example tables given in the JPEG standard, using a single
  4541. user-specified "quality" setting to determine the scaling multiplier.  This
  4542. works fairly well for midrange qualities (not too far from the sample tables
  4543. themselves) but is quite nonoptimal at very high or low quality settings.
  4544.  
  4545. 5. Encode the reduced coefficients using either Huffman or arithmetic coding.
  4546. (Strictly speaking, baseline JPEG only allows Huffman coding; arithmetic
  4547. coding is an optional extension.)   Notice that this step is lossless, so it
  4548. doesn't affect image quality.  The arithmetic coding option uses Q-coding;
  4549. it is identical to the coder used in JBIG (see question 74).  Be aware that
  4550. Q-coding is patented.  Most existing implementations support only the Huffman
  4551. mode, so as to avoid license fees.  The arithmetic mode offers maybe 5 or 10%
  4552. better compression, which isn't enough to justify paying fees.
  4553.  
  4554. 6. Tack on appropriate headers, etc, and output the result.  In a normal
  4555. "interchange" JPEG file, all of the compression parameters are included
  4556. in the headers so that the decompressor can reverse the process.  These
  4557. parameters include the quantization tables and the Huffman coding tables.
  4558. For specialized applications, the spec permits those tables to be omitted
  4559. from the file; this saves several hundred bytes of overhead, but it means
  4560. that the decompressor must know a-priori what tables the compressor used.
  4561. Omitting the tables is safe only in closed systems.
  4562.  
  4563.  
  4564. The decompression algorithm reverses this process.  The decompressor
  4565. multiplies the reduced coefficients by the quantization table entries to
  4566. produce approximate DCT coefficients.  Since these are only approximate,
  4567. the reconstructed pixel values are also approximate, but if the design
  4568. has done what it's supposed to do, the errors won't be highly visible.
  4569. A high-quality decompressor will typically add some smoothing steps to
  4570. reduce pixel-to-pixel discontinuities.
  4571.  
  4572. The JPEG standard does not specify the exact behavior of compressors and
  4573. decompressors, so there's some room for creative implementation.  In
  4574. particular, implementations can trade off speed against image quality by
  4575. choosing more accurate or faster-but-less-accurate approximations to the
  4576. DCT.  Similar tradeoffs exist for the downsampling/upsampling and colorspace
  4577. conversion steps.  (The spec does include some minimum accuracy requirements
  4578. for the DCT step, but these are widely ignored, and are not too meaningful
  4579. anyway in the absence of accuracy requirements for the other lossy steps.)
  4580.  
  4581.  
  4582. Extensions:
  4583.  
  4584. The progressive mode is intended to support real-time transmission of images.
  4585. It allows the DCT coefficients to be sent piecemeal in multiple "scans" of
  4586. the image.  With each scan, the decoder can produce a higher-quality
  4587. rendition of the image.  Thus a low-quality preview can be sent very quickly,
  4588. then refined as time allows.  The total space needed is roughly the same as
  4589. for a baseline JPEG image of the same final quality.  (In fact, it can be
  4590. somewhat *less* if a custom Huffman table is used for each scan, because the
  4591. Huffman codes can be optimized over a smaller, more uniform population of
  4592. data than appears in a baseline image's single scan.)  The decoder must do
  4593. essentially a full JPEG decode cycle for each scan: inverse DCT, upsample,
  4594. and color conversion must all be done again, not to mention any color
  4595. quantization for 8-bit displays.  So this scheme is useful only with fast
  4596. decoders or slow transmission lines.  Up until 1995, progressive JPEG was a
  4597. rare bird, but its use is now spreading as software decoders have become fast
  4598. enough to make it useful with modem-speed data transmission.
  4599.  
  4600. The hierarchical mode represents an image at multiple resolutions.  For
  4601. example, one could provide 512x512, 1024x1024, and 2048x2048 versions of the
  4602. image.  The higher-resolution images are coded as differences from the next
  4603. smaller image, and thus require many fewer bits than they would if stored
  4604. independently.  (However, the total number of bits will be greater than that
  4605. needed to store just the highest-resolution frame in baseline form.)
  4606. The individual frames in a hierarchical sequence can be coded progressively
  4607. if desired.  Hierarchical mode is not widely supported at present.
  4608.  
  4609. Part 3 of the JPEG standard, approved at the end of 1995, introduces several
  4610. new extensions.  The one most likely to become popular is variable
  4611. quantization, which allows the quantization table to be scaled to different
  4612. levels in different parts of the image.  In this way the "more critical"
  4613. parts of the image can be coded at higher quality than the "less critical"
  4614. parts.  A signaling code can be inserted at any DCT block boundary to set a
  4615. new scaling factor.
  4616.  
  4617. Another Part 3 extension is selective refinement.  This feature permits a
  4618. scan in a progressive sequence, or a refinement frame of a hierarchical
  4619. sequence, to cover only part of the total image area.  This is an
  4620. alternative way of solving the variable-quality problem.  My (tgl's) guess
  4621. is that this will not get widely implemented, with variable quantization
  4622. proving a more popular approach, but I've been wrong before.
  4623.  
  4624. The third major extension added by Part 3 is a "tiling" concept that allows
  4625. an image to be built up as a composite of JPEG frames, which may have
  4626. different sizes, resolutions, quality settings, even colorspaces.  (For
  4627. example, a color image that occupies a small part of a mostly-grayscale page
  4628. could be represented as a separate frame, without having to store the whole
  4629. page in color.)  Again, there's some overlap in functionality with variable
  4630. quantization and selective refinement.  The general case of arbitrary tiles
  4631. is rather complex and is unlikely to be widely implemented.  In the simplest
  4632. case all the tiles are the same size and use similar quality settings.
  4633. This case may become popular even if the general tiling mechanism doesn't,
  4634. because it surmounts the 64K-pixel-on-a-side image size limitation that was
  4635. (not very foresightedly) built into the basic JPEG standard.  The individual
  4636. frames are still restricted to 64K for compatibility reasons, but the total
  4637. size of a tiled JPEG image can be up to 2^32 pixels on a side.
  4638.  
  4639. Lossless JPEG:
  4640.  
  4641. The separate lossless mode does not use DCT, since roundoff errors prevent a
  4642. DCT calculation from being lossless.  For the same reason, one would not
  4643. normally use colorspace conversion or downsampling, although these are
  4644. permitted by the standard.  The lossless mode simply codes the difference
  4645. between each pixel and the "predicted" value for the pixel.  The predicted
  4646. value is a simple function of the already-transmitted pixels just above and
  4647. to the left of the current one (for example, their average; 8 different
  4648. predictor functions are permitted).  The sequence of differences is encoded
  4649. using the same back end (Huffman or arithmetic) used in the lossy mode.
  4650.  
  4651. Lossless JPEG with the Huffman back end is certainly not a state-of-the-art
  4652. lossless compression method, and wasn't even when it was introduced.  The
  4653. arithmetic-coding back end may make it competitive, but you're probably best
  4654. off looking at other methods if you need only lossless compression.
  4655.  
  4656. The main reason for providing a lossless option is that it makes a good
  4657. adjunct to the hierarchical mode: the final scan in a hierarchical sequence
  4658. can be a lossless coding of the remaining differences, to achieve overall
  4659. losslessness.  This isn't quite as useful as it may at first appear, because
  4660. exact losslessness is not guaranteed unless the encoder and decoder have
  4661. identical IDCT implementations (ie, identical roundoff errors).  And you
  4662. can't use downsampling or colorspace conversion either if you want true
  4663. losslessness.  But in some applications the combination is useful.
  4664.  
  4665.  
  4666. References:
  4667.  
  4668. For a good technical introduction to JPEG, see:
  4669.     Wallace, Gregory K.  "The JPEG Still Picture Compression Standard",
  4670.     Communications of the ACM, April 1991 (vol. 34 no. 4), pp. 30-44.
  4671. (Adjacent articles in that issue discuss MPEG motion picture compression,
  4672. applications of JPEG, and related topics.)  If you don't have the CACM issue
  4673. handy, a PostScript file containing a revised version of this article is
  4674. available at ftp://ftp.uu.net/graphics/jpeg/wallace.ps.gz.  This file
  4675. (actually a preprint for a later article in IEEE Trans. Consum. Elect.)
  4676. omits the sample images that appeared in CACM, but it includes corrections
  4677. and some added material.  Note: the Wallace article is copyright ACM and
  4678. IEEE, and it may not be used for commercial purposes.
  4679.  
  4680. An alternative, more leisurely explanation of JPEG can be found in "The Data
  4681. Compression Book" by Mark Nelson ([Nel 1991], see question 7).  This book
  4682. provides excellent introductions to many data compression methods including
  4683. JPEG, plus sample source code in C.  The JPEG-related source code is far from
  4684. industrial-strength, but it's a pretty good learning tool.
  4685.  
  4686. An excellent textbook about JPEG is "JPEG Still Image Data Compression
  4687. Standard" by William B. Pennebaker and Joan L. Mitchell.  Published by Van
  4688. Nostrand Reinhold, 1993, ISBN 0-442-01272-1.  650 pages, price US$59.95.
  4689. (VNR will accept credit card orders at 800/842-3636, or get your local
  4690. bookstore to order it.)  This book includes the complete text of the ISO
  4691. JPEG standards, DIS 10918-1 and draft DIS 10918-2.  Review by Tom Lane:
  4692. "This is by far the most complete exposition of JPEG in existence.  It's
  4693. written by two people who know what they are talking about: both served on
  4694. the ISO JPEG standards committee.  If you want to know how JPEG works or
  4695. why it works that way, this is the book to have."
  4696.  
  4697. There are a number of errors in the first printing of the Pennebaker and
  4698. Mitchell book.  An errata list is available at
  4699. ftp://ftp.uu.net/graphics/jpeg/pm.errata.gz.  At last report, all known
  4700. errors were fixed in the second printing.
  4701.  
  4702. The official specification of JPEG is not currently available on-line, and
  4703. is not likely ever to be available for free because of ISO and ITU copyright
  4704. restrictions.  You can order it from your national standards agency as ISO
  4705. standards IS 10918-1, 10918-2, 10918-3, or as ITU-T standards T.81, T.83,
  4706. T.84.  See ftp://ftp.uu.net/graphics/jpeg/jpeg.documents.gz for more info.
  4707. NOTE: buying the Pennebaker and Mitchell textbook is a much better deal
  4708. than purchasing the standard directly: it's cheaper and includes a lot of
  4709. useful explanatory material along with the full draft text of the spec.
  4710. The book unfortunately doesn't include Part 3 of the spec, but if you need
  4711. Part 3, buy the book and just that part and you'll still be ahead.
  4712.  
  4713.  
  4714. ------------------------------------------------------------------------------
  4715.  
  4716. Subject: [76] What is Vector Quantization?
  4717.  
  4718. Some vector quantization software for data analysis that is available
  4719. in the ftp://cochlea.hut.fi/pub/ directory.  One package is lvq_pak and
  4720. one is som_pak (som_pak generates Kohonen maps of data using lvq to
  4721. cluster it).
  4722.  
  4723. A VQ-based codec that is based on the Predictive Residual Vector
  4724. Quantization is in ftp://mozart.eng.buffalo.edu/pub/prvq_codec/PRVQ.tar.gz
  4725.  
  4726. VQ software is also available in ftp://isdl.ee.washington.edu/pub/VQ/
  4727.  
  4728.  
  4729. For a book on Vector Quantization, see the reference (Gersho and Gray)
  4730. given in item 7 of this FAQ. For a review article: N. M. Nasrabadi and
  4731. R. A. King, "Image Coding Using Vector Quantization: A review",
  4732. IEEE Trans. on Communications, vol. COM-36, pp. 957-971, Aug. 1988.
  4733.  
  4734.  
  4735. A short introduction to Vector Quantization, written by Alex Zatsman
  4736. <alex.zatsman@analog.com>:
  4737.  
  4738. In Scalar  Quantization one represents  the values by  fixed subset of
  4739. representative values. For  examples, if you  have  16 bit  values and
  4740. send  only 8 most  signifcant bits, you  get an  approximation  of the
  4741. original data  at  the expense of  precision.  In this case  the fixed
  4742. subset is all the 16-bit numbers divisable by 256, i.e 0, 256, 512,...
  4743.  
  4744. In  Vector Quantization  you   represent   not individual values   but
  4745. (usually small) arrays of them. A typical  example  is a color  map: a
  4746. color picture can  be  represented by  a  2D array  of  triplets  (RGB
  4747. values). In most pictures  those triplets do  not cover the  whole RGB
  4748. space but  tend to   concetrate  in certain   areas. For  example, the
  4749. picture of a forest will typically have a lot of green. One can select
  4750. a relatively  small  subset (typically 256 elements) of representative
  4751. colors, i.e RGB  triplets,  and then approximate  each  triplet by the
  4752. representative of  that small set. In case  of 256 one  can use 1 byte
  4753. instead of 3 for each pixel.
  4754.  
  4755. One  can do   the  same   for  any large  data  sets,  especialy  when
  4756. consecutive points are correlated in some way. CELP speech compression
  4757. algorithms  use  those subsets  "codebooks" and   use them to quantize
  4758. exciation vectors  for linear prediction  -- hence the name CELP which
  4759. stands for Codebook Excited Linear Prediction.  (See item 26 in part 1
  4760. of this FAQ for more information about CELP.)
  4761.  
  4762. Note that Vector Quantization, just like Scalar Quantization, is a lossy
  4763. compression.
  4764.  
  4765. ------------------------------------------------------------------------------
  4766.  
  4767. Subject: [77] Introduction to Fractal compression (long)
  4768.  
  4769.  
  4770. Written by John Kominek <kominek@links.uwaterloo.ca>
  4771.  
  4772. Seven things you should know about Fractal Image Compression (assuming that 
  4773. you want to know about it).
  4774.  
  4775.    1. It is a promising new technology, arguably superior to JPEG -- 
  4776.       but only with an argument.
  4777.    2. It is a lossy compression method.
  4778.    3. The fractals in Fractal Image Compression are Iterated Function
  4779.       Systems.
  4780.    4. It is a form of Vector Quantization, one that employs a virtual
  4781.       codebook.
  4782.    5. Resolution enhancement is a powerful feature but is not some
  4783.       magical way of achieving 1000:1 compression.
  4784.    6. Compression is slow, decompression is fast.
  4785.    7. The technology is patented.
  4786.  
  4787. That's the scoop in condensed form. Now to elaborate, beginning with a little 
  4788. background.
  4789.  
  4790.  
  4791.  A Brief History of Fractal Image Compression
  4792.  --------------------------------------------
  4793.  
  4794. The birth of fractal geometry (or rebirth, rather) is usually traced to IBM 
  4795. mathematician Benoit B. Mandelbrot and the 1977 publication of his seminal 
  4796. book The Fractal Geometry of Nature. The book put forth a powerful thesis: 
  4797. traditional geometry with its straight lines and smooth surfaces does not 
  4798. resemble the geometry of trees and clouds and mountains. Fractal geometry, 
  4799. with its convoluted coastlines and detail ad infinitum, does.
  4800.  
  4801. This insight opened vast possibilities. Computer scientists, for one, found a 
  4802. mathematics capable of generating artificial and yet realistic looking land-
  4803. scapes, and the trees that sprout from the soil. And mathematicians had at 
  4804. their disposal a new world of geometric entities.
  4805.  
  4806. It was not long before mathematicians asked if there was a unity among this 
  4807. diversity. There is, as John Hutchinson demonstrated in 1981, it is the branch 
  4808. of mathematics now known as Iterated Function Theory. Later in the decade 
  4809. Michael Barnsley, a leading researcher from Georgia Tech, wrote the popular 
  4810. book Fractals Everywhere. The book presents the mathematics of Iterated Func-
  4811. tions Systems (IFS), and proves a result known as the Collage Theorem. The 
  4812. Collage Theorem states what an Iterated Function System must be like in order 
  4813. to represent an image.
  4814.  
  4815. This presented an intriguing possibility. If, in the forward direction, frac-
  4816. tal mathematics is good for generating natural looking images, then, in the 
  4817. reverse direction, could it not serve to compress images? Going from a given 
  4818. image to an Iterated Function System that can generate the original (or at 
  4819. least closely resemble it), is known as the inverse problem. This problem 
  4820. remains unsolved.
  4821.  
  4822. Barnsley, however, armed with his Collage Theorem, thought he had it solved. 
  4823. He applied for and was granted a software patent and left academia to found 
  4824. Iterated Systems Incorporated (US patent 4,941,193. Alan Sloan is the co-
  4825. grantee of the patent and co-founder of Iterated Systems.)  Barnsley announced 
  4826. his success to the world in the January 1988 issue of BYTE magazine. This 
  4827. article did not address the inverse problem but it did exhibit several images 
  4828. purportedly compressed in excess of 10,000:1. Alas, it was not a breakthrough. 
  4829. The images were given suggestive names such as "Black Forest" and "Monterey 
  4830. Coast" and "Bolivian Girl" but they were all manually constructed. Barnsley's 
  4831. patent has come to be derisively referred to as the "graduate student algo-
  4832. rithm."
  4833.  
  4834. Graduate Student Algorithm
  4835.    o Acquire a graduate student.
  4836.    o Give the student a picture.
  4837.    o And a room with a graphics workstation.
  4838.    o Lock the door.
  4839.    o Wait until the student has reverse engineered the picture.
  4840.    o Open the door.
  4841.  
  4842. Attempts to automate this process have met little success. As Barnsley admit-
  4843. ted in 1988: "Complex color images require about 100 hours each to encode and 
  4844. 30 minutes to decode on the Masscomp [dual processor workstation]." That's 100 
  4845. hours with a _person_ guiding the process.
  4846.  
  4847. Ironically, it was one of Barnsley's PhD students that made the graduate 
  4848. student algorithm obsolete. In March 1988, according to Barnsley, he arrived 
  4849. at a modified scheme for representing images called Partitioned Iterated 
  4850. Function Systems (PIFS). Barnsley applied for and was granted a second patent 
  4851. on an algorithm that can automatically convert an image into a Partitioned 
  4852. Iterated Function System, compressing the image in the process. (US patent 
  4853. 5,065,447. Granted on Nov. 12 1991.) For his PhD thesis, Arnaud Jacquin imple-
  4854. mented the algorithm in software, a description of which appears in his land-
  4855. mark paper "Image Coding Based on a Fractal Theory of Iterated Contractive 
  4856. Image Transformations." The algorithm was not sophisticated, and not speedy, 
  4857. but it was fully automatic. This came at price: gone was the promise of 
  4858. 10,000:1 compression. A 24-bit color image could typically be compressed from 
  4859. 8:1 to 50:1 while still looking "pretty good." Nonetheless, all contemporary 
  4860. fractal image compression programs are based upon Jacquin's paper.
  4861.  
  4862. That is not to say there are many fractal compression programs available. 
  4863. There are not. Iterated Systems sell the only commercial compressor/decompres-
  4864. sor, an MS-Windows program called "Images Incorporated." There are also an 
  4865. increasing number of academic programs being made freely available. Unfor-
  4866. tunately, these programs are -- how should I put it? -- of merely academic 
  4867. quality. 
  4868.  
  4869. This scarcity has much to do with Iterated Systems' tight lipped policy about 
  4870. their compression technology. They do, however, sell a Windows DLL for pro-
  4871. grammers. In conjunction with independent development by researchers else-
  4872. where, therefore, fractal compression will gradually become more pervasive. 
  4873. Whether it becomes all-pervasive remains to be seen.
  4874.  
  4875. Historical Highlights:
  4876.    1977 -- Benoit Mandelbrot finishes the first edition of The Fractal 
  4877.            Geometry of Nature.
  4878.    1981 -- John Hutchinson publishes "Fractals and Self-Similarity."
  4879.    1983 -- Revised edition of The Fractal Geometry of Nature is 
  4880.            published.
  4881.    1985 -- Michael Barnsley and Stephen Demko introduce Iterated
  4882.            Function Theory in "Iterated Function Systems and the Global
  4883.            Construction of Fractals."
  4884.    1987 -- Iterated Systems Incorporated is founded.
  4885.    1988 -- Barnsley publishes the book Fractals Everywhere.
  4886.    1990 -- Barnsley's first patent is granted.
  4887.    1991 -- Barnsley's second patent is granted.
  4888.    1992 -- Arnaud Jacquin publishes an article that describes the first
  4889.            practical fractal image compression method.
  4890.    1993 -- The book Fractal Image Compression by Michael Barnsley and Lyman 
  4891.            Hurd is published.
  4892.         -- The Iterated Systems' product line matures. 
  4893.    1994 -- Put your name here.
  4894.  
  4895.  
  4896.  On the Inside
  4897.  -------------
  4898.  
  4899. The fractals that lurk within fractal image compression are not those of the 
  4900. complex plane (Mandelbrot Set, Julia sets), but of Iterated Function Theory. 
  4901. When lecturing to lay audiences, the mathematician Heinz-Otto Peitgen intro-
  4902. duces the notion of Iterated Function Systems with the alluring metaphor of a 
  4903. Multiple Reduction Copying Machine. A MRCM is imagined to be a regular copying 
  4904. machine except that:
  4905.  
  4906.   1. There are multiple lens arrangements to create multiple overlapping
  4907.      copies of the original.
  4908.   2. Each lens arrangement reduces the size of the original.
  4909.   3. The copier operates in a feedback loop, with the output of one
  4910.      stage the input to the next. The initial input may be anything.
  4911.  
  4912. The first point is what makes an IFS a system. The third is what makes it 
  4913. iterative. As for the second, it is implicitly understood that the functions 
  4914. of an Iterated Function Systems are contractive. 
  4915.  
  4916. An IFS, then, is a set of contractive transformations that map from a defined 
  4917. rectangle of the real plane to smaller portions of that rectangle. Almost 
  4918. invariably, affine transformations are used. Affine transformations act to 
  4919. translate, scale, shear, and rotate points in the plane. Here is a simple 
  4920. example:
  4921.  
  4922.  
  4923.      |---------------|              |-----|
  4924.      |x              |              |1    |
  4925.      |               |              |     |
  4926.      |               |         |---------------|
  4927.      |               |         |2      |3      |
  4928.      |               |         |       |       |
  4929.      |---------------|         |---------------|  
  4930.  
  4931.          Before                      After
  4932.  
  4933.      Figure 1. IFS for generating Sierpinski's Triangle.
  4934.  
  4935. This IFS contains three component transformations (three separate lens ar-
  4936. rangements in the MRCM metaphor). Each one shrinks the original by a factor of 
  4937. 2, and then translates the result to a new location. It may optionally scale 
  4938. and shift the luminance values of the rectangle, in a manner similar to the 
  4939. contrast and brightness knobs on a TV.
  4940.  
  4941. The amazing property of an IFS is that when the set is evaluated by iteration, 
  4942. (i.e. when the copy machine is run), a unique image emerges. This latent image 
  4943. is called the fixed point or attractor of the IFS. As guaranteed by a result 
  4944. known as the Contraction Theorem, it is completely independent of the initial 
  4945. image. Two famous examples are Sierpinski's Triangle and Barnsley's Fern. 
  4946. Because these IFSs are contractive, self-similar detail is created at every 
  4947. resolution down to the infinitesimal. That is why the images are fractal.
  4948.  
  4949. The promise of using fractals for image encoding rests on two suppositions: 1. 
  4950. many natural scenes possess this detail within detail structure (e.g. clouds), 
  4951. and 2. an IFS can be found that generates a close approximation of a scene 
  4952. using only a few transformations. Barnsley's fern, for example, needs but 
  4953. four. Because only a few numbers are required to describe each transformation, 
  4954. an image can be represented very compactly. Given an image to encode, finding 
  4955. the optimal IFS from all those possible is known as the inverse problem.
  4956.  
  4957. The inverse problem -- as mentioned above -- remains unsolved. Even if it 
  4958. were, it may be to no avail. Everyday scenes are very diverse in subject 
  4959. matter; on whole, they do not obey fractal geometry. Real ferns do not branch 
  4960. down to infinity. They are distorted, discolored, perforated and torn. And the 
  4961. ground on which they grow looks very much different.
  4962.  
  4963. To capture the diversity of real images, then, Partitioned IFSs are employed. 
  4964. In a PIFS, the transformations do not map from the whole image to the parts, 
  4965. but from larger parts to smaller parts. An image may vary qualitatively from 
  4966. one area to the next (e.g. clouds then sky then clouds again). A PIFS relates 
  4967. those areas of the original image that are similar in appearance. Using Jac-
  4968. quin's notation, the big areas are called domain blocks and the small areas 
  4969. are called range blocks. It is necessary that every pixel of the original 
  4970. image belong to (at least) one range block. The pattern of range blocks is 
  4971. called the partitioning of an image.
  4972.  
  4973. Because this system of mappings is still contractive, when iterated it will 
  4974. quickly converge to its latent fixed point image. Constructing a PIFS amounts 
  4975. to pairing each range block to the domain block that it most closely resembles 
  4976. under some to-be-determined affine transformation. Done properly, the PIFS 
  4977. encoding of an image will be much smaller than the original, while still 
  4978. resembling it closely.
  4979.  
  4980. Therefore, a fractal compressed image is an encoding that describes:
  4981.    1. The grid partitioning (the range blocks).
  4982.    2. The affine transforms (one per range block).
  4983.  
  4984. The decompression process begins with a flat gray background. Then the set of 
  4985. transformations is repeatedly applied. After about four iterations the attrac-
  4986. tor stabilizes. The result will not (usually) be an exact replica of the 
  4987. original, but reasonably close.
  4988.  
  4989.  
  4990.  Scalelessnes and Resolution Enhancement
  4991.  ---------------------------------------
  4992.  
  4993. When an image is captured by an acquisition device, such as a camera or scan-
  4994. ner, it acquires a scale determined by the sampling resolution of that device. 
  4995. If software is used to zoom in on the image, beyond a certain point you don't 
  4996. see additional detail, just bigger pixels. 
  4997.  
  4998. A fractal image is different. Because the affine transformations are spatially 
  4999. contractive, detail is created at finer and finer resolutions with each itera-
  5000. tion. In the limit, self-similar detail is created at all levels of resolu-
  5001. tion, down the infinitesimal. Because there is no level that 'bottoms out' 
  5002. fractal images are considered to be scaleless.
  5003.  
  5004. What this means in practice is that as you zoom in on a fractal image, it will 
  5005. still look 'as it should' without the staircase effect of pixel replication. 
  5006. The significance of this is cause of some misconception, so here is the right 
  5007. spot for a public service announcement.
  5008.  
  5009.                         /--- READER BEWARE ---\
  5010.  
  5011. Iterated Systems is fond of the following argument. Take a portrait that is, 
  5012. let us say, a grayscale image 250x250 pixels in size, 1 byte per pixel. You 
  5013. run it through their software and get a 2500 byte file (compression ratio = 
  5014. 25:1). Now zoom in on the person's hair at 4x magnification. What do you see? 
  5015. A texture that still looks like hair. Well then, it's as if you had an image 
  5016. 1000x1000 pixels in size. So your _effective_ compression ratio is 25x16=400.
  5017.  
  5018. But there is a catch. Detail has not been retained, but generated. With a 
  5019. little luck it will look as it should, but don't count on it. Zooming in on a 
  5020. person's face will not reveal the pores. 
  5021.  
  5022. Objectively, what fractal image compression offers is an advanced form of 
  5023. interpolation. This is a useful and attractive property. Useful to graphic 
  5024. artists, for example, or for printing on a high resolution device. But it does 
  5025. not bestow fantastically high compression ratios.
  5026.  
  5027.                         \--- READER BEWARE ---/
  5028.  
  5029. That said, what is resolution enhancement? It is the process of compressing an 
  5030. image, expanding it to a higher resolution, saving it, then discarding the 
  5031. iterated function system. In other words, the compressed fractal image is the 
  5032. means to an end, not the end itself.
  5033.  
  5034.  
  5035.  The Speed Problem
  5036.  -----------------
  5037.  
  5038. The essence of the compression process is the pairing of each range block to a 
  5039. domain block such that the difference between the two, under an affine trans-
  5040. formation, is minimal. This involves a lot of searching. 
  5041.  
  5042. In fact, there is nothing that says the blocks have to be squares or even 
  5043. rectangles. That is just an imposition made to keep the problem tractable. 
  5044.  
  5045. More generally, the method of finding a good PIFS for any given image involves 
  5046. five main issues: 
  5047.    1. Partitioning the image into range blocks. 
  5048.    2. Forming the set of domain blocks. 
  5049.    3. Choosing type of transformations that will be considered. 
  5050.    4. Selecting a distance metric between blocks. 
  5051.    5. Specifying a method for pairing range blocks to domain blocks. 
  5052.  
  5053. Many possibilities exist for each of these. The choices that Jacquin offered 
  5054. in his paper are: 
  5055.    1. A two-level regular square grid with 8x8 pixels for the large
  5056.       range blocks and 4x4 for the small ones. 
  5057.    2. Domain blocks are 16x16 and 8x8 pixels in size with a subsampling 
  5058.       step size of four. The 8 isometric symmetries (four rotations, 
  5059.       four mirror flips) expand the domain pool to a virtual domain 
  5060.       pool eight times larger. 
  5061.    3. The choices in the last point imply a shrinkage by two in each 
  5062.       direction, with a possible rotation or flip, and then a trans-
  5063.       lation in the image plane. 
  5064.    4. Mean squared error is used. 
  5065.    5. The blocks are categorized as of type smooth, midrange, simple
  5066.       edge, and complex edge. For a given range block the respective
  5067.       category is searched for the best match.
  5068.  
  5069. The importance of categorization can be seen by calculating the size of the 
  5070. total domain pool. Suppose the image is partitioned into 4x4 range blocks. A 
  5071. 256x256 image contains a total of (256-8+1)^2  = 62,001 different 8x8 domain 
  5072. blocks. Including the 8 isometric symmetries increases this total to 496,008. 
  5073. There are (256-4+1)^2 = 64,009 4x4 range blocks, which makes for a maximum of 
  5074. 31,748,976,072 possible pairings to test. Even on a fast workstation an ex-
  5075. haustive search is prohibitively slow. You can start the program before de-
  5076. parting work Friday afternoon; Monday morning, it will still be churning away. 
  5077.  
  5078. Increasing the search speed is the main challenge facing fractal image com-
  5079. pression.
  5080.  
  5081.  
  5082.  Similarity to Vector Quantization
  5083.  ---------------------------------
  5084.  
  5085. To the VQ community, a "vector" is a small rectangular block of pixels. The 
  5086. premise of vector quantization is that some patterns occur much more frequent-
  5087. ly than others. So the clever idea is to store only a few of these common 
  5088. patterns in a separate file called the codebook. Some codebook vectors are 
  5089. flat, some are sloping, some contain tight texture, some sharp edges, and so 
  5090. on -- there is a whole corpus on how to construct a codebook. Each codebook 
  5091. entry (each domain block) is assigned an index number. A given image, then, is 
  5092. partitioned into a regular grid array. Each grid element (each range block) is 
  5093. represented by an index into the codebook. Decompressing a VQ file involves 
  5094. assembling an image out of the codebook entries. Brick by brick, so to speak.
  5095.  
  5096. The similarity to fractal image compression is apparent, with some notable 
  5097. differences. 
  5098.    1. In VQ the range blocks and domain blocks are the same size; in an
  5099.       IFS the domain blocks are always larger. 
  5100.    2. In VQ the domain blocks are copied straight; in an IFS each domain 
  5101.       block undergoes a luminance scaling and offset.
  5102.    3. In VQ the codebook is stored apart from the image being coded; in 
  5103.       an IFS the codebook is not explicitly stored. It is comprised of
  5104.       portions of the attractor as it emerges during iteration. For that
  5105.       reason it is called a "virtual codebook." It has no existence
  5106.       independent of the affine transformations that define an IFS.
  5107.    4. In VQ the codebook is shared among many images; in an IFS the 
  5108.       virtual codebook is specific to each image.
  5109.  
  5110. There is a more refined version of VQ called gain-shape vector quantization in 
  5111. which a luminance scaling and offset is also allowed. This makes the similari-
  5112. ty to fractal image compression as close as can be.
  5113.  
  5114.  
  5115.  Compression Ratios
  5116.  ------------------
  5117.  
  5118. Exaggerated claims not withstanding, compression ratios typically range from 
  5119. 4:1 to 100:1. All other things equal, color images can be compressed to a 
  5120. greater extent than grayscale images.
  5121.  
  5122. The size of a fractal image file is largely determined by the number of trans-
  5123. formations of the PIFS. For the sake of simplicity, and for the sake of com-
  5124. parison to JPEG, assume that a 256x256x8 image is partitioned into a regular 
  5125. partitioning of 8x8 blocks. There are 1024 range blocks and thus 1024 trans-
  5126. formations to store. How many bits are required for each?
  5127.  
  5128. In most implementations the domain blocks are twice the size of the range 
  5129. blocks. So the spatial contraction is constant and can be hard coded into the 
  5130. decompression program. What needs to be stored are:
  5131.  
  5132.    x position of domain block        8     6
  5133.    y position of domain block        8     6
  5134.    luminance scaling                 8     5
  5135.    luminance offset                  8     6
  5136.    symmetry indicator                3     3
  5137.                                     --    --
  5138.                                     35    26 bits
  5139.  
  5140. In the first scheme, a byte is allocated to each number except for the symme-
  5141. try indicator. The upper bound on the compression ratio is thus (8x8x8)/35 = 
  5142. 14.63. In the second scheme, domain blocks are restricted to coordinates 
  5143. modulo 4. Plus, experiments have revealed that 5 bits per scale factor and 6 
  5144. bits per offset still give good visual results. So the compression ratio limit 
  5145. is now 19.69. Respectable but not outstanding.
  5146.  
  5147. There are other, more complicated, schemes to reduce the bit rate further. The 
  5148. most common is to use a three or four level quadtree structure for the range 
  5149. partitioning. That way, smooth areas can be represented with large range 
  5150. blocks (high compression), while smaller blocks are used as necessary to 
  5151. capture the details. In addition, entropy coding can be applied as a back-end 
  5152. step to gain an extra 20% or so.
  5153.  
  5154.  
  5155.  Quality: Fractal vs. JPEG
  5156.  -------------------------
  5157.  
  5158. The greatest irony of the coding community is that great pains are taken to 
  5159. precisely measure and quantify the error present in a compressed image, and 
  5160. great effort is expended toward minimizing an error measure that most often is 
  5161. -- let us be gentle -- of dubious value. These measure include signal-to-noise 
  5162. ratio, root mean square error, and mean absolute error. A simple example is 
  5163. systematic shift: add a value of 10 to every pixel. Standard error measures 
  5164. indicate a large distortion, but the image has merely been brightened.
  5165.  
  5166. With respect to those dubious error measures, and at the risk of over-sim-
  5167. plification, the results of tests reveal the following: for low compression 
  5168. ratios JPEG is better, for high compression ratios fractal encoding is better. 
  5169. The crossover point varies but is often around 40:1. This figure bodes well 
  5170. for JPEG since beyond the crossover point images are so severely distorted 
  5171. that they are seldom worth using. 
  5172.  
  5173. Proponents of fractal compression counter that signal-to-noise is not a good 
  5174. error measure and that the distortions present are much more 'natural looking' 
  5175. than the blockiness of JPEG, at both low and high bit rates. This is a valid 
  5176. point but is by no means universally accepted. 
  5177.  
  5178. What the coding community desperately needs is an easy to compute error meas-
  5179. ure that accurately captures subjective impression of human viewers. Until 
  5180. then, your eyes are the best judge.
  5181.  
  5182.  
  5183.  Finding Out More
  5184.  ----------------
  5185.  
  5186.  Please refer to item 17 in part 1 of this FAQ for a list of references,
  5187. available software, and ftp sites concerning fractal compression.
  5188.  
  5189. ------------------------------------------------------------------------------
  5190.  
  5191. Subject: [78] The Burrows-Wheeler block sorting algorithm (long)
  5192.  
  5193.  
  5194. A high-quality implementation of the Burrows-Wheeler
  5195. block-sorting-based lossless compression algorithm is available at
  5196. http://www.cs.man.ac.uk/arch/people/j-seward/bzip-0.15.tar.gz
  5197.  
  5198. Mark Nelson wrote an excellent article "Data Compression with the
  5199. Burrows-Wheeler Transform" for Dr. Dobb's Journal, September 1996.  A copy
  5200. of the article is at http://web2.airmail.net/markn/articles/bwt/bwt.htm
  5201.  
  5202. Another introduction written by Sampo Syreeni <tmaaedu@nexus.edu.lahti.fi>:
  5203.  
  5204.     The Burrows-Wheeler block sorting compression algorithm is described in
  5205. "A Block-sorting Lossless Data Compression Algorithm" by M. Burrows and D.J.
  5206. Wheeler, dated in May 10, 1994. A postscript copy of this paper has been made
  5207. available by Digital on the Systems Research Center (SRC) FTP site at
  5208. ftp://ftp.digital.com/pub/DEC/SRC/research-reports/SRC-124.ps.Z
  5209.  
  5210.     The method was originally discovered by one of the authors (Wheeler) back
  5211. in 1983, but has not been published before. As such, the method is fairly new
  5212. and hasn't gained popularity. Digital also holds the copyrights (and patents?)
  5213. to the method, so it isn't public domain.
  5214.  
  5215.     The method described in the original paper is really a composite of three
  5216. different algorithms: the block sorting main engine (a lossless, very slightly
  5217. expansive preprocessor), the move-to-front coder (a byte-for-byte simple,
  5218. fast, locally adaptive noncompressive coder) and a simple statistical
  5219. compressor (first order Huffman is mentioned as a candidate) eventually doing
  5220. the compression. Of these three methods only the first two are discussed here
  5221. as they are what constitutes the heart of the algorithm. These two algorithms
  5222. combined form a completely reversible (lossless) transformation that - with
  5223. typical input - skews the first order symbol distributions to make the data
  5224. more compressible with simple methods. Intuitively speaking, the method
  5225. transforms slack in the higher order probabilities of the input block (thus
  5226. making them more even, whitening them) to slack in the lower order statistics.
  5227. This effect is what is seen in the histogram of the resulting symbol data.
  5228.  
  5229.     The block sorting preprocessor operates purely on a block basis. One way
  5230. to understand the idea is to think of the input block arranged as a circular
  5231. array where, for every symbol, the succeeding symbols are used as a predictor.
  5232. This predictor is then used to group the symbols with similar right neighbors
  5233. together. This predictor is realized (conceptually) as a two phase process.
  5234. The first phase forms all cyclic shifts of the input block whose size is
  5235. usually a power of two. Note here that the original string is always present
  5236. intact on some row of the resulting matrix. If the block length is n then
  5237. there exist n unique rotations of the original string (to the left). These
  5238. rotations are now viewed as the rows of an N x N matrix of symbols. The second
  5239. phase consists of sorting this resulting conceptual matrix. This phase results
  5240. in the rows coming into order based on their first few symbols. If there is
  5241. some commonly repeated string in the input block (the original paper gives
  5242. "the" as an example), the sorting phase brings all those rotations that have a
  5243. part of this string as the row start very close to each other. The preceding
  5244. symbol in this common string is then found in the last column of the sorted
  5245. matrix. This way common strings result in short bursts of just a few distinct
  5246. characters being formed in the last column of the matrix. The last column is
  5247. what is then output from the second phase. One further bit of information is
  5248. derived from the input data. This is an integer with enough bits to tell the
  5249. size of the input string (that is, log_2(n)). The number is used to note the
  5250. row position into which the original input block got in the sorting algorithm.
  5251. This integer always results in expansion of the data, but is necessary for us
  5252. to be able successfully decompress the string. The absolute amount of overhead
  5253. increases as the logarithm of the input block size so its percentage of the
  5254. output data becomes negligible with useful block sizes anyway.
  5255.  
  5256.     The characteristics of the transformation process make the output from the
  5257. sort ideal for certain kinds of further manipulation. The extreme local
  5258. fluctuations in the first order statistics of the output string lead one to
  5259. use a transformation that boosts and flattens the local fluttering of the
  5260. statistics. The best example (and, of course, the one given in the original
  5261. paper) is move-to-front coding. This coder codes a symbol as the number of
  5262. distinct symbols seen since the symbol's last occurrence. Basically this means
  5263. that the coder outputs the index of an input symbol in a dynamic LIFO stack
  5264. and then updates the stack by moving the symbol to the top. This is easy and
  5265. efficient to implement and results in fast local adaptation. As just a few
  5266. common symbols will (locally) govern the input to the coder, these symbols
  5267. will be kept on the top of the stack and thus the output will mainly consist
  5268. of low numbers. This makes it highly susceptible to first order statistical
  5269. compression methods which are, in case, easy and efficient to implement.
  5270.  
  5271.     The transform matrix described above would require enormous amounts of
  5272. storage space and would not result in a usable algorithm as such. The method
  5273. can, however, be realized very efficiently by suffix and quick sort methods.
  5274. Thus the whole transformation together with the eventual simple compression
  5275. engine is extremely fast but still achieves impressive compression on typical
  5276. input data. When implemented well, the speeds achieved can be in the order of
  5277. pure LZ and the compression ratios can still approach state-of-the-art Markov
  5278. modeling coders. The engine also responds well to increasing block sizes -
  5279. the longer the input block, the more space there is for the patterns to form
  5280. and the more similar input strings there will be in it. This results in almost
  5281. monotonously increasing compression ratios even as the block length goes well
  5282. into the megabyte range.
  5283.     The decompression cascade is basically just the compression cascade
  5284. backwards. More logic is needed to reverse the main sorting stage, however.
  5285. This logic involves reasoning around the order of the first the last column of
  5286. the conceptual coding matrix. The reader is referred to the original paper for
  5287. an in depth treatment of the subject. The original paper also contains a more
  5288. thorough discussion of why the method works and how to implement it.
  5289.  
  5290.     And now a little demonstration. The original block to be compressed is
  5291. chosen to be the (rather pathological) string "good, jolly good". This was
  5292. taken as an example because it has high redundancy and it is exactly 16 bytes
  5293. long. The first picture shows the cyclic shifts (rotations) of the input
  5294. string. The second shows the matrix after sorting. Note that the last column
  5295. now has many double characters in it. Note also that the original string has
  5296. been placed into the 6th row now. The third picture shows the output for this
  5297. input block. The index integer has been packed to a full byte although 4 bits
  5298. would suffice in this case (log_2(16)=4). The fourth and fifth pictures show
  5299. the transformed string after move-to-front-coding. The sixth picture shows the
  5300. statistical distribution of the characters in the output string. Notice the
  5301. disproportionately large amount of ones and zeros, even with a very short
  5302. string like this. This is the output that is then routed through the simple
  5303. statistical encoder. It should compress very well, as the distribution of the
  5304. characters in the input block is now very uneven.
  5305.  
  5306.  
  5307.       0 1 2 3 4 5 6 7 8 9 A B C D E F        0 1 2 3 4 5 6 7 8 9 A B C D E F
  5308.       -------------------------------        -------------------------------
  5309.   0 | g o o d ,   j o l l y   g o o d    0 |   g o o d g o o d ,   j o l l y
  5310.   1 | o o d ,   j o l l y   g o o d g    1 |   j o l l y   g o o d g o o d ,
  5311.   2 | o d ,   j o l l y   g o o d g o    2 | ,   j o l l y   g o o d g o o d
  5312.   3 | d ,   j o l l y   g o o d g o o    3 | d ,   j o l l y   g o o d g o o
  5313.   4 | ,   j o l l y   g o o d g o o d    4 | d g o o d ,   j o l l y   g o o
  5314.   5 |   j o l l y   g o o d g o o d ,    5 | g o o d ,   j o l l y   g o o d
  5315.   6 | j o l l y   g o o d g o o d ,      6 | g o o d g o o d ,   j o l l y
  5316.   7 | o l l y   g o o d g o o d ,   j    7 | j o l l y   g o o d g o o d ,
  5317.   8 | l l y   g o o d g o o d ,   j o    8 | l l y   g o o d g o o d ,   j o
  5318.   9 | l y   g o o d g o o d ,   j o l    9 | l y   g o o d g o o d ,   j o l
  5319.   A | y   g o o d g o o d ,   j o l l    A | o d ,   j o l l y   g o o d g o
  5320.   B |   g o o d g o o d ,   j o l l y    B | o d g o o d ,   j o l l y   g o
  5321.   C | g o o d g o o d ,   j o l l y      C | o l l y   g o o d g o o d ,   j
  5322.   D | o o d g o o d ,   j o l l y   g    D | o o d ,   j o l l y   g o o d g
  5323.   E | o d g o o d ,   j o l l y   g o    E | o o d g o o d ,   j o l l y   g
  5324.   F | d g o o d ,   j o l l y   g o o    F | y   g o o d g o o d ,   j o l l
  5325.  
  5326.              1. The shifts                    2. In lexicographic order
  5327.  
  5328.  
  5329.                                                 121,45,102,114,0,1,36,0,
  5330.          "y,dood  oloojggl",5                   1,113,1,0,112,110,0,3,5
  5331.  
  5332.      3. The output from block sort          4. After move-to-front-coding
  5333.  
  5334.  
  5335.                                              00: 4;  01: 3;  03: 1;  05: 1;
  5336.           79,2D,66,72,0,1,24,0,              24: 1;  2D: 1;  66: 1;  6E: 1;
  5337.           1,71,1,0,70,6E,0,3,5               70: 1;  71: 1;  72: 1;  79: 1
  5338.  
  5339.            5. In hexadecimal                      6. The statistics
  5340.  
  5341. ------------------------------------------------------------------------------
  5342.  
  5343.           End of part 2 of the comp.compression faq.
  5344.  
  5345.  
  5346. Part 3: (Long) list of image compression hardware
  5347.  
  5348. [85] Image compression hardware
  5349. [99] Acknowledgments
  5350.  
  5351.  
  5352. Search for "Subject: [#]" to get to question number # quickly. Some news
  5353. readers can also take advantage of the message digest format used here.
  5354.  
  5355. ------------------------------------------------------------------------------
  5356.  
  5357. Subject: [85] Image compression hardware
  5358.  
  5359. Here is a list of sources of image compression hardware (JPEG, MPEG,
  5360. H.261 and others), reposted with the author's permission.  The list is
  5361. certainly dated already, but it is a good starting point for
  5362. seeking compression chips. (Please send corrections/additions to
  5363. gzip@prep.ai.mit.edu). References are taken from:
  5364.  
  5365.    VIDEO COMPRESSION OPTIONS, IEEE CICC 6-May-92
  5366.    John J. Bloomer, jbloomer@crd.ge.com, Fathy F. Yassa, Aiman A. Abdel-Malek
  5367.    General Electric Corporate R&D, KWC317 Signals and Systems Laboratory
  5368.    PO Box 8, Schenectady NY, 12301
  5369.  
  5370. (Too many people have sent comments, corrections or additions so I am
  5371. just making a common acknowledgment here.)
  5372.  
  5373. [Check also:
  5374.   http://www.dspnet.com/       Tech-Online's catalog
  5375.   http://www.c-cube.com/       C-Cube Microsystems
  5376.   http://datacompression.com/  DCP Research Corp
  5377.   http://www.ftelinc.com/      FutureTel
  5378. ]
  5379.  
  5380.  Pipelined Processors, Building Blocks (Chip Sets)
  5381.  -------------------------------------------------
  5382.  
  5383. STI3200, IMSA121, STI3208 - SGS-Thompson DCT processors.  602-867-6200
  5384.     - 3200 has multiple block size options, DC to 13.5 MHz
  5385.     - A121 8x8 fixed blocks, DC to 20MHz, add/sub loop, CCITT compatible
  5386.     - 3208 8x8 fixed blocks, DC to 40MHz, CCITT compatible at 20MHz
  5387.  
  5388. STI3220 - SGS-Thompson motion estimator (H.261, MPEG).  602-867-6279
  5389.     - 8-bit input pixels, 4-bit H and V vectors out
  5390.     - adjustable block size matcher (8x8, 8x16, 16x16)
  5391.     - +7/-8 search window
  5392.     - 5V, 2W at 18MHz (max), 68 pin PLCC
  5393.  
  5394. L64765 , L64735 , L64745 - 3-chip LSI Logic JPEG set.
  5395.     408-433-8000, 800-433-8778
  5396.     - L64765 raster-to-block and color-space converter, jointly developed
  5397.           with Rapid Tech.
  5398.     - L64735 block DCT processor
  5399.     - L64745 JPEG coder support, stand-alone lossless DPCM codec, dynamic
  5400.           Huffman
  5401.     - 27 MB/s on CCIR601 frames
  5402.     - minimal support logic, color and gray scale
  5403.     - 68-pin PGA or PLCC, 27 and 20 MHz versions
  5404.  
  5405. L647*0 and L6471* families - LSI Logic H.621/MPEG pieces.  408-433-8000
  5406.     - L64720 motion estimator, 30/40MHz, 8x8, 16x16 blocks, 32x32 or 16x16 
  5407.           search window, 68-pin CPGA or PPGA
  5408.     - L64730 & 735 8x8 DCT processors (12 & 8-9 bits)
  5409.     - L64740 8x8 block quantization
  5410.     - L64760 intra/inter-frame coding decision
  5411.     - L64715 BCH error correction
  5412.     - L64750/L64751 variable length encode/decode (H.261-specific)
  5413.  
  5414. ZR36020 and ZR36031 - Zoran DCT processor & quantization/encoding. 408-986-1314
  5415.     - JPEG-like scheme using 16-bit, two's complement fixed point
  5416.           arithmetic
  5417.     - includes bit-rate controls for constant # of pictures per card
  5418.     - 7.4 MHz, < 1W, 20mW in standby mode, 7.5 frames/s (f/s)
  5419.     - 36020 - 44-pin plastic quad flatpack (PQFP) or 48-pin ceramic DIP
  5420.     - 36031 - 100-pin PQFP or 85-pin PGA.
  5421.     - co-developments with Fuji Photo Film Co. Ltd. digital IC-card
  5422.           camera market
  5423.  
  5424.     Does 2-passes of image: generate histogram for optimum Huffman
  5425.     tables and quantization compute step size (ala H.261 and
  5426.     MPEG-I) for each macroblock or minimum coded unit (MCU).
  5427.  
  5428.     JPEG-compatible codec expected soon.
  5429.  
  5430. LDM3104  - Olympus DCT coefficient encoder
  5431.     - constant rate, digital IC-card camera market
  5432.     - 750 mW, 25 mW standby, 100-poin QFP
  5433.  
  5434. TMC2312 - TRW quantizer/Huffman encoder, TMC2313 Huffman decoder/dequantizer
  5435.  
  5436. TMC2311 - TRW CMOS Fast Cosine Transform Processor.  
  5437.     - 12 Bits, 15 M pixels/s
  5438.     - complies with the CCITT SGXV ( e.g. JPEG, H.261 and MPEG )
  5439.     - includes an adder-subtractor for linear predictive coding
  5440.  
  5441. MN195901 - Matsushita Electric Industrial Co.   See ISSCC 1992
  5442.     - 16-bit, 60 MIP video signal processor
  5443.     - 25 uS instruction processing
  5444.     - on-board DCT and absolute differencing
  5445.     - Philips Signetics US fab.
  5446.  
  5447. HGCT - Ricoh CRC, Generalized Chen Transform demonstration chip.
  5448.     - 2D JPEG/MPEG/H.261 compatible DCT
  5449.     - includes quantization
  5450.     - 30MHz, 15K gates
  5451.     - licensing possible
  5452.  
  5453. GCTX64000 - Graphic Communication Technology Corp. chipset
  5454.     - provides CCITT H.261
  5455.     - VLSI Technology and Hitachi supply H.261 codec core. 1 micron CMOS.
  5456.  
  5457. BT - British Telecommunications  plc., Martlesham labs designed
  5458.     - H.261 codec chipset, Motorola fab.
  5459.     - 13 chips total for codec.
  5460.  
  5461.  
  5462.  Pipelined Processors, Monolithic, Programmable
  5463.  ----------------------------------------------
  5464.  
  5465. Vision Processor - Integrated Information Technology Inc. 408-727-1885
  5466.     - generic DCT, motion compensated & entropy coding codec
  5467.     - microcode for still- and motion-video compression (JPEG, H.261 and
  5468.           MPEG1)
  5469.     - 1 micron CMOS, 20 MHz and 33 MHz, PGA and 84-pin QFP  
  5470.     - JPEG only and JPEG/H/261/MPEG versions available, H.261 at 30 f/s.  
  5471.     - used by Compression Labs, Inc. CDV teleconferencing system
  5472.     - rumored to be the heart of the AT&T picture phone
  5473.  
  5474. MN195901 - Matsushita Electric Industrial Corp
  5475.     - 40 MHz DSP, built-in DCT
  5476.     - 16-bit fixed-point
  5477.  
  5478. AVP1000 -  AT&T  JPEG, MPEG and H.261 codec chipset.  800-372-2447
  5479.     - 1400D decoder, 1400C system controller
  5480.     - 1300E H.261 (CIF, QCIF, CIF240) at 30 f/s, I-frame only MPEG.
  5481.     - 1400E is superset of 1300E, motion with 1/2 pixel resolution over +/-
  5482.           32 pixels
  5483.     - YCbCr video or digital input, on-board rate FIFOs, external RAM
  5484.           required
  5485.     - 0.75 micron, 50 MHz CMOS
  5486.  
  5487.     AVP1000 is from AT&T Microelectronics.  The AT&T chip set
  5488.     handles MPEG-1, H.261, and JPEG.  1400D has on board color
  5489.     space convertor.  Limited to 4Mb/s coded rate.  The DSP does
  5490.     the MUSICAM decoding (up to layer II ?)
  5491.  
  5492.  
  5493. 82750PB, 82750DB - Intel DVI  pixel and display YUV color space processors.
  5494.     - proprietary machine code employed for compression
  5495.     - usable for other algorithms (e.g., JPEG, H.261 or MPEG1 at reduced
  5496.           data rates)
  5497.  
  5498.  
  5499.  Pipelined Processors, Monolithic, Fixed Lossless - Entropy Coders, DPCM, VQ
  5500.  ---------------------------------------------------------------------------
  5501.  
  5502. DCP - Integrated Information Tech. Inc. Data Compressor Processor  408-727-1885
  5503.     - LZ codec with on-chip dictionary store
  5504.     - on-chip buffers supporting block moves
  5505.     - targeting disk drives and network controller markets
  5506.     - 3.3V, 84-pin PQFP
  5507.  
  5508. Mystic - HP's DC-LZ codec.  408-749-9500
  5509.  
  5510. AHA3210 - Advanced Hardware Architectures DC-LZ codec. 208-883-8000
  5511.     - two independent DMA ports for 10 MB/s compress, decompress &
  5512.           pass-thru
  5513.     - addressing allows up to 16 MB record compression
  5514.     - 20 MHz internal clock, 200 mW, 100-pin PQFP
  5515.     - interface to AHA5101/5121 QIC tape controller/formatter
  5516.     - HP licensee
  5517.  
  5518. AHA3xxx/xxy - Rice (UNC) algorithm, 20M samples/sec, 4 to 14 bits. 208-883-8000
  5519.  
  5520. CRM1000 - CERAM Inc. entropy codec, proprietary algorithm.  719-540-8500
  5521.  
  5522. Rice - UNC algorithm prototype, 180 Mb/s.  See IEEE CICC 1992
  5523.     - other CICC 1992 papers:
  5524.        +JS.E. Kerneny et.al. differential read, pyramidal output CCD
  5525.          + A. Aggoun et.al. DPCM processing
  5526.  
  5527. DCD - Philips Data Compressor Decompressor IC. 914-945-6000
  5528.     - See CICC 1990 proceedings, H. Blume, et.al.
  5529.     - LZ codec, 20 MHz clock
  5530.     - Internal FIFOs, separate input/output buses, max 10 Mword/s data in
  5531.     - 5 V CMOS, 175-pin PGA
  5532.  
  5533. 9705 - Second generation Stac Electronics accelerator chip.  619-431-7474
  5534.     - Stacker LZA compression scheme(LZ-based)
  5535.     - compress at approx. 2.5 MB/s, decompress at 6 MB/s (39+ faster than
  5536.           9704)
  5537.     - standby mode 300uA
  5538.     - embedded in tapes and disks (e.g., QIC-122 Ten X Technology
  5539.           512-346-8360)
  5540.     - file compression board & software:
  5541.         + for the PC/AT - from Stac
  5542.         + for the Macintosh - from Sigma Design 415-770-0100 (40 MHz 9703)
  5543.     - InfoChip Systems Inc. - proprietary string-matching technology
  5544.           408-727-0514
  5545.  
  5546. VCEP or OTI95C71/Am95C71 - Oak Technology Inc. 408-737-0888
  5547.     - AMD CCITT B&W fax image compression
  5548.  
  5549.  
  5550.  Pipelined Processors, Monolithic, Fixed Lossy
  5551.  ---------------------------------------------
  5552.  
  5553. MB86356B - Fujitsu LTD.
  5554.     - JPEG DIS 10918-1 baseline  codec
  5555.     - on-chip quantizer tables
  5556.     - 2.5M pixel/sec input, up to 10MB/sec output
  5557.     - supports progressive and DPCM lossless modes 
  5558.     - 135 pin PGA.
  5559.  
  5560. CL550-30 - C-Cube Microsystems 408-944-6300, literature@c-cube.com
  5561.     - JPEG-8-R2 compliant baseline codec
  5562.     - 350-level pipeline, on-chip Huffman and quantizer table
  5563.     - 44.1 MB/sec (15 MB/sec for -10)
  5564.     - RGB, YUV, CMYK supported, CCIR 601 in real-time
  5565.     - 16/32-bit host interface 
  5566.     - 144 pin PGA or QFP, 2.5W at 29.41 MHz
  5567.  
  5568.     Limited to 2MB/sec (15Mb/s) coded rate.  35MHz PGA version
  5569.     available.  2:1 horizontal filter, on board programmable color
  5570.     space convertor.  Allows on pair of quantization tables to be
  5571.     loaded while other pair is used to code or decode data stream.
  5572.     Needs maintanence by host.
  5573.  
  5574. STI140 - SGS-Thompson JPEG baseline codec.  617-259-0300 [** Now cancelled **]
  5575.     - see CICC 1991 proceedings, M. Bolton.
  5576.     - 20 Mpixel/sec input, up to 20 MB/sec output
  5577.     - supports 24-bit color, 8-bit grey and 12-bit extended pixels
  5578.     - on chip Huffman and quantizer tables
  5579.     - 144 pin PQFP, 5V, < 2W., 10mW power-down mode
  5580.     - 1.2 micron, 3-layer metal CMOS, 20 MHz.    `
  5581.  
  5582. UVC7710 - UVC Corp. Integrated Multimedia Processor. Was 714-261-5336, out
  5583.           of business now.
  5584.     - proprietary, patented intra-frame compression, on-chip code tables
  5585.     - 20-35:1, 12.5 Mpixels/sec., compressed audio
  5586.     - includes much of the PC-AT (16-bit ISA) bus interface logic
  5587.     - 128 pin PJQFP plastic
  5588.  
  5589. CL950 - C-Cube/JVC implementation of the MPEG-JVC or extended mode MPEG2 
  5590.         announced.  6-9 Mb/sec.
  5591.  
  5592.     JVC mode is not MPEG-II compliant (there isn't an MPEG2 standard yet)
  5593.     but is an extension of MPEG1 at a higher rate plus interlace video
  5594.     handling.
  5595.  
  5596. CL450 - Announced June 1992.  Scaled down version of CL950, with 3Mb/sec
  5597.         limit.  Does not code or decode JPEG, only MPEG-I decoding.
  5598.  
  5599. CD-I - ASICs planned for CD-ROM, Compact Disk-Interactive defacto standards
  5600.     - CD-ROM XA - Sony-Philips-Motorola-Microsoft
  5601.     - CDTV -  Commodore.  YUV processing.
  5602.     - audio ADPCM encode/decode PC/AT boards available from Sony
  5603.           408-432-0190
  5604.  
  5605. Motorola MCD250 Full Motion Video Decoder.   512-928-5053.
  5606.     This is a CD-I MPEG Video decoder which requires only a single
  5607.     4Mbit DRAM for FMV decoding. Decodes System and Video Layers
  5608.     at up to 5Mbits/sec, converts from 24/25/30 fps IPB streams to
  5609.     25/30 fps output video in 24bit RGB/YUV format. Supports extra
  5610.     CD-I functions such as windowing and still picture mode.
  5611.     Targetted at low cost consumer applications such as CD-I,
  5612.     CD-Karaoke, Video-CD and cable TV.
  5613.  
  5614. Motorola MCD260 MPEG Audio Host Interface and DSP56001-33.  512-928-5053.
  5615.     The MCD260 is a low cost interface IC which goes between a 68K
  5616.     bus and a DSP56K and strips out the MPEG System Layer whilst also
  5617.     buffering and synchronising. A 33MHz 56001 with 8Kwords of DSPRAM
  5618.     decodes the MPEG Audio (Layer 1/II @ 44.1KHz, all modes and bit rates)
  5619.  
  5620. Pixel Magic PM-2. Contact: Don Shulsinger, Pixel Magic, 508-688-4410.
  5621. - JBIG compression/decompression at 30 Mb/s (typical and worst-case)
  5622. - G3/G4 compression/decompression at 90 Mb/s (typical), 30 Mb/s (worst-case)
  5623. - scaling on decode from 1/256 to 256X
  5624. - rotation by 90 degrees
  5625. - clipping to a window and padding out to another
  5626. - lookup table filtering on 3x3 neighborhoods
  5627. - on-chip FIFOs on input and output
  5628. - bookmarking for suspend/resume
  5629.  
  5630.  
  5631.  Codecs Chips Under Development
  5632.  ------------------------------
  5633.  
  5634. MPEG1 codec chips due from - TI, Brooktree, Cypress Semiconductor, Motorola 
  5635. (successor to the DSP96002 Multimedia Engine), Xing Technology/Analog Devices, 
  5636. Sony and C-Cube
  5637.  
  5638.  
  5639. Windbond Electronics Corp. is developing a DSP chip for CD-I, MPEG and JPEG
  5640.  
  5641.  
  5642.  Using these Chips: Board Level Compression Hardware
  5643.  ------------------------------------------------------
  5644.  
  5645. + JPEG Using CL550
  5646.  
  5647. + JPEG Using Other Chip Sets
  5648.  
  5649. + DSP Chip Based JPEG/MPEG Solutions
  5650.  
  5651. + Integrated Compressed Digital Video Boards 
  5652.  
  5653.  
  5654.  JPEG Using CL550
  5655.  ---------------
  5656. C-Cube - 408-944-6300 ISA and NuBus boards 
  5657.     - for development and limited time-constraint applications
  5658.     - 1-2.5 MB/sec host bus constraints
  5659.     - Image Compression Interface (ISI) software for 3rd party CL550
  5660.           integration
  5661.  
  5662. VideoSpigot/SuperSqueeze - SuperMac Technology  408 541-6100
  5663.     - a CL550A on a NuBus board
  5664.     - 24 frame/s with CD-quality audio
  5665.     - reads from Winchester and magneto-optic drives
  5666.  
  5667. Fluency VSA-1000 - Fluent Machines, Inc. AT board set.  508 626-2144
  5668.     - compress/decompress real-time synced audio & video to a i386 PC
  5669.           Winchester
  5670.     - NTSC or PAL input, 320x240 pixels saved
  5671.     - uses i960 chip, no additional boards needed
  5672.     - M/S Windows support, 3rd party S/W (e.g., AimTech 603-883-0220)
  5673.  
  5674. Super Motion Compression - New Media Graphics  PC/AT board.  800 288-2207
  5675.     - 8Khz, 8-bit compressed audio
  5676.     - 30 f/s JPEG to & from disk
  5677.     - earlier reports: still-frame compression in several seconds per MB
  5678.  
  5679.  
  5680. Leadview  - Lead Tech Inc. AT board uses the CL550 to compress/decompress
  5681.             JFIF or JTIF format files
  5682.  
  5683. Monalisa - Opta Inc. AT board uses the CL550
  5684.  
  5685. Squeeze - Rapid Technology AT board
  5686.     - Integrated by a number of vendors into 3rd party multimedia,
  5687.           video-editing PC stations
  5688.  
  5689. Parallax Graphics - SBus, VME and PC-AT boards.  408-727-2220 or
  5690.           info@parallax.com
  5691.  
  5692. Chips and Technologies - JPEG development kit due.
  5693.  
  5694. Image Manipulation Systems, Inc - SBus compression/framebuffer/video I/O boards
  5695.     800-745-5602 or imsinfo%thumper@src.honeywell.com
  5696.  
  5697.  
  5698.  JPEG Using Other Chipsets
  5699.  -------------------------
  5700.  
  5701. Visionary - Rapid Technology JPEG AT board.  716-833-8534
  5702.     -  LSI Logic JPEG chips L647-35, -45 & -65
  5703.     - 30 f/s motion JPEG
  5704.     - 256x240 pixel compression and display from CCIR-601 input
  5705.     - private codec-frame buffer bus
  5706.     - also integrated with TrueVision multimedia hardware
  5707.  
  5708. Media 100  - Data Translation nonlinear video production system for the
  5709.           Macintosh  (QuickTime).  22 MB/s (PAL) and 18MB/s (NTSC) throughput.
  5710.  
  5711. Alice - Telephoto Communications Inc. 619-452-0903
  5712.     - Alice-H350 (PC/AT) and -H365 (PS/2) codec boards
  5713.     - use a 40 MHz TMS320C51 DSP and a IMSA121 DCT processor chip
  5714.     - JPEG (lossy and lossless), CCITT G3/G4, color and grey-scale images
  5715.  
  5716. Xing Technology - Hardware accelerator.  xing@xingtech.com or 805-473-0145
  5717.     - compatible with their VT-Express JPEG Turbo Accelerator Software
  5718.  
  5719. Video/1 - PsiTech Inc. 714-968-7818
  5720.     - includes a 6U VME/VSB JPEG Processing Card 
  5721.     - compresses RS-170, NTSC, PAL or Secam video into 8 MB of on-board RAM
  5722.  
  5723.  
  5724.  DSP Chip Based JPEG/MPEG Solutions
  5725.  ----------------------------------
  5726.  
  5727. Optipac - Optivision Inc. PC/AT, ISA & VME codecs.  800-562-8934
  5728.     - JPEG (lossless and lossy), CCITT III/IV
  5729.     - 1 to 5 TMS32C025s
  5730.     - 512x400x16-bit images in < 1 sec.
  5731.  
  5732. XCeed ICDP-II - Micron Technology Inc. NuBus card
  5733.     - uses two AT&T Microelectronics DSP-16 DSP chips
  5734.     - driven by Storm Technologies PicturePress software
  5735.     - executes an enhanced JPEG algorithm at near-realtime.
  5736.  
  5737. PicturePress Accelerator - Storm Technology 415-691-1111 (see above)
  5738.     - also has a line of VME compression boards
  5739.     - Micro Dynamics Ltd. imaging systems use Storm accelerator
  5740.           301-589-6300
  5741.  
  5742. Picture Packer Accelerator - Video & Image Compression Corp.
  5743.     - AT and NuBus boards use the JPEG Open Standard and a TMS320C25
  5744.  
  5745. SunVideo (S-bus) - Sun Microsystems
  5746.         - PAL/NTSC framegrabber with an integrated C-Cube CL4000
  5747.       VideoRISC processor and downloadable video compression for
  5748.       MPEG, MJPEG or CellB. It achieves about 10 Frames/sec on
  5749.       MPEG Level 1 picture data compression. The board costs about $1K.
  5750.  
  5751. Phoenix System - T/one Inc. uses an Optivision Optipac 3250 to talk to a Storm 
  5752.                  Technologies NuBus PicturePress Accelerator to talk JPEG over 
  5753.                  analog phone lines.
  5754.  
  5755. Nextdimension - NeXt Computer Inc. 415-780-3912
  5756.     - 24+8-bit alpha, 640x480, 30 f/s decompression
  5757.     - CL550 version not shipping as announced. 
  5758.  
  5759. Spirit-40  - Sonitech International Inc. ISA card. 617-235-6824
  5760.     - two TMS320C40 DSPs for 80 MFLOPS
  5761.     - connect 16 boards in a hypercube for up to 1280 MFLOPS
  5762.     - JPEG, MPEG-1 audio and other voice coding applications included 
  5763.  
  5764. HardPak - CERAM Inc., ISA and EISA file compression board.  719-540-8500
  5765.     - 3.4 x 1.8 inch footprint (notebook, laptops)
  5766.     - 32KB on-board write-thru file compression cache
  5767.     - CERAM also has an SBus compressive swap-space accelerator for Suns
  5768.  
  5769. macDSP - Spectral Innovations, AT&T DSPC32-based accelerator.  408-727-1314
  5770.     - JPEG functions available
  5771.     - 30 MFLOPS on the NuBus
  5772.  
  5773.  
  5774.  Integrated Digital Video Boards - Miscellaneous Multimedia, Video Conferencing
  5775.  ------------------------------------------------------------------------------
  5776.  
  5777. VCI/oem - Vista Communication Instruments, Inc. +358 0 460 099
  5778.     - two AT-board H.261 video codec, PAL or NTSC cameras and monitors
  5779.     -56 kbps (64 kbps) to 2 Mbps, 64 kbps increments
  5780.     - H.221 framing and synchronizing     - H.241 network signalling 
  5781.     - H.200/AV.254 forthcoming standard for compressed audio
  5782.     - network interface boards available
  5783.  
  5784. MediaStation- VideoLogic Inc., JPEG compression board for ISA bus. 617-494-0530
  5785.     - works with VideoLogic DVA-4000/ISA motion video board, custom bus
  5786.     - CL-550 plus ADPCM and PCM audio support
  5787.     - Inmos Transputer for I/O scheduling
  5788.     - Microsoft Windows Multimedia Extensions and proprietary interfaces
  5789.  
  5790. DECspin - Digital Equipment CorpSound/Picture Information Network 508-493-5111
  5791.     - full motion, true-color (24-bit) and greyscale (8-bit black & white)
  5792.     - variable frame size and rate up to 640 x480 x30 NTSC true-color 
  5793.     - Internet or DECnet transmission and disk I/O of live synchronized
  5794.           video/audio
  5795.     - video teleconferencing using standard network protocols 
  5796.     - create and edit of audio and video sequences
  5797.     - voice grade live audio sequences
  5798.     - DECmedia DECvideo and DECaudio hardware and software required
  5799.  
  5800. ActionMedia II - Intel/IBM DVI PS/2 and PC/AT boards.  914-642-5472
  5801.     - i750 processor boards for capture and delivery systems
  5802.     - Microsoft programming support libraries
  5803.     - proprietary RTV and PLV compression algorithms resident, time and
  5804.           time/space VQ
  5805.     - Real Time  Video (RTV) algorithm 1.5 , effective 128x120 pixel
  5806.           sequence at 30 f/s.
  5807.     - RTV 1.0 is 128x240 at 10 f/s. 
  5808.     - Presentation Level Video (PLV) - extensive off-line processing,
  5809.           exploits inter-frame coherence.  
  5810.     - i750 processor capable of playing-back PLV-compressed 256x240
  5811.           sequences at 30 f/s. 
  5812.  
  5813. DVI Board - Fast Electronic U.S. Inc. laptop board.  508-655-3278
  5814.     - uses Intel i750 chipset
  5815.     - compress or decompress video at up to 30 f/s
  5816.  
  5817. EyeQ - New Video Corp. DVI boards for the Macintosh.  213-396-0282
  5818.     - uses Intel i750 chipset
  5819.     - 150 KB/s full-motion compressed video
  5820.     - T1 and Winchester integration paths
  5821.  
  5822. Copernicus 1000 & 2000 - DesignTech, 408-453-9510
  5823.     - DVI-based presentation and authoring systems 
  5824.  
  5825. Spectrum Signal Processing - DSP96002-based PC-AT board
  5826.     - up to four boards in cascade
  5827.     - other TI, Analog Devices and AT&T-based DSP offerings
  5828.  
  5829. Ariel Corp. - Dual DSP96002 PC-AT board with compression support.  201-429-2900
  5830.  
  5831. Capture I - UVC Corp., 16-bit ISA bus board.  was 714-261-5336, out
  5832.           of business now.
  5833.     - 30 f/s of 640/480 interlace capture and record (uses UVC7710)
  5834.     - NTSC or PAL input
  5835.     - VPC200/201 development board set - proprietary NTSC video codec
  5836.          (audio card required).  
  5837.  
  5838. Leadview  - Lead Technologies, Inc. accelerates an enhanced JPEG algorithm
  5839.    on ISA
  5840.  
  5841. IBM - near-term availability:
  5842.     (1) IBM United Kingdom and British Telecommunications plc. 
  5843.     - PC or PS/2 add-on boards by end of 1993
  5844.     - interface to ISDN 2 service (one or two 64kb/s channels)
  5845.     - BT also planning residential videophone product with GEC Marconi Ltd.
  5846.  
  5847.     (2) IBM Japan PS/2 board 
  5848.     - uses GCTX64000 for H.261 
  5849.     - ISDN (narrowband 64kb/s ) and IEEE 802.5 LAN interfaces
  5850.  
  5851.  
  5852. Optibase 100 - Optibase, Inc. DSP-based compression/expansion boards.
  5853.    818-719-6566
  5854.     - supports JPEG
  5855.     - supports CCITT G.721 and ANSI T1.301 & T1.303  drafts (voice and
  5856.           music) 
  5857.     - and proprietary compression (AADCT, lossless)
  5858.  
  5859. Optibase MPEG Lab Pro and MPEG Lab +. Phone: 214-386-2040 or 800-451-510
  5860.  
  5861. Motorola - DSP56002 (fixed-point 40MHz version of the 56001)
  5862.  
  5863. AT&T JPEG coder (George Warner <warnergt@aloft.att.com>)
  5864.         - runs on a DSP3210 under the VCOS operating system.
  5865.       The coder can be used to simultaneously compress/decompress
  5866.       multiple images and/or be used in conjunction with other DSP
  5867.       modules to preprocess or postprocess the image data.
  5868.  
  5869.       Other modules available for the DSP3210 include audio coders
  5870.       (such as MPEG, SBC, CDXA, and G.722), modem/fax data pumps
  5871.       (V.32bis, V.22bis, and V.29), DTMF, call progress detection,
  5872.       sample rate conversion, and more.
  5873.  
  5874.  
  5875. MWave - TI, IBM, Intermetrics multimedia system, due from IBM in 1993. 
  5876.  
  5877. Misc. NuBus boards - RasterOps , Radius, Mass Microsystems, Orange Micro,
  5878. IBM M - - Motion.
  5879.  
  5880. P.OEM - Interated Systems Inc. fractal compression boards for the PC.
  5881. 404-840-0310
  5882.  
  5883. two desktop video conferencing products for Sparc's
  5884. with the Parallax XVIDEO board:
  5885.  
  5886. Communique! - desktop video conferencing products for Sparcs with the Parallax
  5887.               XVIDEO board:
  5888.         InSoft, Inc., 4718 Old Gettsburg Road, Executive Park West I, Suite 307
  5889.         Mechanicsburg, PA 17055, USA. email: info@insoft.com
  5890.         phone: 717-730-9501, fax: 717-730-9504
  5891.  
  5892. PSVC - desktop video conferencing products for Sparcs with the Parallax
  5893.               XVIDEO board:
  5894.     Paradise Software, Inc., 55 Princeton Heightstown Rd, Suite 109
  5895.     Princeton, NJ 08550, USA. email: support@paradise.com
  5896.     phone: 609-275-4475, fax: 609-275-4702
  5897.  
  5898. North Valley Research - video and other time-based media in a UNIX environment
  5899.         North Valley Research; 15262 NW Greenbriar Pkwy; Beaverton, OR  97006
  5900.         Phone (503) 531-5707, Fax (503) 690-2320. Todd Brunhoff <toddb@nvr.com>
  5901.  
  5902. Visionetics MPEG MasterTM for 386 PC. phone (310) 316-7940,
  5903.          fax (310) 316-7457, e-mail 72622.2112@compuserve.com.
  5904.     MPEG Video compliant with ISO-11172 
  5905.     Up to 16 million colors regardless of VGA card or VGA mode 
  5906.     704 x 480 NTSC, 704x576 PAL resolution 
  5907.     Full motion video NTSC ( 30 fps), Pal (25 fps) 
  5908.     VIGABUSTM high speed digital video bus 
  5909.  
  5910.     MPEG audio  Layer I and II 
  5911.     16 bit stereo digital audio playback 
  5912.     20 Hz - 20 KHz frequency response 
  5913.     Stereo headphone/preamp output 
  5914.  
  5915. RealMagic board. Sigma Designs, 510-770-0100
  5916.         - MPEG Audio and Video playback board (ISA bus). Full compliance with
  5917.           ISO CD 11172. Supports 30 fps (NTSC), and 25 fps (PAL).
  5918.         - MPEG sound standards - Layer I and II.
  5919.         - On-board CD ROM interface (not on RealMagic Lite board)
  5920.  
  5921. RealMagic Producer. Sigma Designs, 510-770-0100
  5922.         - Video/Audio Capture and MPEG encoding controller (PCI bus). 
  5923.         - Compressed Data Format: MPEG-1, 352x240 (NTSC), 352x288 (PAL).
  5924.         - Audio Capture - MPEG-1, Layer I and II. 44.1 kHz sampling frequency.
  5925.         - Require Pentium system, 16 MB RAM, fast SCSI hard drive.
  5926.  
  5927.  
  5928.  Boards Under Development
  5929.  ------------------------
  5930.  
  5931. Matrox - Matrox Studio line of PC boards will include a 64-bit MOVIE bus and
  5932.          JPEG compression.
  5933.  
  5934.  
  5935. ------------------------------------------------------------------------------
  5936.  
  5937. Subject: [99] Acknowledgments
  5938.  
  5939.  
  5940. There are too many people to cite. Thanks to all people who directly
  5941. or indirectly contributed to this FAQ.
  5942.  
  5943.