home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: Graphics / Graphics.zip / JPEG2OS2.ZIP / JPEGFAQ.TXT < prev    next >
Internet Message Format  |  1992-02-07  |  29KB

  1. From: tgl+@cs.cmu.edu (Tom Lane)
  2. Subject: JPEG image compression: Frequently Asked Questions
  3. Summary: trying to clear up some of the confusion
  4. Keywords: JPEG, image compression, FAQ
  5. Organization: School of Computer Science, Carnegie Mellon
  6.  
  7. Archive-name: jpeg-faq
  8. Last-modified: 24 Jan 1992
  9.  
  10. This FAQ article discusses JPEG image compression.  Suggestions for
  11. additions and clarifications are welcome.
  12.  
  13. This article includes the following sections:
  14.  
  15. 1)  What is JPEG?
  16. 2)  Why use JPEG?
  17. 3)  How well does it work?
  18. 4)  What are good "quality" settings for JPEG?
  19. 5)  When should I use JPEG, and when should I stick with GIF?
  20. 6)  Where can I get JPEG software?
  21. 7)  What's all this hoopla about color quantization?
  22. 8)  How does JPEG work?
  23. 9)  What about lossless JPEG?
  24. 10)  Why all the argument about file formats?
  25. 11)  And what about arithmetic coding?
  26. 12)  Does loss accumulate with repeated compression/decompression?
  27.  
  28. Sections 7 and up can be ignored unless you are interested in details.
  29.  
  30.  
  31. 1)  What is JPEG?
  32.  
  33. JPEG (pronounced "jay-peg") is a standardized image compression mechanism.
  34. JPEG stands for Joint Photographic Experts Group, the original name of the
  35. committee that wrote the standard.  JPEG is designed for compressing either
  36. full-color or gray-scale digital images of "natural" (real-world) scenes.
  37. JPEG does not handle black-and-white (1-bit-per-pixel) images, nor does it
  38. handle motion picture compression.  (Standards for compressing those types
  39. of images are being worked on by other committees, named JBIG and MPEG
  40. respectively.)
  41.  
  42. JPEG is "lossy", meaning that the image you get out of decompression isn't
  43. quite identical to what you originally put in.  The algorithm achieves much
  44. of its compression by exploiting known limitations of the human eye, notably
  45. the fact that small color details aren't perceived as well as small details
  46. of light-and-dark.  Thus, JPEG is intended for compressing images that will
  47. be looked at by humans.  If you plan to machine-analyze your images, the
  48. small errors introduced by JPEG may be a problem for you, even if they are
  49. invisible to the eye.
  50.  
  51. A useful property of JPEG is that the degree of lossiness can be varied by
  52. adjusting compression parameters.  This means that the image maker can trade
  53. off file size against output image quality.  You can make *extremely* small
  54. files if you don't mind poor quality; this is useful for indexing image
  55. archives, making thumbnail views or icons, etc. etc.  Conversely, if you
  56. aren't happy with the output quality at the default compression setting, you
  57. can jack up the quality until you are satisfied, and accept lesser compression.
  58.  
  59.  
  60. 2)  Why use JPEG?
  61.  
  62. There are two good reasons: to make your image files smaller, and to store
  63. 24-bit-per-pixel color data instead of 8-bit-per-pixel data.
  64.  
  65. Making image files smaller is a big win for transmitting files across
  66. networks and for archiving libraries of images.  Being able to compress a
  67. 2 Mbyte full-color file down to 100 Kbytes or so makes a big difference in
  68. disk space and transmission time!  (If you are comparing GIF and JPEG, the
  69. size ratio is more like four to one.  More details below.)
  70.  
  71. Unless your viewing software supports JPEG directly, you'll have to convert
  72. JPEG to some other format for viewing or manipulating images.  (Right now,
  73. not many viewers include JPEG support, but this will change rapidly.)  Thus,
  74. using JPEG is essentially a time/space tradeoff: you give up some time in
  75. order to store or transmit an image more cheaply.
  76.  
  77. It's worth noting that when network or phone transmission is involved, the
  78. time savings from transferring a shorter file can be much greater than the
  79. extra time to decompress the file.  I'll let you do the arithmetic yourself.
  80.  
  81. The other reason that JPEG will gradually replace GIF is that it stores full
  82. color information: 24 bits/pixel (16 million colors) instead of 8 or less
  83. (256 or fewer colors).  If you have only 8-bit display hardware then this
  84. may not seem like much of an advantage to you.  Within a couple of years,
  85. though, GIF will look as obsolete as black-and-white MacPaint format does
  86. today.  Furthermore, for reasons detailed in section 7, JPEG is far more
  87. useful than GIF for exchanging images among people with widely varying color
  88. display hardware.  Hence JPEG is considerably more appropriate than GIF for
  89. use as a Usenet posting standard.
  90.  
  91.  
  92. 3)  How well does it work?
  93.  
  94. Pretty darn well.  Here are some sample file sizes for an image I have handy,
  95. a 727x525 full-color image of a ship in a harbor.  The first three files are
  96. for comparison purposes; the rest were created with the free JPEG software
  97. described further on.
  98.  
  99. File       Size in bytes        Comments
  100.  
  101. ship.ppm    1145040  Original file in PPM format (no compression;
  102.              3 bytes per pixel plus a few bytes overhead)
  103. ship.ppm.Z     963829  PPM file passed through Unix compress
  104.              compress doesn't accomplish a lot, you'll note.
  105. ship.gif     240438  Converted to GIF with ppmquant -fs 256 | ppmtogif
  106.              Most of the savings is the result of losing color
  107.              info: GIF saves 8 bits/pixel, not 24.  (See sec. 7.)
  108.  
  109. ship.jpg95     155607  cjpeg -Q 95    (highest useful quality setting)
  110.              This is indistinguishable from the 24-bit original,
  111.              at least to my nonprofessional eyeballs.
  112. ship.jpg75      57995  cjpeg -Q 75    (default setting)
  113.              You have to look mighty darn close to distinguish this
  114.              from the original, even with both on-screen at once.
  115. ship.jpg50      38399  cjpeg -Q 50
  116.              This has slight defects; if you know what to look
  117.              for, you could tell it's been JPEGed without seeing
  118.              the original.  Still as good image quality as many
  119.              recent postings in Usenet pictures groups.
  120. ship.jpg25      25186  cjpeg -Q 25
  121.              JPEG's characteristic "blockiness" becomes apparent
  122.              at this setting (djpeg -b helps some).  I've seen
  123.              plenty of Usenet postings that were uglier than this.
  124. ship.jpg5o       6597  cjpeg -Q 5 -o
  125.              Blocky, but perfectly satisfactory for preview or
  126.              indexing purposes.  Note that this file is TINY.
  127.  
  128. In this case JPEG can make a file that's a factor of four or five smaller
  129. than a GIF of comparable quality (the -Q 75 file is every bit as good as the
  130. GIF, better if you have a full-color display).  This seems to be a typical
  131. ratio for real-world scenes.
  132.  
  133.  
  134. 4)  What are good "quality" settings for JPEG?
  135.  
  136. (Note: the -Q settings discussed in this article apply to the free JPEG
  137. software described in section 6.  Other JPEG implementations, such as Image
  138. Alchemy, may use a completely different quality scale.)
  139.  
  140. The name of the game in using JPEG is to pick the lowest quality setting
  141. (smallest file size) that decompresses into an image indistinguishable from
  142. the original.  This setting will vary from one image to another and from one
  143. observer to another, but here are some rules of thumb.
  144.  
  145. The default quality setting (-Q 75) is very often the best choice.  This
  146. setting is about the lowest you can go without expecting to see defects in a
  147. typical image.  Try -Q 75 first; if you see defects, then go up.  Except for
  148. experimental purposes, never go above -Q 95; saying -Q 100 will produce a
  149. file two or three times as large as -Q 95, but of hardly any better quality.
  150.  
  151. If the image was less than perfect quality to begin with, you might be able
  152. to go down to -Q 50 without objectionable degradation.  On the other hand,
  153. you might need to go to a HIGHER quality setting to avoid further degradation.
  154. This last case seems to apply most of the time when converting GIFs to JPEG
  155. (see next section for more information).
  156.  
  157. If you are prepared to tolerate visible defects, and want a very small file
  158. (say for preview or indexing purposes), a -Q setting in the range of 5 to 10
  159. is about right.  -Q 2 or so may be amusing as "op art".
  160.  
  161. Another recommendation: when you are making a final version of an image for
  162. posting on Usenet or archiving, specify "-o" to cjpeg.  This will make the
  163. file a little smaller without affecting image quality; it will take longer
  164. to do the compression, but not any longer to decompress.
  165.  
  166.  
  167. 5)  When should I use JPEG, and when should I stick with GIF?
  168.  
  169. As a rule of thumb, JPEG is superior to GIF for storing full-color and
  170. gray-scale images of "realistic" scenes; that means scanned photographs and
  171. similar material.  JPEG is superior even if you don't have 24-bit display
  172. hardware, and it is a LOT superior if you do.  (See section 7 for details.)
  173.  
  174. GIF does significantly better on images with only a few distinct colors,
  175. such as cartoons and line drawings.  In particular, large areas of pixels
  176. that are all *exactly* the same color are compressed very efficiently indeed
  177. by GIF.  JPEG can't squeeze these files as much as GIF does without
  178. introducing visible defects.  This sort of image is best kept in GIF form.
  179. (Incidentally, many people have developed an odd habit of putting a large
  180. constant-color border around a GIF image.  This was nearly free in terms of
  181. storage cost in GIF files.  It is NOT free in JPEG files.  Do yourself a
  182. favor and don't add a border; let your viewer blank out unused screen area.
  183. If you're converting a GIF to JPEG, crop off any border first.)
  184.  
  185. JPEG also has a hard time with very sharp edges: a row of pure-black pixels
  186. adjacent to a row of pure-white pixels, for example.  Sharp edges tend to
  187. come out blurred unless you use a very high quality setting.  Again, this
  188. sort of thing is not found in scanned photographs, but it shows up fairly
  189. often in GIF files: borders, overlaid text, etc.  The blurriness is
  190. particularly objectionable with text that's only a few pixels high.  If you
  191. have a GIF with a lot of small-size overlaid text, don't JPEG it.
  192.  
  193. Computer-drawn images (ray-traced scenes, for instance) usually fall between
  194. scanned images and cartoons in terms of complexity.  The more complex and
  195. subtly rendered the image, the more likely that JPEG will do well on it.
  196.  
  197. If you have an existing library of GIF images, you may wonder whether you
  198. should convert them to JPEG.  You will lose some image quality if you do,
  199. but the disk space savings may justify converting anyway.  (Section 7, which
  200. argues that JPEG image quality is superior to GIF, only applies if both
  201. formats start from a full-color original.  If you start from a GIF, you've
  202. already irretrievably lost a great deal of information; JPEG can only make
  203. things worse.)
  204.  
  205. Experience to date suggests that large, high-quality GIFs are the best
  206. candidates for conversion to JPEG.  They chew up the most storage so offer
  207. the most potential savings, and they convert to JPEG with least degradation.
  208. Don't waste your time converting any GIF much under 100 Kbytes.  Also, don't
  209. expect JPEG files converted from GIFs to be as small as those created
  210. directly from full-color originals.  To maintain image quality you may have
  211. to let the converted files be as much as twice as big as straight-through
  212. JPEG files would be (i.e., shoot for 1/2 or 1/3rd the size of the GIF file,
  213. not 1/4th as shown in the earlier comparisons).  A -Q setting of 85 to 95
  214. will minimize the additional degradation caused by converting a GIF to JPEG.
  215.  
  216.  
  217. 6)  Where can I get JPEG software?
  218.  
  219. If you are looking for "canned" software, viewers, etc:
  220.  
  221. There is not a lot of pre-built, no-thought-required JPEG software available
  222. yet.  This short list will no doubt grow with time.
  223.  
  224. For X Windows, John Bradley's XV version 2.00 is the best JPEG viewer around.
  225. It's available for FTP from export.lcs.mit.edu or grip.cis.upenn.edu.  The
  226. file is called 'xv-2.00.tar.Z' and is located in the 'contrib' directory on
  227. export or the 'pub' directory on grip.  XV's only real shortcoming is that
  228. it does not fully exploit 24-bit displays (it reduces all images to 8 bits).
  229. If you have a 24-bit display you will get better results from "xloadimage",
  230. which is also available from export, file contrib/xloadimage.3.01.tar.Z.
  231. This version does not read JPEG files, but it will read the PPM files put
  232. out by the free JPEG converter described below.  There is also a patched
  233. version called "xli" (see files xli.* in same directory) that does read JPEG
  234. directly.  However, xli is a quick hack rather than an official release;
  235. caveat user.
  236.  
  237. For MS-DOS, Handmade Software offers two (rather pricy) shareware programs:
  238. Image Alchemy and GIF2JPG/JPG2GIF (contact hsi@netcom.com for details).  The
  239. PC versions of these programs are available for FTP from wuarchive.wustl.edu,
  240. directory mirrors/msdos/graphics, files alchmy15.zip and gif2jpg5.zip; also
  241. from SIMTEL20 and its other mirror sites.  (Image Alchemy is also available
  242. as an executable for Sun Unix machines, but I don't know where to find it.)
  243. GIF2JPG/JPG2GIF only perform JPEG<=>GIF format conversion.  Image Alchemy
  244. converts files between these and many other formats, and can also display
  245. images on some types of hardware.  The display option is pretty limited,
  246. so you'll still want a separate viewer program.  (WARNING: GIF2JPG produces
  247. a proprietary file format unless you specify -j.  Be sure to use -j if you
  248. want to exchange JPEG files with other Usenet users.  For that matter, it's
  249. not real clear that you should be posting JPEG files made from GIFs; see
  250. section 5.)
  251.  
  252. For the Macintosh, Storm Technology has released a free program that can
  253. decode and view JPEG images (though not create them).  This is called
  254. Picture Decompress.  Make sure you get version 2.0.1 or later; earlier
  255. versions are not compatible with JFIF file format.  This program can be
  256. FTPed from sumex-aim.stanford.edu, directory /info-mac/app, file
  257. picture-decompress-201.hqx.  You'll also need a tool for adjusting file type
  258. codes; set the type of a downloaded image file to 'JPEG' to allow Picture
  259. Decompress to open it.
  260.  
  261. If none of the above fits your situation, you can obtain and compile the
  262. free JPEG converter program described below.  You'll also need a viewer
  263. program, and if your viewer only handles GIF files, you'll want a separate
  264. color quantization program (we recommend ppmquant from the PBMPLUS package
  265. for Unix machines; on PCs, try Piclab).  This last requirement will go away
  266. with the next release of the free code.
  267.  
  268. There are numerous commercial JPEG offerings, with more popping up every
  269. day.  I recommend that you not spend money on one of these unless you find
  270. the available free or shareware software vastly too slow.  In that case,
  271. purchase a hardware-assisted product.  Ask pointed questions about whether
  272. the product complies with the final JPEG standard and about whether it can
  273. handle the JFIF file format; many of the earliest commercial releases are
  274. not and never will be compatible with anyone else's files.
  275.  
  276.  
  277. If you are looking for source code to work with:
  278.  
  279. Free, portable C code for JPEG compression is available from the Independent
  280. JPEG Group, which I lead.  A package containing our source code,
  281. documentation, and some small test files is available from several places.
  282. The "official" archive site for this source code is ftp.uu.net (137.39.1.9
  283. or 192.48.96.9).  Look under directory /graphics/jpeg; the current release
  284. is jpegsrc.v2.tar.Z.  (This is a compressed TAR file; don't forget to
  285. retrieve in binary mode.)  You can retrieve this file by FTP or UUCP.  Folks
  286. in Europe may find it easier to FTP from nic.funet.fi (see directory
  287. pub/graphics/programs/jpeg).  The source code is also available on
  288. CompuServe, in the GRAPHSUPPORT forum (GO PICS), library 10, as jpsrc2.zip.
  289.  
  290. The free JPEG code provides conversion between JPEG "JFIF" format and image
  291. files in PBMPLUS PPM, Utah RLE, Truevision Targa, and GIF file formats.
  292. (However, output to GIF format is not of high quality at present; ditto for
  293. colormapped Targa and RLE formats.)  The core compression and decompression
  294. modules can easily be reused in other programs, such as image viewers.  The
  295. package is highly portable; we have tested it on many machines ranging from
  296. PCs to Crays.
  297.  
  298. We have released this software for both noncommercial and commercial use.
  299. Companies are welcome to use it as the basis for JPEG-related products.
  300. We do not ask a royalty, although we do ask for an acknowledgement in
  301. product literature (see the README file in the distribution for details).
  302. We hope to make this software industrial-quality --- although, as with
  303. anything that's free, we offer no warranty and accept no liability.
  304.  
  305. The Independent JPEG Group is a volunteer organization; if you'd like to
  306. contribute to improving our software, you are welcome to join.
  307.  
  308. If you are not reasonably handy at configuring and installing portable C
  309. programs, you may have some difficulty installing the free source code.
  310. Steve Davis (strat@cis.ksu.edu) has volunteered to maintain an archive of
  311. pre-built executable versions of the free JPEG code for various machines.
  312. His FTP archive is at procyon.cis.ksu.edu (129.130.10.80 -- this number is
  313. due to change soon); look under /pub/JPEG to see what he currently has.
  314. (The administrators of this system ask that FTP traffic be limited to
  315. non-prime hours.)  This archive is not maintained by the Independent JPEG
  316. Group, and files in it may not represent the latest source code.
  317.  
  318.  
  319. 7)  What's all this hoopla about color quantization?
  320.  
  321. Most people don't have full-color (24 bit per pixel) display hardware.
  322. Typical display hardware stores 8 or fewer bits per pixel, so it can display
  323. 256 or fewer distinct colors at a time.  To display a full-color image, the
  324. computer must map the image into an appropriate set of representative
  325. colors.  This process is called "color quantization".
  326.  
  327. Clearly, color quantization is a lossy process.  It turns out that for most
  328. images, the details of the color quantization algorithm have MUCH more impact
  329. on the final image quality than do any errors introduced by JPEG (except at
  330. the very lowest JPEG quality settings).
  331.  
  332. Since JPEG is inherently a full-color format, converting a JPEG image for
  333. display on 8-bit-or-less hardware requires color quantization.  But a GIF
  334. image, by definition, has already been quantized to 256 or fewer colors.
  335. For purposes of Usenet picture distribution, GIF has the advantage that the
  336. sender precomputes the color quantization and recipients don't have to.
  337. This is also the *disadvantage* of GIF: you're stuck with the sender's
  338. quantization.  If the sender quantized to a different number of colors than
  339. what you can display, you have to re-quantize, resulting in much poorer
  340. image quality than if you had quantized once from a full-color image.
  341. Furthermore, if the sender didn't use a high-quality color quantization
  342. algorithm, you're out of luck.
  343.  
  344. For this reason, JPEG offers the promise of *significantly better* image
  345. quality for all users whose machines don't match the sender's display
  346. hardware.  JPEG's full color image can be quantized to precisely match the
  347. user's display hardware.  Furthermore, you will be able to take advantage of
  348. future improvements in quantization algorithms (there is a lot of active
  349. research in this area), or purchase better display hardware, to get a better
  350. view of JPEG images you already have.  With GIF, you're stuck forevermore
  351. with what was sent.
  352.  
  353. It's also worth mentioning that many GIF-viewing programs include rather
  354. shoddy quantization routines.  If you view a 256-color GIF on a 16-color EGA
  355. display, for example, you are probably getting a much worse image than you
  356. need to.  This is partly an inevitable consequence of doing two color
  357. quantizations (one to create the GIF, one to display it), but often it's
  358. also due to sloppiness.  JPEG conversion programs will be forced to use
  359. high quality quantizers in order to get acceptable results at all, and in
  360. normal use they will quantize directly to the number of colors to be
  361. displayed.  Thus, JPEG is likely to provide better results than the average
  362. GIF program for low-color-resolution displays as well as high-resolution ones!
  363.  
  364. (Incidentally, the current "V2" release of the free JPEG software does NOT
  365. include a good color quantizer; we assume you have a separate quantizer
  366. program, such as ppmquant from the PBMPLUS package.  For this reason we
  367. don't recommend using the free software as a JPEG->GIF converter.  This
  368. shortcoming will be fixed in the next release.)
  369.  
  370.  
  371. 8)  How does JPEG work?
  372.  
  373. The buzz-words to know are chrominance subsampling, discrete cosine
  374. transforms, coefficient quantization, and Huffman or arithmetic entropy
  375. coding.  This article's long enough already, so I'm not going to say more
  376. than that.  For a good technical introduction, see:
  377.     Wallace, Gregory K.  "The JPEG Still Picture Compression Standard",
  378.     Communications of the ACM, April 1991 (vol. 34 no. 4), pp. 30-44.
  379. (Adjacent articles in that issue discuss MPEG motion picture compression,
  380. applications of JPEG, and related topics.)  If you don't have the CACM issue
  381. handy, a PostScript file containing a revised version of this article is
  382. available at ftp.uu.net, graphics/jpeg/wallace.ps.Z.  The file (actually a
  383. preprint for an article to appear in IEEE Trans. Consum. Elect.) omits the
  384. sample images that appeared in CACM, but it includes corrections and some
  385. added material.  Note: the Wallace article is copyright ACM and IEEE, and
  386. it may not be used for commercial purposes.
  387.  
  388.  
  389. 9)  What about lossless JPEG?
  390.  
  391. There's a great deal of confusion on this subject.  The JPEG committee did
  392. define a truly lossless compression algorithm, i.e., one that guarantees the
  393. final output is bit-for-bit identical to the original input.  However, this
  394. lossless mode has almost nothing in common with the regular, lossy JPEG
  395. algorithm.  As far as I know, the lossless JPEG mode is not implemented in
  396. any software available to the public.
  397.  
  398. Saying "-Q 100" to the free JPEG software DOES NOT get you a lossless image.
  399. What it does get rid of is deliberate information loss in the coefficient
  400. quantization step.  There is still a good deal of information loss in the
  401. color subsampling step.  (There should be a command line switch to disable
  402. subsampling, but as of today, there isn't one.)
  403.  
  404. Even with both quantization and subsampling turned off, the standard JPEG
  405. algorithm is not truly lossless, because it is subject to roundoff errors in
  406. various calculations.  The maximum error is a few counts in any one pixel
  407. value; it's highly unlikely that this could be perceived by the human eye,
  408. but it might be a concern if you are doing machine processing of an image.
  409.  
  410. At this minimum-loss setting, standard JPEG produces files that are perhaps
  411. half the size of an uncompressed 24-bit-per-pixel image.  JPEG's true
  412. lossless mode provides roughly the same amount of compression, but it
  413. guarantees bit-for-bit accuracy.
  414.  
  415. If you have an application requiring lossless storage of images with less
  416. than 6 bits per pixel (per color component), you may want to look into the
  417. JBIG bilevel image compression standard.  This performs better than JPEG
  418. lossless on such images.  JPEG lossless is superior to JBIG on images with
  419. 8 or more bits per pixel; furthermore, it is public domain, while the JBIG
  420. techniques are heavily covered by patents.
  421.  
  422.  
  423. 10)  Why all the argument about file formats?
  424.  
  425. Strictly speaking, JPEG refers only to a family of compression algorithms;
  426. it does *not* refer to a specific image file format.  The JPEG committee was
  427. prevented from defining a file format by turf wars within the international
  428. standards organizations.
  429.  
  430. Since we can't actually exchange images with anyone else unless we agree on
  431. a common file format, this leaves us with a problem.  In the absence of
  432. official standards, a lot of JPEG program writers have just gone off to
  433. "do their own thing", and as a result their programs aren't compatible with
  434. anybody else's.
  435.  
  436. The closest thing we have to a de-facto standard JPEG format is some work
  437. that's been coordinated by people at C-Cube Microsystems.  They have defined
  438. two JPEG-based file formats:
  439.   * JFIF (JPEG File Interchange Format), a "low-end" format that transports
  440.     pixels and not much else.
  441.   * TIFF/JPEG, an extension of the Aldus TIFF format.  TIFF is a "high-end"
  442.     format that will let you record just about everything you ever wanted to
  443.     know about an image, and a lot more besides :-).  TIFF is a lot more
  444.     complex than JFIF, and may well prove less transportable, because
  445.     different vendors have historically implemented slightly different and
  446.     incompatible subsets of TIFF.  It's not likely that adding JPEG to the mix
  447.     will do anything to improve this situation.
  448. Both of these formats were developed with input from all the major vendors
  449. of JPEG-related products; it's reasonably likely that future commercial
  450. products will adhere to one or both standards.  (However, as of right now,
  451. January 1992, it's too early for many such products to have appeared.)
  452.  
  453. A particular case that people may be interested in is Apple's QuickTime
  454. software for the Macintosh.  QuickTime uses a JFIF-compatible format wrapped
  455. inside the Mac-specific PICT structure.  Conversion between JFIF and
  456. PICT/JPEG should be pretty straightforward; in fact Apple may release a
  457. utility for the purpose.
  458.  
  459. I believe that Usenet should adopt JFIF as the replacement for GIF in
  460. picture postings.  JFIF is simpler than TIFF and is available now; the
  461. TIFF/JPEG spec is still being hammered out.  Even when TIFF/JPEG is
  462. available, the JFIF format is likely to be a widely supported "lowest
  463. common denominator"; TIFF/JPEG files may never be as transportable.
  464.  
  465.  
  466. 11)  And what about arithmetic coding?
  467.  
  468. The JPEG spec defines two different "back end" modules for the final output
  469. of compressed data: either Huffman coding or arithmetic coding is allowed.
  470. The choice has no impact on image quality, but arithmetic coding usually
  471. produces a smaller compressed file.  On typical images, arithmetic coding
  472. produces a file 5 or 10 percent smaller than Huffman coding.  (All the
  473. file-size numbers previously cited are for Huffman coding.)
  474.  
  475. Unfortunately, the particular variant of arithmetic coding specified by the
  476. JPEG standard is subject to patents owned by IBM, AT&T, and Mitsubishi.
  477. Thus *you cannot legally use arithmetic coding* unless you obtain licenses
  478. from these companies.  (The "fair use" doctrine allows people to implement
  479. and test the algorithm, but actually storing any images with it is dubious
  480. at best.)
  481.  
  482. At least in the short run, I recommend that people not worry about
  483. arithmetic coding; the space savings isn't great enough to justify the
  484. potential legal hassles.  In particular, arithmetic coding *should not*
  485. be used for any images to be exchanged on Usenet.
  486.  
  487. There is some small chance that the legal situation may change in the
  488. future.  Stay tuned for further details.
  489.  
  490.  
  491. 12)  Does loss accumulate with repeated compression/decompression?
  492.  
  493. It would be nice if, having compressed an image with JPEG, you could
  494. decompress it, manipulate it (crop off a border, say), and recompress it
  495. without any further image degradation beyond what you lost initially.
  496. Unfortunately THIS IS NOT THE CASE.  In general, recompressing an altered
  497. image loses more information, though (usually) not as much as was lost the
  498. first time around.
  499.  
  500. The next best thing would be that if you decompress an image and recompress
  501. it *without changing it* then there is no further loss, i.e., you get an
  502. identical JPEG file.  Even this is not true; at least, not with the current
  503. free JPEG software.  It's essentially a problem of accumulation of roundoff
  504. error.  If you repeatedly compress and decompress, the image will eventually
  505. degrade to where you can see visible changes from the first-generation
  506. output.  (It usually takes many such cycles to get visible change.)
  507. One of the things on our to-do list is to see if accumulation of error can
  508. be avoided or limited, but I am not hopeful about it.
  509.  
  510. In any case, the most that could possibly be guaranteed would be that
  511. compressing the unmodified full-color output of djpeg, at the original
  512. quality setting, would introduce no further loss.  Even such simple changes
  513. as cropping off a border could cause further roundoff-error degradation.
  514. (If you're wondering why, it's because the pixel-block boundaries move.
  515. If you cropped off only multiples of 16 pixels, you might be safe, but
  516. that's a mighty limited capability!)
  517.  
  518. The bottom line is that JPEG is a useful format for archival storage and
  519. transmission of images, but you don't want to use it as an intermediate
  520. format for sequences of image manipulation steps.  Use a lossless format
  521. (PPM, RLE, TIFF, etc) while working on the image, then JPEG it when you are
  522. ready to file it away.  Aside from avoiding degradation, you will save a lot
  523. of compression/decompression time this way :-).
  524.  
  525.  
  526. ---------------------
  527.  
  528. For more information about JPEG in general or the free JPEG software in
  529. particular, contact the Independent JPEG Group at jpeg-info@uunet.uu.net.
  530.  
  531. -- 
  532.             tom lane
  533.             organizer, Independent JPEG Group
  534. Internet: tgl@cs.cmu.edu    BITNET: tgl%cs.cmu.edu@carnegie
  535.  
  536.  
  537.