For more information on ASTC, take a look at the ARM Multimedia Blog posts "ASTC Texture Compression: ARM Pushes the Envelope in Graphics Technology" and "ARM Unveils Details of ASTC Texture Compression at HPG Conference".
I have started this thread for users of this evaluation tool to ask questions. Here's a very quick "getting started" guide:
First, accept the license, download the tarball and unpack. In the subdirectories Win32, Mac OS X and Linux32 are binaries for, you guessed it, Windows, Mac OS X, and Linux (x86 versions). If you are running on another system, you might like to try compiling from source - take a look at Source/buildinstructions.txt .
Open a terminal, change to the appropriate directory for your system, and run the astcenc encoder program, like this on Linux or Mac OS:
./astcenc
Or like this on Windows:
astcenc
Invoking the tool with no arguments gives a very extensive help message, including usage instructions, and details of all the possible options.
First, find a 24-bit .png or .tga file you wish to use, say /images/example.png (or on windows C:\images\example.png).
You can compress it using the -c option, like this (use the first line for Linux or Mac OS, second line for Windows users):
./astcenc -c /images/example.png /images/example-compressed.astc 6x6 -mediumastcenc -c C:\images\example.png C:\images\example-compressed.astc 6x6 -medium
./astcenc -c /images/example.png /images/example-compressed.astc 6x6 -medium
astcenc -c C:\images\example.png C:\images\example-compressed.astc 6x6 -medium
The -c indicates a compression operation, followed by the input and output filenames. The block footprint size follows, in this case 6x6 pixels, then the requested compression speed, medium.
To decompress the file again, you should use:
astcenc -d /images/example-compressed.astc /images/example-decompressed.tgaastcenc -d C:\images\example-compressed.astc C:\images\example-decompressed.tga
astcenc -d /images/example-compressed.astc /images/example-decompressed.tga
astcenc -d C:\images\example-compressed.astc C:\images\example-decompressed.tga
The -d indicates decompression, followed by the input and output filenames. The output file will be an uncompressed TGA image.
If you just want to test what compression and decompression are like, use the test mode:
astcenc -t /images/example.png /images/example-decompressed.tga 6x6 -mediumastcenc -c C:\images\example.png C:\images\example-compressed.tga 6x6 -medium
astcenc -t /images/example.png /images/example-decompressed.tga 6x6 -medium
astcenc -c C:\images\example.png C:\images\example-compressed.tga 6x6 -medium
This is equivalent to compressing and then immediately decompressing again, and it also prints out statistics about the fidelity of the resulting image, using the peak signal-to-noise ratio.
Take a look at the input and output images.
The block footprints go from 4x4 (8 bits per pixel) all the way up to 12x12 (0.89 bits/pixel). Like any lossy codec, such as JPEG there will come a point where selecting too aggressive a compression results in inacceptable quality loss, and ASTC is no exception. Finding this optimum balance between size and quality is one place where ASTC excels since its compression ratio is adjustable in much finer steps than other texture codecs.
The compression speed runs from -veryfast, through -fast, -medium and -thorough, up to -exhaustive. In general, the more time the encoder has to spend looking for good encodings, the better the results.
So, download, run, have a play, and post any questions or results on this thread.
Hi Sean,
Few more questions:
Question-1: I assume when you mean hardware it is Mali GPU ASTC decoder. so in that case GPU does not support sRGB coversion. please confirm this.
Question-2: Incase of normal maps the decoder swizzle pattern is "raz1" then "z" derivation is sqrt(1-r^2-a^2) is supported Mali GPU ASTC decoder.
Thanks,
Devendran Mani.
Devmani,
By "hardware" I do indeed mean the GPU ASTC decoder. Since OpenGL ES mandates that textures may be stored in sRGB color space, and the sRGB-to-linear conversion is quite complex, it is usually supported in hardware so that linear RGB values are returned to the shader pipeline. This is true for all the existing mobile GPUs that I am aware of.
Normal maps, however, are usually just stored as RG textures (X in the R channel, Y in the G channel), and just the X and Y are returned to the shader pipeline. Normal maps are less often used than color maps, and for many use cases the Z component is not required by the shader. Any block of hardware to calculate Z directly would be rarely used, so it is usually left up to the shader to calculate Z if it is required using a relatively simple square root operation. Again, this behavior is the same for all the mobile GPUs.
The reason we include the "z" swizzle on output from the software decoder is so that it is easier for conventional three-component imaging tools to measure the fidelity of the output image.
Sean.
I have one more questions:
LDR endpoint Decoding section(3.8) in ASTC specification:
"The bit_transfer_signed procedure transfers a bit from one signed byte value (a) to another (b). The result is an 8-bit signed integer value and a 6-bit integer value sign extended to 8 bits."
I understand that "a" is 6 bit signed value and ranges from -32 to 31 but as menctioned above line in specification, Is "b" is 8 bit signed value? (-128 to 127)
If "b" is not signed value: why do we need to clamp (clamp_unorm8(eo)) in Luminance+Alpha, Base_offest mode (mode#4) ?
Kindly clarify.
Devendran Mani
Devendran,
You are right that this is strictly not necessary, as the bit-transfer procedure does indeed guarantee that the unsigned value b is in the correct range. You do need to clamp e1, because the previous addition operation may overflow. I suspect that the description is down to the way the hardware works - the LDR endpoints which clamp their output share a common unit which clamps both values, and it is more expensive to special-case this decoding mode than it is to allow half of the unit to operate as a "no-op".
I was doing basic testing with ASTC encoder, I find for the below config I am fing visiable artificats:
Encode setting are : medium with upto 4 possible partitions and 1024 partition indices.
other tools such as 1/2 plane and refinement iteration 2 times are also enabled.
Visible patched at the boundaries of the objects. Is it expected?
Note: I could not up load the image, due system issue.
What kind of behaviors/artifacts are expected for 4x4 & 8x8 configuration with best & medium quality configurations.
ASTC is a lossy compression - if you reduce the bitrate you will expect to get more artefacts, in particular around edges which often have high-frequency components.
Hi Peter,
Thanks for the info.
One more question related to a ASTC encoder issue.
The ARM texture compression tool v4.2.0 & v4.1.0 give diffrent PSNR for a test image as below.
V4.2.1 = 62dB & V4.2.0 = ~50dB
Version : 4.1.0 - above image is from.
Above picture V 4.2.0 - above image.
We observed some line artifacts in V 4.2.0. after analysis we find that 0xFF00 mask is applied in the void extend block at end of decoding.
if we remove the 0xFF00 mask then the PSNR performance matches and the line artifacts are not seen.
Please share your views on this issue.
Hi Pete,
Kindly clarify the below:
We find that the images are flipped(in Y direction) before encoding and then encoded.
Please let me know why the image is flipped? - is flipping function needed in encoder?
Like most things in graphics much depends on where you think your origin is. In OpenGL ES the texture origin is in the bottom left (in Direct 3D and many related texture encoding formats it is in the top left).
Hi Devmani,
These 2 releases probably ship with different builds of the astc encoder, hence the difference in output. Thanks for flagging this,
Chris