The internal details of ARM's Adaptive Scalable Texture Compression (ASTC) technology were launched this week at the High Performance Graphics conference in Paris, France.
Tom Olson presented his paper entitled "Adaptive Scalable Texture Compression", as part of the session on texture and appearance on Wednesday 27 June 2012.
This is the first of two blog posts giving an overview of the ASTC technology as presented in the paper.
As a quick recap, ASTC offers a number of advantages over existing texture compression schemes:
Despite all this flexibility, quality is universally better than existing texture compression schemes for LDR images, and is comparable to the de facto industry standard for HDR.
ASTC, like all current texture compression schemes, divides the image into fixed-size blocks. These blocks cover a fixed-size "footprint" in the texture image, and are encoded using a fixed number of bits. This feature makes it possible to access texels quickly in any order, with a well-bounded cost for that access.
This is in contrast to stream-based, variable-bitrate image formats such as PNG, where the decoding process requires that you have decoded the previous texels in the image. Obviously, this would be a problem if the texels you wish to access are at the bottom right of the texture.
The 2D block footprints in ASTC range from 4x4 texels up to 12x12. By dividing the 128 bits by the number of texels in the footprint, we derive bit rates from 8 bpp (128 bits / 16 texels) down to 0.89 bpp (128 bits / 144 texels).
In the simplest case, the encoder analyses each block in isolation and selects two colors which define the end points of a line in the color space. The approximate colors of texels can then be reconstructed from these color endpoints by interpolating between them. For each texel in the footprint, a weight value is stored, and the weighted average calculated. The weight, mathematically, is a value in the range 0 to 1, but for storage this is quantized to a few bits. Selecting the endpoint colors and the weights to make an optimal match to the texel colors in the original block is the job of the encoder.
Tom's previous blog post on ASTC goes into some detail about the constraints of each of the existing texture compression methods.
With this constraint in place, and by interleaving the bits, trits and quints appropriately, BISE encodes a sequence of length S (i.e.an array of S integer values) using a fixed number of bits:
This is the key innovation that allows ASTC to efficiently trade space between color endpoint values and texel weights.
The other thing that this gives us the ability to change the number of values represented in relatively small increments. With other texture compression techniques, if the artists are not happy with the quality of their image at one bit rate, their only options are to double its bit rate, or to try another compression scheme entirely. Each of these has its own problems.
Paying a 100% penalty for storage, transmission and memory bandwidth on a texture is a serious proposition, especially if the result at the lower bit rate is only just below the acceptable quality threshold.
Moving to a different compression scheme is not always possible, as the deployment platform may not support the scheme that the designer wants to use. Even when it does, requalifying the image takes time and effort, as the kinds of errors introduced will be different.
ASTC, by exploiting the fractional bits offered by BISE, allows the footprint to vary more smoothly. The available bit rates range from 0.89 bpp up to 8bpp in fine steps, with no step requiring more than 25% more memory than the previous one. Thus, the content developer has much more control over the space-to-quality trade-off than with other formats.
This means that the ASTC encoder and decoder have to work with non-power-of-two block footprint sizes, but the power of base-3 and base-5 arithmetic comes into play again, and this is used to implement fast division and modulo operations. This makes address calculations for a 6x8 block footprint just as fast as for 8x8.
In ARM Unveils Details of ASTC Texture Compression at HPG Conference - Part 2 we will see how Bounded Integer Sequence Encoding, working in tandem with other features, gives rise to the extraordinary flexibility of ASTC.
are there some examples for ABFC and ASTC on ARM platform？Thanks in advance