compressed images are large about imgcomp-cvpr

[raindropstarbucks]

@fab-jul

[fab-jul]

I'm not sure I understand :) bpp = bits per pixel = bytes / number of pixels. the conversion factor is just number of pixels, I don't see how one image can be 500kB and 0.388 bpp and aonther can be 350kB and 0.6 bpp :)

[raindropstarbucks]

Thank you for your quick reply! :) Well,for example, in your paper,Figure 5: Example image (kodim21) from the Kodak testing set, compressed with different methods .The first image is 0.124bpp, 37.7KB, the JPEG-compressed image is 0.150bpp, 8.26KB. I cannot understand why a image of smaller bpp takes more storage.

[fab-jul]

Where are the KB numbers coming from?

[raindropstarbucks]

I saved them from your paper, then I get the KB number.

[fab-jul]

from the arxiv? or from the pdf?

[raindropstarbucks]

from the pdf

[fab-jul]

I see. The problem is that a PDF has no way of decoding images produced by our approach. Thus, to show our images in the paper, we had to save them as JPGs. It's just for visualization purposes.

If you want to obtain a compressed representation of an image using our approach, use the --real_bpp flag as described here.

[raindropstarbucks]

@fab-jul I hope I don't bother you. :) I use the --real_bpp flag, then I get the same problem. I use the same images as yours(kodim21). The original image in Figure5 is 637.05kB, then I get the image compressed by the model, 0.3587bpp, 464.98kB, and the image compressed by JPEG, 0.61bpp, 344.81kB. Why a image of smaller bpp takes more storage really makes me confused.

[fab-jul]

No worries! I'll try to explain better:

Say you have an image x. You want to compress it to a bitstream (a file), let's call this f. Later you want to decompress f, which will give you back an image y. Note that y ≠ x, because there is some distortion!

What you care about is the size of the file f. How do you get that? You run my code with --real_bpp. That will create a file, and count the bits of that file (Line 55 of bitcounter.py). That is what will be printed in the console, it's the bpp needed by our approach.

However, when you run val.py with --real_bpp, it produces also the output y, because your computer doesn't have a built-in decoder to obtain y from f!! So it saves y directly as a '.png', so that you can look at it, and you can see the distortion. The important thing is: The number of bytes used by y tell you nothing about the size of f! That's why there is a mismatch between bytes and bpp: The bytes are not the size of f.

Note that when you pass --real_bpp, we just check (in bit_counter.py), that the symbols decoded from f are the same as the ones we encoded (L68). That is enough to ensure that our encoding works, and that's the only point of --real_bpp: To show that the theoretical bitrates are almost the actual real bitrates.

[raindropstarbucks]

Thank you very much!