Can any one mail me the code for plotting psnr versus bpp?

how to plot psnr (peal signal to noise ratio ) versus bpp(bits per pixels)

Answer 1

[Image Analyst]

Assuming you've varied by bpp and gotten different psnr's for the different bpp

plot(bpp, thePsnr, 'bo-');

bpp and thePsnr are arrays that you've built up by trying different bpp.

Don't use psnr as a variable name because it's the name of a built in function in the Image Processing Toolbox.

[ANJU PS]

thanks..wil try..

[ANJU PS]

how this bpp is calculated?

[Walter Roberson]

bpp is not calculated, it is a given (perhaps looped over.)

However, you might be interested in

minpixel = min(YourImage(:));
maxpixel = max(YourImage(:)); 
min_pixel_diff = min( diff( unique(YourImage(:)) ) );
if isempty(min_pixel_diff)
  bits_needed = 1;     %data is a constant
else
  bits_needed = ceil(log2((maxpixel - minpixel) / min_pixel_diff));
end

min_pixel_diff here will become the smallest difference between pixel values that are not identical, and bits_needed becomes the number of bits that you would theoretically need to represent the image in, if you were to scale and shift the image to require the fewest number of bits.

This is not identical to the number of bits actually used in the representation of YourImage. For example, if the image was YourImage = uint16(randi([743, 812], 512, 768, 3)); then it would be represented as 16 bits per image, but you only have a span of at most (812-743+1) which is 70 different values, so you could represent the image as the constant 743 plus a value that needs only 7 bits to distinguish all of the possibilities. The formula here calculates that 7. And the formula works for images represented as values in the range 0 to 1 as well -- for example it could detect that the distinct values are spaced 1/128 apart which again needs 7 bits to represent.

[Image Analyst]

You can get the size of the image in bytes on disk using dir. You can get the number of elements of the image after you read it in with size. Then you can get the bits per pixel for that image by doing

bpp = (8 * sizeOfImageInBytes) / (rows * columns);

If you do different compression schemes (like BMP, PNG, JPG, etc.) you will get different sizes on disk. Also you can specify different quality parameters for the hated JPG format which will change the disk size. You can get psnr with the psnr() function. With that, plus things like "for" and "plot", you should have everything you need to make your plot.

[Mohana Singh]

@Image Analyst when you write

bpp = (8 * sizeOfImageInBytes) / (rows * columns);

does it remain the same no matter what the color space? For RGB I would think it would change as below to account for the increased number of pixels in the extra channels.

bpp = (8 * sizeOfImageInBytes) / (rows * columns * 3);

I tried saving 'pepper.png' as RGB as well as grayscale (converted using rgb2gray), they have different sizes on disk, 288kb vs 89kb. It could be that the numerator is taking care of different bpps, but I cant find any published paper / book source confirming this. Please let me know what you think? Also kindly point to sources where I may confirm/read about this. Thanks a lot!

[Image Analyst]

Well certainly the first equation is right for gray scale images and color images where you're calling a pixel all three colors, like a 24 bit pixel.

Your second equation would be if you want the bits for one color channel pixel. So if the 24 bit pixel (8 bits, red, 8 bits green, and 8 bits blue) got compressed down to 15 bits, then you'd have 15 bits per pixel instead of 24. If you want the number of bits for each color, then you mihgt say that you have 5 of that 15 bits (a third) in the red, another 5 bits in the green, and the final 5 bits encoding the blue part of the 24 bit pixel. I don't think they're quite as separable as that when everything is mashed together and encrypted but it's helpful to think of it like that.

[Stephen23]

"For RGB I would think it would change as below to account for the increased number of pixels in the extra channels."

No, the original formula is correct: one pixel of an image consists of all color channels, ragardless of how many color channels are used.

"It could be that the numerator is taking care of different bpps, but I cant find any published paper / book source confirming this"

Your suggestion is entirely unrelated to how image compression actually works, so you are very unlikely to find it in any book or paper. Transform coding processes blocks of pixels, not individual pixels.

"Also kindly point to sources where I may confirm/read about this."

https://en.wikipedia.org/wiki/Image_compression

https://en.wikipedia.org/wiki/Portable_Network_Graphics#Compression

[Mohana Singh]

Thanks @Image Analyst so basically, what you're saying is a 'pixel' is not the individual unit in each color channel, but the unit made up of 3 color values instead.

[Walter Roberson]

A pixel is a unit with however much memory is required to store all of the color information. In cases of compression or mosaicing then bits per pixel may be non-integer, the mean (average) number required as it is not required that exactly the same amount of memory is used for each pixel.

[Mohana Singh]

Thank you! I somehow got majorly confused, thanks a lot for clearing it up.

Answer 2

[Spandan Tiwari]

There's also a function called psnr() in Image Processing Toolbox, that you can use.