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