Why pixels do not weight the same? (in bytes)

Question

My experiment (see image collage below):

1. I created an white 640x400 image in GIMP and exported as png. It weights 1409 bytes.
2. Then I added a black coloured line and exported as png. It weights 1694 bytes.
3. Then, I coloured that line red and exported as png. It weights 1754 bytes.
4. Starting from the white image in 1., I added a red square and exported as png. It weights 1426 bytes.
5. From 4., I duplicated the red square and put it somewhere else in the image. I was expecting the png to weight 1426 + (1426-1409) = 1443. Instead, it weights 1729 bytes.
6. Finally, I moved that red square elsewhere, hoping the image to weight 1729 bytes, and instead, it weights 1741 bytes.

I am utterly puzzled. I was expecting pixels to weight the same. This is clearly not the case. Well, maybe colors have different byte structure (e.g. red uses more 1s and 0s than white), but at least a red pixel weights the same everywhere. Steps 4 and 5 confirm that is not the case either. And finally, step 6 indicates that position also matters! Insane!

Can you please shed light on what is going on?

Answer 1

Compression efficiency

A naive bitmap encoding stores all the pixel values directly. However, since there almost always is some redundancy in the image data, compression can be applied to reduce the file size. For example, intuitively, "640x400 white pixels" is a sufficient description to exactly encode all the pixel values that takes only 20 bytes instead of 640x480x3 bytes.

One aspect of lossless compression is that some inputs will be more compressible than others (and, due to pigeonhole principle, many hypothetical inputs will be encoded to a larger file size than before - it's just that we don't expect to use such inputs in practice). This effect of different image features on compressibility is what you are observing in your experiments.

Answer 2

• White.. (all) pixels R255G255B255
• Black line... (x) pixels R255G255B255 and (x) pixels R0G0B0
• Red line... (x) pixels R255G255B255 and (x) pixels R255G0B0
• 1 Red Square .... (x) pixels R255G255B255 and (x*2) pixels R255G0B0
• 2 Red Squares .... (x) pixels R255G255B255 and (2 * x^2) pixels R255G0B0

You can see that with each iteration there is more data to store. Not a large amount more, but more nonetheless.

In other words, a pixel does not have a "set byte size" - all pixels are not the same byte size. The byte size changes based upon the data necessary to render that pixel. A pixel containing all one value for RGBA will be smaller than a pixel containing varied data for each color and/or alpha value.

This all boils down to what are referred to as Chunks in the PNG format and how bit reduction can be utilized in the compression scheme (DEFLATE).

You can read more about the PNG format and about DEFLATE, the compression scheme utilized in the PNG format, at Wikipedia.

Answer 3

The memory space needed for a pixel is the same, no matter what's its color or transparency level. Programmers have found ways to save space by letting their program to analyze patterns and instead of storing every pixel separately a found repeating rule how a pattern is constructed is saved. It really pays off, the available savings can be tens of percents and even more if some error is allowed like in JPG compression. Make a search for image compression methods.

Answer 4

File Formats

How pixels are stored depends on the file format. Most formats support some kind of compression which means that the amount of bytes used will depend on the complexity of the content of the image and not just on the mere number of pixels.

In a truly uncompressed format, each pixel will take the same amount. Try a standard *.bmp format to see that all your images have the same size.

The effect of compression as used by most formats has been explained in the other answers.