home *** CD-ROM | disk | FTP | other *** search
/ Der Mediaplex Sampler - Die 6 von Plex / 6_v_plex.zip / 6_v_plex / DISK5 / DOS_26 / NEWS2637.ZIP / NEWS2637.TXT
Text File  |  1993-06-29  |  60KB  |  1,069 lines
  1. Archive-name: jpeg-faq
  2. Last-modified: 28 June 1993
  3.  
  4. This article discusses JPEG image compression.  Suggestions for additions
  5. and clarifications are welcome.
  6.  
  7. New since version of 14 June 1993:
  8.   * Substantial reorganization and rewriting.  Not all that much new info,
  9.     but I hope it's better presented now.
  10.  
  11.  
  12. This article includes the following sections:
  13.  
  14. [1]  What is JPEG?
  15. [2]  Why use JPEG?
  16. [3]  When should I use JPEG, and when should I stick with GIF?
  17. [4]  How well does JPEG compress images?
  18. [5]  What are good "quality" settings for JPEG?
  19. [6]  Where can I get JPEG software?
  20.     [6A] viewers, application programs, etc.
  21.     [6B] source code
  22. [7]  What's all this hoopla about color quantization?
  23. [8]  What are some rules of thumb for converting GIF images to JPEG?
  24. [9]  Does loss accumulate with repeated compression/decompression?
  25. [10]  Why all the argument about file formats?
  26. [11]  How do I recognize which file format I have, and what do I do about it?
  27. [12]  How does JPEG work?
  28. [13]  Isn't there a lossless JPEG?
  29. [14]  What about arithmetic coding?
  30.  
  31. Sections 1-6 are basic info that every JPEG user needs to know;
  32. sections 7-14 are more advanced info.
  33.  
  34. This article is posted every 2 weeks.  You can always find the latest
  35. version in the news.answers archive at rtfm.mit.edu (18.70.0.224).  By FTP,
  36. fetch /pub/usenet/news.answers/jpeg-faq; or if you don't have FTP, send
  37. e-mail to mail-server@rtfm.mit.edu with body
  38.  send usenet/news.answers/jpeg-faq
  39. Many other FAQ articles are also stored in the same archive.  For more
  40. instructions on use of the archive, send mail to the server with the words
  41. "help" and "index" (without quotes) on separate lines.  If you don't get a
  42. reply, the server may be misreading your return address; add a line such as
  43. "path myname@mysite" to specify your correct e-mail address to reply to.
  44.  
  45.  
  46. ----------
  47.  
  48.  
  49. [1]  What is JPEG?
  50.  
  51. JPEG (pronounced "jay-peg") is a standardized image compression mechanism.
  52. JPEG stands for Joint Photographic Experts Group, the original name of the
  53. committee that wrote the standard.
  54.  
  55. JPEG is designed for compressing either full-color or gray-scale images
  56. of natural, real-world scenes.  It works well on photographs, naturalistic
  57. artwork, and similar material; not so well on lettering, simple cartoons,
  58. or line drawings.  JPEG handles only still images, but there is a related
  59. standard called MPEG for motion pictures.
  60.  
  61. JPEG is "lossy," meaning that the decompressed image isn't quite the same as
  62. the one you started with.  (There are lossless image compression algorithms,
  63. but JPEG achieves much greater compression than is possible with lossless
  64. methods.)  JPEG is designed to exploit known limitations of the human eye,
  65. notably the fact that small color details aren't perceived as well as small
  66. details of light-and-dark.  Thus, JPEG is intended for compressing images
  67. that will be looked at by humans.  If you plan to machine-analyze your
  68. images, the small errors introduced by JPEG may be a problem for you, even
  69. if they are invisible to the eye.
  70.  
  71. A useful property of JPEG is that the degree of lossiness can be varied by
  72. adjusting compression parameters.  This means that the image maker can trade
  73. off file size against output image quality.  You can make *extremely* small
  74. files if you don't mind poor quality; this is useful for applications like
  75. indexing image archives.  Conversely, if you aren't happy with the output
  76. quality at the default compression setting, you can jack up the quality
  77. until you are satisfied, and accept lesser compression.
  78.  
  79.  
  80. [2]  Why use JPEG?
  81.  
  82. There are two good reasons: to make your image files smaller, and to store
  83. 24-bit-per-pixel color data instead of 8-bit-per-pixel data.
  84.  
  85. Making image files smaller is a big win for transmitting files across
  86. networks and for archiving libraries of images.  Being able to compress a
  87. 2 Mbyte full-color file down to 100 Kbytes or so makes a big difference in
  88. disk space and transmission time!  (If you are comparing GIF and JPEG, the
  89. size ratio is more like four to one.  More details in section 4.)
  90.  
  91. If your viewing software doesn't support JPEG directly, you'll have to
  92. convert JPEG to some other format for viewing or manipulating images.  Even
  93. with a JPEG-capable viewer, it takes longer to decode and view a JPEG image
  94. than to view an image of a simpler format such as GIF.  Thus, using JPEG is
  95. essentially a time/space tradeoff: you give up some time in order to store
  96. or transmit an image more cheaply.
  97.  
  98. It's worth noting that when network or phone transmission is involved, the
  99. time savings from transferring a shorter file can be greater than the extra
  100. time to decompress the file.
  101.  
  102. The second fundamental advantage of JPEG is that it stores full color
  103. information: 24 bits/pixel (16 million colors).  GIF, the other image format
  104. widely used on Usenet, can only store 8 bits/pixel (256 or fewer colors).
  105. GIF is reasonably well matched to inexpensive computer displays --- most
  106. run-of-the-mill PCs can't display more than 256 distinct colors at once.
  107. But full-color hardware is getting cheaper all the time, and JPEG images
  108. look *much* better than GIFs on such hardware.  Within a couple of years,
  109. 8-bit GIF will seem as obsolete as black-and-white MacPaint format does
  110. today.  Furthermore, for reasons detailed in section 7, JPEG is far more
  111. useful than GIF for exchanging images among people with widely varying
  112. display hardware.  Hence JPEG is considerably more appropriate than GIF for
  113. use as a Usenet posting standard.
  114.  
  115.  
  116. [3]  When should I use JPEG, and when should I stick with GIF?
  117.  
  118. JPEG is *not* going to displace GIF entirely; for some types of images,
  119. GIF is superior in image quality, file size, or both.  One of the first
  120. things to learn about JPEG is which kinds of images to apply it to.
  121.  
  122. Generally speaking, JPEG is superior to GIF for storing full-color or
  123. gray-scale images of "realistic" scenes; that means scanned photographs and
  124. similar material.  Any continuous variation in color, such as occurs in
  125. highlighted or shaded areas, will be represented more faithfully and in less
  126. space by JPEG than by GIF.
  127.  
  128. GIF does significantly better on images with only a few distinct colors,
  129. such as line drawings and simple cartoons.  Not only is GIF lossless for
  130. such images, but it often compresses them more than JPEG can.  For example,
  131. large areas of pixels that are all *exactly* the same color are compressed
  132. very efficiently indeed by GIF.  JPEG can't squeeze such data as much as GIF
  133. does without introducing visible defects.  (One implication of this is that
  134. large single-color borders are quite cheap in GIF files, while they are best
  135. avoided in JPEG files.)
  136.  
  137. Computer-drawn images (ray-traced scenes, for instance) usually fall between
  138. photographs and cartoons in terms of complexity.  The more complex and
  139. subtly rendered the image, the more likely that JPEG will do well on it.
  140. The same goes for semi-realistic artwork (fantasy drawings and such).
  141.  
  142. JPEG has a hard time with very sharp edges: a row of pure-black pixels
  143. adjacent to a row of pure-white pixels, for example.  Sharp edges tend to
  144. come out blurred unless you use a very high quality setting.  Edges this
  145. sharp are rare in scanned photographs, but are fairly common in GIF files:
  146. borders, overlaid text, etc.  The blurriness is particularly objectionable
  147. with text that's only a few pixels high.  If you have a GIF with a lot of
  148. small-size overlaid text, don't JPEG it.
  149.  
  150. Plain black-and-white (two level) images should never be converted to JPEG;
  151. they violate all of the conditions given above.  You need at least about
  152. 16 gray levels before JPEG is useful for gray-scale images.  It should also
  153. be noted that GIF is lossless for gray-scale images of up to 256 levels,
  154. while JPEG is not.
  155.  
  156. If you have a large library of GIF images, you may want to save space by
  157. converting the GIFs to JPEG.  This is trickier than it may seem --- even
  158. when the GIFs contain photographic images, they are actually very poor
  159. source material for JPEG, because the images have been color-reduced.
  160. Non-photographic images should generally be left in GIF form.  Good-quality
  161. photographic GIFs can often be converted with no visible quality loss, but
  162. only if you know what you are doing and you take the time to work on each
  163. image individually.  Otherwise you're likely to lose a lot of image quality
  164. or waste a lot of disk space ... quite possibly both.  Read sections 7 and 8
  165. if you want to convert GIFs to JPEG.
  166.  
  167.  
  168. [4]  How well does JPEG compress images?
  169.  
  170. Very well indeed, when working with its intended type of image (photographs
  171. and suchlike).  For full-color images, the uncompressed data is normally 24
  172. bits/pixel.  The best known lossless compression methods can compress such
  173. data about 2:1 on average.  JPEG can typically achieve 10:1 to 20:1
  174. compression without visible loss, bringing the effective storage requirement
  175. down to 1 to 2 bits/pixel.  30:1 to 50:1 compression is possible with small
  176. to moderate defects, while for very-low-quality purposes such as previews or
  177. archive indexes, 100:1 compression is quite feasible.  An image compressed
  178. 100:1 with JPEG takes up the same space as a full-color one-tenth-scale
  179. thumbnail image, but it retains much more detail than such a thumbnail.
  180.  
  181. For comparison, a GIF version of the same image would start out by
  182. sacrificing most of the color information to reduce the image to 256 colors
  183. (8 bits/pixel).  This provides 3:1 compression.  GIF has additional "LZW"
  184. compression built in, but LZW doesn't work very well on typical photographic
  185. data; at most you may get 5:1 compression overall, and it's not at all
  186. uncommon for LZW to be a net loss (less than 3:1 overall compression).
  187. When a JPEG file is made from full-color data, using a quality setting just
  188. high enough to prevent visible loss, the JPEG will typically be a factor of
  189. four or five smaller than a GIF file made from the same data.
  190.  
  191. Gray-scale images do not compress by such large factors.  Because the human
  192. eye is much more sensitive to brightness variations than to hue variations,
  193. JPEG can compress hue data more heavily than brightness (gray-scale) data.
  194. A gray-scale JPEG file is generally only about 10%-25% smaller than a
  195. full-color JPEG file of similar visual quality.  But the uncompressed
  196. gray-scale data is only 8 bits/pixel, or one-third the size of the color
  197. data, so the calculated compression ratio is much lower.  The threshold of
  198. visible loss is often around 5:1 compression for gray-scale images.
  199.  
  200. The exact threshold at which errors become visible depends on your viewing
  201. conditions.  The smaller an individual pixel, the harder it is to see an
  202. error; so errors are more visible on a computer screen (at maybe 70
  203. dots/inch) than on a high-quality color printout (300 or more dots/inch).
  204. Thus a higher-resolution image can tolerate more compression ... which is
  205. fortunate considering it's much bigger to start with.  The numbers quoted
  206. above are typical for screen viewing.  Also note that the threshold of
  207. visible error varies somewhat across images.
  208.  
  209.  
  210. [5]  What are good "quality" settings for JPEG?
  211.  
  212. Most JPEG compressors let you pick a file size vs. image quality tradeoff by
  213. selecting a quality setting.  There seems to be widespread confusion about
  214. the meaning of these settings.  "Quality 95" does NOT mean "keep 95% of the
  215. information", as some have claimed.  The quality scale is purely arbitrary;
  216. it's not a percentage of anything.
  217.  
  218. In fact, quality scales aren't even standardized across JPEG programs.  The
  219. quality settings discussed in this article apply to the free JPEG software
  220. described in section 6B, and to many programs based on it.  Other JPEG
  221. implementations, notably Apple's and HSI's, use completely different quality
  222. scales; for instance, Apple's scale covers 0-4, not 0-100.  Some programs
  223. don't even provide a numeric scale, just "high"/"medium"/"low"-style
  224. choices.  (Fortunately, this doesn't prevent different implementations from
  225. exchanging compressed files.)
  226.  
  227. In most cases the user's goal is to pick the lowest quality setting, or
  228. smallest file size, that decompresses into an image indistinguishable from
  229. the original.  This setting will vary from one image to another and from one
  230. observer to another, but here are some rules of thumb.
  231.  
  232. For good-quality, full-color source images, the default quality setting
  233. (Q 75) is very often the best choice.  This setting is about the lowest you
  234. can go without expecting to see defects in a typical image.  Try Q 75 first;
  235. if you see defects, then go up.
  236.  
  237. If the image was less than perfect quality to begin with, you might be able
  238. to drop down to Q 50 without objectionable degradation.  On the other hand,
  239. you might need to go to a *higher* quality setting to avoid further loss.
  240. Q 85 to 95 is often best for converting GIFs (see section 8 for more info).
  241.  
  242. Except for experimental purposes, never go above about Q 95; using Q 100
  243. will produce a file two or three times as large as Q 95, but of hardly any
  244. better quality.  If you see a file made with Q 100, it's a pretty sure sign
  245. that the maker didn't know what he/she was doing.
  246.  
  247. If you want a very small file (say for preview or indexing purposes) and are
  248. prepared to tolerate large defects, a Q setting in the range of 5 to 10 is
  249. about right.  Q 2 or so may be amusing as "op art".
  250.  
  251.  
  252. [6]  Where can I get JPEG software?
  253.  
  254. Most of the programs described in this section are available by FTP.
  255. If you don't know how to use FTP, see the FAQ article "How to find sources".
  256. (If you don't have direct access to FTP, read about ftpmail servers in the
  257. same article.)  That article appears regularly in news.answers, or you can
  258. get it by sending e-mail to mail-server@rtfm.mit.edu with
  259. "send usenet/news.answers/finding-sources" in the body.  The "Anonymous FTP
  260. List FAQ" may also be helpful --- it's usenet/news.answers/ftp-list/faq in
  261. the news.answers archive.
  262.  
  263. NOTE: this list changes frequently.  If you have a copy more than a couple
  264. months old, get the latest JPEG FAQ from the news.answers archive.
  265.  
  266.  
  267. [6A]  If you are looking for viewers, application programs, etc:
  268.  
  269. This section covers programs for the following kinds of systems:
  270.  X Windows, MS-DOS, Microsoft Windows, OS/2, Macintosh,
  271.  Amiga, Atari ST, Acorn Archimedes, NeXT.
  272. If you don't see what you want for your machine, check out the free JPEG
  273. source code described in section 6B.  Assuming you have a C compiler and at
  274. least a little knowledge of compiling C programs, you should be able to
  275. prepare JPEG conversion programs from the source code.  You'll also need a
  276. viewer program.  If your display is 8 bits or less, any GIF viewer will do
  277. fine; if you have a display with more color capability, try to find a viewer
  278. that can read Targa or PPM 24-bit image files.
  279.  
  280. Note that this list concentrates on free and shareware programs that you can
  281. obtain over Internet; but some commercial programs are listed too.  If you
  282. choose a commercial JPEG product, make sure that it can handle the Usenet-
  283. standard JFIF file format, or you won't be able to exchange images with
  284. anyone else.  (See section 10 if you want to know more about file formats.)
  285.  
  286.  
  287. X Windows:
  288.  
  289. XV (shareware, $25) is an excellent viewer for JPEG, GIF, and many other
  290. image formats.  It can also do format conversion and some simple image
  291. manipulations.  It's available for FTP from export.lcs.mit.edu (18.24.0.12),
  292. file contrib/xv-3.00.tar.Z.  Version 3.00 is a major upgrade with support
  293. for 24-bit displays and many other improvements; however, it is brand new
  294. and still has some bugs lurking.  If you prefer not to be on the bleeding
  295. edge, stick with version 2.21, also available from export.  Note that
  296. version 2.21 is not a good choice if you have a 24-bit display (you'll get
  297. only 8-bit color), nor is it good for converting 24-bit images to JPEG.
  298. But 2.21 works fine for converting GIF and other 8-bit images to JPEG.
  299. CAUTION: with version 2.21, be sure to check the "save at normal size"
  300. checkbox when saving a JPEG file, or the file will be blurry.
  301.  
  302. Another good choice for X Windows is John Cristy's free ImageMagick package,
  303. also available from export.lcs.mit.edu, file contrib/ImageMagick.tar.Z.
  304. This package handles many image processing and conversion tasks.  The
  305. ImageMagick viewer handles 24-bit displays correctly; for colormapped
  306. displays, it does better (though slower) color quantization than XV or the
  307. basic free JPEG software.  The current version is 2.3.2.
  308.  
  309. Both of the above are large, complex packages.  If you just want a simple
  310. image viewer, try xloadimage or xli.  xloadimage supports JPEG in its latest
  311. release, 3.03.  xloadimage is free and available from export.lcs.mit.edu,
  312. file contrib/xloadimage-3.03.tar.Z.  xli is a variant version of xloadimage,
  313. said by its fans to be somewhat faster and more robust than the original.
  314. (The current xli is indeed faster and more robust than the current
  315. xloadimage with respect to JPEG files, because it uses the v4 IJG decoder
  316. while xloadimage 3.03 is still using a hacked-over v1.  The next xloadimage
  317. release will fix this.)  xli is also free and available from
  318. export.lcs.mit.edu, file contrib/xli.1.14.tar.Z.  Both programs are said to
  319. do the right thing with 24-bit displays.
  320.  
  321. MS-DOS:
  322.  
  323. This covers plain DOS; for Windows or OS/2 programs, see the next headings.
  324.  
  325. One good choice is Eric Praetzel's free DVPEG, which views JPEG and GIF files.
  326. The current version, 2.5, is available by FTP from sunee.uwaterloo.ca
  327. (129.97.50.50), file pub/jpeg/viewers/dvpeg25.zip.  This is a good basic
  328. viewer that works on either 286 or 386/486 machines.  The user interface is
  329. not flashy, but it's functional.
  330.  
  331. Another freeware JPEG/GIF/TGA viewer is Mohammad Rezaei's Hiview.  The
  332. current version, 1.2, is available from Simtel20 and mirror sites (see NOTE
  333. below), file msdos/graphics/hv12.zip.  Hiview requires a 386 or better CPU
  334. and a VCPI-compatible memory manager (QEMM386 and 386MAX work; Windows and
  335. OS/2 do not).  Hiview is currently the fastest DOS viewer for images that
  336. are no bigger than your screen.  For larger images, it scales the image down
  337. to fit on the screen (rather than using panning/scrolling as most viewers
  338. do).  You may or may not prefer this approach, but there's no denying that
  339. it slows down loading of large images considerably.  Note: installation is a
  340. bit tricky; read the directions carefully!
  341.  
  342. A shareware alternative is ColorView for DOS ($30).  This is easier to
  343. install than either of the two freeware alternatives.  Its user interface is
  344. also much spiffier-looking, although personally I find it harder to use ---
  345. more keystrokes, inconsistent behavior.  It is faster than DVPEG but a
  346. little slower than Hiview, at least on my hardware.  (For images larger than
  347. screen size, DVPEG and ColorView seem to be about the same speed, and both
  348. are faster than Hiview.)  The current version is 2.1, available from
  349. Simtel20 and mirror sites (see NOTE below), file msdos/graphics/dcview21.zip.
  350. Requires a VESA graphics driver; if you don't have one, look in vesadrv2.zip
  351. or vesa-tsr.zip from the same directory.  (Some recent PCs have a built-in
  352. VESA driver, so don't try to load a VESA driver unless ColorView complains
  353. that the driver is missing.)
  354.  
  355. A second shareware alternative is Fullview, which has been kicking around
  356. the net for a while, but I don't know any stable archive location for it.
  357. The current (rather old) version is inferior to the above viewers anyway.
  358. The author tells me that a new version of Fullview will be out shortly
  359. and it will be submitted to the Simtel20 archives at that time.
  360.  
  361. The well-known GIF viewer CompuShow (CSHOW) supports JPEG in its latest
  362. revision, 8.60a.  However, CSHOW's JPEG implementation isn't very good:
  363. it's slow (about half the speed of the above viewers) and image quality is
  364. poor except on hi-color displays.  Too bad ... it'd have been nice to see a
  365. good JPEG capability in CSHOW.  Shareware, $25.  Available from Simtel20 and
  366. mirror sites (see NOTE below), file msdos/gif/cshw860a.zip.
  367.  
  368. Due to the remarkable variety of PC graphics hardware, any one of these
  369. viewers might not work on your particular machine.  If you can't get *any*
  370. of them to work, you'll need to use one of the following conversion programs
  371. to convert JPEG to GIF, then view with your favorite GIF viewer.  (If you
  372. have hi-color hardware, don't use GIF as the intermediate format; try to
  373. find a TARGA-capable viewer instead.  VPIC5.0 is reputed to do the right
  374. thing with hi-color displays.)
  375.  
  376. The Independent JPEG Group's free JPEG converters are available from
  377. Simtel20 and mirror sites (see NOTE below), file msdos/graphics/jpeg4.zip
  378. (or jpeg4386.zip if you have a 386 and extended memory).  These files are
  379. DOS compilations of the free source code described in section 6B; they will
  380. convert JPEG to and from GIF, Targa, and PPM formats.
  381.  
  382. Handmade Software offers free JPEG<=>GIF conversion tools, GIF2JPG/JPG2GIF.
  383. These are slow and are limited to conversion to and from GIF format; in
  384. particular, you can't get 24-bit color output from a JPEG.  The major
  385. advantage of these tools is that they will read and write HSI's proprietary
  386. JPEG format as well as the Usenet-standard JFIF format.  Since HSI-format
  387. files are rather widespread on BBSes, this is a useful capability.  Version
  388. 2.0 of these tools is free (prior versions were shareware).  Get it from
  389. Simtel20 and mirror sites (see NOTE below), file msdos/graphics/gif2jpg2.zip.
  390. NOTE: do not use HSI format for files to be posted on Usenet, since it is
  391. not readable on non-PC platforms.
  392.  
  393. Handmade Software also has a shareware image conversion and manipulation
  394. package, Image Alchemy.  This will translate JPEG files (both JFIF and HSI
  395. formats) to and from many other image formats.  It can also display images.
  396. A demo version of Image Alchemy version 1.6.2 is available from Simtel20 and
  397. mirror sites (see NOTE below), file msdos/graphics/alch162.zip.
  398.  
  399. JPGINDEX is a useful tool for making indexes of JPEG image collections.
  400. Available from Simtel20 and mirror sites, file msdos/graphics/jpgidx13.zip.
  401.  
  402. NOTE ABOUT SIMTEL20: The Internet's key archive site for PC-related programs
  403. is Simtel20, full name wsmr-simtel20.army.mil (192.88.110.20).  Simtel20
  404. runs a non-Unix system with weird directory names; where this document
  405. refers to directory (eg) "msdos/graphics" at Simtel20, that really means
  406. "pd1:<msdos.graphics>".  If you are not physically on MILnet, you should
  407. expect rather slow FTP transfer rates from Simtel20.  There are several
  408. Internet sites that maintain copies (mirrors) of the Simtel20 archives;
  409. most FTP users should go to one of the mirror sites instead.  A popular USA
  410. mirror site is oak.oakland.edu (141.210.10.117), which keeps Simtel20 files
  411. in (eg) "/pub/msdos/graphics".  If you have no FTP capability, you can
  412. retrieve files from Simtel20 by e-mail; see informational postings in
  413. comp.archives.msdos.announce to find out how.  If you are outside the USA,
  414. consult the same newsgroup to learn where your nearest Simtel20 mirror is.
  415.  
  416. Microsoft Windows:
  417.  
  418. Windows viewers are slower than comparable DOS viewers on the same hardware,
  419. due to Windows' system overhead.
  420.  
  421. The newest entry is WinECJ, which is free and EXTREMELY fast.  Version 1.1
  422. is available from Simtel20 and mirror sites (see NOTE above), file
  423. msdos/windows3/winecj11.zip.  Requires Windows 3.1 and 256-or-more-colors
  424. mode.  This is a no-frills viewer with image quality noticeably worse than
  425. most other JPEG viewers.  But it's so fast you'll use it anyway, at least
  426. for previewing.  (Image quality is not a problem if you have a 24-bit
  427. display.  Also, you can purchase a version with better 8-bit image quality
  428. for AUD$30.)
  429.  
  430. JView is freeware, has good on-line help, and can write out the decompressed
  431. image in Windows BMP format; but it's not fast by current standards, and it
  432. doesn't view GIFs.  JView also lacks some other useful features such as
  433. brightness adjustment, but it's still a good basic viewer.  The current
  434. version, 0.9, is available from ftp.cica.indiana.edu (129.79.20.84), file
  435. pub/pc/win3/desktop/jview090.zip.  (Mirrors of this archive can be found at
  436. some other Internet sites, including wuarchive.wustl.edu.)
  437.  
  438. WinJPEG (shareware, $20) displays JPEG,GIF,Targa,TIFF,PCX, and BMP files;
  439. it can write all of these formats too, so it can be used as a converter.
  440. It has some other nifty features including color-balance adjustment and
  441. slideshow.  The current version is 2.2, available from Simtel20 and mirror
  442. sites (see NOTE above), file msdos/windows3/winjp220.zip.  (This is a
  443. 286-compatible version; if you register, you'll get the 386-only version,
  444. which is roughly 25% faster.)
  445.  
  446. ColorView is another shareware entry ($30).  This was an early and promising
  447. contender, but it has not been updated in some time, and at this point it
  448. has no notable advantages over WinJPEG.  If you want to try it anyway, the
  449. current version is 0.97, available from ftp.cica.indiana.edu, file
  450. pub/pc/win3/desktop/cview097.zip.  (I understand that a new version will be
  451. appearing once the authors are finished with ColorView for DOS.)
  452.  
  453. DVPEG (see DOS heading) works under Windows, but only in full-screen mode,
  454. not in a window.  Also note that you can run the DOS conversion programs
  455. described above inside a Windows DOS window.
  456.  
  457. OS/2:
  458.  
  459. The following files are available from hobbes.nmsu.edu (128.123.35.151).
  460. Note: check /pub/uploads for more recent versions --- the hobbes moderator
  461. is not very fast about moving uploads into their permanent directories.
  462.  
  463. /pub/os2/2.x/graphics/jpegv4.zip
  464.     32-bit version of free IJG conversion programs, version 4.
  465. /pub/os2/all/graphics/jpeg4-16.zip
  466.     16-bit version of same, for OS/2 1.x.
  467. /pub/os2/2.x/graphics/imgarc13.zip
  468.     Image Archiver 1.03: image conversion/viewing with PM graphical interface.
  469.     Strong on conversion functions, viewing is a bit weaker.  Shareware, $15.
  470. /pub/os2/2.x/graphics/pmjpeg13.zip
  471.     PMJPEG 1.3: OS/2 2.x port of WinJPEG, a popular viewer for Windows
  472.     (see description in Windows section).  Shareware, $20.
  473. /pub/os2/2.x/graphics/pmview85.zip
  474.     PMView 0.85: JPEG/GIF/BMP/Targa/PCX viewer.  GIF viewing very fast,
  475.     JPEG viewing roughly the same speed as the above two programs.  Has
  476.     image manipulation & slideshow functions.  Shareware, $20.
  477.  
  478. Also worth trying is JoeView, a free JPEG/GIF/BMP viewer.  Version 1.1f is
  479. available from bill_the_cat.nosc.mil (128.49.60.4), file joeview.zip.
  480.  
  481. Macintosh:
  482.  
  483. Most Mac JPEG programs rely on Apple's JPEG implementation, which is part of
  484. the QuickTime system extension; so you need to have QuickTime installed.
  485. To use QuickTime, you need a 68020 or better CPU and you need to be running
  486. System 6.0.7 or later.  (If you're running System 6, you must also install
  487. the 32-bit QuickDraw extension; this is built-in on System 7.)  The latest
  488. version of QuickTime is 1.6, available by FTP from ftp.apple.com, file
  489. dts/mac/sys.soft/quicktime/quicktime.hqx (get the other files in that
  490. directory too!).  Quite a few compatibility problems have been reported with
  491. 1.6, so don't trash your copy of 1.5 until you've checked it out...
  492.  
  493. Mac users should keep in mind that QuickTime's JPEG format, PICT/JPEG, is
  494. not the same as the Usenet-standard JFIF JPEG format.  (See section 10 for
  495. details.)  If you post images on Usenet, make sure they are in JFIF format.
  496. Most of the programs mentioned here can handle either format.
  497.  
  498. The first choice is probably JPEGView, a free program for viewing images
  499. that are in JFIF format, PICT/JPEG format, or GIF format.  It also can
  500. convert between the two JPEG formats.  The current version is 2.0, available
  501. from sumex-aim.stanford.edu (36.44.0.6), file info-mac/app/jpeg-view-20.hqx.
  502. Requires System 7 and QuickTime.  On 8-bit displays, JPEGView usually
  503. produces the best color image quality of all the currently available Mac
  504. JPEG viewers.  JPEGView can view large images in much less memory than other
  505. Mac viewers; in fact, it's the only one that can deal with JPEG images much
  506. over 640x480 pixels on a typical 4MB Mac.  Given a large image, JPEGView
  507. automatically scales it down to fit on the screen, rather than presenting
  508. scroll bars like most other viewers.  (You can zoom in on any desired
  509. portion, though.)  Some people like this behavior, some don't.  Overall,
  510. JPEGView's user interface is very well thought out.
  511.  
  512. GIFConverter, a shareware ($40) image viewer/converter, supports JFIF and
  513. PICT/JPEG, as well as GIF and several other image formats.  The latest
  514. version is 2.3.2.  Get it from sumex-aim.stanford.edu, file
  515. /info-mac/art/gif/gif-converter-232.hqx.  Requires System 6.0.5 or later.
  516. GIFConverter is not better than JPEGView as a plain JPEG/GIF viewer, but
  517. it has much more extensive image manipulation and format conversion
  518. capabilities, so you may find it worth its shareware fee if you do a lot of
  519. playing around with images.  Also, the newest version of GIFConverter can
  520. load and save JFIF images *without* QuickTime, so it is your best bet if
  521. your machine is too old to run QuickTime.  (But it's faster with QuickTime.)
  522. Note: If GIFConverter runs out of memory trying to load a large JPEG, try
  523. converting the file to GIF with JPEG Convert, then viewing the GIF version.
  524.  
  525. JPEG Convert, a Mac version of the free IJG JPEG conversion utilities, is
  526. available from sumex-aim.stanford.edu, file info-mac/app/jpeg-convert-10.hqx.
  527. This will run on any Mac, but it only does file conversion, not viewing.
  528. You can use it in conjunction with any GIF viewer.
  529.  
  530. Previous versions of this FAQ recommended Imagery JPEG v0.6, a JPEG<=>GIF
  531. converter based on an old version of the IJG code.  If you are using this
  532. program, you definitely should replace it with JPEG Convert.
  533.  
  534. Apple has a free but unsupported program called PictPixie, which can view
  535. images in JFIF, PICT/JPEG, and GIF formats, and can convert between these
  536. formats.  Unfortunately PictPixie doesn't work with QuickTime 1.6, and it
  537. has a bunch of other drawbacks as well.  If you want it, you can get it from
  538. ftp.apple.com, file dts/mac/quicktime/qt.1.0.stuff/pictpixie.hqx.  (There is
  539. an old version of PictPixie, called PICTCompressor, floating around the net.
  540. If you have this you should trash it and get something less buggy.  Also,
  541. the QuickTime Starter Kit includes a much cleaned-up descendant of PictPixie
  542. called Picture Compressor.  Note that Picture Compressor is NOT free.)
  543.  
  544. Storm Technology's Picture Decompress is a free JPEG viewer/converter.
  545. This rather old program is inferior to the above programs in many ways, but
  546. it will run without System 7 or QuickTime, so you may be forced to use it on
  547. older systems.  (It does need 32-bit QuickDraw, so really old machines can't
  548. use it.)  You can get it from sumex-aim.stanford.edu, file
  549. info-mac/app/picture-decompress-201.hqx.  You must set the file type of a
  550. downloaded image file to 'JPEG' to allow Picture Decompress to open it.
  551.  
  552. If your machine is too old to run 32-bit QuickDraw (a Mac Plus for instance),
  553. GIFConverter is your only choice for single-program JPEG viewing.  If you
  554. don't want to pay for GIFConverter, use JPEG Convert and a free GIF viewer.
  555.  
  556. More and more commercial Mac applications are supporting JPEG, although not
  557. all can deal with the Usenet-standard JFIF format.  Adobe Photoshop, version
  558. 2.0.1 or later, can read and write JFIF-format JPEG files (use the JPEG
  559. plug-in from the Acquire menu).  You must set the file type of a downloaded
  560. JPEG file to 'JPEG' to allow Photoshop to recognize it.
  561.  
  562. Amiga:
  563.  
  564. Most programs listed in this section are stored in the AmiNet archive at
  565. amiga.physik.unizh.ch (130.60.80.80).  There are many mirror sites of this
  566. archive and you should try to use the closest one.  In the USA, a good
  567. choice is wuarchive.wustl.edu; look under /mirrors/amiga.physik.unizh.ch/...
  568.  
  569. HamLab Plus is an excellent JPEG viewer/converter, as well as being a
  570. general image manipulation tool.  It's cheap (shareware, $20) and can read
  571. several formats besides JPEG.  The current version is 2.0.8.  A demo version
  572. is available from amiga.physik.unizh.ch (and mirror sites), file
  573. amiga/gfx/edit/hamlab208d.lha.  The demo version will crop images larger
  574. than 512x512, but it is otherwise fully functional.
  575.  
  576. Rend24 (shareware, $30) is an image renderer that can display JPEG, ILBM,
  577. and GIF images.  The program can be used to create animations, even
  578. capturing frames on-the-fly from rendering packages like Lightwave.  The
  579. current version is 1.05, available from amiga.physik.unizh.ch (and mirror
  580. sites), file amiga/os30/gfx/rend105.lha.  (Note: although this directory is
  581. supposedly for AmigaDOS 3.0 programs, the program will also run under
  582. AmigaDOS 1.3, 2.04 or 2.1.)
  583.  
  584. Viewtek is a free JPEG/ILBM/GIF/ANIM viewer.  The current version is 1.04,
  585. available from amiga.physik.unizh.ch (and mirror sites), file
  586. amiga/gfx/show/ViewTek104.lha.
  587.  
  588. If you're willing to spend real money, there are several commercial packages
  589. that support JPEG.  Two are written by Thomas Krehbiel, the author of Rend24
  590. and Viewtek.  These are CineMorph, a standalone image morphing package, and
  591. ImageFX, an impressive 24-bit image capture, conversion, editing, painting,
  592. effects and prepress package that also includes CineMorph.  Both are
  593. distributed by Great Valley Products.  Art Department Professional (ADPro),
  594. from ASDG Inc, is the most widely used commercial image manipulation
  595. software for Amigas.  ImageMaster, from Black Belt Systems, is another
  596. well-regarded commercial graphics package with JPEG support.
  597.  
  598. The free IJG JPEG software is available compiled for Amigas from
  599. amiga.physik.unizh.ch (and mirror sites) in directory amiga/gfx/conv, file
  600. AmigaJPEGV4.lha.  These programs convert JPEG to/from PPM,GIF,Targa formats.
  601.  
  602. The Amiga world is heavily infested with quick-and-dirty JPEG programs, many
  603. based on an ancient beta-test version of the free IJG JPEG software (thanks
  604. to a certain magazine that published same on its disk-of-the-month, without
  605. so much as notifying the authors).  Among these are "AugJPEG", "NewAmyJPEG",
  606. "VJPEG", and probably others I have not even heard of.  In my opinion,
  607. anything older than IJG version 3 (March 1992) is not worth the disk space
  608. it's stored on; if you have such a program, trash it and get something newer.
  609.  
  610. Atari ST:
  611.  
  612. The free IJG JPEG software is available compiled for Atari ST, TT, etc,
  613. from atari.archive.umich.edu, file /atari/Graphics/jpeg4bin.zoo.
  614. These programs convert JPEG to/from PPM, GIF, Targa formats.
  615.  
  616. For monochrome ST monitors, try MGIF, which manages to achieve four-level
  617. gray-scale effect by flickering.  Version 4.1 reads JPEG files.  Available
  618. from atari.archive.umich.edu, file /atari/Graphics/mgif41b.zoo.
  619.  
  620. I have not heard of any other free or shareware JPEG-capable viewers for
  621. Ataris, but surely there must be some by now?  Pointers appreciated.
  622.  
  623. Acorn Archimedes:
  624.  
  625. !ChangeFSI, supplied with RISC OS 3 version 3.10, can convert from and view
  626. JPEG JFIF format.  Provision is also made to convert images to JPEG,
  627. although this must be done from the CLI rather than by double-clicking.
  628.  
  629. Recent versions (since 7.11) of the shareware program Translator can handle
  630. JPEG, along with about 30 other image formats.  While older versions can be
  631. found on some Archimedes bboards, the current version is only available by
  632. registering with the author, John Kortink, Nutterbrink 31, 7544 WJ, Enschede,
  633. The Netherlands.  Price 35 Dutch guilders (about $22 or 10 pounds).
  634.  
  635. There's also a commercial product called !JPEG which provides JPEG read/write
  636. functionality and direct JPEG viewing, as well as a host of other image
  637. format conversion and processing options.  This is more expensive but not
  638. necessarily better than the above programs.  Contact: DT Software, FREEPOST,
  639. Cambridge, UK.  Tel: 0223 841099.
  640.  
  641. NeXT:
  642.  
  643. ImageViewer is a PD utility that displays images and can do some format
  644. conversions.  The current version reads JPEG but does not write it.
  645. ImageViewer is available from the standard NeXT archives at
  646. sonata.cc.purdue.edu and cs.orst.edu, somewhere in /pub/next (both are
  647. currently being re-organized, so it's hard to point to specific
  648. sub-directories).  Note that there is an older version floating around that
  649. does not support JPEG.
  650.  
  651. NeXTStep includes built-in support for TIFF/JPEG, but not for the
  652. Usenet-standard JFIF format.
  653.  
  654.  
  655. [6B]  If you are looking for source code to work with:
  656.  
  657. Free, portable C code for JPEG compression is available from the Independent
  658. JPEG Group, which I lead.  A package containing our source code,
  659. documentation, and some small test files is available from ftp.uu.net
  660. (192.48.96.9) in directory /graphics/jpeg.  The current release is v4, file
  661. jpegsrc.v4.tar.Z.  (This is a compressed TAR file; don't forget to retrieve
  662. in binary mode.)  You can retrieve this file by FTP or UUCP.  Copies can
  663. also be found at many other Internet sites.  If you are on a PC and don't
  664. know how to cope with .tar.Z format, you may prefer ZIP format, which you
  665. can find at Simtel20 and mirror sites (see NOTE above), file
  666. msdos/graphics/jpegsrc4.zip.  This file is also available on CompuServe, in
  667. the GRAPHSUPPORT forum (GO PICS), library 15, as jpsrc4.zip.  If you have no
  668. FTP access, you can retrieve the source from your nearest comp.sources.misc
  669. archive; version 4 appeared as issues 55-72 of volume 34.  (If you don't
  670. know how to retrieve comp.sources.misc postings, see the FAQ article "How to
  671. find sources", referred to at the top of section 6.)
  672.  
  673. The free JPEG code provides conversion between JPEG "JFIF" format and image
  674. files in GIF, PBMPLUS PPM/PGM, Utah RLE, and Truevision Targa file formats.
  675. The core compression and decompression modules can easily be reused in other
  676. programs, such as image viewers.  The package is highly portable; we have
  677. tested it on many machines ranging from PCs to Crays.
  678.  
  679. We have released this software for both noncommercial and commercial use.
  680. Companies are welcome to use it as the basis for JPEG-related products.
  681. We do not ask a royalty, although we do ask for an acknowledgement in
  682. product literature (see the README file in the distribution for details).
  683. We hope to make this software industrial-quality --- although, as with
  684. anything that's free, we offer no warranty and accept no liability.
  685.  
  686. The Independent JPEG Group is a volunteer organization; if you'd like to
  687. contribute to improving our software, you are welcome to join.
  688.  
  689.  
  690. [7]  What's all this hoopla about color quantization?
  691.  
  692. Most people don't have full-color (24 bit per pixel) display hardware.
  693. Typical display hardware stores 8 or fewer bits per pixel, so it can display
  694. 256 or fewer distinct colors at a time.  To display a full-color image, the
  695. computer must choose an appropriate set of representative colors and map the
  696. image into these colors.  This process is called "color quantization".
  697. (This is something of a misnomer; "color selection" or "color reduction"
  698. would be a better term.  We're stuck with the standard usage though.)
  699.  
  700. Clearly, color quantization is a lossy process.  It turns out that for most
  701. images, the details of the color quantization algorithm have *much* more
  702. impact on the final image quality than do any errors introduced by JPEG
  703. itself (except at the very lowest JPEG quality settings).  Making a good
  704. color quantization algorithm is a black art, and no single algorithm is best
  705. for all images.
  706.  
  707. Since JPEG is a full-color format, converting a color JPEG image for display
  708. on 8-bit-or-less hardware requires color quantization.  The speed and image
  709. quality of a JPEG viewer running on such hardware are largely determined by
  710. its quantization algorithm.  You'll see great variation in image quality
  711. among viewers on 8-bit displays, much more than occurs on 24-bit displays.
  712.  
  713. On the other hand, a GIF image has already been quantized to 256 or fewer
  714. colors.  (A GIF *does* have a specific number of colors in its palette, and
  715. the format doesn't allow more than 256 palette entries.)  GIF has the
  716. advantage that the image maker precomputes the color quantization, so
  717. viewers don't have to; this is one of the things that make GIF viewers
  718. faster than JPEG viewers.  But this is also the *disadvantage* of GIF:
  719. you're stuck with the maker's quantization.  If the maker quantized to a
  720. different number of colors than what you can display, you'll either waste
  721. display capability or have to quantize again to further reduce the number of
  722. colors (which results in much poorer image quality than if you had quantized
  723. once from a full-color image).  Furthermore, if the maker didn't use a
  724. high-quality color quantization algorithm, you're out of luck --- the image
  725. is ruined.
  726.  
  727. For this reason, JPEG promises significantly better image quality than GIF
  728. for all users whose machines don't match the image maker's display hardware.
  729. JPEG's full color image can be quantized to precisely match the viewer's
  730. display hardware.  Furthermore, you will be able to take advantage of future
  731. improvements in quantization algorithms (there is a lot of active research
  732. in this area), or purchase better display hardware, to get a better view of
  733. JPEG images you already have.  With a GIF, you're stuck forevermore with
  734. what was sent.
  735.  
  736. A growing number of people have better-than-8-bit display hardware already:
  737. 15-bit "hi-color" PC displays, true 24-bit displays on workstations and
  738. Macintoshes, etc.  For these people, GIF is already obsolete, as it cannot
  739. represent an image to the full capabilities of their display.  JPEG images
  740. can drive these displays much more effectively.
  741.  
  742. In short, JPEG is an all-around better choice than GIF for representing
  743. images in a machine-independent fashion.
  744.  
  745.  
  746. It's sometimes thought that a JPEG converted from a GIF shouldn't require
  747. color quantization.  This is false: even when you feed a 256-or-less-color
  748. GIF into JPEG, what comes out of the decompressor is not 256 colors, but
  749. thousands of colors.  This happens because JPEG's lossiness affects each
  750. pixel a little differently, so two pixels that started with identical colors
  751. will usually come out with slightly different colors.  Each original color
  752. gets "smeared" into a group of nearby colors.  Therefore quantization is
  753. always required to display a color JPEG on a colormapped display, regardless
  754. of the image source.
  755.  
  756. The same effect makes it nearly meaningless to talk about the number of
  757. colors used by a JPEG image.  Even if you were to count the number of
  758. distinct pixel values, different JPEG decoders would give you different
  759. results because of roundoff error differences.  I occasionally see posted
  760. images described as "256-color JPEG".  This tells me that the poster
  761. (a) hasn't read this FAQ and (b) probably converted the JPEG from a GIF.
  762. JPEGs can be classified as color or gray-scale, but number of colors just
  763. isn't a useful concept for JPEG, any more than it is for a real photograph.
  764.  
  765.  
  766. [8]  What are some rules of thumb for converting GIF images to JPEG?
  767.  
  768. Converting GIF files to JPEG is a tricky business --- you are piling one set
  769. of limitations atop a quite different set, and the results can be awful.
  770. Certainly a JPEG made from a GIF will never be as good as a JPEG made from
  771. true 24-bit color data.  But if what you've got is GIFs, and you need to
  772. save space, here are some hints for getting the best results.
  773.  
  774. With care and a clean source image, it's often possible to make a JPEG of
  775. quality equivalent to the GIF.  This does *not* mean that the JPEG looks
  776. identical to the GIF --- it probably won't on an 8-bit display, because the
  777. color quantization process used to display the JPEG won't exactly match the
  778. GIF's quantization.  (See section 7 for more about that.)  But given a good
  779. viewer, the JPEG will look as good as the GIF.  Some people claim that on
  780. 24-bit displays, a carefully converted JPEG can look better than the GIF
  781. source, because dither patterns have been eliminated.  (More about dithering
  782. in a moment.)
  783.  
  784. On the other hand, JPEG conversion *will* degrade an unsuitable image or one
  785. that is converted carelessly.  If you are not willing to take the amount of
  786. trouble suggested below, you're much better off leaving your GIF images
  787. alone.  Simply cranking the JPEG quality setting up to a very high value
  788. wastes space (which defeats the whole point of the exercise...) and some
  789. images will be degraded anyway.
  790.  
  791. The first rule is never to convert an image that's not appropriate for JPEG
  792. (see section 3 about that).  Large, high-visual-quality photographic images
  793. are usually the best material.  And they take up lots of space in GIF form,
  794. so they offer significant potential space savings.  (A good rule of thumb is
  795. not to bother converting any GIF that's much under 100 Kbytes; the potential
  796. space savings isn't worth the hassle.)
  797.  
  798. The second rule is to look at each JPEG, to make sure you are happy with it,
  799. before throwing away the corresponding GIF; this will give you a chance to
  800. re-do the conversion with a higher quality setting if necessary.  Also
  801. compare the file sizes --- if the image isn't suitable JPEG material, a JPEG
  802. file of reasonable quality may come out *larger* than the GIF.
  803.  
  804. The third rule is to get rid of the border.  Many people have developed
  805. an odd habit of putting a large single-color border around a GIF image.
  806. While useless, this is nearly free in terms of storage cost in GIF files.
  807. It is NOT free in JPEG files, either in storage space or in decoding time;
  808. and the sharp border boundary can create visible artifacts ("ghost" edges).
  809. Furthermore, when viewing a bordered JPEG on an 8-bit display, the quantizer
  810. will think the border color is important because there's so much of it, and
  811. hence will waste color palette entries on the border, thus actually reducing
  812. the displayed quality of the main part of the image!  So do yourself a favor
  813. and crop off any border before JPEGing.
  814.  
  815. Gray-scale images usually convert without much problem.  When using cjpeg,
  816. be sure to specify -gray.  (By default, cjpeg treats GIFs as color files;
  817. this works but wastes space and time for gray-scale data.)  Quality settings
  818. around the default (75) are usually fine.
  819.  
  820. Color images are much trickier.  Color GIFs of photographic images are
  821. usually "dithered" to fool your eye into seeing more than the 256 colors
  822. that GIF can actually store.  If you enlarge the image, you will find that
  823. adjacent pixels are often of significantly different colors; at normal size
  824. the eye averages these pixels together to produce the illusion of an
  825. intermediate color value.  The trouble with dithering is that, to JPEG, it
  826. looks like high-spatial-frequency color noise; and JPEG can't compress noise
  827. very well.  The resulting JPEG file is both larger and of lower image
  828. quality than what you would have gotten from JPEGing the original full color
  829. image (if you had it).  To get around this, you need to "smooth" the GIF
  830. image before compression.  Smoothing averages together nearby pixels, thus
  831. approximating the color that you thought you saw anyway, and in the process
  832. getting rid of the rapid color changes that give JPEG trouble.  Proper use
  833. of smoothing will both reduce the size of the compressed file and give you a
  834. better-looking output image than you'd get without smoothing.
  835.  
  836. With the V4 free JPEG software (or programs based on it), a simple smoothing
  837. capability is built in.  Try "-smooth 10" or so when converting GIFs.
  838. Values of 10 to 25 seem to work well for high-quality GIFs.  Heavy-handed
  839. dithering may require larger smoothing factors.  (If you can see regular
  840. fine-scale patterns on the GIF image even without enlargement, then strong
  841. smoothing is definitely called for.)  Too large a smoothing factor will blur
  842. the output image, which you don't want.  If you are an image processing
  843. wizard, you can also do smoothing with a separate filtering program, but
  844. appropriate use of such tools is beyond the scope of this FAQ.
  845.  
  846. Quality settings around 85 (a bit higher than default) usually work well
  847. when converting color GIFs, assuming that you've picked a good smoothing
  848. factor.  You may need to go higher if you can't hide the dithering pattern
  849. with a reasonable smoothing factor.  Really badly dithered GIFs are best
  850. left as GIFs.
  851.  
  852. Don't expect JPEG files converted from GIFs to be as small as those created
  853. directly from full-color originals.  You won't be able to smooth away all of
  854. the dithering noise without ruining the image, and this noise wastes space.
  855. Typically, a good-quality converted JPEG will be 1/2 to 1/3rd the size of
  856. the GIF file, not 1/4th as suggested in section 4.  (If the JPEG comes out
  857. much more than half the size of the GIF, this is a good sign that the image
  858. shouldn't be converted at all.)
  859.  
  860. The upshot of all this is that "cjpeg -quality 85 -smooth 10" is probably a
  861. good starting point for converting color GIFs.  But if you care about the
  862. image, you'll want to check the results and maybe try a few other settings.
  863. Blindly converting a large GIF library at this or any other setting is a
  864. recipe for disaster.
  865.  
  866.  
  867. [9]  Does loss accumulate with repeated compression/decompression?
  868.  
  869. It would be nice if, having compressed an image with JPEG, you could
  870. decompress it, manipulate it (crop off a border, say), and recompress it
  871. without any further image degradation beyond what you lost initially.
  872. Unfortunately THIS IS NOT THE CASE.  In general, recompressing an altered
  873. image loses more information.  Hence it's important to minimize the number
  874. of generations of JPEG compression between initial and final versions of an
  875. image.
  876.  
  877. It turns out that if you decompress and recompress an image at the same
  878. quality setting first used, little or no further degradation occurs.
  879. (Counterintuitively, this works better the lower the quality setting.
  880. But you must use *exactly* the same setting, or all bets are off.)
  881. This means that you can make local modifications to an image without
  882. material degradation of other areas of the image.  Unfortunately, cropping
  883. doesn't count as a local change!  JPEG processes the image in small blocks,
  884. and cropping usually moves the block boundaries, so that the image looks
  885. completely different to JPEG.  You can take advantage of the low-degradation
  886. behavior if you are careful to crop the top and left margins only by a
  887. multiple of the block size (typically 16 pixels), so that the remaining
  888. blocks start in the same places.
  889.  
  890. The bottom line is that JPEG is a useful format for archival storage and
  891. transmission of images, but you don't want to use it as an intermediate
  892. format for sequences of image manipulation steps.  Use a lossless format
  893. (PPM, RLE, TIFF, etc) while working on the image, then JPEG it when you are
  894. ready to file it away.  Aside from avoiding degradation, you will save a lot
  895. of compression/decompression time this way :-).
  896.  
  897.  
  898. [10]  Why all the argument about file formats?
  899.  
  900. Strictly speaking, JPEG refers only to a family of compression algorithms;
  901. it does *not* refer to a specific image file format.  The JPEG committee was
  902. prevented from defining a file format by turf wars within the international
  903. standards organizations.
  904.  
  905. Since we can't actually exchange images with anyone else unless we agree on
  906. a common file format, this leaves us with a problem.  In the absence of
  907. official standards, a number of JPEG program writers have just gone off to
  908. "do their own thing", and as a result their programs aren't compatible with
  909. anybody else's.
  910.  
  911. The closest thing we have to a standard JPEG format is some work that's been
  912. coordinated by people at C-Cube Microsystems.  They have defined two
  913. JPEG-based file formats:
  914.   * JFIF (JPEG File Interchange Format), a "low-end" format that transports
  915.     pixels and not much else.
  916.   * TIFF/JPEG, aka TIFF 6.0, an extension of the Aldus TIFF format.  TIFF is
  917.     a "high-end" format that will let you record just about everything you
  918.     ever wanted to know about an image, and a lot more besides :-).  TIFF is
  919.     a lot more complex than JFIF, and is generally less transportable,
  920.     because different vendors have often implemented slightly different
  921.     and incompatible subsets of TIFF.  It's not likely that adding JPEG to
  922.     the mix will do anything to improve this situation.
  923. Both of these formats were developed with input from all the major vendors
  924. of JPEG-related products; it's reasonably likely that future commercial
  925. products will adhere to one or both standards.
  926.  
  927. JFIF has emerged as the de-facto standard on Usenet.  JFIF is simpler than
  928. TIFF and is available now; the TIFF 6.0 spec has only recently been
  929. officially adopted, and it is still unusably vague on some crucial details.
  930. Even when TIFF/JPEG is well defined, the JFIF format is likely to be a
  931. widely supported "lowest common denominator"; TIFF/JPEG files may never be
  932. as transportable.
  933.  
  934. A particular case of interest is Apple's Macintosh QuickTime software.
  935. QuickTime uses a JFIF-compatible format wrapped inside the Mac-specific PICT
  936. structure.  Conversion between JFIF and PICT/JPEG is pretty straightforward,
  937. and several Mac programs are available to do it (see Mac portion of section
  938. 6A).  If you have an editor that handles binary files, you can strip a
  939. PICT/JPEG file down to JFIF by hand; see section 11 for details.
  940.  
  941. Another particular case is Handmade Software's programs (GIF2JPG/JPG2GIF and
  942. Image Alchemy).  These programs are capable of reading and writing JFIF
  943. format.  By default, though, they write a proprietary format developed by
  944. HSI.  This format is NOT readable by any non-HSI programs and should not be
  945. used for Usenet postings.  Use the -j switch to get JFIF output.  (This
  946. applies to old versions of these programs; the current releases emit JFIF
  947. format by default.  You still should be careful not to post HSI-format
  948. files, unless you want to get flamed by people on non-PC platforms.)
  949.  
  950.  
  951. [11]  How do I recognize which file format I have, and what do I do about it?
  952.  
  953. If you have an alleged JPEG file that your software won't read, it's likely
  954. to be HSI format or some other proprietary JPEG-based format.  You can tell
  955. what you have by inspecting the first few bytes of the file:
  956.  
  957. 1.  A JFIF-standard file will start with the characters (hex) FF D8 FF E0,
  958.     followed by two variable bytes (often hex 00 10), followed by 'JFIF'.
  959.  
  960. 2.  If you see FF D8 at the start, but not the rest of it, you may have a
  961.     "raw JPEG" file.  This is probably decodable as-is by JFIF software ---
  962.     it's worth a try, anyway.
  963.  
  964. 3.  HSI files start with 'hsi1'.  You're out of luck unless you have HSI
  965.     software.  Portions of the file may look like plain JPEG data, but they
  966.     won't decompress properly with non-HSI programs.
  967.  
  968. 4.  A Macintosh PICT file, if JPEG-compressed, will have a couple hundred
  969.     bytes of header followed by a JFIF header (scan for 'JFIF').  Strip off
  970.     everything before the FF D8 and you should be able to read it.
  971.  
  972. 5.  Anything else: it's a proprietary format, or not JPEG at all.  If you are
  973.     lucky, the file may consist of a header and a raw JPEG data stream.
  974.     If you can identify the start of the JPEG data stream (look for FF D8),
  975.     try stripping off everything before that.
  976.  
  977. In uuencoded Usenet postings, the characteristic JFIF pattern is
  978.  
  979.  "begin" line
  980.  M_]C_X ...
  981.  
  982. whereas uuencoded HSI files will start with
  983.  
  984.  "begin" line
  985.  M:'-I ...
  986.  
  987. If you learn to check for the former, you can save yourself the trouble of
  988. downloading non-JFIF files.
  989.  
  990.  
  991. [12]  How does JPEG work?
  992.  
  993. The buzz-words to know are chrominance subsampling, discrete cosine
  994. transforms, coefficient quantization, and Huffman or arithmetic entropy
  995. coding.  This article's long enough already, so I'm not going to say more
  996. than that here.  For technical information see the comp.compression FAQ,
  997. which is available from the news.answers archive at rtfm.mit.edu, in files
  998. /pub/usenet/news.answers/compression-faq/part[1-3].  If you need help in
  999. using the news.answers archive, see the top of this article.
  1000.  
  1001.  
  1002. [13]  Isn't there a lossless JPEG?
  1003.  
  1004. There's a great deal of confusion on this subject.  The JPEG committee did
  1005. define a truly lossless compression algorithm, i.e., one that guarantees the
  1006. final output is bit-for-bit identical to the original input.  However, this
  1007. lossless mode has almost nothing in common with the regular, lossy JPEG
  1008. algorithm, and it offers much less compression.  At present, very few
  1009. implementations of lossless JPEG exist, and all of them are commercial.
  1010.  
  1011. Saying "-quality 100" to the free JPEG software DOES NOT get you a lossless
  1012. image.  What it does get rid of is deliberate information loss in the
  1013. coefficient quantization step.  There is still a good deal of information
  1014. loss in the color subsampling step.  (With the V4 free JPEG code, you can
  1015. also say "-sample 1x1" to turn off subsampling.  Keep in mind that some
  1016. commercial JPEG implementations cannot cope with the resulting file.)
  1017.  
  1018. Even with both quantization and subsampling turned off, the regular JPEG
  1019. algorithm is not lossless, because it is subject to roundoff errors in
  1020. various calculations.  The maximum error is a few counts in any one pixel
  1021. value; it's highly unlikely that this could be perceived by the human eye,
  1022. but the error will accumulate to become visible if you put the image through
  1023. multiple cycles of compression.
  1024.  
  1025. At this minimum-loss setting, regular JPEG produces files that are perhaps
  1026. half the size of an uncompressed 24-bit-per-pixel image.  True lossless JPEG
  1027. provides roughly the same amount of compression, but it guarantees
  1028. bit-for-bit accuracy.
  1029.  
  1030. If you have an application requiring lossless storage of images with less
  1031. than 6 bits per pixel (per color component), you may want to look into the
  1032. JBIG bilevel image compression standard.  This performs better than JPEG
  1033. lossless on such images.  JPEG lossless is superior to JBIG on images with
  1034. 6 or more bits per pixel; furthermore, JPEG is public domain (at least with a
  1035. Huffman back end), while the JBIG techniques are heavily covered by patents.
  1036.  
  1037.  
  1038. [14]  What about arithmetic coding?
  1039.  
  1040. The JPEG spec defines two different "back end" modules for the final output
  1041. of compressed data: either Huffman coding or arithmetic coding is allowed.
  1042. The choice has no impact on image quality, but arithmetic coding usually
  1043. produces a smaller compressed file.  On typical images, arithmetic coding
  1044. produces a file 5 or 10 percent smaller than Huffman coding.  (All the
  1045. file-size numbers previously cited are for Huffman coding.)
  1046.  
  1047. Unfortunately, the particular variant of arithmetic coding specified by the
  1048. JPEG standard is subject to patents owned by IBM, AT&T, and Mitsubishi.
  1049. Thus *you cannot legally use arithmetic coding* unless you obtain licenses
  1050. from these companies.  (The "fair use" doctrine allows people to implement
  1051. and test the algorithm, but actually storing any images with it is dubious
  1052. at best.)
  1053.  
  1054. At least in the short run, I recommend that people not worry about
  1055. arithmetic coding; the space savings isn't great enough to justify the
  1056. potential legal hassles.  In particular, arithmetic coding *should not*
  1057. be used for any images to be exchanged on Usenet.
  1058.  
  1059.  
  1060. ---------------------
  1061.  
  1062. For more information about JPEG in general or the free JPEG software in
  1063. particular, contact the Independent JPEG Group at jpeg-info@uunet.uu.net.
  1064.  
  1065. -- 
  1066.    tom lane
  1067.    organizer, Independent JPEG Group
  1068.    tgl@cs.cmu.edu or tgl@netcom.com
  1069.