Here, Wikipedia gives an example of 5 images with the same pixel dimensions of 300 pixels by 225 pixels, but with differing bit depths from 1 bit/pixel all the way to 24 bits/pixel. I thought that to calculate the file size of a given image, I could just consider the total number of pixels (300*225=67,500 pixels) and then multiply this further by the bit depth of the image, then divide by 8 to get the number of bytes and divide by 1024 to get the number of KB. However, when I do this, my calculations always seem to overestimate the actual image file size by around a factor of 2. Does anyone know why this naive calculation doesn't work?
Your naive computation works on naive image formats (early BMP, TGA).
However, most popular image formats use some form of compression, which can be lossless or lossy, and in both cases, the achieved size reduction will depend on the image content.
PNG and GIF do something close to "run-length-encoding" (RLE): when several contiguous pixels have the same value they are replaced by a single value and a count. Other formats (like some options of TIFF) can do an internal ZIP-like compression of the data. These methods are "lossless": the output of the decompression is exactly identical to the input.
Other formats (JPG in particular) drop parts of the data that make hopefully little difference. These methods are "lossy" because the image you get out may not be exactly the source image.
The reason is simple. The images are in PNG format, which implies lossless compression (like
zip) of the data. Your calculations will be true if you store the image information without compression.
You even can see an odd situation if the image uses lossy compression (like JPG) where depending on the level of JPG compression you might get an image with greater colour depth but a smaller size.