home *** CD-ROM | disk | FTP | other *** search
/ Archive Magazine 1996 / ARCHIVE_96.iso / discs / utilities / utility_02 / convrters2 / !ChangeFSI / JPEGinfo < prev    next >
Text File  |  1996-03-11  |  21KB  |  421 lines

  1. The Independent JPEG Group's JPEG software
  2. ==========================================
  3.  
  4. README for release 3 of  17-Mar-92
  5. ==================================
  6.  
  7. This distribution contains the third official release of the Independent JPEG
  8. Group's free JPEG software.  You are welcome to redistribute this software and
  9. to use it for any purpose, subject to the conditions under LEGAL ISSUES, below.
  10.  
  11. For usage instructions, see section USAGE.
  12.  
  13. This software is still undergoing revision.  Updated versions may be obtained
  14. by FTP or UUCP to UUNET and other archive sites; see ARCHIVE LOCATIONS below
  15. for details.
  16.  
  17. If you intend to become a serious user of this software, please contact
  18. jpeg-info@uunet.uu.net to be added to our electronic mailing list.  Then
  19. you'll be notified of updates and have a chance to participate in discussions,
  20. etc.
  21.  
  22. This software is the work of Tom Lane, Philip Gladstone, Luis Ortiz,
  23. Lee Crocker, Ge' Weijers, and other members of the Independent JPEG Group.
  24.  
  25.  
  26. DISCLAIMER
  27. ==========
  28.  
  29. THIS SOFTWARE IS NOT COMPLETE NOR FULLY DEBUGGED.  It is not guaranteed to be
  30. useful for anything, nor to be compatible with subsequent releases, nor to be
  31. an accurate implementation of the JPEG standard.  (See LEGAL ISSUES for even
  32. more disclaimers.)
  33.  
  34. Please report any problems with this software to jpeg-info@uunet.uu.net.
  35.  
  36.  
  37. WHAT'S HERE
  38. ===========
  39.  
  40. This distribution contains compiled C software to implement JPEG image
  41. compression and decompression.  JPEG (pronounced "jay-peg") is a standardized
  42. compression method for full-color and gray-scale images.  JPEG is intended for
  43. "real-world" scenes; cartoons and other non-realistic images are not its strong
  44. suit.  JPEG is lossy, meaning that the output image is not necessarily
  45. identical to the input image.  Hence you should not use JPEG if you have to
  46. have identical output bits.  However, on typical images of real-world scenes,
  47. very good compression levels can be obtained with no visible change, and
  48. amazingly high compression levels can be obtained if you can tolerate a
  49. low-quality image.  For more details, see the references, or just experiment
  50. with various compression settings.
  51.  
  52. The software implements JPEG baseline and extended-sequential compression
  53. processes.  Provision is made for supporting all variants of these processes,
  54. although some uncommon parameter settings aren't implemented yet.  For legal
  55. reasons, we are not distributing code for the arithmetic-coding process; see
  56. LEGAL ISSUES.  At present we have made no provision for supporting the
  57. progressive, hierarchical, or lossless processes defined in the standard.
  58.  
  59. The present software is not far beyond the prototype stage.  It does not
  60. support all possible variants of the JPEG standard, and some functions have
  61. rather slow and/or crude implementations.  However, it is useful already.
  62.  
  63. The emphasis in designing this software has been on achieving portability and
  64. flexibility, while also making it fast enough to be useful.  We have not yet
  65. undertaken serious performance measurement or tuning; we intend to do so in
  66. the future.
  67.  
  68. In particular, we welcome the use of this software as a component of commercial
  69. products; no royalty is required.
  70.  
  71.  
  72. ARCHIVE LOCATIONS
  73. =================
  74.  
  75. The "official" archive site for this software (including the source) is
  76. ftp.uu.net (Internet address 137.39.1.9 or 192.48.96.9).  The most recent
  77. released version can always be found there in directory graphics/jpeg.  This
  78. particular version will be archived as jpegsrc.v3.tar.Z.  If you are on the
  79. Internet, you can retrieve files from UUNET by anonymous FTP.  If you don't
  80. have FTP access, UUNET's archives are also available via UUCP; contact
  81. postmaster@uunet.uu.net for information on retrieving files that way.
  82.  
  83. Various other Internet sites maintain copies of the UUNET file, which may or
  84. may not be up-to-date.  In Europe, try nic.funet.fi (128.214.6.100; look in
  85. directory pub/graphics/programs/jpeg).
  86.  
  87. You can also obtain this software from CompuServe, in the GRAPHSUPPORT forum
  88. (GO PICS), library 10; this version will be file jpsrc3.zip.
  89.  
  90.  
  91. SOFTWARE THAT'S NO HELP AT ALL
  92. ==============================
  93.  
  94. Handmade Software's shareware PC program GIF2JPG produces files that are
  95. totally incompatible with our programs.  They use a proprietary format that is
  96. an amalgam of GIF and JPEG representations.  However, you can force GIF2JPG
  97. to produce compatible files with its -j switch, and their decompression
  98. program JPG2GIF can read our files (at least ones produced with our default
  99. option settings).
  100.  
  101. Unfortunately, many commercial JPEG implementations are also incompatible as
  102. of this writing, especially programs released before summer 1991.  The root of
  103. the problem is that the ISO JPEG committee failed to specify a concrete file
  104. format.  Some vendors "filled in the blanks" on their own, creating
  105. proprietary formats that no one else could read.  (For example, none of the
  106. early commercial JPEG implementations for the Macintosh were able to exchange
  107. compressed files.)
  108.  
  109. The file format we have adopted is called JFIF (see REFERENCES).  This format
  110. has been agreed to by a number of major commercial JPEG vendors, and we expect
  111. that it will become the de facto standard.  JFIF is a minimal representation;
  112. work is also going forward to incorporate JPEG compression into the TIFF
  113. standard, for use in "high end" applications that need to record a lot of
  114. additional data about an image.  We intend to support JPEG-in-TIFF in the
  115. future.  We hope that these two formats will be sufficient and that other,
  116. incompatible JPEG file formats will not proliferate.
  117.  
  118. Indeed, part of the reason for developing and releasing this free software is
  119. to help force rapid convergence to de facto standards for JPEG file formats.
  120. SUPPORT STANDARD, NON-PROPRIETARY FORMATS: demand JFIF or JPEG-in-TIFF!
  121.  
  122.  
  123. REFERENCES
  124. ==========
  125.  
  126. The best and most readily available introduction to the JPEG compression
  127. algorithm is Wallace's article in the April '91 CACM:
  128.         Wallace, Gregory K.  "The JPEG Still Picture Compression Standard",
  129.         Communications of the ACM, April 1991 (vol. 34 no. 4), pp. 30-44.
  130. (Adjacent articles in that issue discuss MPEG motion picture compression,
  131. applications of JPEG, and related topics.)  We highly recommend reading that
  132. article before trying to understand the innards of any JPEG software.
  133. If you don't have the CACM issue handy, a PostScript file containing a revised
  134. version of the article is available at ftp.uu.net, graphics/jpeg/wallace.ps.Z.
  135. The file (actually a preprint for an article to appear in IEEE Trans. Consumer
  136. Electronics) omits the sample images that appeared in CACM, but it includes
  137. corrections and some added material.  Note: the Wallace article is copyright
  138. ACM and IEEE, and it may not be used for commercial purposes.
  139.  
  140. For more detail about the JPEG standard you pretty much have to go to the
  141. draft standard (which is not nearly as intelligible as Wallace's article).
  142. The standard is not now available electronically; you must order a paper copy
  143. through ISO.  In the US, copies may be ordered from ANSI Sales at (212)
  144. 642-4900.  The standard is divided into two parts: Part 1 is the actual
  145. specification, and Part 2 covers compliance testing methods.  The current
  146. "committee draft" version of Part 1 is titled "Digital Compression and Coding
  147. of Continuous-tone Still Images, Part 1: Requirements and guidelines" and has
  148. document number ISO/IEC CD 10918-1.  (The alternate number SC2 N2215 should
  149. also be mentioned when ordering.)  This draft is expected to be superseded by
  150. the Draft International Standard version around the end of November 1991.
  151. Ordering info will be the same as above, but replace "CD" with "DIS" in the
  152. document number (alternate number not yet known).  The committee draft of
  153. Part 2 is expected to be available around the end of December 1991.  It will
  154. be titled "Digital Compression and Coding of Continuous-tone Still Images,
  155. Part 2: Compliance testing" and will have document number ISO/IEC CD 10918-2
  156. (alternate number not yet known).
  157.  
  158. The JPEG standard does not specify all details of an interchangeable file
  159. format.  For the omitted details we follow the "JFIF" conventions, revision
  160. 1.01.  A copy of the JFIF spec is available from:
  161.         Literature Department
  162.         C-Cube Microsystems, Inc.
  163.         399A West Trimble Road
  164.         San Jose, CA  95131
  165.         (408) 944-6300
  166. The same source can supply copies of the draft JPEG-in-TIFF documents
  167. (Appendixes O and P to the TIFF spec).  PostScript versions of these
  168. documents can also be obtained by e-mail from the C-Cube mail server,
  169. netlib@c3.pla.ca.us.  Send the message "send jfif_ps from jpeg" to obtain the
  170. JFIF document; "send app_o_ps from jpeg" and "send app_p_ps from jpeg" will
  171. produce the TIFF documents.  Send the message "help" if you have trouble.
  172.  
  173.  
  174. LEGAL ISSUES
  175. ============
  176.  
  177. The authors make NO WARRANTY or representation, either express or implied,
  178. with respect to this software, its quality, accuracy, merchantability, or
  179. fitness for a particular purpose.  This software is provided "AS IS", and you,
  180. its user, assume the entire risk as to its quality and accuracy.
  181.  
  182. This software is copyright (C) 1991, 1992, Thomas G. Lane.
  183. All Rights Reserved except as specified below.
  184.  
  185. Permission is hereby granted to use, copy, modify, and distribute this
  186. software (or portions thereof) for any purpose, without fee, subject to these
  187. conditions:
  188. (1) If any part of the source code for this software is distributed, then this
  189. README file must be included, with this copyright and no-warranty notice
  190. unaltered; and any additions, deletions, or changes to the original files
  191. must be clearly indicated in accompanying documentation.
  192. (2) If only executable code is distributed, then the accompanying
  193. documentation must state that "this software is based in part on the work of
  194. the Independent JPEG Group".
  195. (3) Permission for use of this software is granted only if the user accepts
  196. full responsibility for any undesirable consequences; the authors accept
  197. NO LIABILITY for damages of any kind.
  198.  
  199. Permission is NOT granted for the use of any author's name or author's company
  200. name in advertising or publicity relating to this software or products derived
  201. from it.  This software may be referred to only as "the Independent JPEG
  202. Group's software".
  203.  
  204. We specifically permit and encourage the use of this software as the basis of
  205. commercial products, provided that all warranty or liability claims are
  206. assumed by the product vendor.
  207.  
  208. It appears that the arithmetic coding option of the JPEG spec is covered by
  209. patents owned by IBM and AT&T, as well as a pending Japanese patent of
  210. Mitsubishi.  Hence arithmetic coding cannot legally be used without obtaining
  211. one or more licenses.  For this reason, support for arithmetic coding has been
  212. removed from the free JPEG software.  (Since arithmetic coding provides only a
  213. marginal gain over the unpatented Huffman mode, it is unlikely that very many
  214. people will choose to use it.  If you do obtain the necessary licenses,
  215. contact jpeg-info@uunet.uu.net for a copy of our arithmetic coding modules.)
  216. So far as we are aware, there are no patent restrictions on the remaining
  217. code.
  218.  
  219.  
  220. We are required to state that
  221.     "The Graphics Interchange Format(c) is the Copyright property of
  222.     CompuServe Incorporated.  GIF(sm) is a Service Mark property of
  223.     CompuServe Incorporated."
  224.  
  225.  
  226. TO DO
  227. =====
  228.  
  229. Many of the modules need fleshing out to provide more complete
  230. implementations, or to provide faster paths for common cases.
  231. Improving the speed will be the next big work item for the JPEG group.
  232.  
  233. We'd appreciate it if people would compile and check out the code on as wide a
  234. variety of systems as possible, and report any portability problems
  235. encountered (with solutions, if possible).  Checks of file compatibility with
  236. other JPEG implementations would also be of interest.  Finally, we would
  237. appreciate code profiles showing where the most time is spent, especially on
  238. unusual systems.
  239.  
  240. Please send bug reports, offers of help, etc. to jpeg-info@uunet.uu.net.
  241.  
  242. USAGE instructions for the Independent JPEG Group's JPEG software
  243. =================================================================
  244.  
  245. GENERAL USAGE
  246.  
  247. We provide two programs, cjpeg to compress an image file into JPEG format,
  248. and djpeg to decompress a JPEG file back into a conventional image format.
  249.  
  250. On Unix-like systems, you say:
  251.         cjpeg [switches] [imagefile] >jpegfile
  252. or
  253.         djpeg [switches] [jpegfile]  >imagefile
  254. The programs read the specified input file, or standard input if none is
  255. named.  They always write to standard output (with trace/error messages to
  256. standard error).  These conventions are handy for piping images between
  257. programs.
  258.  
  259. On most non-Unix systems, you say:
  260.         cjpeg [switches] imagefile jpegfile
  261. or
  262.         djpeg [switches] jpegfile  imagefile
  263. i.e., both the input and output files are named on the command line.  This
  264. style is a little more foolproof, and it loses no functionality if you don't
  265. have pipes.  (You can get this style on Unix too, if you prefer, by defining
  266. TWO_FILE_COMMANDLINE when you compile the programs; see SETUP.)
  267.  
  268. The currently supported image file formats are: PPM (PBMPLUS color format),
  269. PGM (PBMPLUS gray-scale format), GIF and Targa. cjpeg recognizes the input
  270. image format automatically, with the exception of some Targa-format files.  You
  271. have to tell djpeg which format to generate (PPM by default).
  272.  
  273. The only JPEG file format currently supported is the JFIF format.  Support for
  274. the TIFF/JPEG format will probably be added at some future date.
  275.  
  276.  
  277. CJPEG DETAILS
  278.  
  279. The command line switches for cjpeg are:
  280.  
  281.         -Q quality      Scale quantization tables to adjust image quality.
  282.                         Quality is 0 (worst) to 100 (best); default is 75.
  283.                         (See below for more info.)
  284.  
  285.         -o              Perform optimization of entropy encoding parameters.
  286.                         Without this, default encoding parameters are used.
  287.                         -o usually makes the JPEG file a little smaller, but
  288.                         cjpeg runs somewhat slower and needs much more memory.
  289.                         Image quality and speed of decompression are unaffected
  290.                         by -o.
  291.  
  292.         -T              Input file is Targa format.  Targa files that contain
  293.                         an "identification" field will not be automatically
  294.                         recognized by cjpeg; for such files you must specify
  295.                         -T to force cjpeg to treat the input as Targa format.
  296.  
  297.         -I              Generate noninterleaved JPEG file (not yet supported).
  298.  
  299.         -a              Use arithmetic coding rather than Huffman coding.
  300.                         (Not currently supported for legal reasons.)
  301.  
  302.         -d              Enable debug printout.  More -d's give more printout.
  303.                         Also, version information is printed at startup.
  304.  
  305.         -m memory       Set limit for amount of memory to use in processing
  306.                         large images.  Value is in thousands of bytes, or
  307.                         millions of bytes if "M" is attached to the number.
  308.                         For example, -m 4m selects 4000000 bytes.  If more
  309.                         space is needed, temporary files will be used.
  310.  
  311. The -Q switch lets you trade off compressed file size against quality of the
  312. reconstructed image: the higher the -Q setting, the larger the JPEG file, and
  313. the closer the output image will be to the original input.  Normally you want
  314. to use the lowest -Q setting (smallest file) that decompresses into something
  315. visually indistinguishable from the original image.  For this purpose the -Q
  316. setting should be between 50 and 95; the default of 75 is often about right.
  317. If you see defects at -Q 75, then go up 5 or 10 counts at a time until you are
  318. happy with the output image.  (The optimal setting will vary from one image to
  319. another.)
  320.  
  321. -Q 100 will generate a quantization table of all 1's, eliminating loss in the
  322. quantization step (but there is still information loss in subsampling, as well
  323. as roundoff error).  This setting is mainly of interest for experimental
  324. purposes.  -Q values above about 95 are NOT recommended for normal use; the
  325. compressed file size goes up dramatically for hardly any gain in output image
  326. quality.
  327.  
  328. In the other direction, -Q values below 50 will produce very small files of
  329. low image quality.  Settings around 5 to 10 might be useful in preparing an
  330. index of a large image library, for example.  Try -Q 2 (or so) for some
  331. amusing Cubist effects.  (Note: -Q values below about 25 generate 2-byte
  332. quantization tables, which are considered optional in the JPEG standard.
  333. cjpeg emits a warning message when you give such a -Q value, because some
  334. commercial JPEG programs may be unable to decode the resulting file.)
  335.  
  336.  
  337. DJPEG DETAILS
  338.  
  339. The command line switches for djpeg are:
  340.  
  341.         -G              Select GIF output format (implies -q, with default
  342.                         of 256 colors).
  343.  
  344.         -P              Select PPM or PGM output format (this is the default).
  345.                         PGM is emitted if the JPEG file is gray-scale or if -g
  346.                         is specified.
  347.  
  348.         -R              Select RLE output format.  Requires URT library.
  349.  
  350.         -T              Select Targa output format.  Gray-scale format is
  351.                         emitted if the JPEG file is gray-scale or if -g is
  352.                         specified; otherwise, colormapped format is emitted
  353.                         if -q is specified; otherwise, 24-bit full-color
  354.                         format is emitted.
  355.  
  356.         -g              Force gray-scale output even if input is color.
  357.  
  358.         -q N            Quantize to N colors.  This reduces the number of
  359.                         colors in the output image so that it can be displayed
  360.                         on a colormapped display or stored in a colormapped
  361.                         file format.  For example, if you have an 8-bit
  362.                         display, you'd need to quantize to 256 or fewer colors.
  363.  
  364.         -D              Do not use dithering in color quantization.
  365.                         By default, Floyd-Steinberg dithering is applied when
  366.                         quantizing colors, but on some images dithering may
  367.                         result in objectionable "graininess".  If that
  368.                         happens, you can turn off dithering with -D.
  369.                         -D is ignored unless you also say -q or -G.
  370.  
  371.         -1              Use one-pass instead of two-pass color quantization.
  372.                         The one-pass method is faster and needs less memory,
  373.                         but it produces a lower-quality image.
  374.                         -1 is ignored unless you also say -q or -G.  Also,
  375.                         the one-pass method is always used for gray-scale
  376.                         output (the two-pass method is no improvement then).
  377.  
  378.         -b              Perform cross-block smoothing.  This is quite
  379.                         memory-intensive and only seems to improve the image
  380.                         at very low quality settings (-Q 10 to 20 or so).
  381.                         At normal -Q settings it may make the image worse.
  382.  
  383.         -d              Enable debug printout.  More -d's give more printout.
  384.                         Also, version information is printed at startup.
  385.  
  386.         -m memory       Set limit for amount of memory to use in processing
  387.                         large images.  Value is in thousands of bytes, or
  388.                         millions of bytes if "M" is attached to the number.
  389.                         For example, -m 4m selects 4000000 bytes.  If more
  390.                         space is needed, temporary files will be used.
  391.  
  392.  
  393. HINTS
  394.  
  395. Avoid running an image through a series of JPEG compression/decompression
  396. cycles.  Image quality loss will accumulate; after ten or so cycles the image
  397. may be noticeably worse than it was after one cycle.  It's best to use a
  398. lossless format while manipulating an image, then convert to JPEG format when
  399. you are ready to file the image away.
  400.  
  401. The -o option to cjpeg is worth using when you are making a "final" version
  402. for posting or archiving.  It's also a win when you are using low -Q settings
  403. to make very small JPEG files; the percentage improvement is often a lot more
  404. than it is on larger files.
  405.  
  406. The default memory usage limit (-m) is set when the software is compiled.
  407. If you get an "insufficient memory" error, try specifying a smaller -m value,
  408. even -m 0 to use the absolute minimum space.  You may want to recompile with
  409. a smaller default value if this happens often.
  410.  
  411. djpeg with two-pass color quantization requires a good deal of space; on
  412. MS-DOS machines it may run out of memory even with -m 0.  In that case you
  413. can still decompress, with some loss of image quality, by specifying -1
  414. for one-pass quantization.
  415.  
  416. If more space is needed than will fit in the available main memory (as
  417. determined by -m), temporary files will be used.  The temporary files are often
  418. rather large: in typical cases they occupy three bytes per pixel, for example
  419. 3*800*600 = 1.44Mb for an 800x600 image.  If you don't have enough free disk
  420. space, leave out -o (for cjpeg) or specify -1 (for djpeg).
  421.