From: qralston@gl.pitt.edu (James Ralston Crawford)
Newsgroups: comp.graphics,alt.binaries.pictures.d,alt.binaries.pictures.erotica.d
Subject: get your facts straight about JPEG! (was Re: JPEG viewer...)
Date: 14 Apr 92 05:31:13 GMT
Reply-To: qralston@gl.pitt.edu
Followup-To: alt.binaries.pictures.d
Organization: Computing and Information Services, University of Pittsburgh

First, 2787al@gmuvax2.gmu.edu (Death Angel) shows us his ignorance:

> >	Why don't you simply convert the jpg files to gif & then view
> > those? 
>
>   Because the quality of the picture will decrease and why do that if
> there is a jpeg viewer availble?


And sarnold@bgsu.edu (G. Steve Arnold) then does likewise:

> 	Besides, have you ever timed a Jpeg to Gif conversion? small
> ones for me can take as long as 3 minutes each. It would be easier
> just to have a jpeg viewer.


	JPEG is a complex image compression format designed to work
best with 24-bit images.  The algorithms used to compress and
decompress JPEG files take time.  However, for most users, the
majority of the time spent when trying to view a JPEG file IS NOT
SPENT DOING THE ACTUAL JPEG DECOMPRESSION.  It's spent in the
QUANTIZATION STEP that is required for any graphical displays other
than 24-bit (or higher.)

	First of all, let's explain what "bits" mean.  Not so long
ago, 8-bit was the default graphics standard.  This means that each
pixel in your image is represented by 1 byte.  Taking the mathematical
combination, this means that with 8-bit graphics, you have the
potential for 2^8 (256) colors.  (These combinations then map to a
colormap of some sort, but I won't get in to that.)

	However, 8-bit graphics is on the way out, and 24-bit graphics
(and higher) is on the way in.  In 24-bit graphics, instead of
representing each pixel with 1 byte, each pixel is represented by 3
bytes... one for each of the red, green, and blue components.  So, for
each pixel, there are 256 possible red values, 256 possible green
values, and 256 possible blue values.  Taking the mathematical
combination of that, for each pixel, you have (2^8)(2^8)(2^8) = 2^24 =
16,777,216 possible colors to choose from.

	(Yes, I know I oversimplified things.  But this is long enough
already.)

	Most common file formats of the past (and, unfortunately,
still in use today) use 8-bit color.  GIF, PCX, BMP... they're all
8-bit.  You can't take 24-bit image data and save it in any of these
formats; they don't support it.

	However, JPEG is *NOT* 8-bit.  JPEG is 24-bit.  You *can* save
24-bit image data in JPEG format; in fact, you are SUPPOSED to use
24-bit image data when creating JPEG files.  When you uncompress a
JPEG file, you are left with 24-bit image data.

	Now, here is where the fun starts.  Most graphical displays
are, unfortunately, still 8-bit.  So you have a file that has, say,
100,000 colors in it, but your display can only show you 256 at a
time.

	So, what do you do?

	You do what is called *quantizing* the image.  This involves
using various algorithms to pick 256 colors that best represent the
100,000-color image, and using various dithering algorithms to blend
and blur those colors to approximate the colors that you had to
discard, because your hardware can't show them to you.

	The more complex your dithering algorithm, the more pleasing
the results will look to your eye.  However, the more complex
dithering algorithm you use, the more time it takes.

	THIS IS WHAT TAKES SO DAMN LONG.

	Of course, you can cut corners and use a quick, sloppy
dithering algorithm.  But then the image that you end up staring at
looks like hell.  99% percent of the time, when people bitch about how
poor JPEG quality is, the only thing that is actually "poor" is their
quantization step.  But they're too dim to realize this.

	Now let's pick apart these statements again:

> Because the quality of the picture will decrease and why do that if
> there is a jpeg viewer availble?

	He's on the right track.  Converting to GIF literally destroys
image information, and hence, the quality of the image.  What he fails
to realize though, is that the same "quality decrease" that is
necessary to explode the JPEG file and then hammer it down into a GIF
file is also necessary to display the image on the screen.  (Unless
you can display 32K colors, but I dare say that's the exception and
not the rule.)

	So, unless you have a 32K color card, there is no possible way
you can see anything of higher quality than what would be written in
the GIF file.

> 	Besides, have you ever timed a Jpeg to Gif conversion? small
> ones for me can take as long as 3 minutes each. It would be easier
> just to have a jpeg viewer.

	Steve seems to think that a direct JPEG viewer will save him
the long and tedious required quantization step.  Unfortunately, he's
wrong.

	So, for PC users (and a lot of other users as well), it's a
trade off.  You want a quick, fast JPEG viewer?  Fine.  But your
images are going to look like hell, because the quantization step will
be done poorly.  You want to have a good, high-quality JPEG viewer?
Fine.  But be ready to go walk the dog in between images loads.
(Depending on the speed of your machine, of course.)  But
unfortunately, no one's going to do two snaps up in a circle and pull
the Magic, 2-Second Super-High-Quality JPEG Viewer out of some bodily
orifice.  You just can't have your cake and eat it too.

	Obviously, there's a compromise somewhere in between quality
and waiting time.  Unfortunately, from what I've seen of DOS JPEG
viewers so far, they're skewed way, way, too far towards the "quick
and dirty" mindset.

	Corrections appreciated.  Flamage ignored.

-J

-- 
James Ralston Crawford \ Advanced Graphics Lab
qralston+@pitt.edu \ qralston@pittvms.bitnet
"There's more to being in a band than being in a band."  - DL
Newsgroups: comp.graphics