| View previous topic :: View next topic |
| Author |
Message |
Ben Nelson
Guest
|
 Posted: Fri Aug 22, 2003 8:26 pm Post subject: Using JPEG Quantization Tables |
 |
|
I putting the finishing touches on a JPEG decompression program, but
had a quick question about the use of the Quantization Tables in
decompressing the image. Everything I>ve read thus far suggests that
the values in the Quantization Table are applied spacially to each 8x8
block of quantized image data. I.e. The value in cell (0,0) of the
table is applied to the image (chroma or luma) data in position (0,0)
of each 8x8 image block.
However, as Alessandro Russo pointed out in article
<3ED5CAD4.7F2EBBFB@jpegclub.org>, the quantization table is not
symmetric. So spacial selection of the quantization values doesn>t
seem to make sense, since the pixels in the lower-right corner of each
image block would be weighted more heavily than those in the
upper-left.
Bottom line = 2 questions:
1. How do I select which quantization table value to apply to each
element of the image data?
2. What do I do with the value chosen? My research suggests that I
simply multiply the Q table value with the image data value to get an
approximation of the original value. However, there are also many
documents discussing such complex things as Inverse Discrete Cosine
Transforms (DCTs).
Thanks for your help,
Ben |
|
| |
|
 Back to top |
Thomas Richter
Guest
|
| Posted: Fri Aug 22, 2003 9:29 pm Post subject: Re: Using JPEG Quantization Tables |
|
|
Hi,
[quote]I putting the finishing touches on a JPEG decompression program, but
had a quick question about the use of the Quantization Tables in
decompressing the image. Everything I>ve read thus far suggests that
the values in the Quantization Table are applied spacially to each 8x8
block of quantized image data. I.e. The value in cell (0,0) of the
table is applied to the image (chroma or luma) data in position (0,0)
of each 8x8 image block.
[/quote]
Yes, except that each 8x8 block is represented by its Fourier-
(or rather, DCT) amplitudes.
[quote]However, as Alessandro Russo pointed out in article
3ED5CAD4.7F2EBBFB@jpegclub.org>, the quantization table is not
symmetric.
[/quote]
"The quantization table" as suggested by ISO. You can make your
own, but for decoding, you need to take what you find in the stream.
[quote]So spacial selection of the quantization values doesn>t
seem to make sense, since the pixels in the lower-right corner of each
image block would be weighted more heavily than those in the
upper-left.
[/quote]
??? I don>t understand the question. Yes, pixels are by default
weighted differently, but that is why 'spacial selection of the
quantization values' is necessary in first place.???
[quote]1. How do I select which quantization table value to apply to each
element of the image data?
[/quote]
By using the quantization values as recorded in the JPEG stream. Each
is applied to one coefficient in the zig-zag that re-builds the DCT
amplitudes. See section B.2.4.1 of the JPEG standard for how a
quantization table looks like.
[quote]2. What do I do with the value chosen? My research suggests that I
simply multiply the Q table value with the image data value to get an
approximation of the original value.
[/quote]
Yes. See A.3.4 of the standard.
[quote]However, there are also many
documents discussing such complex things as Inverse Discrete Cosine
Transforms (DCTs).
[/quote]
Well, I afraid so. (-; There>s no (traditional) JPEG without DCT.
A JPEG-decoder will do the following:
1) Decode quantized DCT values (thru huffman encoding) from stream,
2) dequantize them with the quantizer tables,
3) perform an inverse DCT
So long,
Thomas |
|
| |
|
| Back to top |
Ben Nelson
Guest
|
| Posted: Sat Aug 23, 2003 3:40 am Post subject: Re: Using JPEG Quantization Tables |
|
|
Thomas Richter <thor@cleopatra.math.tu-berlin.de> wrote in message news:<bi5gdh$iva$1@mamenchi.zrz.TU-Berlin.DE>...
[quote]Hi,
I putting the finishing touches on a JPEG decompression program, but
had a quick question about the use of the Quantization Tables in
decompressing the image. Everything I>ve read thus far suggests that
the values in the Quantization Table are applied spacially to each 8x8
block of quantized image data. I.e. The value in cell (0,0) of the
table is applied to the image (chroma or luma) data in position (0,0)
of each 8x8 image block.
Yes, except that each 8x8 block is represented by its Fourier-
(or rather, DCT) amplitudes.
However, as Alessandro Russo pointed out in article
3ED5CAD4.7F2EBBFB@jpegclub.org>, the quantization table is not
symmetric.
"The quantization table" as suggested by ISO. You can make your
own, but for decoding, you need to take what you find in the stream.
So spacial selection of the quantization values doesn>t
seem to make sense, since the pixels in the lower-right corner of each
image block would be weighted more heavily than those in the
upper-left.
??? I don>t understand the question. Yes, pixels are by default
weighted differently, but that is why 'spacial selection of the
quantization values' is necessary in first place.???
[/quote]
Nevermind ... I was just rephrasing what I said above about Q(0,0)
being applied to Img(0,0). You answered my question.
[quote]
1. How do I select which quantization table value to apply to each
element of the image data?
By using the quantization values as recorded in the JPEG stream. Each
is applied to one coefficient in the zig-zag that re-builds the DCT
amplitudes. See section B.2.4.1 of the JPEG standard for how a
quantization table looks like.
2. What do I do with the value chosen? My research suggests that I
simply multiply the Q table value with the image data value to get an
approximation of the original value.
Yes. See A.3.4 of the standard.
However, there are also many
documents discussing such complex things as Inverse Discrete Cosine
Transforms (DCTs).
Well, I afraid so. (-; There>s no (traditional) JPEG without DCT.
[/quote]
Hmm, ok. {-8 It can>t be too hard to code the Inverse DCT though,
the function is fairly well documented on mathematics sites. I>ll
probably start a separate thread if I get lost on this. Thanks. (:
[quote]A JPEG-decoder will do the following:
1) Decode quantized DCT values (thru huffman encoding) from stream,
[/quote]
Yep, I>m working on this part now. The JPEG image I>m working
with is compressing using Baseline DCT, and so has 4 Huffman tables
(AC and DC Chroma, AC and DC Luma). The standard document seems to
give two guidelines for decompression here.
1. The first pixel (at 0,0) in each 64 pixel grid is compressed with
the DC table. The other 63 are compressed with the AC table.
2. The Y, Cb, and Cr (YUV) components are interlaced in the
bit-stream.
I.e. (0,0)[Y,U,V] ; (1,0)[Y,U,V] ; ... ; (7,7)[Y,U,V]
So, if I understand this right, I use the H tables in the following
order for each 8x8 section.
* DC Luma to decompress the first byte - Y(0,0)
* DC Chroma to decompress the next two bytes - Cb(0,0) and Cr(0,0)
* Alternating AC Luma (1 byte) and AC Chroma (2 bytes) to decompress
the remaining 189 bytes ... Y(0,1) to Y(7,7) and Cb/Cr(0,1) to
Cb/Cr(7,7).
[quote]2) dequantize them with the quantizer tables,
[/quote]
Thanks for your help, I know how to do this now.
[quote]3) perform an inverse DCT
[/quote]
Ok, at least I know for sure that it needs to be done for
decompression now, none of the documents I read were very clear on
that point.
[quote]
So long,
Thomas
[/quote]
Thanks for your help so far ... I can start writing the function to
de-quantize the values now. I don>t want to get ahead of myself, but
I think I>ll hold off a bit on the Huffman decompression until I>m
sure I have the sequence right.
Ben
P.S. The values in Spectral Selection Start, Spectral Selection End,
and Successive Approximation (last 3 bytes of SOS header) are not used
for Baseline JPEGs, right? The file I>m using to test assigns them
the values 0, 63, and [ b0000 | b0000 ] respectively. |
|
| |
|
| Back to top |
Thomas Richter
Guest
|
| Posted: Mon Aug 25, 2003 1:34 pm Post subject: Re: Using JPEG Quantization Tables |
|
|
Hi,
[quote]A JPEG-decoder will do the following:
1) Decode quantized DCT values (thru huffman encoding) from stream,
Yep, I>m working on this part now. The JPEG image I>m working
with is compressing using Baseline DCT, and so has 4 Huffman tables
(AC and DC Chroma, AC and DC Luma). The standard document seems to
give two guidelines for decompression here.
1. The first pixel (at 0,0) in each 64 pixel grid is compressed with
the DC table. The other 63 are compressed with the AC table.
2. The Y, Cb, and Cr (YUV) components are interlaced in the
bit-stream.
I.e. (0,0)[Y,U,V] ; (1,0)[Y,U,V] ; ... ; (7,7)[Y,U,V]
[/quote]
This rather depends on whether component interleaving is enabled or not.
It>s a baseline coder option.
[quote]So, if I understand this right, I use the H tables in the following
order for each 8x8 section.
* DC Luma to decompress the first byte - Y(0,0)
* DC Chroma to decompress the next two bytes - Cb(0,0) and Cr(0,0)
* Alternating AC Luma (1 byte) and AC Chroma (2 bytes) to decompress
the remaining 189 bytes ... Y(0,1) to Y(7,7) and Cb/Cr(0,1) to
Cb/Cr(7,7).
[/quote]
Depends on the mode, see above.
[quote]P.S. The values in Spectral Selection Start, Spectral Selection End,
and Successive Approximation (last 3 bytes of SOS header) are not used
for Baseline JPEGs, right? The file I>m using to test assigns them
the values 0, 63, and [ b0000 | b0000 ] respectively.
[/quote]
Baseline JPEG supports only "sequential" encoding, thus 0..63 are AFAIK
the only possibilities here. Extended JPG can do more ("progessive") modes.
Recommended reading:
JPEG Still Image Data Compression Standard, by
William B. Pennebaker, Joan L. Mitchell, Van Nosstrand Reinhold,
New York, 1993, ISBN 0-442-01272-1
So long,
Thomas |
|
| |
|
| Back to top |
|
