| |
 |
|
|
Science Forum Index » Compression Forum » Calculating JPEG compression ratio?
Page 1 of 1
|
| Author |
Message |
| James Sumners |
 Posted: Thu Apr 17, 2008 10:16 pm |
|
|
|
Guest
|
I'm working on a paper in which I want to compare compressing an image
with JPEG and with the Haar wavelet. My focus is on the Haar wavelet,
and to that end I have written an application to read a grayscale TIFF,
apply the DWT, and calculate the compression ratio. I calculate the
compression ratio by dividing the number of nonzero entries in the
original image matrix by the number of nonzero entries in the
compressed image matrix.
Since JPEG is not the focus of my paper, and I am only using it for
comparison, I want to be able to do the same thing with the JPEG
compressed image without writing my own JPEG encoder. Does anyone know
of an open source, or at least free for educational use, tool for doing
this?
I am currently using DCT Lab[1], but I am unable to export the
compressed image matrix from the tool. At least, I think I am unable to
do so. I can export the original image, the restored image, and the
"DCT Coefficients". None of which are very sparse matrices (maybe 6
zero entries).
Thank you,
James Sumners
[1] -- http://sprljan.com/nikola/matlab/dctlab.html |
|
|
| Back to top |
|
| Thomas Richter |
| Posted: Fri Apr 18, 2008 1:28 am |
|
|
|
Guest
|
James Sumners schrieb:
Quote: I'm working on a paper in which I want to compare compressing an image
with JPEG and with the Haar wavelet. My focus is on the Haar wavelet,
and to that end I have written an application to read a grayscale TIFF,
apply the DWT, and calculate the compression ratio. I calculate the
compression ratio by dividing the number of nonzero entries in the
original image matrix by the number of nonzero entries in the compressed
image matrix.
Hmm. That's a strange definition of compression factor. I would rather
define it as the number of bits spent on average per pixel, computed on
the compressed result.
Quote: Since JPEG is not the focus of my paper, and I am only using it for
comparison, I want to be able to do the same thing with the JPEG
compressed image without writing my own JPEG encoder. Does anyone know
of an open source, or at least free for educational use, tool for doing
this?
Sure enough. The IJG offers free C code.
http://www.ijg.org/
So long,
Thomas |
|
|
| Back to top |
|
| James Sumners |
| Posted: Fri Apr 18, 2008 8:07 pm |
|
|
|
Guest
|
On 2008-04-18 02:28:29 -0400, Thomas Richter <thor@math.tu-berlin.de> said:
Quote: James Sumners schrieb:
I'm working on a paper in which I want to compare compressing an image
with JPEG and with the Haar wavelet. My focus is on the Haar wavelet,
and to that end I have written an application to read a grayscale TIFF,
apply the DWT, and calculate the compression ratio. I calculate the
compression ratio by dividing the number of nonzero entries in the
original image matrix by the number of nonzero entries in the compressed
image matrix.
Hmm. That's a strange definition of compression factor. I would rather
define it as the number of bits spent on average per pixel, computed on
the compressed result.
Why is that strange? If each integer pixel representation is 1 byte,
then the nonzero entries make up the actual data to be stored.
Quote:
Since JPEG is not the focus of my paper, and I am only using it for
comparison, I want to be able to do the same thing with the JPEG
compressed image without writing my own JPEG encoder. Does anyone know
of an open source, or at least free for educational use, tool for doing
this?
Sure enough. The IJG offers free C code.
http://www.ijg.org/
So long,
Thomas
Thank you.
I finally heard back from the DCT Lab toolbox author and can now export
the compressed image matrix from the toolbox to the general Matlab
workspace. This lets me perform the same calculation as I do with my
wavelet program. |
|
|
| Back to top |
|
| Thomas Richter |
| Posted: Sat Apr 19, 2008 2:30 am |
|
|
|
Guest
|
James Sumners wrote:
Quote: On 2008-04-18 02:28:29 -0400, Thomas Richter <thor@math.tu-berlin.de> said:
James Sumners schrieb:
I'm working on a paper in which I want to compare compressing an image
with JPEG and with the Haar wavelet. My focus is on the Haar wavelet,
and to that end I have written an application to read a grayscale TIFF,
apply the DWT, and calculate the compression ratio. I calculate the
compression ratio by dividing the number of nonzero entries in the
original image matrix by the number of nonzero entries in the compressed
image matrix.
Hmm. That's a strange definition of compression factor. I would rather
define it as the number of bits spent on average per pixel, computed on
the compressed result.
Why is that strange? If each integer pixel representation is 1 byte,
then the nonzero entries make up the actual data to be stored.
Well, except that this isn't quite how JPEG works, only approximately.
You need to identify *which* coefficients are zero (costs additonal
rate) and you can use statistical information on the nonzero
coefficients to compress them (reduces the rate), so the numbers you get
do not tell much, I afraid.
The Haar wavelet isn't really state of the art, you should probably look
into more sophisticated transforms, too, to make this a reasonable
comparison.
So long,
Thomas |
|
|
| Back to top |
|
| Phil Carmody |
| Posted: Sat Apr 19, 2008 3:21 am |
|
|
|
Guest
|
James Sumners <nospam@thankyou.verymuch> writes:
Quote: On 2008-04-18 02:28:29 -0400, Thomas Richter <thor@math.tu-berlin.de> said:
James Sumners schrieb:
I'm working on a paper in which I want to compare compressing an image
with JPEG and with the Haar wavelet. My focus is on the Haar wavelet,
and to that end I have written an application to read a grayscale TIFF,
apply the DWT, and calculate the compression ratio. I calculate the
compression ratio by dividing the number of nonzero entries in the
original image matrix by the number of nonzero entries in the compressed
image matrix.
Hmm. That's a strange definition of compression factor. I would
rather
define it as the number of bits spent on average per pixel, computed on
the compressed result.
Why is that strange? If each integer pixel representation is 1 byte,
then the nonzero entries make up the actual data to be stored.
Do you really think that the following two sets are
sensibly called equally compressible?
137 6 0 78 0 0 -51 0
0 0 -38 0 0 0 0 0
0 0 31 0 0 0 0 0
17 0 0 0 109 0 0 0
5 0 0 0 0 0 0 28
0 0 0 0 0 0 0 0
0 -10 0 0 0 0 5 0
0 0 0 -49 0 0 0 0
1 1 1 1 0 0 0 0
1 1 1 0 0 0 0 0
1 1 1 0 0 0 0 0
1 1 0 0 0 0 0 0
1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
They both have the same number of nonzero entries.
Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration |
|
|
| Back to top |
|
| James Sumners |
| Posted: Sat Apr 19, 2008 11:21 am |
|
|
|
Guest
|
On 2008-04-19 03:30:27 -0400, Thomas Richter <thor@math.tu-berlin.de> said:
Quote: James Sumners wrote:
On 2008-04-18 02:28:29 -0400, Thomas Richter <thor@math.tu-berlin.de> said:
James Sumners schrieb:
I'm working on a paper in which I want to compare compressing an image
with JPEG and with the Haar wavelet. My focus is on the Haar wavelet,
and to that end I have written an application to read a grayscale TIFF,
apply the DWT, and calculate the compression ratio. I calculate the
compression ratio by dividing the number of nonzero entries in the
original image matrix by the number of nonzero entries in the compressed
image matrix.
Hmm. That's a strange definition of compression factor. I would rather
define it as the number of bits spent on average per pixel, computed on
the compressed result.
Why is that strange? If each integer pixel representation is 1 byte,
then the nonzero entries make up the actual data to be stored.
Well, except that this isn't quite how JPEG works, only approximately.
You need to identify *which* coefficients are zero (costs additonal
rate) and you can use statistical information on the nonzero
coefficients to compress them (reduces the rate), so the numbers you get
do not tell much, I afraid.
Okay. Thank you for that clarification. My advisor feels this
calculation is sufficient for the purposes of my paper, though, so I
will stick with it. I'm just doing a basic comparison.
Quote:
The Haar wavelet isn't really state of the art, you should probably look
into more sophisticated transforms, too, to make this a reasonable comparison.
So long,
Thomas
Agreed. But this paper is more of a "here are two methods, this is what
the results of each look like" thing. The rigourous part of the paper
is in the theory behind the Haar wavelet. Honestly, I wouldn't have
even bothered with the JPEG portion if my advisor didn't insist on it. |
|
|
| Back to top |
|
| James Sumners |
| Posted: Sat Apr 19, 2008 11:31 am |
|
|
|
Guest
|
On 2008-04-19 04:21:18 -0400, Phil Carmody
<thefatphil_demunged@yahoo.co.uk> said:
Quote: James Sumners <nospam@thankyou.verymuch> writes:
On 2008-04-18 02:28:29 -0400, Thomas Richter <thor@math.tu-berlin.de> said:
James Sumners schrieb:
I'm working on a paper in which I want to compare compressing an image
with JPEG and with the Haar wavelet. My focus is on the Haar wavelet,
and to that end I have written an application to read a grayscale TIFF,
apply the DWT, and calculate the compression ratio. I calculate the
compression ratio by dividing the number of nonzero entries in the
original image matrix by the number of nonzero entries in the compressed
image matrix.
Hmm. That's a strange definition of compression factor. I would
rather
define it as the number of bits spent on average per pixel, computed on
the compressed result.
Why is that strange? If each integer pixel representation is 1 byte,
then the nonzero entries make up the actual data to be stored.
Do you really think that the following two sets are
sensibly called equally compressible?
137 6 0 78 0 0 -51 0
0 0 -38 0 0 0 0 0
0 0 31 0 0 0 0 0
17 0 0 0 109 0 0 0
5 0 0 0 0 0 0 28
0 0 0 0 0 0 0 0
0 -10 0 0 0 0 5 0
0 0 0 -49 0 0 0 0
1 1 1 1 0 0 0 0
1 1 1 0 0 0 0 0
1 1 1 0 0 0 0 0
1 1 0 0 0 0 0 0
1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
They both have the same number of nonzero entries.
Phil
In the sense that there are 13 bytes of nonzero data in each matrix,
yes. Are they equivalently compressible in real terms? I suppose not.
I merely need a metric by which I can say, "Okay, this image,
compressed to have X number of nonzero elements, has a possible Y
compression ratio with JPEG and Z compression ratio with the Haar
wavelet. This is what each restored image looks like...."
This is an undergraduate mathematics paper. I had to pick something of
sufficient complexity (the Haar wavelet), research it, and write a
short paper on it.
I fully understand that my simple calculation is not definitive or
thorough. But I don't need it to be. |
|
|
| Back to top |
|
| |
|
Page 1 of 1
All times are GMT - 5 Hours
The time now is Sat Oct 11, 2008 3:54 pm
|
|