JPEG image compression FAQ, part 1/2

JPEG image compression FAQ, part 1/2

Post by Tom La » Wed, 26 Mar 1997 04:00:00


Archive-name: jpeg-faq/part1
Posting-Frequency: every 14 days
Last-modified: 1 March 1997

This article answers Frequently Asked Questions about JPEG image compression.
This is part 1, covering general questions and answers about JPEG.  Part 2
gives system-specific hints and program recommendations.  As always,
suggestions for improvement of this FAQ are welcome.

New since version of 1 February 1997:
  * New section 21 explains how to find height/width in a JPEG file.

This article includes the following sections:

Basic questions:

[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?
[7] How do I view JPEG images posted on Usenet?

More advanced questions:

[8] What is color quantization?
[9] What are some rules of thumb for converting GIF images to JPEG?
[10] Does loss accumulate with repeated compression/decompression?
[11] What is progressive JPEG?
[12] Can I make a transparent JPEG?
[13] Isn't there a lossless JPEG?
[14] Why all the argument about file formats?
[15] How do I recognize which file format I have, and what do I do about it?
[16] How does JPEG work?
[17] What about arithmetic coding?
[18] Could an FPU speed up JPEG?  How about a DSP chip?
[19] Isn't there an M-JPEG standard for motion pictures?
[20] What if I need more than 8-bit precision?
[21] How can my program extract image dimensions from a JPEG file?
[22] Where can I learn about using images on the World Wide Web?

Miscellaneous:

[23] Where are FAQ lists archived?

This article and its companion are posted every 2 weeks.  If you can't find
part 2, you can get it from the news.answers archive at rtfm.mit.edu
(see "[23] Where are FAQ lists archived?").  Part 2 changes very frequently;
get a new copy if the one you are reading is more than a couple months old.

------------------------------

Subject: [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 such
as 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.  Some viewers obtain remarkable speedups in this
way.

------------------------------

Subject: [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 win for transmitting files across networks
and for archiving libraries of images.  Being able to compress a 2 Mbyte
full-color file down to, say, 100 Kbytes makes a big difference in disk
space and transmission time!  And JPEG can easily provide 20:1 compression
of full-color data.  If you are comparing GIF and JPEG, the size ratio is
usually more like 4:1 (see "[4] How well does JPEG compress images?").

If your viewing software doesn't support JPEG directly, you'll have to
convert JPEG to some other format to view the image.  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.  But it's worth noting that when network
or telephone transmission is involved, the time savings from transferring a
shorter file can be greater than the 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 the net, 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,
GIF will probably seem as obsolete as black-and-white MacPaint format does
today.  Furthermore, JPEG is far more useful than GIF for exchanging images
among people with widely varying display hardware, because it avoids
prejudging how many colors to use (see "[8] What is color quantization?").
Hence JPEG is considerably more appropriate than GIF for use as a Usenet
and World Wide Web standard format.

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 real disadvantage of lossy compression is that if you repeatedly
compress and decompress an image, you lose a little quality each time
(see "[10] Does loss accumulate with repeated compression/decompression?").
This is a serious objection for some applications but matters not at all
for many others.

------------------------------

Subject: [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, such as ray-traced scenes, 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).
But icons that use only a few colors are handled better by GIF.

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:
consider 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.  (If you want to
attach descriptive text to a JPEG image, put it in as a comment rather than
trying to overlay it on the image.  Most recent JPEG software can deal with
textual comments in a JPEG file, although older viewers may just ignore the
comments.)

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 8 and 9
if you want to convert GIFs to JPEG.

------------------------------

Subject: [4] How well ...

read more »

 
 
 

JPEG image compression FAQ, part 1/2

Post by Tom La » Mon, 31 Mar 1997 04:00:00


Archive-name: jpeg-faq/part1
Posting-Frequency: every 14 days
Last-modified: 30 March 1997

This article answers Frequently Asked Questions about JPEG image compression.
This is part 1, covering general questions and answers about JPEG.  Part 2
gives system-specific hints and program recommendations.  As always,
suggestions for improvement of this FAQ are welcome.

New since version of 1 March 1997:
  * Updated location for WWW FAQs.

This article includes the following sections:

Basic questions:

[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?
[7] How do I view JPEG images posted on Usenet?

More advanced questions:

[8] What is color quantization?
[9] What are some rules of thumb for converting GIF images to JPEG?
[10] Does loss accumulate with repeated compression/decompression?
[11] What is progressive JPEG?
[12] Can I make a transparent JPEG?
[13] Isn't there a lossless JPEG?
[14] Why all the argument about file formats?
[15] How do I recognize which file format I have, and what do I do about it?
[16] How does JPEG work?
[17] What about arithmetic coding?
[18] Could an FPU speed up JPEG?  How about a DSP chip?
[19] Isn't there an M-JPEG standard for motion pictures?
[20] What if I need more than 8-bit precision?
[21] How can my program extract image dimensions from a JPEG file?
[22] Where can I learn about using images on the World Wide Web?

Miscellaneous:

[23] Where are FAQ lists archived?

This article and its companion are posted every 2 weeks.  If you can't find
part 2, you can get it from the news.answers archive at rtfm.mit.edu
(see "[23] Where are FAQ lists archived?").  Part 2 changes very frequently;
get a new copy if the one you are reading is more than a couple months old.

------------------------------

Subject: [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 such
as 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.  Some viewers obtain remarkable speedups in this
way.

------------------------------

Subject: [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 win for transmitting files across networks
and for archiving libraries of images.  Being able to compress a 2 Mbyte
full-color file down to, say, 100 Kbytes makes a big difference in disk
space and transmission time!  And JPEG can easily provide 20:1 compression
of full-color data.  If you are comparing GIF and JPEG, the size ratio is
usually more like 4:1 (see "[4] How well does JPEG compress images?").

If your viewing software doesn't support JPEG directly, you'll have to
convert JPEG to some other format to view the image.  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.  But it's worth noting that when network
or telephone transmission is involved, the time savings from transferring a
shorter file can be greater than the 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 the net, 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,
GIF will probably seem as obsolete as black-and-white MacPaint format does
today.  Furthermore, JPEG is far more useful than GIF for exchanging images
among people with widely varying display hardware, because it avoids
prejudging how many colors to use (see "[8] What is color quantization?").
Hence JPEG is considerably more appropriate than GIF for use as a Usenet
and World Wide Web standard format.

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 real disadvantage of lossy compression is that if you repeatedly
compress and decompress an image, you lose a little quality each time
(see "[10] Does loss accumulate with repeated compression/decompression?").
This is a serious objection for some applications but matters not at all
for many others.

------------------------------

Subject: [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, such as ray-traced scenes, 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).
But icons that use only a few colors are handled better by GIF.

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:
consider 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.  (If you want to
attach descriptive text to a JPEG image, put it in as a comment rather than
trying to overlay it on the image.  Most recent JPEG software can deal with
textual comments in a JPEG file, although older viewers may just ignore the
comments.)

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 8 and 9
if you want to convert GIFs to JPEG.

------------------------------

Subject: [4] How well does JPEG compress images?

Very well ...

read more »

 
 
 

JPEG image compression FAQ, part 1/2

Post by Tom La » Mon, 31 Mar 1997 04:00:00


Archive-name: jpeg-faq/part2
Posting-Frequency: every 14 days
Last-modified: 30 March 1997

This article answers Frequently Asked Questions about JPEG image compression.
This is part 2, covering system-specific hints and program recommendations
for a variety of computer systems.  Part 1 covers general questions and
answers about JPEG.  As always, suggestions for improvement of this FAQ are
welcome.

New since version of 16 February 1997:
  * Updated location for WWW FAQs.

This article includes the following sections:

General info:

[1] What is covered in this FAQ?
[2] How do I retrieve these programs?

Programs and hints for specific systems:

[3] X Windows
[4] Unix (without X)
[5] MS-DOS
[6] Microsoft Windows
[7] OS/2
[8] Macintosh
[9] Amiga
[10] Atari ST
[11] Acorn Archimedes
[12] NeXT
[13] Other systems

Source code for JPEG:

[14] Freely available source code for JPEG

Miscellaneous:

[15] Which programs support progressive JPEG?
[16] Where are FAQ lists archived?

This article and its companion are posted every 2 weeks.  If you can't find
part 1, you can get it from the news.answers archive at rtfm.mit.edu
(see "[16] Where are FAQ lists archived?"). This article changes frequently;
get a new copy if the one you are reading is more than a couple months old.

------------------------------

Subject: [1] What is covered in this FAQ?

This list describes programs that are of particular interest to JPEG users.
For the most part, I concentrate on viewers, since a viewer program is the
first thing you'll need.  Some general image-editing programs are listed
too, especially if they are useful as plain viewers (meaning that they can
load and display an image as quickly and easily as a dedicated viewer).
Programs that convert JPEG to and from other image file formats are also
covered.

I list only freeware and shareware programs that are available on the
Internet by FTP.  Commercial products are intentionally excluded, to keep
the list to a reasonable size and to avoid any appearance of advertising.
Also, I try to list only programs that are popular among Usenet users, as
indicated by comments and recommendations in news articles.  I have no
access to many of the types of systems covered here, so I have to rely on
what other people say about a program to decide whether to list it.  If you
have an opinion pro or con on any program, I'd appreciate hearing it.

This FAQ also includes a few hints that are specific to a machine or
program, and thus don't belong in the general discussion of part 1.

------------------------------

Subject: [2] How do I retrieve these programs?

All the files mentioned in this FAQ are available by standard Internet FTP.
If you don't know how to use FTP, please read the article "Anonymous FTP
FAQ List", which you can get by sending e-mail to mail-ser...@rtfm.mit.edu
with the single line "send usenet/news.answers/ftp-list/faq" in the body.
(See also "[16] Where are FAQ lists archived?")  This section gives some
quick reminders which are not meant as a substitute for reading the FTP FAQ.

If you do not have direct access to FTP, you can use an "ftpmail" server to
obtain files by e-mail.  See the FTP FAQ for details.

If you use a WWW browser such as Mosaic or Lynx, it will do FTP for you.
To retrieve a file described here as "site.name:/path/to/file", tell the
browser to open the URL "ftp://site.name/path/to/file".  (If you are reading
this FAQ in the WWW FAQ archive, the file names should appear as links that
you can just click on.)  Don't forget to set save-to-disk mode first.

Many of the pointers given here refer to popular central archive sites,
such as ftp.simtel.net for DOS software or sumex-aim.stanford.edu for Mac.
These sites are often overloaded, and are likely to refuse your connection
request when they are busy.  You can try again at a less popular time of
day, or you can look for a "mirror site".  Most central archive sites have
groups of mirror sites that keep copies of their files.  Find out the name
of the mirror site closest to you, and visit that site instead; it's good
net citizenship and you'll get faster response.  Check the FAQs for the
newsgroups specific to your system type to find lists of mirror sites.
(The archive site may list some mirror sites in its connection-refused error
message.  Unfortunately, some FTP programs won't show you the whole message.
WWW browsers are often bad about this.)

If you are able to reach the archive site, but the file you want doesn't
exist, most likely it's been replaced by a newer version.  Get a directory
listing of the directory that's supposed to contain the file, and look for
a file with a similar name but a higher version number.  (If you find an
out-of-date reference in a *current* version of the JPEG FAQ, I'd
appreciate hearing about it by e-mail.)

Practically all of the files listed here are compressed archive files.
This means you need to retrieve them in binary mode.  (WWW browsers do this
automatically, but many older FTP programs must be told to use binary mode.)
Once you've got the archive file, you'll need a decompressor/dearchiver
to extract the program and documentation files inside it.  Check the FAQs
for your system type to find out where to get dearchiver programs.

------------------------------

Subject: [3] X Windows

XV is an excellent viewer for JPEG, GIF, and many other image formats.
It can also do format conversion and some simple image manipulations.
Get it from ftp.cis.upenn.edu:/pub/xv/xv-3.10a.tar.gz.  Shareware, $25.
Version 3.10 has some nifty new features, and it loads JPEGs noticeably
faster than any prior version.  If you're still using version 2.anything,
it's definitely time to upgrade.  HINT: 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.)  You can set this
mode to be default by adding "xv.force8: true" to your .Xdefaults file.

Another excellent choice is John Cristy's free ImageMagick package,
ftp.x.org:/contrib/applications/ImageMagick/ImageMagick-3.7.1.tar.gz.  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 IJG JPEG
software.

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:/R5contrib/xloadimage.4.1.tar.gz.  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:/contrib/applications/xli.1.16.tar.gz.

------------------------------

Subject: [4] Unix (without X)

If you want a command-line JPEG conversion program, see the IJG source code
described in section 14.  (This code is included as a subdirectory in most
of the X programs described above, although they may not have the latest
version.)

Non-X viewers are hard to come by, since they are very hardware dependent.
Linux users with VGA/SVGA displays may like zgv.  Version 2.7 is available
from sunsite.unc.edu:/pub/Linux/apps/graphics/viewers/zgv2.7-bin.tar.gz.
(Several other alternatives are available in the same directory.)
If you use a less popular platform, you're probably out of luck.

------------------------------

Subject: [5] MS-DOS

This covers plain DOS; for Windows or OS/2 programs, see the next sections.

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 ftp.simtel.net,
which is the site referenced by the FTP pointers given below.  However,
there are numerous mirror sites that 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.  You can also access the
Simtel archives via WWW at www.simtel.net.

QPV (formerly called QPEG) is an extremely fast JPEG viewer. In exchange for
speed, QPV 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,TGA,BMP,PNG.
Requires 386-or-better CPU and VGA-or-better display card.  Current version
is 1.7c, available from ftp.tu-clausthal.de:/pub/msdos/graphics/qpv17c.zip.
In the USA, a closer site is ftp.best.com:/pub/bryanw/qpv/.  Shareware, $20.

SEA is a new JPEG/PNG/GIF/etc viewer and file-format converter.  It is
very very fast --- faster than QPV in most cases, according to the authors.
Also, it can read progressive JPEGs; QPV can't.  Current version is 1.2c,
available from ftp.simtel.net:/pub/simtelnet/msdos/graphics/sea12c.zip.
Shareware, $24.  Requires 386-or-better CPU and VESA-compatible display.

DVPEG is a free viewer for JPEG, GIF, Targa, and PPM files.  Current version
is 3.0l, available from sunee.uwaterloo.ca:/pub/jpeg/viewers/dvpeg30l.zip.
(That's lower case l, not digit 1.)  This is a good basic viewer that comes
in both 286 and 386-and-up versions.  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 QPV.  On 8-bit displays, its two-pass
quantization mode is slow but gives much better image quality than QPV can
provide.

Lesser-used DOS viewers include:
* DISPLAY, alias DISP. ...

read more »