Compression - jpg file size

Author

jpg file size

herojits

2007-02-16, 6:56 pm

Hi All,

Is it possible to control a jpg encoder to create a jpg file with a
file size smaller
than a given limit ?

Regards,
Herojit

byaarov@yahoo.com

2007-02-16, 6:56 pm

On Feb 16, 6:58 am, "herojits" <heroj...@gmail.com> wrote:
> Hi All,
>
> Is it possible to control a jpg encoder to create a jpg file with a
> file size smaller
> than a given limit ?
>
> Regards,
> Herojit

Yes, see the ImageMagick library. It lets you control the
quantization step and hence decide how lossy the image is to be.

Bargav

Thomas Richter

2007-02-16, 6:56 pm

herojits wrote:

> Is it possible to control a jpg encoder to create a jpg file with a
> file size smaller
> than a given limit ?

"In principle yes", but this requires a complexity that is pretty high
compared to JPEG-1 standards. You can do the following:

a) Iterate over a loop where you recompress the same stream over and
over again, adjust the quantization tables along the go until it fits.
For typical images, this should converge after, say, 5 to 10 steps for a
sufficient precision.

b) Make an ad-hoc assumption about the statistics of the DC coefficients
(something like GGD might just work well), from that compute a suitable
estimate of the quantizer steps, then compress and do the iteration
until it fits. This requires an additional measurement step, but less
iteration steps because in my experience you can hit the rate by that
pretty well.

Note that, by the very nature of JPEG-1, this is more complicated than
it need to be because JPEG-1 is not an embedded codestream. But it may
be fast enough to make this a plausible approach.

Whether there is an existing codec out there that does that is beyond my
knowledge. AFAIK the IJG codec does not provide this as an option.

So long,
Thomas

cr88192

2007-02-16, 6:56 pm

"Thomas Richter" <thor@math.tu-berlin.de> wrote in message
news:53m8j8F1tnhjmU1@mid.dfncis.de...
> herojits wrote:
>
>
> "In principle yes", but this requires a complexity that is pretty high
> compared to JPEG-1 standards. You can do the following:
>
> a) Iterate over a loop where you recompress the same stream over and over
> again, adjust the quantization tables along the go until it fits.
> For typical images, this should converge after, say, 5 to 10 steps for a
> sufficient precision.
>
> b) Make an ad-hoc assumption about the statistics of the DC coefficients
> (something like GGD might just work well), from that compute a suitable
> estimate of the quantizer steps, then compress and do the iteration until
> it fits. This requires an additional measurement step, but less iteration
> steps because in my experience you can hit the rate by that pretty well.
>
> Note that, by the very nature of JPEG-1, this is more complicated than
> it need to be because JPEG-1 is not an embedded codestream. But it may
> be fast enough to make this a plausible approach.
>

I will add to this. it could be possible to shave off some size (assuming
the above fails to get it down enough) by explicitly "taking out" many of
the high-frequency components.

the lower limit in this case is:
format overhead (huffman tables and quantizer tables);
space needed for DC coefficients;
space needed to encode a bunch of EOB values (in this case, likely 1 bit
each).

so, a 1024x768 image would need:
128x96 DC coefficients, or 12288 values;
12288 bits (EOB values), or 1536 bytes.

assuming no DC value exceeds about 16, with an average of around 2. we will
typically need between 1/2 bits for the huff-coded prefix, I will assume
1.25 average, and around 2/3 bits for the suffix (will assume about 2.5), so
approx 3.75 bits/DC coeff on average.

so, about 46080 bits, or 5760 bytes.

overhead, I will guess around 200 bytes.

7496 bytes.

an image at this resolution containing a flat color is 4941 bytes, so my
estimate is a little over the theoretical minimum, but at this point all one
will have is a flat color anyways (wheras in my estimate one could have an
almost recognizable image...).

so, yes, there is a lower limit here.

> Whether there is an existing codec out there that does that is beyond my
> knowledge. AFAIK the IJG codec does not provide this as an option.
>
> So long,
> Thomas

Sponsored Links