efficiency of compressed textures and mipmaps (2 different questions)

Hello there.
I’ve read about different compression formats out of which I came to prefer s3tc and etc (maybe astc but it’s a bit slower at real-time decompression). Now I wonder for each of them how unused space in a texture is more compressed and how different sized empty space is compressed: to a constant size, linear, logarithmic etc. For ex: if 25% of empty space => 1 byte and 75% => 3 bytes, then it’s linear; if both compress into 5 bytes, then it’s constant, you get the point.
Does anyone know or could give me a link?

Second question is somehow related. About mipmapping I’ve read on Wikipedia that a set only occupies 33% more space than the original texture alone and it’s shown with a 3 channel texture, which it makes sense. But what about 1, 2 or 4 channels? Does the “discount” apply?

[QUOTE=mireazma;1264491]Hello there.
I’ve read about different compression formats out of which I came to prefer s3tc and etc (maybe astc but it’s a bit slower at real-time decompression). Now I wonder for each of them how unused space in a texture is more compressed and how different sized empty space is compressed: to a constant size, linear, logarithmic etc. For ex: if 25% of empty space => 1 byte and 75% => 3 bytes, then it’s linear; if both compress into 5 bytes, then it’s constant, you get the point.
Does anyone know or could give me a link?

Second question is somehow related. About mipmapping I’ve read on Wikipedia that a set only occupies 33% more space than the original texture alone and it’s shown with a 3 channel texture, which it makes sense. But what about 1, 2 or 4 channels? Does the “discount” apply?[/QUOTE]

I don’t really understand what you mean by empty, a region of constant color ?

However, all TC formats have a fixed compression ratio, the compressed size of an “empty” texture is exactly the same as a “non-empty” texture. Only ASTC has an optimization for large constant-color regions, the so-called “void extents”. The void extent encodes not just the constant color but also the size of the constant color range, so that the hardware may skip reads to adjacent texels if they are within the constant color range.

However, these constant color texels are still all present in the encoded image, so no space is saved (only bandwidth).

For the second question, the 33% overhead is an estimate. This comes from the fact that usually the next mipmap level has 1/4th of the size of the current, so the relative size of an infinite mipmap chain is 1 + 1/4 + 1/16 + 1/64 + … = 1.333… and this is independent of the size of a single pixel. So assuming that all mipmaps have the same encoding, the 33% increase is the same.

In practice there are some cases where the size of next mipmap is not 1/4th of the current size, e.g. for alignment reasons or because there is a minimal size due to the compression format. However this usually applies only to the lowest mipmap levels which have only a tiny influence on the overall texture size.

Thanks for the explanations. Yes, I meant constant color but I was biased by cases like UV maps where there’s “empty” space around useful texels rgba(0, 0, 0, 0) :slight_smile:
Now it follows that I’d should use ASTC for night sky textures with scarce tiny stars. But then I’m in doubt again:

  1. To use a single big texture where the background is rgba(0,0,0,0) – which looks like (?) a waste of drawing and (excepting ASTC) waste of memory;
  2. Use several star textures drawn at different locations – which seems like (?) wasting bandwith by multiple drawing instructions.

Oh and about rgba mipmaps, they have 4 channels, or only using RG channels – still the same size mipmap economy?

To use a single big texture where the background is rgba(0,0,0,0) – which looks like (?) a waste of drawing and (excepting ASTC) waste of memory;

The thing about all texture compression formats is that they have a fixed compression size. Unlike JPG and PNG, the content of the image is irrelevant to its compressed size. The only thing that matters is which format is being used and what the size of the image is.

A DXT1/BC1 compressed texture will always be 4-bits-per-pixel, so a 256x256 mipmap layer of a BC1 compressed texture will always be 32KB in size.

When mbentrup was talking about ASTC’s features with regard to constant color regions, what he was referring to was that ASTC looks better with such regions, since its compression system makes some special allowance for it. You get more bang for your bits. It doesn’t make your image data smaller (per se. ASTC has different compression formats that have different sizes, so you can use a more heavily compressed format and potentially not see a loss of quality).

Oh and about rgba mipmaps, they have 4 channels, or only using RG channels – still the same size mipmap economy?

I don’t know what you mean by “mipmap economy”.

If you’re trying to compare a compressed RGBA texture’s size to an uncompressed RG texture’s size, just count the bits per pixel.

I appreciate you helping me again.
By mipmap economy I mean the fact that adding mipmaps to a 3 channel texture, the whole set of all sized mips fits “economically” into the size of a channel, hence the 1.33x with mips versus 1x without (saw it on Wikipedia – 3 channel). And I was wondering whether it may apply to any number of channels of the original texture.

I suspect you may have misunderstood something.

The percent increase in space for mipmaps has nothing to do with channels or anything that relates to the image format. It’s entirely about the number of dimensions of the texture. 2D textures take up 33% because each lower mipmap level is 1/4th the size of the one above it. Taken as the limit to infinity, an infinite sum of 1/4ths yields a 33% increase over the base size.

It’s just a coincidence that, for a 3 channel format, 33% happens to be exactly one channel (assuming all channels are of the same bitdepth). There’s nothing special or “economical” about it, and it certainly doesn’t save space.

Now I understand. Thanks again.