A large png on disk may only take up a couple megabytes but I imagine that on the gpu the same png is stored in an uncompressed format which takes up much more space. Is this true? If it is true, how much space?
JPG and PNG files will almost always be smaller on-disk than in memory; they need to be decompressed on-the-fly to acquire raw RGB data, thus requiring more processing power for the loading and more RAM afterwards. So many modern engines opt to store the same format on disk as they do in memory, leading to files that are the same size as the texture's memory requirements (but also larger than a PNG or JPG). RGB/RGBA and S3TC/DXTn/BCn are the most widely used formats, because they are read straight into memory without any processing (DXT textures are precompressed).
So, these are the sizes for different common texture formats:
If you use a image with mipmaps, the texture will require 4/3 as much memory. Additionally, the texture width and height may be rounded up internally to be a power of two on old or less capable hardware, and on some very limited hardware, also forced to be a square.
More info on DXT: it's a lossy compression; this means, some color data is lost when compressing the texture. This has a negative impact on your texture, distorting sharp borders and creating "blocks" on gradients; but the benefits are far better than the disadvantages (if you have a texture that looks horribly bad in DXT, just keep it uncompressed; the other ones will make up for the size loss). Also, since the pixels are compressed by fixed-size blocks, the texture width and height must be a multiple of four.
AFAIK it's the images width * height * BPP, independent if it's a PNG, JPG or BMP. I don't know how DDS or other compressable formats are layed out.
Mip-mapping will increase the need for video memory to.
My knowledge in this topic may be a little outdated. I've abandoned 3D a while ago.
Obviously: It depends on the format.
Let's take a 256 by 256 pixel square texture. If it's uncompressed 32-bit with an alpha channel (
16-bit formats (eg:
Then you get onto the compressed formats. In XNA you have DXT1, DXT3 and DXT5 (also known as S3 Compression). This is a lossy compression format. It is also a block-based format - which means that you can sample from it (because you know which block a pixel is in). It's also faster, because you use less bandwidth.
The compression ratio of DXT1 is 8:1 and for DXT3 and DXT5 is 4:1.
So a DXT1 image of 256x256 is 32KB. And DXT3 or DXT5 is 64KB.
And then there's mipmapping. If this is enabled, this creates a series of images in graphics memory each half the size of the previous. So for our 256x256 image: 128x128, 64x64, 32x32, 16x16, 8x8, 4x4, 2x2, 1x1. A texture with mipmapping is approximately 133% the size of the original.
Most GPUs can only read a very specific compression format. eg. BC*, DXT*, not formats like png. So yes, it is true for the most part that a .png will take more space in video memory than on disk.
Textures can be stored compressed or uncompressed in both video memory and system memory.
For uncompressed textures, the general rule of thumb is that it will take the same amount of space in video memory as it does in uncompressed form in system memory.
For DXT1 compressed textures. the GPU stores 8 bytes for each 4x4 tile in your texture. The uncompressed data (at 8-bits per RGB channel) would ordinarily be 4x4x3 = 48 bytes, so that's a compression ratio of 6:1. For DXT3/DXT5 compressed textures, the GPU stores 16 bytes for each 4x4 tile in your texture. That's a slightly lower compression ratio of 3:1.
There are some caveats with both uncompressed and compressed textures: