On 15 Jan 1999, Christopher Biggs wrote:
> Jan Steinman <jans@xxxxxxxxxxx> moved upon the face of the 'Net and spake
> thusly:
>
> > A simple empirical test suggests otherwise for JPEG: just look at the file
> > size continue to go down as you compress it over and over. If it is not
Not much. After two iterations, the gain is really marginal.
> > getting progressively less quality where did the bits go? Why weren't they
> > removed the first time, if they don't contribute to the photo quality?
Well, of course they do.
> JPEG will continue to degrade over multiple iterations.
As I said, not much. Just test it. Do not forget not to resize or do
any touching. Open file1.jpg, save as file2.jpg, open file2.jpg, save as
file3.jpg, etc. all with, say, a 75% quality. See the file sizes of
about 10 images.
> > As I understand it, JPEG works by taking areas of similar color and
> > replacing them with a single color. It will continue to do so, regardless
No. JPEG works the way Chris has said.
> > of whether it has already been done. In common use, the reduction in
> > quality tends to be asymptotic -- it approaches a limit -- but it still
> > reduces quality each time it is used.
>
> JPEG works by
>
> 1. Convert to YUV colourspace
> 2. decimate the colour resolution to half the luminance
> resolution
> 3. consider the image in 8x8 blocks
> 4. perform "Discrete Cosine Transform" on each block and
> encode the coefficients of the DCT output
> using a configurable amount of precision (this
> is the variable compression).
What I would like to add to the step 4 is that, the configurable amount
of precision is obtained by quantizing the DCT output.
When you invert this operation and obtain an image to view, its YUV
transform will be in such a way that the decimation of color resolution
and quantization of DCT coefficients will be "almost" similar to the
first iteration JPEG.
As an example, Say, your original number is 3.5555. You scale it by 3, and
then round it for coding. You get round(10.6665) = 11. In the inverse
operation for viewing, you get 11/3 = 3.6666. This is what you see in
your first, say, JPEG image. Now, if you do the same operation on 3.6666,
then you get round(10.9999) = 11 again, and in the second JPEG image, you
again see 11/3 = 3.6666.
Similar things happen in quantization steps of JPEG.
> For the non-mathematical, a DCT has the effect of losing fine detail
> but keeping the general "trend" of colour change across each block.
It is not the DCT which has that affect. It is just a transform to
frequency domain. The effect is due to the quantization of DCT.
If there is a "strong" detail, then it has a large DCT value,
and it does not vanish by quantization, so it does not necessarily get
blurred.
As for the second sentence, actually it is JPEGs weak point not
to keep the general trend of colour change accross the blocks. Therefore,
usually smooth images are unintentionally compressed too much and the
8x8 blocks become visible. I would like to suggest that you produce an
artificial very smooth "wave" image and a very high contrast "busy"
image, and code at 40etting. You will see that at the same setting,
the smooth image has a smaller JPEG but the JPEG image is unbearable. Low
pass (smooth) images and sharp transitions of smooth regions (graphics
art images) are bad for JPEG.
> For signal-theory types this is analogous to doing noise reduction by
> performing a Fourier transform, clipping the output and then inverting
> the transform.
Well, you use all the DCT components. You don't clip (as in noise
reduction). But, it is true that you quantize the high variation parts
more.
My appologies for so much elaboration. For a calm down, may I introduce
my humble photo gallery at:
http://ltswww.epfl.ch/~gerek/
You click on the "personal", and then "photography", and then
"My pictures" on the left menu. If your browser does not support
javascript well, or if you do not want to crash your computer with so
many operations, you can directly go to
http://ltswww.epfl.ch/~gerek/Personal/Images/photos.html
All pictures were taken on cheap 100/200/400 print films and scanned by
an old HP deskscan II.
Cheers,
OMer.
< This message was delivered via the Olympus Mailing List >
< For questions, mailto:owner-olympus@xxxxxxxxxxxxxxx >
< Web Page: http://Zuiko.sls.bc.ca/swright/olympuslist.html >
|