From tgl+@cs.cmu.edu Thu Mar 3 11:00:11 1994 Xref: saips.cv.nrao.edu comp.graphics:32204 alt.graphics.pixutils:5795 alt.binaries.pictures.utilities:8798 alt.binaries.pictures.d:12467 alt.binaries.pictures.erotica.d:24268 comp.answers:3830 alt.answers:1892 news.answers:18045 Newsgroups: comp.graphics,alt.graphics.pixutils,alt.binaries.pictures.utilities,alt.binaries.pictures.d,alt.binaries.pictures.erotica.d,comp.answers,alt.answers,news.answers Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!darwin.sura.net!howland.reston.ans.net!noc.near.net!das-news.harvard.edu!honeydew.srv.cs.cmu.edu!tgl From: tgl+@cs.cmu.edu (Tom Lane) Subject: JPEG image compression: Frequently Asked Questions Message-ID: Followup-To: alt.binaries.pictures.d Summary: Useful info about JPEG (JPG) image files and programs Keywords: JPEG, image compression, FAQ Sender: news@cs.cmu.edu (Usenet News System) Supersedes: Nntp-Posting-Host: g.gp.cs.cmu.edu Reply-To: jpeg-info@uunet.uu.net Organization: School of Computer Science, Carnegie Mellon Date: Sun, 20 Feb 1994 23:16:19 GMT Approved: news-answers-request@MIT.Edu Expires: Sun, 20 Mar 1994 23:15:40 GMT Lines: 1094 Archive-name: jpeg-faq Last-modified: 20 February 1994 This article discusses JPEG image compression. Suggestions for additions and clarifications are welcome. New since version of 6 February 1994: * New version of DVPEG (3.0l). * Miscellaneous minor improvements in wording. This article includes the following sections: [1] What is JPEG? [2] Why use JPEG? [3] When should I use JPEG, and when should I stick with GIF? [4] How well does JPEG compress images? [5] What are good "quality" settings for JPEG? [6] Where can I get JPEG software? [6A] viewers, application programs, etc. [6B] source code [7] What's all this hoopla about color quantization? [8] What are some rules of thumb for converting GIF images to JPEG? [9] Does loss accumulate with repeated compression/decompression? [10] Why all the argument about file formats? [11] How do I recognize which file format I have, and what do I do about it? [12] How does JPEG work? [13] Isn't there a lossless JPEG? [14] What about arithmetic coding? [15] Could an FPU speed up JPEG? How about a DSP chip? Sections 1-6 are basic info that every JPEG user needs to know; sections 7-15 are more advanced info. This article is posted every 2 weeks. You can always find the latest version in the news.answers archive at rtfm.mit.edu (18.70.0.209). By FTP, fetch rtfm.mit.edu:/pub/usenet/news.answers/jpeg-faq. If you don't have FTP, send e-mail to mail-server@rtfm.mit.edu with the body send usenet/news.answers/jpeg-faq (If you don't get a reply, the server may be misreading your return address; add a line such as "path myname@mysite" to specify your correct e-mail address to reply to.) Many other FAQ articles are available in the news.answers archive, which is also accessible via WAIS, WWW, and Gopher services. For more information about the archive, retrieve the file rtfm.mit.edu:/pub/usenet/news.answers/news-answers/introduction. ---------- [1] What is JPEG? JPEG (pronounced "jay-peg") is a standardized image compression mechanism. JPEG stands for Joint Photographic Experts Group, the original name of the committee that wrote the standard. JPEG is designed for compressing either full-color or gray-scale images of natural, real-world scenes. It works well on photographs, naturalistic artwork, and similar material; not so well on lettering, simple cartoons, or line drawings. JPEG handles only still images, but there is a related standard called MPEG for motion pictures. JPEG is "lossy," meaning that the decompressed image isn't quite the same as the one you started with. (There are lossless image compression algorithms, but JPEG achieves much greater compression than is possible with lossless methods.) JPEG is designed to exploit known limitations of the human eye, notably the fact that small color changes are perceived less accurately than small changes in brightness. Thus, JPEG is intended for compressing images that will be looked at by humans. If you plan to machine-analyze your images, the small errors introduced by JPEG may be a problem for you, even if they are invisible to the eye. A useful property of JPEG is that the degree of lossiness can be varied by adjusting compression parameters. This means that the image maker can trade off file size against output image quality. You can make *extremely* small files if you don't mind poor quality; this is useful for applications like indexing image archives. Conversely, if you aren't happy with the output quality at the default compression setting, you can jack up the quality until you are satisfied, and accept lesser compression. Another important aspect of JPEG is that decoders can trade off decoding speed against image quality, by using fast but inaccurate approximations to the required calculations. Until recently, most publicly available JPEG code has adopted a best-possible-quality philosophy, but we are now starting to see the appearance of viewers that give up some image quality in order to obtain significant speedups. [2] Why use JPEG? There are two good reasons: to make your image files smaller, and to store 24-bit-per-pixel color data instead of 8-bit-per-pixel data. Making image files smaller is a big win for transmitting files across networks and for archiving libraries of images. Being able to compress a 2 Mbyte full-color file down to 100 Kbytes or so makes a big difference in disk space and transmission time! (If you are comparing GIF and JPEG, the size ratio is more like four to one. More details in section 4.) If your viewing software doesn't support JPEG directly, you'll have to convert JPEG to some other format for viewing or manipulating images. Even with a JPEG-capable viewer, it takes longer to decode and view a JPEG image than to view an image of a simpler format such as GIF. Thus, using JPEG is essentially a time/space tradeoff: you give up some time in order to store or transmit an image more cheaply. It's worth noting that when network or phone transmission is involved, the time savings from transferring a shorter file can be greater than the extra time needed to decompress the file. The second fundamental advantage of JPEG is that it stores full color information: 24 bits/pixel (16 million colors). GIF, the other image format widely used on Usenet, can only store 8 bits/pixel (256 or fewer colors). GIF is reasonably well matched to inexpensive computer displays --- most run-of-the-mill PCs can't display more than 256 distinct colors at once. But full-color hardware is getting cheaper all the time, and JPEG images look *much* better than GIFs on such hardware. Within a couple of years, 8-bit GIF will seem as obsolete as black-and-white MacPaint format does today. Furthermore, for reasons detailed in section 7, JPEG is far more useful than GIF for exchanging images among people with widely varying display hardware. Hence JPEG is considerably more appropriate than GIF for use as a Usenet posting standard. A lot of people are scared off by the term "lossy compression". But when it comes to representing real-world scenes, *no* digital image format can retain all the information that impinges on your eyeball. By comparison with the real-world scene, JPEG loses far less information than GIF. The technical meaning of "lossy" has nothing to do with this, though; it refers to loss of information over repeated compression cycles, a problem that you may or may not care about. (If you do, see section 9.) [3] When should I use JPEG, and when should I stick with GIF? JPEG is *not* going to displace GIF entirely; for some types of images, GIF is superior in image quality, file size, or both. One of the first things to learn about JPEG is which kinds of images to apply it to. Generally speaking, JPEG is superior to GIF for storing full-color or gray-scale images of "realistic" scenes; that means scanned photographs and similar material. Any continuous variation in color, such as occurs in highlighted or shaded areas, will be represented more faithfully and in less space by JPEG than by GIF. GIF does significantly better on images with only a few distinct colors, such as line drawings and simple cartoons. Not only is GIF lossless for such images, but it often compresses them more than JPEG can. For example, large areas of pixels that are all *exactly* the same color are compressed very efficiently indeed by GIF. JPEG can't squeeze such data as much as GIF does without introducing visible defects. (One implication of this is that large single-color borders are quite cheap in GIF files, while they are best avoided in JPEG files.) Computer-drawn images (ray-traced scenes, for instance) usually fall between photographs and cartoons in terms of complexity. The more complex and subtly rendered the image, the more likely that JPEG will do well on it. The same goes for semi-realistic artwork (fantasy drawings and such). JPEG has a hard time with very sharp edges: a row of pure-black pixels adjacent to a row of pure-white pixels, for example. Sharp edges tend to come out blurred unless you use a very high quality setting. Edges this sharp are rare in scanned photographs, but are fairly common in GIF files: borders, overlaid text, etc. The blurriness is particularly objectionable with text that's only a few pixels high. If you have a GIF with a lot of small-size overlaid text, don't JPEG it. Plain black-and-white (two level) images should never be converted to JPEG; they violate all of the conditions given above. You need at least about 16 gray levels before JPEG is useful for gray-scale images. It should also be noted that GIF is lossless for gray-scale images of up to 256 levels, while JPEG is not. If you have a large library of GIF images, you may want to save space by converting the GIFs to JPEG. This is trickier than it may seem --- even when the GIFs contain photographic images, they are actually very poor source material for JPEG, because the images have been color-reduced. Non-photographic images should generally be left in GIF form. Good-quality photographic GIFs can often be converted with no visible quality loss, but only if you know what you are doing and you take the time to work on each image individually. Otherwise you're likely to lose a lot of image quality or waste a lot of disk space ... quite possibly both. Read sections 7 and 8 if you want to convert GIFs to JPEG. [4] How well does JPEG compress images? Very well indeed, when working with its intended type of image (photographs and suchlike). For full-color images, the uncompressed data is normally 24 bits/pixel. The best known lossless compression methods can compress such data about 2:1 on average. JPEG can typically achieve 10:1 to 20:1 compression without visible loss, bringing the effective storage requirement down to 1 to 2 bits/pixel. 30:1 to 50:1 compression is possible with small to moderate defects, while for very-low-quality purposes such as previews or archive indexes, 100:1 compression is quite feasible. An image compressed 100:1 with JPEG takes up the same space as a full-color one-tenth-scale thumbnail image, yet it retains much more detail than such a thumbnail. For comparison, a GIF version of the same image would start out by sacrificing most of the color information to reduce the image to 256 colors (8 bits/pixel). This provides 3:1 compression. GIF has additional "LZW" compression built in, but LZW doesn't work very well on typical photographic data; at most you may get 5:1 compression overall, and it's not at all uncommon for LZW to be a net loss (less than 3:1 overall compression). When a JPEG file is made from full-color data, using a quality setting just high enough to prevent visible loss, the JPEG will typically be a factor of four or five smaller than a GIF file made from the same data. Gray-scale images do not compress by such large factors. Because the human eye is much more sensitive to brightness variations than to hue variations, JPEG can compress hue data more heavily than brightness (gray-scale) data. A gray-scale JPEG file is generally only about 10%-25% smaller than a full-color JPEG file of similar visual quality. But the uncompressed gray-scale data is only 8 bits/pixel, or one-third the size of the color data, so the calculated compression ratio is much lower. The threshold of visible loss is often around 5:1 compression for gray-scale images. The exact threshold at which errors become visible depends on your viewing conditions. The smaller an individual pixel, the harder it is to see an error; so errors are more visible on a computer screen (at maybe 70 dots/inch) than on a high-quality color printout (300 or more dots/inch). Thus a higher-resolution image can tolerate more compression ... which is fortunate considering it's much bigger to start with. The numbers quoted above are typical for screen viewing. Also note that the threshold of visible error varies considerably across images. [5] What are good "quality" settings for JPEG? Most JPEG compressors let you pick a file size vs. image quality tradeoff by selecting a quality setting. There seems to be widespread confusion about the meaning of these settings. "Quality 95" does NOT mean "keep 95% of the information", as some have claimed. The quality scale is purely arbitrary; it's not a percentage of anything. In fact, quality scales aren't even standardized across JPEG programs. The quality settings discussed in this article apply to the free JPEG software described in section 6B, and to many programs based on it. Other JPEG implementations, notably Apple's and HSI's, use completely different quality scales; for instance, Apple's scale covers 0-4, not 0-100. Some programs don't even provide a numeric scale, just "high"/"medium"/"low"-style choices. (Fortunately, this doesn't prevent different implementations from exchanging compressed files.) In most cases the user's goal is to pick the lowest quality setting, or smallest file size, that decompresses into an image indistinguishable from the original. This setting will vary from one image to another and from one observer to another, but here are some rules of thumb. For good-quality, full-color source images, the default quality setting (Q 75) is very often the best choice. This setting is about the lowest you can go without expecting to see defects in a typical image. Try Q 75 first; if you see defects, then go up. If the image was less than perfect quality to begin with, you might be able to drop down to Q 50 without objectionable degradation. On the other hand, you might need to go to a *higher* quality setting to avoid further loss. Q 85 to 95 is often best for converting GIFs (see section 8 for more info). Except for experimental purposes, never go above about Q 95; using Q 100 will produce a file two or three times as large as Q 95, but of hardly any better quality. If you see a file made with Q 100, it's a pretty sure sign that the maker didn't know what he/she was doing. If you want a very small file (say for preview or indexing purposes) and are prepared to tolerate large defects, a Q setting in the range of 5 to 10 is about right. Q 2 or so may be amusing as "op art". [6] Where can I get JPEG software? Most of the programs described in this section are available by FTP. If you don't know how to use FTP, see the FAQ article "How to find sources". (If you don't have direct access to FTP, read about ftpmail servers in the same article.) That article appears regularly in news.answers, or you can get it by sending e-mail to mail-server@rtfm.mit.edu with "send usenet/news.answers/finding-sources" in the body. The "Anonymous FTP List FAQ" may also be helpful --- it's usenet/news.answers/ftp-list/faq in the news.answers archive. NOTE: this list changes frequently. If you have a copy more than a couple months old, get the latest JPEG FAQ from the news.answers archive. [6A] If you are looking for viewers, application programs, etc: This section covers programs for the following kinds of systems: X Windows, MS-DOS, Microsoft Windows, OS/2, Macintosh, Amiga, Atari ST, Acorn Archimedes, NeXT. If you don't see what you want for your machine, check out the free JPEG source code described in section 6B. Assuming you have a C compiler and at least a little knowledge of compiling C programs, you should be able to prepare JPEG conversion programs from the source code. You'll also need a viewer program. If your display is 8 bits or less, any GIF viewer will do fine; if you have a display with more color capability, try to find a viewer that can read Targa or PPM 24-bit image files. Note that this list concentrates on free and shareware programs that you can obtain over Internet; but a few commercial programs are listed too. If you choose a commercial JPEG product, make sure that it can handle the Usenet- standard JFIF file format, or you won't be able to exchange images with anyone else. (See section 10 if you want to know more about file formats.) X Windows: XV (shareware, $25) is an excellent viewer for JPEG, GIF, and many other image formats. It can also do format conversion and some simple image manipulations. It's available for FTP from ftp.cis.upenn.edu (130.91.6.8), file pub/xv/xv-3.00a.tar.Z. Version 3.00 is a major upgrade with support for 24-bit displays and many other improvements; however, it is brand new and still has some bugs lurking. If you prefer not to be on the bleeding edge, stick with version 2.21, available from the same place. Note that version 2.21 is not a good choice if you have a 24-bit display (you'll get only 8-bit color), nor is it good for converting 24-bit images to JPEG. But 2.21 works fine for converting GIF and other 8-bit images to JPEG. CAUTIONS: * with version 3.0, if you have an 8-bit display then you need to "lock 8-bit mode" to get decent display of JPEG images. (But do NOT do this if you intend to resave the image, because it'll be written from the 8-bit version, thus costing you image quality.) * with version 2.21, you need to check the "save at normal size" checkbox when saving a JPEG file, or the file will be blurry. Both of these workarounds can be set up in your .Xdefaults file. Another good choice for X Windows is John Cristy's free ImageMagick package, available from ftp.x.org (198.112.44.100), file contrib/ImageMagick.tar.Z. This package handles many image processing and conversion tasks. The ImageMagick viewer handles 24-bit displays correctly; for colormapped displays, it does better (though slower) color quantization than XV or the basic free JPEG software. The current version is 2.3.6. Both of the above are large, complex packages. If you just want a simple image viewer, try xloadimage or xli. xloadimage views and converts many image file types including JPEG. Version 4.1 has better JPEG support than prior versions and is easier to install. xloadimage is free and available >from ftp.x.org, file contrib/xloadimage.4.1.tar.Z. xli is a variant version of xloadimage; xli is slightly better as an interactive viewer, but it can't be used as a converter, and it supports fewer file formats. xli is also free and available from ftp.x.org, file contrib/xli.1.15.tar.Z. If you want a command-line JPEG conversion program, see the IJG source code described in section 6B. (This code is included as a subdirectory in most of the above-mentioned packages.) MS-DOS: This covers plain DOS; for Windows or OS/2 programs, see the next headings. QPEG is the fastest noncommercial JPEG viewer I know of. In exchange for speed, QPEG gives up some image quality, particularly on 256-or-less-color displays. Its best feature is a really-fast small preview window, which is great for searching through lots of image files. Also views GIF and Targa. Requires 386-or-better CPU and VGA-or-better display card. Shareware, $20. Current version is 1.3f, available from ftp.tu-clausthal.de (139.174.2.10), file pub/msdos/graphics/qpeg13f.exe (a self-extracting archive). From the USA, access to that site is very slow; instead try ftp.rahul.net in directory pub/bryanw/pc/jpeg/. DVPEG is a free viewer for JPEG, GIF, Targa, and PPM files. The current version, 3.0l, is available by FTP from sunee.uwaterloo.ca (129.97.50.50), file pub/jpeg/viewers/dvpeg30l.zip. (That's lower case l, not digit 1.) This is a good basic viewer that works on either 286 or 386/486 machines. The user interface is clunky but functional. DVPEG is substantially faster than it used to be; on hi-color displays it is nearly as fast as QPEG. Lesser-used DOS viewers include: * DISPLAY, alias DISP. Has many nice image manipulation features including contact-sheet generation. But for simple viewing, it is unfriendly and harder to use than the above programs. Requires 386 or better, does not work under Windows. Current version is 1.61, available from nctuccca.edu.tw: /PC/graphics/disp/disp161.zip. Freeware. * ColorView for DOS. This viewer's main advantage is easy installation. Menu interface is spiffy-looking but I find it a bit clunky to use. Does not require 386, should work with any display that has a VESA driver. Current version is 2.1, available from Simtel archive sites (see NOTE below), file msdos/graphics/dcview21.zip. Requires a VESA graphics driver; if you don't have one, look in vesadrv2.zip or vesa-tsr.zip from the same directory. Shareware, $30. DISRECOMMENDATION: The well-known GIF viewer CompuShow (CSHOW, recently renamed 2SHOW) supports JPEG, but CSHOW's JPEG implementation is crummy: it's much slower than any of the above viewers, and the image quality is poor except on hi-color displays. Too bad ... it'd have been nice to see a good JPEG capability in CSHOW. If you want it anyway, see Simtel archive sites (see NOTE below), file msdos/gif/cshw101a.zip. Shareware, $25. Due to the remarkable variety of PC graphics hardware, any one of these viewers might not work on your particular machine. If you can't get *any* of them to work, you'll need to use one of the following conversion programs to convert JPEG to GIF, then view with your favorite GIF viewer. (If you have hi-color hardware, don't use GIF as the intermediate format; try to find a TARGA-capable viewer instead. VPIC5.0 is reputed to do the right thing with hi-color displays.) The free IJG JPEG converters are available from Simtel archive sites (see NOTE below), file msdos/graphics/jpeg4.zip (or jpeg4386.zip if you have a 386 and extended memory). These programs will convert JPEG to and from GIF, Targa, and PPM formats; they are DOS compilations of the free source code described in section 6B. Handmade Software offers free JPEG<=>GIF conversion tools, GIF2JPG/JPG2GIF. These are slow and are limited to conversion to and from GIF format; in particular, they can't produce 24-bit color output from a JPEG. The sole advantage of these tools is that they will read and write HSI's proprietary JPEG format as well as the Usenet-standard JFIF format. Since HSI-format files are rather widespread on BBSes, this is a useful capability. Version 2.0 of these tools is free (prior versions were shareware). Get it from Simtel archive sites (see NOTE below), file msdos/graphics/gif2jpg2.zip. NOTE: do not use HSI format for files to be posted on Usenet, since it is not readable on non-PC platforms. Handmade Software also has a shareware image conversion and manipulation package, Image Alchemy. This will translate JPEG files (both JFIF and HSI formats) to and from many other image formats. It can also display images. A demo version of Image Alchemy version 1.7 is available from Simtel archive sites (see NOTE below), file msdos/graphics/alch17.zip. JPGINDEX is a useful tool for making indexes of JPEG image collections. Available from Simtel archive sites, file msdos/graphics/jpgidx13.zip. NOTE ABOUT SIMTEL FILES: The largest Internet collection of PC-related programs is the Simtel archives (named for the original archive site, now defunct). The principal archive site for these files is oak.oakland.edu (141.210.10.117), which keeps Simtel files under /pub; so look in, eg, /pub/msdos/graphics. There are many mirror sites which keep copies of the Simtel files; for quickest response you should use the mirror site closest to you. Consult the periodic postings in comp.archives.msdos.announce to find your nearest mirror site. If you have no FTP capability, the same postings will tell you how to retrieve Simtel files by e-mail. Microsoft Windows: LView is a freeware viewer/converter for JPEG, GIF, Targa, and BMP files. The latest version is 3.1, available from ftp.std.com (192.74.137.7), file src/pc/graphics/lview/lview31.zip. Requires 386 or better CPU. This is a very good, feature-laden program. LView can load JPEGs with either fast/low-quality (ECJ) code or slow/high-quality (IJG) code. WinECJ is a fast, no-frills viewer with image quality noticeably worse than most other JPEG viewers. But it's faster than other Windows viewers, so if you don't want to exit Windows and run QPEG, it's good for previewing. (You can purchase a version with better image quality for AUD$30.) Version 1.2 is free and available from Simtel archive sites (see NOTE above), file msdos/windows3/winecj12.zip. Requires Windows 3.1 and 256-or-more-colors mode. If you want more than bare-bones features, try LView instead; LView with the ECJ option is only fractionally slower than WinECJ, and it does much more. WinJPEG (shareware, $20) displays JPEG,GIF,Targa,TIFF,PCX, and BMP files; it can write all of these formats too, so it can be used as a converter. It has some other nifty features including screen capture, color-balance adjustment, and slideshow. The current version is 2.43, available from ftp.cica.indiana.edu, file pub/pc/win3/desktop/winjp243.zip. (This is a 286-compatible version; if you register, you'll get the 386-and-up version, which is roughly twice as fast.) DVPEG (see DOS heading) works under Windows, but only in full-screen mode, not in a window. Also note that you can run the DOS conversion programs described earlier inside a Windows DOS window. OS/2: The following files are available from ftp-os2.cdrom.com (192.153.46.2): os2/2_x/graphics/joevw122.zip JoeView 1.22: free JPEG/GIF/BMP/PCX/TIFF viewer. os2/2_x/graphics/pmjpeg15.zip PMJPEG 1.5: OS/2 2.x port of WinJPEG, a popular viewer for Windows (see description in Windows section). Shareware, $20. os2/2_x/graphics/pmvu86a.zip PMView 0.86a: JPEG/GIF/BMP/Targa/PCX viewer. GIF viewing very fast, JPEG viewing roughly the same speed as the above two programs. Has image manipulation & slideshow functions. Shareware, $35. os2/2_x/graphics/imgarc13.zip Image Archiver 1.03: image conversion/viewing with PM graphical interface. Strong on conversion functions, viewing is a bit weaker. Shareware, $15. os2/2_x/graphics/jpegv4.zip 32-bit version of free IJG conversion programs, version 4. os2/all/graphics/jpeg4_16.zip 16-bit version of same, for OS/2 1.x. All of the OS/2 viewers require Palette Manager for best display quality. Macintosh: Most Mac JPEG programs rely on Apple's JPEG implementation, which is part of the QuickTime system extension; so you need to have QuickTime installed. To use QuickTime, you need a 68020 or better CPU and you need to be running System 6.0.7 or later. (If you're running System 6, you must also install the 32-bit QuickDraw extension; it is built-in on System 7.) The latest version of QuickTime is 1.6.1, available by FTP from ftp.apple.com, file dts/mac/sys.soft/quicktime/quicktime-1-6-1.hqx. Mac users should keep in mind that QuickTime's JPEG format, PICT/JPEG, is not the same as the Usenet-standard JFIF JPEG format. (See section 10 for details.) If you post images on Usenet, make sure they are in JFIF format. Most of the programs mentioned here can handle either format. JPEGView is an excellent free program for viewing JFIF, PICT/JPEG, and GIF files. It also can convert between the two JPEG formats and can create preview images for files. The current version is 3.1, available from sumex-aim.stanford.edu (36.44.0.6), file info-mac/grf/util/jpeg-view-31.hqx. Requires System 7 and QuickTime. JPEGView usually produces the best color image quality of all the currently available Mac JPEG viewers, and it needs much less memory to view large images than most other Mac viewers. Given a large image, JPEGView automatically scales it down to fit on the screen, rather than presenting scroll bars like most other viewers. (You can zoom in on any desired portion, though.) Some people like this behavior, some don't. Overall, JPEGView's user interface is very well thought out. GIFConverter, a shareware ($40) image viewer/converter, supports JFIF, PICT/JPEG, GIF, and many other image formats. Current version is 2.3.7, available at mac.archive.umich.edu (141.211.120.11), file mac/graphics/graphicsutil/gifconverter2.37.cpt.hqx. Requires System 6.0.5 or later. GIFConverter is not better than JPEGView as a plain JPEG/GIF viewer, but it has much more extensive image manipulation and format conversion capabilities. Also, GIFConverter can load and save JFIF images *without* QuickTime, so it is your best bet if your machine is too old to run QuickTime. (But it's faster with QuickTime.) Hint: if GIFConverter runs out of memory while loading a large JPEG, try converting the file to GIF with JPEG Convert, then viewing the GIF version. JPEG Convert, a Mac version of the free IJG JPEG conversion utilities, is available from sumex-aim.stanford.edu, file info-mac/app/jpeg-convert-10.hqx. This will run on any Mac, but it only does file conversion, not viewing. You can use it in conjunction with any GIF viewer. Previous versions of this FAQ recommended Imagery JPEG v0.6, a JPEG<=>GIF converter based on an old version of the IJG code. If you are using this program, you definitely should replace it with JPEG Convert. Storm Technology's Picture Decompress is a free JPEG viewer/converter. This rather old program is inferior to the above programs in many ways, but it will run without System 7 or QuickTime, so you may be forced to use it on older systems. (It does need 32-bit QuickDraw, so really old machines can't use it.) You can get it from sumex-aim.stanford.edu, file info-mac/app/picture-decompress-201.hqx. If your machine is too old to run 32-bit QuickDraw (a Mac Plus for instance), GIFConverter is your only choice for single-program JPEG viewing. If you don't want to pay for GIFConverter, use JPEG Convert and a free GIF viewer. More and more commercial Mac applications are supporting JPEG, although not all can deal with the Usenet-standard JFIF format. Adobe Photoshop, version 2.0.1 or later, can read and write JFIF-format JPEG files (use the JPEG plug-in from the Acquire menu). You must set the file type of a downloaded JPEG file to 'JPEG' to allow Photoshop to recognize it. Amiga: Most programs listed in this section are available from "AmiNet" archive sites. The master AmiNet site is wuarchive.wustl.edu (128.252.135.4), but there are many mirror sites and you should try to use the closest one. FastJPEG is a new free JPEG viewer; it's fast and has pretty good image quality, but it has some limitations (notably, it won't view grayscale JPEGs, nor anything other than JPEG format). Version 1.0 is available from Aminet sites, file pub/aminet/gfx/show/FastJPEG_1.0.lha. HamLab Plus is an excellent JPEG viewer/converter, as well as being a general image manipulation tool. It's cheap (shareware, $20) and can read several formats besides JPEG. The current version is 2.0.8. A demo version is available from AmiNet sites, file pub/aminet/gfx/edit/hamlab208d.lha. The demo version will crop images larger than 512x512, but it is otherwise fully functional. Rend24 (shareware, $30) is an image renderer that can display JPEG, ILBM, and GIF images. The program can be used to create animations, even capturing frames on-the-fly from rendering packages like Lightwave. The current version is 1.05, available from AmiNet sites, file pub/aminet/os30/gfx/rend105.lha. (Note: although this directory is supposedly for AmigaDOS 3.0 programs, the program will also run under AmigaDOS 1.3, 2.04 or 2.1.) Viewtek is a free JPEG/ILBM/GIF/ANIM viewer. The current version is 2.0, available from AmiNet sites, file pub/aminet/gfx/show/ViewTek20.lha. Viewtek is fast but sacrifices some image quality to get the speed. The free IJG JPEG software is available compiled for Amigas from AmiNet sites, file pub/aminet/gfx/conv/AmigaJPEGV4.lha. These programs convert JPEG to/from PPM,GIF,Targa formats. If you're willing to spend real money, there are several commercial packages that support JPEG. Two are written by Thomas Krehbiel, the author of Rend24 and Viewtek. These are CineMorph, a standalone image morphing package, and ImageFX, an impressive 24-bit image capture, conversion, editing, painting, effects and prepress package that also includes CineMorph. Both are distributed by Great Valley Products. Art Department Professional (ADPro), >from ASDG Inc, is the most widely used commercial image manipulation software for Amigas. ImageMaster, from Black Belt Systems, is another well-regarded commercial graphics package with JPEG support. The Amiga world is heavily infested with quick-and-dirty JPEG programs, many based on an ancient beta-test version of the free IJG JPEG software (thanks to a certain magazine that published same on its disk-of-the-month, without so much as notifying the authors). Among these are "AugJPEG", "NewAmyJPEG", "VJPEG", and probably others I have not even heard of. In my opinion, anything older than IJG version 3 (March 1992) is not worth the disk space it's stored on; if you have such a program, trash it and get something newer. Atari ST: GEM-View (shareware, $26) displays JPEG, GIF, and other image formats. Current version is 2.48, available from atari.archive.umich.edu, file /atari/Graphics/Gemview/gview248.lzh. This is a well regarded viewer. The English documentation tends to be a few versions behind, though. The free IJG JPEG software is available compiled for Atari ST/TT/etc >from atari.archive.umich.edu, file /atari/Graphics/jpeg4bin.zoo. These programs convert JPEG to/from PPM, GIF, Targa formats. For monochrome ST monitors, try MGIF, which manages to achieve four-level gray-scale effect by flickering. Version 4.2 loads JPEG files much faster than 4.1 did. Available from atari.archive.umich.edu, file /atari/Graphics/mgif42b.zoo. Acorn Archimedes: !ChangeFSI, supplied with RISC OS 3 version 3.10, can convert from and view JPEG JFIF format. Provision is also made to convert images to JPEG, although this must be done from the CLI rather than by double-clicking. The Acorn archive at micros.hensa.ac.uk (148.88.8.84) contains several JPEG-capable programs. Read the file /micros/arch/riscos/index for retrieval instructions. Interesting archive entries include: a022 Translator 7.18: image file format converter (shareware) b008 FYEO 1.02: For Your Eyes Only, fast JPEG/GIF image viewer b024 ARCJPEG 1.12R: IJG v4 software (JPEG<=>PPM,GIF,Targa) w/ desktop front end There's also a commercial product called !JPEG which provides JPEG read/write functionality and direct JPEG viewing, as well as a host of other image format conversion and processing options. Contact: DT Software, FREEPOST, Cambridge, UK. Tel: 0223 841099. NeXT: ImageViewer is a PD utility that displays images and can do some format conversions. The current version reads JPEG but does not write it. ImageViewer is available from the NeXT archives at sonata.cc.purdue.edu and cs.orst.edu, file pub/next/3.0/bin/ImageViewer0.9i.tar.Z. Note that there is an older version floating around that does not support JPEG. NeXTStep includes built-in support for TIFF/JPEG, but not for the Usenet-standard JFIF format. Be warned that the TIFF/JPEG standard is likely to change away from the flavor currently produced by NeXTStep, so compatibility with other platforms is doubtful. [6B] If you are looking for source code to work with: Free, portable C code for JPEG compression is available from the Independent JPEG Group, which I lead. A package containing our source code, documentation, and some small test files is available from ftp.uu.net (192.48.96.9) in directory /graphics/jpeg. The current release is v4, file jpegsrc.v4.tar.Z. (This is a compressed TAR file; don't forget to retrieve in binary mode.) You can retrieve this file by FTP or UUCP. Copies can also be found at many other Internet sites. If you are on a PC and don't know how to cope with .tar.Z format, you may prefer ZIP format, which you can find at Simtel archive sites (see NOTE above), file msdos/graphics/jpegsrc4.zip. On CompuServe, see the GRAPHSUPPORT forum (GO GRAPHSUP), library 15, file jpgs4a.zip. If you have no FTP access, you can retrieve the source from your nearest comp.sources.misc archive; version 4 appeared as issues 55-72 of volume 34. (If you don't know how to retrieve comp.sources.misc postings, see the FAQ article "How to find sources", referred to at the top of section 6.) The free JPEG code provides conversion between JPEG "JFIF" format and image files in GIF, PBMPLUS PPM/PGM, Utah RLE, and Truevision Targa file formats. The core compression and decompression modules can easily be reused in other programs, such as image viewers. The package is highly portable; we have tested it on many machines ranging from PCs to Crays. We have released this software for both noncommercial and commercial use. Companies are welcome to use it as the basis for JPEG-related products. We do not ask a royalty, although we do ask for an acknowledgement in product literature (see the README file in the distribution for details). We hope to make this software industrial-quality --- although, as with anything that's free, we offer no warranty and accept no liability. The Independent JPEG Group is a volunteer organization; if you'd like to contribute to improving our software, you are welcome to join. A different free JPEG implementation, written by the PVRG group at Stanford, is available from havefun.stanford.edu in directory pub/jpeg. This program is designed for research and experimentation rather than production use; it is slower, harder to use, and less portable than the IJG code, but it implements a larger subset of the JPEG standard. [7] What's all this hoopla about color quantization? Most people don't have full-color (24 bit per pixel) display hardware. Typical display hardware stores 8 or fewer bits per pixel, so it can display 256 or fewer distinct colors at a time. To display a full-color image, the computer must choose an appropriate set of representative colors and map the image into these colors. This process is called "color quantization". (This is something of a misnomer; "color selection" or "color reduction" would be a better term. We're stuck with the standard usage though.) Clearly, color quantization is a lossy process. It turns out that for most images, the details of the color quantization algorithm have *much* more impact on the final image quality than do any errors introduced by JPEG itself (except at the very lowest JPEG quality settings). Making a good color quantization algorithm is a black art, and no single algorithm is best for all images. Since JPEG is a full-color format, converting a color JPEG image for display on 8-bit-or-less hardware requires color quantization. The speed and image quality of a JPEG viewer running on such hardware are largely determined by its quantization algorithm. You'll see great variation in image quality among viewers on 8-bit displays, much more than occurs on 24-bit displays. On the other hand, a GIF image has already been quantized to 256 or fewer colors. (A GIF *does* have a specific number of colors in its palette, and the format doesn't allow more than 256 palette entries.) GIF has the advantage that the image maker precomputes the color quantization, so viewers don't have to; this is one of the things that make GIF viewers faster than JPEG viewers. But this is also the *disadvantage* of GIF: you're stuck with the maker's quantization. If the maker quantized to a different number of colors than what you can display, you'll either waste display capability or have to quantize again to further reduce the number of colors (which results in much poorer image quality than if you had quantized once from a full-color image). Furthermore, if the maker didn't use a high-quality color quantization algorithm, you're out of luck --- the image is ruined. For this reason, JPEG promises significantly better image quality than GIF for all users whose machines don't match the image maker's display hardware. JPEG's full color image can be quantized to precisely match the viewer's display hardware. Furthermore, you will be able to take advantage of future improvements in quantization algorithms (there is a lot of active research in this area), or purchase better display hardware, to get a better view of JPEG images you already have. With a GIF, you're stuck forevermore with what was sent. A growing number of people have better-than-8-bit display hardware already: 15-bit "hi-color" PC displays, true 24-bit displays on workstations and Macintoshes, etc. For these people, GIF is already obsolete, as it cannot represent an image to the full capabilities of their display. JPEG images can drive these displays much more effectively. In short, JPEG is an all-around better choice than GIF for representing images in a machine-independent fashion. It's sometimes thought that a JPEG converted from a GIF shouldn't require color quantization. This is false: even when you feed a 256-or-less-color GIF into JPEG, what comes out of the decompressor is not 256 colors, but thousands of colors. This happens because JPEG's lossiness affects each pixel a little differently, so two pixels that started with identical colors will usually come out with slightly different colors. Each original color gets "smeared" into a group of nearby colors. Therefore quantization is always required to display a color JPEG on a colormapped display, regardless of the image source. The same effect makes it nearly meaningless to talk about the number of colors used by a JPEG image. Even if you tried to count the number of distinct pixel values, different JPEG decoders would give you different results because of roundoff error differences. I occasionally see posted images described as "256-color JPEG". This tells me that the poster (a) hasn't read this FAQ and (b) probably converted the JPEG from a GIF. JPEGs can be classified as color or gray-scale, but number of colors just isn't a useful concept for JPEG, any more than it is for a real photograph. [8] What are some rules of thumb for converting GIF images to JPEG? Converting GIF files to JPEG is a tricky business --- you are piling one set of limitations atop a quite different set, and the results can be awful. Certainly a JPEG made from a GIF will never be as good as a JPEG made from true 24-bit color data. But if what you've got is GIFs, and you need to save space, here are some hints for getting the best results. With care and a clean source image, it's often possible to make a JPEG of quality equivalent to the GIF. This does *not* mean that the JPEG looks identical to the GIF --- it probably won't on an 8-bit display, because the color quantization process used to display the JPEG won't exactly match the GIF's quantization. (See section 7 for more about that.) But given a good viewer, the JPEG will look as good as the GIF. Some people claim that on 24-bit displays, a carefully converted JPEG can look better than the GIF source, because dither patterns have been eliminated. (More about dithering in a moment.) On the other hand, JPEG conversion *will* degrade an unsuitable image or one that is converted carelessly. If you are not willing to take the amount of trouble suggested below, you're much better off leaving your GIF images alone. Simply cranking the JPEG quality setting up to a very high value wastes space (which defeats the whole point of the exercise...) and some images will be degraded anyway. The first rule is never to convert an image that's not appropriate for JPEG (see section 3 about that). Large, high-visual-quality photographic images are usually the best material. And they take up lots of space in GIF form, so they offer significant potential space savings. (A good rule of thumb is not to bother converting any GIF that's much under 100 Kbytes; the potential space savings isn't worth the hassle.) The second rule is to look at each JPEG, to make sure you are happy with it, before throwing away the corresponding GIF; this will give you a chance to re-do the conversion with a higher quality setting if necessary. Also compare the file sizes --- if the image isn't suitable JPEG material, a JPEG file of reasonable quality may come out *larger* than the GIF. The third rule is to get rid of the border. Many people have developed an odd habit of putting a large single-color border around a GIF image. While useless, this is nearly free in terms of storage cost in GIF files. It is NOT free in JPEG files, either in storage space or in decoding time; and the sharp border boundary can create visible artifacts ("ghost" edges). Furthermore, when viewing a bordered JPEG on an 8-bit display, the quantizer will think the border color is important because there's so much of it, and hence will waste color palette entries on the border, thus actually reducing the displayed quality of the main part of the image! So do yourself a favor and crop off any border before JPEGing. Gray-scale images usually convert without much problem. When using cjpeg, be sure to specify -gray. (Otherwise, cjpeg treats a GIF as color data; this works but wastes space and time for gray-scale data.) Quality settings around the default (75) are usually fine. Color images are much trickier. Color GIFs of photographic images are usually "dithered" to fool your eye into seeing more than the 256 colors that GIF can actually store. If you enlarge the image, you will find that adjacent pixels are often of significantly different colors; at normal size the eye averages these pixels together to produce the illusion of an intermediate color value. The trouble with dithering is that, to JPEG, it looks like high-spatial-frequency color noise; and JPEG can't compress noise very well. The resulting JPEG file is both larger and of lower image quality than what you would have gotten from JPEGing the original full color image (if you had it). To get around this, you need to "smooth" the GIF image before compression. Smoothing averages together nearby pixels, thus approximating the color that you thought you saw anyway, and in the process getting rid of the rapid color changes that give JPEG trouble. Proper use of smoothing will both reduce the size of the compressed file and give you a better-looking output image than you'd get without smoothing. With the V4 free JPEG software (or programs based on it), a simple smoothing capability is built in. Try "-smooth 10" or so when converting GIFs. Values of 10 to 25 seem to work well for high-quality GIFs. Heavy-handed dithering may require larger smoothing factors. (If you can see regular fine-scale patterns on the GIF image even without enlargement, then strong smoothing is definitely called for.) Too large a smoothing factor will blur the output image, which you don't want. If you are an image processing wizard, you can also do smoothing with a separate filtering program, but appropriate use of such tools is beyond the scope of this FAQ. Quality settings around 85 (a bit higher than default) usually work well when converting color GIFs, assuming that you've picked a good smoothing factor. You may need to go higher if you can't hide the dithering pattern with a reasonable smoothing factor. Really badly dithered GIFs are best left as GIFs. Don't expect JPEG files converted from GIFs to be as small as those created directly from full-color originals. You won't be able to smooth away all of the dithering noise without ruining the image, and this noise wastes space. Typically, a good-quality converted JPEG will be 1/2 to 1/3rd the size of the GIF file, not 1/4th as suggested in section 4. (If the JPEG comes out much more than half the size of the GIF, this is a good sign that the image shouldn't be converted at all.) The upshot of all this is that "cjpeg -quality 85 -smooth 10" is probably a good starting point for converting color GIFs. But if you care about the image, you'll want to check the results and maybe try a few other settings. Blindly converting a large GIF library at this or any other setting is a recipe for disaster. [9] Does loss accumulate with repeated compression/decompression? It would be nice if, having compressed an image with JPEG, you could decompress it, manipulate it (crop off a border, say), and recompress it without any further image degradation beyond what you lost initially. Unfortunately THIS IS NOT THE CASE. In general, recompressing an altered image loses more information. Hence it's important to minimize the number of generations of JPEG compression between initial and final versions of an image. It turns out that if you decompress and recompress an image at the same quality setting first used, little or no further degradation occurs. (Counterintuitively, this works better the lower the quality setting. But you must use *exactly* the same setting, or all bets are off.) This means that you can make local modifications to an image without material degradation of other areas of the image. Unfortunately, cropping doesn't count as a local change! JPEG processes the image in small blocks, and cropping usually moves the block boundaries, so that the image looks completely different to JPEG. You can take advantage of the low-degradation behavior if you are careful to crop the top and left margins only by a multiple of the block size (typically 16 pixels), so that the remaining blocks start in the same places. The bottom line is that JPEG is a useful format for archival storage and transmission of images, but you don't want to use it as an intermediate format for sequences of image manipulation steps. Use a lossless 24-bit format (PPM, RLE, TIFF, etc) while working on the image, then JPEG it when you are ready to file it away. Aside from avoiding degradation, you will save a lot of compression/decompression time this way :-). [10] Why all the argument about file formats? Strictly speaking, JPEG refers only to a family of compression algorithms; it does *not* refer to a specific image file format. The JPEG committee was prevented from defining a file format by turf wars within the international standards organizations. Since we can't actually exchange images with anyone else unless we agree on a common file format, this leaves us with a problem. In the absence of official standards, a number of JPEG program writers have just gone off to "do their own thing", and as a result their programs aren't compatible with anybody else's. The closest thing we have to a standard JPEG format is some work that's been coordinated by people at C-Cube Microsystems. They have defined two JPEG-based file formats: * JFIF (JPEG File Interchange Format), a "low-end" format that transports pixels and not much else. * TIFF/JPEG, aka TIFF 6.0, an extension of the Aldus TIFF format. TIFF is a "high-end" format that will let you record just about everything you ever wanted to know about an image, and a lot more besides :-). TIFF is a lot more complex than JFIF, and is generally less transportable, because different vendors have often implemented slightly different and incompatible subsets of TIFF. It's not likely that adding JPEG to the mix will do anything to improve this situation. Both of these formats were developed with input from all the major vendors of JPEG-related products; it's reasonably likely that future commercial products will adhere to one or both standards. JFIF has emerged as the de-facto standard on Usenet. JFIF is simpler than TIFF and is available now; the TIFF 6.0 spec for incorporating JPEG is not widely implemented, partly because it has some serious design flaws. It is likely that the TIFF 6.0 JPEG section will be changed significantly before widespread adoption occurs. Even when TIFF/JPEG is well defined, the JFIF format is likely to be a widely supported "lowest common denominator"; TIFF/JPEG files may never be as transportable. A particular case of wide interest is Apple's Macintosh QuickTime software. QuickTime uses a JFIF-compatible format wrapped inside the Mac-specific PICT structure. Conversion between JFIF and PICT/JPEG is pretty straightforward, and several Mac programs are available to do it (see Mac portion of section 6A). If you have an editor that handles binary files, you can even strip a PICT/JPEG file down to JFIF by hand; see section 11 for details. Another particular case is Handmade Software's DOS programs (GIF2JPG/JPG2GIF and Image Alchemy). These programs are capable of reading and writing JFIF format. By default, though, they write a proprietary format developed by HSI. This format is NOT readable by any non-HSI programs and should not be used for Usenet postings. Use the -j switch to get JFIF output. (This applies to old versions of these programs; the current releases emit JFIF format by default. You still should be careful not to post HSI-format files, unless you want to get flamed by people on non-PC platforms.) [11] How do I recognize which file format I have, and what do I do about it? If you have an alleged JPEG file that your software won't read, it's likely to be HSI format or some other proprietary JPEG-based format. You can tell what you have by inspecting the first few bytes of the file: 1. A JFIF-standard file will start with the four bytes (hex) FF D8 FF E0, followed by two variable bytes (often hex 00 10), followed by 'JFIF'. 2. If you see FF D8 at the start, but not the 'JFIF' marker, you may have a "raw JPEG" file. This is probably decodable as-is by JFIF software --- it's worth a try, anyway. 3. HSI files start with 'hsi1'. You're out of luck unless you have HSI software. Portions of the file may look like plain JPEG data, but they won't decompress properly with non-HSI programs. 4. A Macintosh PICT file, if JPEG-compressed, will have several hundred bytes of header (often 726 bytes, but not always) followed by JPEG data. Look for the 3-byte sequence (hex) FF D8 FF --- the text 'Photo - JPEG' will usually appear shortly before this header, and 'JFIF' or 'AppleMark' will usually appear shortly after it. Strip off everything before the FF D8 FF and you should be able to decode the file. 5. Anything else: it's a proprietary format, or not JPEG at all. If you are lucky, the file may consist of a header and a raw JPEG data stream. If you can identify the start of the JPEG data stream (look for FF D8), try stripping off everything before that. In uuencoded Usenet postings, the characteristic JFIF pattern is "begin" line M_]C_X ... whereas uuencoded HSI files will start with "begin" line M:'-I ... If you learn to check for the former, you can save yourself the trouble of downloading non-JFIF files. [12] How does JPEG work? The buzz-words to know are chrominance subsampling, discrete cosine transforms, coefficient quantization, and Huffman or arithmetic entropy coding. This article's too long already, so I'm not going to say more than that here. For technical information see the comp.compression FAQ, which is available from the news.answers archive at rtfm.mit.edu, in files /pub/usenet/news.answers/compression-faq/part[1-3]. If you need help in using the news.answers archive, see the top of this article. The comp.compression FAQ is also a good starting point for information on other state-of-the-art image compression methods, such as wavelets and fractals. A quick comparison: wavelets are likely to be the basis of the next generation of image-compression standards, but they are 5 to 10 years behind JPEG in the standardization pipeline; as for fractals, it's very difficult to separate real performance from hype. [13] Isn't there a lossless JPEG? There's a great deal of confusion on this subject. The JPEG committee did define a truly lossless compression algorithm (i.e., one that guarantees the final output is bit-for-bit identical to the original input). However, this lossless mode has almost nothing in common with the regular lossy JPEG algorithm, and it offers much less compression. At present, very few implementations of lossless JPEG exist. The PVRG code mentioned in section 6B is the only noncommercial code I know of that handles lossless JPEG. Lossless JPEG typically compresses full-color data by around 2:1. Lossless JPEG works well only on continuous-tone images; it does not provide useful compression of palette-color images or low-bit-depth images. (The JBIG standard is considered superior to lossless JPEG for images of less than 6 bits/sample.) Cranking a regular JPEG implementation up to its maximum quality setting *does not* get you lossless storage. Even at the maximum possible quality setting, regular JPEG is not lossless, because it is subject to roundoff errors in various calculations. Roundoff errors are nearly always too small to be seen, but they will accumulate if you put the image through multiple cycles of compression. Many implementations won't even let you get to the maximum possible setting, because it's such an inefficient way to use regular JPEG. With the IJG JPEG software, for example, you have to say not only "-quality 100" but also "-sample 1x1" to eliminate all deliberate loss of information. The resulting files are far larger and of only fractionally better quality than files generated at more reasonable settings. If you really need lossless storage, don't try to approximate it with regular JPEG. [14] What about arithmetic coding? The JPEG spec defines two different "back end" modules for the final output of compressed data: either Huffman coding or arithmetic coding is allowed. The choice has no impact on image quality, but arithmetic coding usually produces a smaller compressed file. On typical images, arithmetic coding produces a file 5 to 10 percent smaller than Huffman coding. (All the file-size numbers previously cited are for Huffman coding.) Unfortunately, the particular variant of arithmetic coding specified by the JPEG standard is subject to patents owned by IBM, AT&T, and Mitsubishi. Thus *you cannot legally use arithmetic coding* unless you obtain licenses >from these companies. (The "fair use" doctrine allows people to implement and test the algorithm, but actually storing any images with it is dubious at best.) At least in the short run, I recommend that people not worry about arithmetic coding; the space savings isn't great enough to justify the potential legal hassles. In particular, arithmetic coding *should not* be used for any images to be exchanged on Usenet. [15] Could an FPU speed up JPEG? How about a DSP chip? Since JPEG is so compute-intensive, many people suggest that using an FPU chip (a math coprocessor) should speed it up. This is not so. Production-quality JPEG programs use only integer arithmetic and so are unaffected by the presence or absence of floating-point hardware. Converting the key operations to floating point would only slow things down. (On some very expensive machines, where floating point arithmetic is actually faster than integer, such a rewrite would indeed be a win. Most such hardware has "Cray" on the nameplate :-).) On the other hand, DSP chips are ideally suited for fast repetitive integer arithmetic, so programming a DSP to do JPEG can yield significant speedups. DSPs are starting to be found as add-ons for workstations and PCs, so you can expect to see DSP-based JPEG programs popping up. --------------------- If you have more questions about JPEG in general or the free JPEG software in particular, contact the Independent JPEG Group at jpeg-info@uunet.uu.net. -- tom lane organizer, Independent JPEG Group tgl@cs.cmu.edu or tgl@netcom.com From rip@rcl.wau.nl Thu Mar 3 11:00:43 1994 Newsgroups: alt.graphics.pixutils Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!EU.net!sun4nl!news.nic.surfnet.nl!wau.nl!RIP@rcl.wau.nl From: rip@rcl.wau.nl (Frans Rip (Wageningen Agric.U., Netherlands, 08370-82098)) Subject: Re: DOS screen capture software Message-ID: Sender: news@news.wau.nl (News Administrator) Reply-To: rip@rcl.wau.nl Organization: Wageningen Agricultural University References: <1994Feb19.135612.7651@Princeton.EDU> Date: Mon, 28 Feb 1994 09:52:09 GMT Lines: 16 In article <1994Feb19.135612.7651@Princeton.EDU>, bstango@tucson.Princeton.EDU (Robert T. Stango) writes: > >Hope this is the place for this. >I am looking for a TSR screen capture program to capture some screen >shots to import to Bard's Tale Construction Set. Anybody know of any?? >This is for a DOS based computer (286). I have software to convert to >the final file format (lbm) so I don't care what format the capture >software saves the picture in. Thanks in advance. > have you tried PCXDUMP ? version 9 (oct 1993) is available via FTP on wuarchive.wustl.edu in /mirrors/msdos/graphics otherwise you may contact Frans Rip From jef@netcom.com Thu Mar 3 11:02:20 1994 Xref: saips.cv.nrao.edu alt.graphics.pixutils:5843 alt.answers:1963 Newsgroups: alt.graphics.pixutils,alt.answers Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!howland.reston.ans.net!agate!library.ucla.edu!csulb.edu!csus.edu!netcom.com!jef From: jef@netcom.com (Jef Poskanzer) Subject: (28feb93) Welcome to alt.graphics.pixutils - automated posting. Message-ID: Followup-To: poster Reply-To: Jef Poskanzer Organization: Paratheo-Anametamystikhood of Eris Esoteric Date: Tue, 1 Mar 1994 16:04:17 GMT Approved: jef@netcom.com Expires: Tue, 5 Apr 1994 16:04:17 GMT Lines: 178 Archive-name: pixutils-faq This message is automatically posted once a month to inform new readers and remind old readers of what alt.graphics.pixutils is about. It was last changed on 28feb93. If you don't want to see this posting every month, please add the subject line to your kill file. Thank you. --- Jef Jef Poskanzer jef@netcom.com jef@well.sf.ca.us "...Is this a trick question?" - - - - - - - - - - This newsgroup is for discussion of pixmap utilities. A pixmap is any image composed of pixels, whether it's a one-bit-deep bitmap, a grayscale image, colormapped, or full color. There are dozens of different file formats for storing pixmaps, and there are a number of software packages for converting between formats and displaying formats. Some of these packages are listed in the Frequently Asked Questions posting in comp.graphics - the relevant excerpts are appended below. Discussion of these packages and other similar ones will probably be the main topic here. Posting uuencoded sample pixmaps for some weird format you're trying to decipher is fine, especially if they are small, but mass posting of pixmaps is not welcome. - - - - - - - - - - [from the comp.graphics weekly posting] 7) Free image manipulation software. There are a number of toolkits for converting from one image format to another, doing simple image manipulations such as size scaling, plus the above-mentioned 24 -> 8, color -> gray, gray -> b&w conversions. Here are pointers to some of them: PBMPLUS, by Jef Poskanzer. Comprehensive format conversion and image manipulation package. The latest version is always available via anonymous FTP as ftp.ee.lbl.gov:pbmplus*.tar.Z, wuarchive.wustl.edu:graphics/graphics/packages/pbmplus/pbmplus*.tar.Z, and export.lcs.mit.edu:contrib/pbmplus*.tar.Z. IM Raster Toolkit, by Alan Paeth (awpaeth@watcgl.uwaterloo.ca). Provides a portable and efficient format and related toolkit. The format is versatile in supporting pixels of arbitrary channels, components, and bit precisions while allowing compression and machine byte-order independence. The kit contains more than 50 tools with extensive support of image manipulation, digital halftoning and format conversion. Previously distributed on tape c/o the University of Waterloo, an FTP version will appear someday. Utah RLE Toolkit. Conversion and manipulation package, similar to PBMPLUS. Available via FTP as cs.utah.edu:pub/urt-*, weedeater.math.yale.edu:pub/urt-*, and freebie.engin.umich.edu:pub/urt-*. Fuzzy Pixmap Manipulation, by Michael Mauldin . Conversion and manipulation package, similar to PBMPLUS. Version 1.0 available via FTP as nl.cs.cmu.edu:/usr/mlm/ftp/fbm.tar.Z, ftp.uu.net:pub/fbm.tar.Z, and ucsd.edu:graphics/fbm.tar.Z. Img Software Set, by Paul Raveling . Reads and writes its own image format, displays on an X11 screen, and does some image manipulations. Version 1.3 is available via FTP as export.lcs.mit.edu:contrib/img_1.3.tar.Z, and venera.isi.edu:pub/img_1.3.tar.Z along with a large collection of color images. Xim, The X Image Manipulator, by Philip Thompson, does essential interactive displaying, editing, filtering, converting images. Available in the X11R4 source tree. A more recent version is available via ftp from gis.mit.edu. Requires X11R4 and the OSF/Motif1.1 toolkit for the interface. This is not a paint package. Xim reads/writes gif, xwd, xbm, tiff, rle, xim, (writes level 2 eps) and other formats. Also has a library and command line utilities for building your owm applications. xloadimage, by Jim Frost . Reads in images in various formats and displays them on an X11 screen. Available via FTP as export.lcs.mit.edu:contrib/xloadimage*, and in your nearest comp.sources.x archive. TIFF Software, by Sam Leffler . Nice portable library for reading and writing TIFF files, plus a few tools for manipulating them and reading other formats. Available via FTP as ucbvax.berkeley.edu:pub/tiff/*.tar.Z or ftp.uu.net:graphics/tiff.tar.Z xtiff, an X11 tool for viewing a TIFF file. It was written to handle as many different kinds of TIFF files as possible while remaining simple, portable and efficient. xtiff illustrates some common problems with building pixmaps and using different visual classes. It is distributed as part of Sam Leffler's libtiff package and it is also available on export.lcs.mit.edu, ftp.uu.net and comp.sources.x. xtiff 2.0 was announced in 4/91; it includes Xlib and Xt versions. ALV, a Sun-specific image toolkit. Version 2.0.6 posted to comp.sources.sun on 11dec89. Also available via email to alv-users-request@cs.bris.ac.uk. popi, an image manipulation language. Version 2.1 posted to comp.sources.misc on 12dec89. ImageMagick, an X11 package for display and interactive manipulation of images. Includes tools for image conversion, annotation, compositing, animation, and creating montages. ImageMagick can read and write many of the more popular image formats. Available via FTP as export.lcs.mit.edu:contrib/ImageMagick.tar.Z. Khoros, a huge (~100 meg) graphical development environment based on X11R4. Khoros components include a visual programming language, code generators for extending the visual language and adding new application packages to the system, an interactive user interface editor, an interactive image display package, an extensive library of image and signal processing routines, and 2D/3D plotting packages. Available via FTP as ftp.eece.unm.edu:pub/khoros/*. LaboImage, a SunView-based image processing and analysis package. It includes more than 200 image manipulation, processing and measurement routines, on-line help, plus tools such as an image editor, a color table editor and several biomedical utilities. Available via anonymous FTP as ftp.ads.com:pub/VISION-LIST-ARCHIVE/SHAREWARE/LaboImage_4.0.tar.Z The San Diego Supercomputer Center Image Tools, software tools for reading, writing, and manipulating raster images. Binaries for some machines available via anonymous FTP in sdsc.edu:sdscpub. The Independent JPEG Group has written a package for reading and writing JPEG files. FTP to ftp.uu.net:graphics/jpeg/jpegsrc.v?.tar.Z Don't forget to set binary mode when you FTP tar files. For you MILNET folks who still don't have name servers, the IP addresses are: ftp.ads.com 128.229.36.25 cs.utah.edu 128.110.4.21 export.lcs.mit.edu 18.24.0.12 freebie.engin.umich.edu 141.212.68.23 ftp.ee.lbl.gov 128.3.112.20 ftp.uu.net 192.48.96.9 gis.mit.edu 18.80.1.118 nl.cs.cmu.edu 128.2.222.56 ftp.eece.unm.edu 129.24.24.119 sdsc.edu 132.249.20.22 ucbvax.berkeley.edu 128.32.133.1 venera.isi.edu 128.9.0.32 weedeater.math.yale.edu 130.132.23.17 wuarchive.wustl.edu 128.252.135.4 Please do *not* post or mail messages saying "I can't FTP, could someone mail this to me?" There are a number of automated mail servers that will send you things like this in response to a message. See item 13 below for details on some. 8) Format documents for GIF, TIFF, IFF, BIFF, WHIFF, etc. You almost certainly don't need these. Read the above item 7 on free image manipulation software. Get one or more of these packages and look through them. Chances are excellent that the image converter you were going to write is already there. But if you still want one of the format documents, many such files are available by anonymous ftp from zamenhof.cs.rice.edu (128.42.1.75) in directory pub/graphics.formats. These files were collected off the net and are believed to be correct. This archive includes pixel formats, and two- and three-dimensional object formats. Other file format descriptions are welcome, send to Mark Hall . 13) How to FTP by email. There are a number of sites that archive the Usenet sources newsgroups and make them available via an email query system. You send a message to an automated server saying something like "send comp.sources.unix/fbm", and a few hours or days later you get the file in the mail. In addition, there used to be some FTP-by-mail servers, which would accept FTP commands by mail and then mail back the results. Unfortunately, the services were abused, and have been shut down. From oliver@zeus.fysik4.kth.se Thu Mar 3 11:03:36 1994 Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!pipex!sunic!news.kth.se!news.kth.se!oliver From: oliver@zeus.fysik4.kth.se (Oliver Trepte) Newsgroups: alt.graphics.pixutils Subject: New release of Netpbm Date: 02 Mar 1994 13:56:40 GMT Organization: The Royal Institute of Technology Lines: 44 Distribution: alt Message-ID: NNTP-Posting-Host: zeus.fysik4.kth.se Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Available for anonymous ftp from any of the sites listed below is now a new release of the image conversion and manipulation package Netpbm. Netpbm is a network supported follow-up to Pbmplus. It contains a lot of new facilities, options, and bug fixes. ftp sites: * wuarchive.wustl.edu (128.252.135.4), directory /graphics/graphics/packages/NetPBM * ikaros.fysik4.kth.se (130.237.35.2), directory /pub/netpbm. * ftp.informatik.uni-oldenburg.de (134.106.1.9). This site also carries binaries for the Amiga. * peipa.essex.ac.uk (155.245.115.161), directory ipa/src/manip * ftp.rahul.net (192.160.13.1), directory /pub/davidsen/source * ftp.cs.ubc.ca, directory /ftp/archive/netpbm You'll also find a mirror site at the BBS: * sixhub.tmr.com, phone +1 518 3468033, in the "source" area. News in this release of Netpbm (compared to the 7 December 1993 release): PGM asciitopgm New filter. fitstopgm Replaced by fitstopnm. pgmtofits Replaced by pnmtofits. pgmtopbm Upgraded. pgmkernel New filter. PPM ppmchange Upgraded. xvminitoppm New filter. PNM pnmalias New filter. pnmtofits Replacement for pgmtofits. fitstopnm Replacement for fitstopgm. pnmtosgi New filter. sgitopnm New filter. pstopnm New filter. Oliver From Ingo.Wilken@arbi.informatik.uni-oldenburg.de Tue Mar 8 19:26:32 1994 Newsgroups: alt.graphics.pixutils Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!howland.reston.ans.net!pipex!uknet!EU.net!Germany.EU.net!netmbx.de!zib-berlin.de!uniol!Ingo.Wilken From: Ingo.Wilken@arbi.informatik.uni-oldenburg.de (Ingo Wilken) Subject: Re: PPM to GIF/PCX/BMP Organization: University of Oldenburg, Germany Date: Mon, 7 Mar 1994 13:27:16 GMT Message-ID: <1994Mar7.154729.5364@arbi.Informatik.Uni-Oldenburg.DE> References: <2ld0t9$pjh@ugle.unit.no> Keywords: Converting Sender: news@arbi.Informatik.Uni-Oldenburg.DE Lines: 22 are@idt.unit.no (Are Vinje) writes: > Anyone know any good converters which handles PPM format > and GIF/BMP/PCX. Amiga: Hamlab Plus - Shareware, slightly crippled (512x512 size limit) evaluation version available on Aminet ADPro - commercial Unix/X11: XV 3.xx - available on any FTP site that carries X11 stuff > I have got PPMPLUS but I don't like it. Well, it works, it's free, it's portable, you get the source... So what's wrong with it? Ingo -- Ingo Wilken, CS Student, Univ.of Oldenburg, FRG | You mean I really did all of wilken@uniol.uucp (..!uunet!unido!uniol!wilken) | dat stuff? Now dat explains Ingo.Wilken@arbi.informatik.uni-oldenburg.de | why my head hurts an' why I wilken@uniol.zer IRC:Nobody OL:ingo@faramir | feel so bad! -Snarf From gas@globus.ffi.no Thu Mar 10 15:12:02 1994 Xref: saips.cv.nrao.edu comp.graphics:33105 alt.graphics.pixutils:5898 comp.unix.admin:17957 comp.unix.solaris:14416 Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!news.duke.edu!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!sunic!trane.uninett.no!nac.no!helios.ffi.no!helios.ffi.no!gas From: gas@globus.ffi.no (Geir Atle Storhaug) Newsgroups: comp.graphics,alt.graphics.pixutils,comp.unix.admin,comp.unix.solaris Subject: Re: PhotoCD & UNIX ? - PCD to TIFF? Date: 10 Mar 1994 09:50:13 GMT Organization: Forsvarets forskningsinstitutt, Kjeller, Norge. Lines: 22 Distribution: inet Message-ID: References: <1994Mar10.004935.118596@yuma> Reply-To: Geir-Atle.Storhaug@ffi.no NNTP-Posting-Host: globus.ffi.no In-reply-to: ront@picea.CFNR.ColoState.EDU's message of 10 Mar 94 00:49:35 GMT >>>>> "Ronald" == Ronald Thomas writes: In article <1994Mar10.004935.118596@yuma> ront@picea.CFNR.ColoState.EDU (Ronald Thomas) writes: > 3) Is there a PCD to TIFF converter around, perhaps as a new > addition to the PBMplus toolkit? (I'd like a straight, > hi-resolution conversion of the PCD format to TIFF) > 4) Is there a UNIX (SunOS 4.1.3 or Sol 2.2) viewer of Kodak > PhotoCD's, or a program that views/reads/converts the *.pcd > format? Check out hpcdtoppm. I found it at lth.se:/pub/netnews/sources.misc/volume39/hpcdtoppm/*. Kodak also has a "Photo CD Access toolkit" available for Sun. This includes format conversion and viewing etc. Costs £695 in the OK. -- ____ ___ Geir Atle Storhaug (Senior Scientist) / ____/\ (__ X400 : G=Geir-Atle;S=Storhaug;O=ffi;P=uninett;C=no; \___// \___) RFC : Geir-Atle.Storhaug@ffi.no Phone (office): +47-63-807658 Phone (home): +47-63-838987 Fax:+47-63-807509 Forsvarets forskningsinstitutt, FFI/VM, Postboks 25, N-2007 Kjeller, NORWAY From al164580@academ01.mty.itesm.mx Fri Mar 11 13:58:38 1994 Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!math.ohio-state.edu!howland.reston.ans.net!cs.utexas.edu!news.tamu.edu!mtecv2.mty.itesm.mx!al164580 From: al164580@academ01.mty.itesm.mx (Alejandro Reyes Ramos) Newsgroups: alt.graphics.pixutils Subject: Re: xv3 won't read JPEG Date: 11 Mar 94 04:29:30 GMT Organization: ITESM, Campus Monterrey Lines: 13 Message-ID: References: <2l95ts$bff@gondor.sdsu.edu> NNTP-Posting-Host: openlab70.mty.itesm.mx hurlbut@ucssun1.sdsu.edu (jack hurlbut) writes: >I've downloaded some JPEG format images from NASA ftp sites that xv3 >can't read. Any ideas? In JPEG FAQ there is a note about another implementation of JPEG which differs from the Independent Group's standard. Probably the files you got are in this format. Try converting them to Targa or something else using djpeg, and then load them with xv. From oliver@zeus.fysik4.kth.se Fri Mar 11 13:58:48 1994 Xref: saips.cv.nrao.edu comp.graphics:33164 alt.graphics.pixutils:5908 comp.unix.admin:17983 comp.unix.solaris:14473 Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!darwin.sura.net!howland.reston.ans.net!pipex!uknet!EU.net!sunic!news.kth.se!news.kth.se!oliver From: oliver@zeus.fysik4.kth.se (Oliver Trepte) Newsgroups: comp.graphics,alt.graphics.pixutils,comp.unix.admin,comp.unix.solaris Subject: Re: PhotoCD & UNIX ? - PCD to TIFF? Date: 11 Mar 1994 08:26:10 GMT Organization: The Royal Institute of Technology Lines: 18 Distribution: inet Message-ID: References: <1994Mar10.004935.118596@yuma> NNTP-Posting-Host: zeus.fysik4.kth.se Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit In-reply-to: ront@picea.CFNR.ColoState.EDU's message of 10 Mar 94 00:49:35 GMT >3) Is there a PCD to TIFF converter around, perhaps as a new addition > to the PBMplus toolkit? (I'd like a straight, hi-resolution > conversion of the PCD format to TIFF) There is an hpcdtoppm utility in the latest release of Netpbm, which you can find at e.g. wuarchive.wustl.edu, /graphics/graphics/packages. I don't know if this will do the work for you. >From the Netpbm README file: Netpbm is based on the widely spread Pbmplus package (release: 10 Dec 91). On top of that, a lot of improvements and additions have been made. After the latest release of Pbmplus, a lot of additional filters have been circulating on the net. The aim of Netpbm was, to collect these and to turn them into a package. This work has been performed by a group of program- mers around the world. Oliver From oman@winternet.mpls.mn.us Sat Mar 12 08:26:48 1994 Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!msuinfo!uwm.edu!news.moneng.mei.com!howland.reston.ans.net!europa.eng.gtefsd.com!emory!news-feed-2.peachnet.edu!umn.edu!mr.net!winternet.mpls.mn.us!oman From: oman@winternet.mpls.mn.us (Jonathan Ort) Newsgroups: alt.graphics.pixutils Subject: Targa File Header Date: 11 Mar 1994 20:45:33 GMT Organization: StarNet Communications, Inc Lines: 33 Message-ID: <2lql9d$1a1@blackice.winternet.mpls.mn.us> NNTP-Posting-Host: icicle.winternet.mpls.mn.us X-Newsreader: TIN [version 1.2 PL2] // Targa file BASE header structure (Type 1) struct TgaHeader_type { BYTE idlen; // Length of I.D. Field BYTE maptype; // Color map type BYTE ttype; // Targa file type WORD cmapor; // junk WORD maplen; // Color map size BYTE mapsize; // # of bits in each color map entry WORD llx; // Lower left x co-ord WORD lly; // Lower left y co-ord WORD Wd; // Width of image WORD Ht; // Height of image BYTE pixsize; // # of bits per pixel BYTE flags; // Image flags } TgaHeader; BYTE is unsigned 8 bits WORD is unsigned 16 bits I think a structure for your images would look like: 0 0 2 0 0 0 0 320 200 24 0 From moore@gold.diac.mmm.com Wed Mar 16 09:15:26 1994 Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!batcomputer!news.reed.edu!usenet.ee.pdx.edu!cs.uoregon.edu!sgiblab!swrinde!emory!news-feed-2.peachnet.edu!umn.edu!dawn.mmm.com!dawn.mmm.com!moore From: moore@gold.diac.mmm.com (Richard Moore) Newsgroups: alt.graphics.pixutils Subject: Re: Bitmap files (.BMP) to .PS or .EPS Date: 15 Mar 1994 20:55:04 GMT Organization: 3M Company, 3M Center, Minnesota, USA Lines: 17 Distribution: usa Message-ID: References: <2lof8s$i8d@nntp2.Stanford.EDU> NNTP-Posting-Host: gold.diac.mmm.com In-reply-to: sk@leland.Stanford.EDU's message of 11 Mar 1994 00:50:36 GMT In article <2lof8s$i8d@nntp2.Stanford.EDU> sk@leland.Stanford.EDU (Sam K.) writes: I'm trying to convert a bitmap image created by a graphics postprocessor to Postscript or Encapsulated Postscript format. Is there a program that does this conversion in DOS or Windows environment? Thanks in advance. Sam sk@blume.stanford.edu Coreldraw handles many different file formats under windows. What is the format of the bitmap image ? Coreldraw can then export to eps or print to ps. Photoshop may do the job also. There is a product called hyjack (?) that I have not used that will convert file formats. rjmoore@mmm.com From moore@gold.diac.mmm.com Wed Mar 16 09:15:35 1994 Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!batcomputer!ghost.dsi.unimi.it!univ-lyon1.fr!jussieu.fr!math.ohio-state.edu!howland.reston.ans.net!europa.eng.gtefsd.com!emory!news-feed-2.peachnet.edu!news-feed-1.peachnet.edu!umn.edu!dawn.mmm.com!dawn.mmm.com!moore From: moore@gold.diac.mmm.com (Richard Moore) Newsgroups: alt.graphics.pixutils Subject: Re: PostScript -> ??? Date: 15 Mar 1994 21:02:58 GMT Organization: 3M Company, 3M Center, Minnesota, USA Lines: 16 Message-ID: References: <2ltf37$1oe@lace.Colorado.EDU> NNTP-Posting-Host: gold.diac.mmm.com In-reply-to: c_walker@cc.colorado.edu's message of 12 Mar 1994 22:18:15 GMT In article <2ltf37$1oe@lace.Colorado.EDU> c_walker@cc.colorado.edu writes: Does anyone know of a package which can convert PostScript files to any other image format? Something for a UNIX platform would be preferred but could also use something MS-DOS based. Thanks in advance. C. Nicholas Walker cwalker@nostromo.cc.colorado.edu #include You can get ghostscript from prep.ai.mit.edu in the /pub/gnu directory. rjmoore@mmm.com From oliver@zeus.fysik4.kth.se Tue Mar 29 09:32:56 1994 Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!zip.eecs.umich.edu!newsxfer.itd.umich.edu!news.cic.net!magnus.acs.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!pipex!sunic!news.kth.se!news.kth.se!oliver From: oliver@zeus.fysik4.kth.se (Oliver Trepte) Newsgroups: alt.graphics.pixutils Subject: Re: P5 to P2 converter wanted Date: 29 Mar 1994 10:11:17 GMT Organization: The Royal Institute of Technology Lines: 7 Message-ID: References: <2mra8p$9nc@nntp2.Stanford.EDU> <2msmj3$q6q@falcon.ccs.uwo.ca> <2n7s6j$p47@news.doit.wisc.edu> NNTP-Posting-Host: zeus.fysik4.kth.se Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit In-reply-to: rownd@engr.wisc.edu's message of 29 Mar 1994 00:19:31 GMT >Would some kind soul please email me a P5 to P2 converter program. I have a >file that is in *.pnm format with a P5 header. I would prefer to work in >a P2 flavor. You could use pnmnoraw from pbmplus or netbpm. Oliver From timl@netcom.netcom.com Tue Mar 29 09:33:19 1994 Xref: saips.cv.nrao.edu alt.graphics.pixutils:6016 comp.graphics.algorithms:4387 alt.binaries.pictures.utilities:8910 alt.binaries.pictures.d:13132 Newsgroups: alt.graphics.pixutils,comp.graphics.algorithms,alt.binaries.pictures.utilities,alt.binaries.pictures.d Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!usenet.cis.ufl.edu!usenet.ufl.edu!gatech!howland.reston.ans.net!wupost!csus.edu!netcom.com!netcom!timl From: timl@netcom.netcom.com (Tim Lesher) Subject: Re: JPEG to Gif converter for windows In-Reply-To: mcscs1mar@zippy.dct.ac.uk's message of 28 Mar 94 19:21:35 +0100 Message-ID: Followup-To: alt.binaries.pictures.d Sender: timl@netcom.com (Tim Lesher) Organization: NETCOM On-line services References: <2mqn6r$3ei@agate.berkeley.edu> <2mor5o$7c6@cville-srv.wam.umd.edu> <1994Mar28.063617.21437@cam.compserv.utas.edu.au> <2n70p1$1al@zeus.rbi.informatik.uni-frankfurt.de> <1994Mar28.192135.2094@zippy.dct.ac.uk> Date: Tue, 29 Mar 1994 06:42:11 GMT Lines: 30 In article <1994Mar28.192135.2094@zippy.dct.ac.uk> mcscs1mar@zippy.dct.ac.uk (A.Raverboy) writes: In article <2n70p1$1al@zeus.rbi.informatik.uni-frankfurt.de>, frank@zeus.rbi.informatik.uni-frankfurt.de (Frank Pilhofer) writes: > > I've got such a program at home that loads jpeg and will even save them > > as gif. But hey, why do you want to do it? Converting to gif will blow > > up the files by factor 2 or more. > > Since I'm typing this post not at home, I just don't remember the name > > of the program, but I'll post it next time. Be patient. > > Does it hell. Converting a JPG to a GIF will probably > either save or add a couple of bytes to the file size. Before we start Yet Another Gif/JPEG flamewar, remember: GIF is a FIXED compression method, meaning that you always get the same compression ratio for a given file. Because it's lossy, JPEG lets you decide how much you want to crunch the data down, so it's possible to take a GIF-format image and crunch it with JPEG in such a manner that you can get a file that's significantly bigger than the GIF, or MUCH smaller. It all depends on how tightly the JPEG file is compresses. Also remember that JPEG is a 24-bit algorithm, while GIF is 8-bit. Depending on your point of view, sometimes you do want an 8-bit image to better go along with whatever 8-bit hardware you're showing it on. (By the way, crossposting a request like this to all the above groups DOESN'T significantly increase your chances of getting a response--it just increases the traffic. Note the followup-to.) Tim From mansfiel@saucer.cc.umr.edu Tue Mar 29 09:33:44 1994 Xref: saips.cv.nrao.edu alt.graphics.pixutils:6017 comp.graphics.algorithms:4388 alt.binaries.pictures.utilities:8911 alt.binaries.pictures.d:13133 alt.binaries.pictures.erotica.d:25824 Newsgroups: alt.graphics.pixutils,comp.graphics.algorithms,alt.binaries.pictures.utilities,alt.binaries.pictures.d,alt.binaries.pictures.erotica.d Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!news.duke.edu!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!vixen.cso.uiuc.edu!moe.ksu.ksu.edu!usenet-feed.umr.edu!saucer.cc.umr.edu!mansfiel From: mansfiel@saucer.cc.umr.edu (Christopher Mansfield) Subject: Re: JPEG to Gif converter for windows Followup-To: alt.graphics.pixutils,comp.graphics.algorithms,alt.binaries.pictures.utilities,alt.binaries.pictures.d,alt.binaries.pictures.erotica.d References: <1994Mar28.063617.21437@cam.compserv.utas.edu.au> Date: Tue, 29 Mar 1994 08:22:50 GMT Nntp-Posting-Host: saucer.cc.umr.edu X-Newsreader: TIN [version 1.1 PL8] Organization: University of Missouri-Rolla, Missouri's Technological University Sender: cnews@umr.edu (UMR Usenet News Administration) Message-ID: <1994Mar29.082250.22880@umr.edu> Lines: 48 Sean 'Guardian' Costain (scostain@lawson.its.utas.edu.au) wrote: : In article <2mqn6r$3ei@agate.berkeley.edu>, jav@uclink.berkeley.edu (Francisco Javier Femenia) writes: : > : >In article <2mor5o$7c6@cville-srv.wam.umd.edu>, : >Maverick wrote: : >> Does anyone have a shareware or freeware version of djpeg (or similar) : >>for windows? Does such a program exist and if so can you mail me or post it : >>here. : >> : >>Please email : >> : >>Thanks, : >> Ritu : >> ritu@wam.umd.edu : > : >Same for me, please. : >Thanks. : >-- : >F. Javier Femenia "I've never even had any real friends." : >jav@uclink.berkeley.edu "Hnurmph." : >FDC Stroll-around Rajah hopeful "Except you, Rajah." _Aladdin_ : Count me in : Angelhawk There is a Windows 3.x program called "Paint Shop Pro" that is incredible. It supports 23 of the most popular formats including JPEG, GIF, PCX, BMP, TIFF, etc. It can convert any file type to any other file type. You can also crop, rotate, dither, adjust brightness and contrast, and anything else you could possibly think of. You can view several images at once in different windows (depending on how much memory you have and how large your swap file is). You can get "Paint Shop Pro" (and "Graphic Workshop" for Windows which does a lot of the same stuff) from "The Software Labs," a mail/phone order shareware catalog. Their phone number is 1-800-569-7900. Call and have a catalog mailed to you. Enjoy! -- |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | Chris Mansfield | "We've upped our standards. | | | Up yours." | | mansfiel@saucer.cc.umr.edu | -Comedy Central | | | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~