CR & Bit Per Pixel image compression
34 views (last 30 days)
Show older comments
Diyar Aldusky
on 28 Jan 2012
Edited: Walter Roberson
on 24 Jun 2017
hello urgent help
i am looking for a help in ( Bit per Pixel ) and ( Compression Ratio ) on image compression , i had make my project about ( EZW ) image compression and i got the reconstructed image , but i want to know how to calculate both ( Bit Per Pixel & CR ), what is the role for calculating them for Embeded Zero Tree Wavelet Transform ( EZW ) and in which stage should i calculate and which paprameters should i got for calculation ., because ( EZW ) generate ( dominant list ) and ( subordinate list ) ...
0 Comments
Accepted Answer
Walter Roberson
on 28 Jan 2012
Bit Per Pixel = total number of bits in final file, divided by number of pixels in final file
Compression Ratio = total number of bits in final file, divided by number of bits in original file
The rest of your question is about theoretical details of a particular transform, and so should be addressed to a forum that details with transform theory. It is not a MATLAB question.
5 Comments
Renjith V Ravi
on 4 Mar 2017
@Walter Roberson : Please provide the reference for the formula, you had written for compression ratio.
Walter Roberson
on 4 Mar 2017
For the formula I gave in the comments below https://www.mathworks.com/matlabcentral/answers/27322-cr-bit-per-pixel-image-compression#comment_410392 involving log2() of the states, you can use Bell, Cleary, Witten, "Text Compression", https://www.amazon.com/Text-Compression-Timothy-C-Bell/dp/0139119914 which is a very nice text that discussions the theory of data compression at length.
More Answers (1)
ENG Amina
on 30 Nov 2016
HI, I want to calculate the compression ratio ,i had make code BTC compression ON image could you help me?
Greetings
3 Comments
Walter Roberson
on 1 Dec 2016
Note by the way that if the compression method had been
round(double(Input)/2)
then the possible outputs would be the floating point integers from 0 to 128, which is 129 possibilities, log base 2 of which would exceed 7. In isolation, that would require 8 bits to represent -- no compression achieved. However, a clever output scheme such as arithmetic encoding could approach log2(129) bits for the representation.
Walter Roberson
on 1 Dec 2016
I indicated earlier that for a 4 x 4 block of uint8 there are only a limited number of different means.
The sum of 16 integer values in the range 0 to 255 can take on any number in the range 0*16 to 255*16. That is 4081 different potential results, and since the mean always divides by 16 for such a block, that would give 4081 different possible means. Those different means could be numbered 0 to 4080 -- indeed, the numbering could be the sum of the 16 different values. That would require only 12 bits to represent, which would be a lot less than 64 bits required for a floating point mean.
16 bits for the intensity map plus 12 bits for the representation of the mean would give 28 bits; to that you would have to add however many bits turned out to be required to represent the standard deviation (I have not figured out yet how many possibilities there are.) Worst case would be that a full 64 bit double would be needed, for a total of 16 + 12 + 64 = 92 bits, compared to the 16 * 8 = 128 bits required to store the original data. My experiments suggest that in practice there are far fewer possible standard deviations, but I am having difficulty finding a formula for the situation.
See Also
Categories
Find more on Denoising and Compression in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!