On 7/17/05, Chris Barker <ftog@xxxxxxxxxxxxxxxx> wrote:
>
> I have wondered, on occasion, what might cause the differences in
> file size, whether compressed or not.
I had done some reading on jpeg compression in the past but can't
remember exactly how it works at the moment. Have to fish out my copy
of "Programming Web Graphics with Perl & GNU Software" (from O'Reilly
of course). The big thing to realise is that each application's
"quality" settings are completely arbitrary and don't bear any
relationship to other applications' settings. What I mean by that is
that a setting of 90 in one program is not the same as a quality of 90
in another program. The only way you can really compare jpeg
compression between different programs is to compare files of the same
size. There are several steps in the compression (4 in total if memory
serves) which can take various levels of quality so the developers may
have used different settings in the various steps to arrive at the
same file size in the end.
As for sub-sampling, if memory serves, that's a method where the
chroma values of adjacent pixels are averaged in order to reduce the
file size. At a setting of 1x1 there should be none (you're averaging
a grid of 1 pixel by 1 pixel). A common setting (at lower jpeg quality
settings) is 2x2 sub-sampling. Normally, each pixel would have 24-bits
of data (8 bits each for Luminance, Chroma A and Chroma B) so for a
2x2 grid you would use 96 bits of data (4 x 24). When sub-sampling,
you keep the luminance value for each pixel but only store 1 chroma
value for A and B for the whole grid. This results in each 2x2 grid
only needing 48 bits of data (4 x 8 + 8 + 8). For images with lots of
solid colour this is a great way to get small files (50% savings right
there) but for images with lots of fine detail the results are usually
not good.
==============================================
List usage info: http://www.zuikoholic.com
List nannies: olympusadmin@xxxxxxxxxx
==============================================
|