0
\$\begingroup\$

I am writing a Technical Design Document and starting to list assets and their file sizes.

The formula for calculating the file size of a PNG is easy: width x height x bit depth.

I am having a problem with the file size windows shows in the file properties for some of my png's.

Background image: Background

The dimensions are 1280 x 720 32bit and filesize ought to be 3,686,400B. Windows Properties shows 3.6KB. Shouldn't this be 3600KB?

Background filesize

Now I have a cursor image:

Cursor

32 x 32 32bit ought to be 4,096B. Why does the file properties in windows say the file size is 304B?

cursor file size

As you can see the size on disk is correct for the cursor but the size is off. With the background image the size is correct but the size on disk is bigger.

I am using GIMP to create the images and exporting with none of the tick boxes checked, so no comments or background colour saved etc.

Can anyone explain why windows does this? Thank you.

\$\endgroup\$
  • 1
    \$\begingroup\$ I think the sizes are smaller than expected because png's are compressed files? \$\endgroup\$ – balldrix Nov 2 '16 at 10:38
3
\$\begingroup\$

We know that a disk is made up of Tracks and Sectors. In Windows that means the OS allocates space for files in "clusters" or "allocation units".

The size of a cluster can vary, but typical ranges are from 512 bytes to 32K or more. For example, on my C:\ drive, the allocation unit is 4096 bytes. This means that Windows will allocate 4096 bytes for any file or portion of a file that is from 1 to 4096 bytes in length.

If I have a file that is 17KB (kilo bytes), then the Size on disk would be 20.48 KB (or 20480 bytes). The calculation would be 4096 (1 allocation unit) x 5 = 20480 bytes. It takes 5 allocation units to hold a 17KB file.

Another example would be if I have a file that is 2000 bytes in size. The file size on disk would be 4096 bytes. The reason is, because even though the entire file can fit inside one allocation unit, it still takes up 4096 of space (one allocation unit) on disk (only one file can use an allocation unit and cannot be shared with other files).

So the size on disk is the space of all those sectors in which the file is saved. That means,usually, the size on disk is always greater than the actual size.

So the actual size of a file(s) or folder(s) should always be taken from the Size value when viewing the properties window.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ I now understand why both files show as 4096 as size on disk, thank you for the explaination. Regarding my file size calculations I believe the calculations are for uncompressed images, so this will be the size for BMP or space taken up on the VRAM. I've used PNG's so my file size calcualation doesn't work. \$\endgroup\$ – balldrix Nov 2 '16 at 10:50
  • \$\begingroup\$ @balldrix BMP files may also be compressed using Huffman or RLE according to specifications. You also need to add extra bytes for mandatory header(s). Size calculations are pretty complex. \$\endgroup\$ – wondra Nov 2 '16 at 11:14
3
\$\begingroup\$

PNG is an image format which uses the lossless DEFLATE algorithm to compress the image data. For that reason PNG files are usually far smaller than the sum of their pixels. Especially when you have images with large areas of the same color, because these are very easy to compress.

Image format compression only reduces the size on disk. When you load the image, your graphics framework will usually uncompress the image data. The memory consumption of the texture in the running game will be indeed width x height x bit depth. That means unless your graphics framework uses texture compression, which means that it will recompress the image data to reduce the data in VRAM again. But that will very likely be a different algorithm with different parameters than the one used by your image editor, so the PNG filesize isn't reliable in this regard either.

Windows shows both files as consuming 4 KB on disk because that's the cluster size of your Windows filesystem. By default, NTFS always allocates space in clusters of 4 KB (you can set a different cluster size when you create a new hard drive partition). So the "space on disk" gets rounded up to 4KB increments. However, this is likely not relevant in your case. When you are that worried about a few KB of filesize, you are either developing for the web or for smartphones. In the first case the HTTP protocol will only transfer the actual file, not the padding needed to get it to 4KB. In the second case all your assets will be bundled into a single file with the executable, so they will appear as one file on disc.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.