This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ASTC Evaluation Codec

Mali has just published an evaluation codec for the new ARM Adaptive Scalable Texture Compression (ASTC) standard.

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:

Getting Started

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.

How do I run the tool?

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 -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.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 -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.

Experimenting

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.

  • Note: This was originally posted on 26th November 2012 at http://forums.arm.com

    Hi,

    I'm seeing some slightly strange/inaccurate results for opaque images encoded with HDR endpoints (using either the -forcehdr_rgba or -forcehdr_rgb switches).

    In these cases the encoder produces .astc files using rgb only HDR endpoint modes, but decoding these files to .dds format results in alpha channel values less than 1. Specifically I'm seeing 16bit floats of 0x3BF7 (0.996) in the alpha channel rather than the 0x3C00 (1.0) that the spec indicates should be produced.

    Is this the best place to report bugs such as this?

    Cheers,

    Pete
  • Note: This was originally posted on 27th November 2012 at http://forums.arm.com

    Hello Pete, welcome to the forum.

    This is as good a place as any to report bugs. It would be very helpful if you could attach the problem file, and I can then have a look at it in the debugger. If the .astc file has RGB-only endpoints, then I would expect that the Alpha channel should consistently be 0x3C00 (1.0) as you say.

    Which version of the encoder are you using?
  • Note: This was originally posted on 27th November 2012 at http://forums.arm.com

    Hi Sean,

    Thanks for your reply. I've attached an example .astc file that exhibits this problem. It is a binary .astc but I had to change the extension for the forum to let me upload it!

    I've checked the source .dds image and I'm confident it had an alpha channel at 1.0 throughout. I've checked the first two blocks of the .astc file as well and I think they both use endpoint mode 7 (HDR RGB, base + scale) so shouldn't carry alpha information. To encode (in Linux) I used:

    astcenc -c AllHalfValues_in.dds AllHalfValues.astc 4x4 -medium -forcehdr_rgb

    To decode I used:

    astcenc -d AllHalfValues.astc AllHalfValues_out.dds

    I'm using the v1.1 release of the codec, downloaded from this site just a few days ago.

    Cheers,

    Pete
  • Note: This was originally posted on 28th November 2012 at http://forums.arm.com

    Pete.

    Looks like this is indeed a bug. If you are building from source, you can patch this quite easily as follows:

    In file astc_color_unquantize.cpp, lines 890 and 891 currently read:

       output0->w = 0xFFFF;
       output1->w = 0xFFFF;

    They should read:

       output0->w = 0x00FF;
       output1->w = 0x00FF;

    The bug is that these are then bit-replicated later on (by multiplying by 257), which produces 0xFEFF, which is the wrong answer for a fully-opaque texture.
  • Note: This was originally posted on 3rd December 2012 at http://forums.arm.com

    Hi Sean,

    I wasn't building from source, but I am now and this does indeed seem to fix the issue. Thanks very much!

    Out of curiosity, while in the example I posted here I used the "-forcehdr_rgb" switch, the problem also existed when I used the "-forcehdr_rgba" switch and I was wondering why this would be? Would the "alpha_force_use_of_hdr" flag not be set when this switch is used, in which case the fix above would not have any effect? (I have confirmed that it does fix the alpha for either switch.)

    Will this fix be rolled out in a new binary release at some point? If so I was wondering if there are any other bug fixes/updates in the pipeline?

    Cheers,

    Pete
  • Note: This was originally posted on 26th June 2013 at http://forums.arm.com

    I'm not sure there is any option in the standard encoder other than the -a/-alphablend option you have already found. You can use the "-ch" option to set the weight biases for the error metrics, so you can skew the compression in favor of minimizing the alpha channel error.

    That said this is designed only as a reference encoder; if you have specialized requirements the source code is included so you can tune the encoder for your specific  requirements (different error metrics, making it faster by optimizing the search space based on knowledge of your input data, etc).

    HTH,
    Iso
  • Note: This was originally posted on 14th January 2013 at http://forums.arm.com

    Hello sean,

      We found that the ASTC evaluation codec download link may have some problem. We can't get the codec any more. 

      Would you please help to confirm?  Or is there any other way to get the codec?

      Thank you!
  • Note: This was originally posted on 14th January 2013 at http://forums.arm.com

    Aceknight,

    First, many apologies for the inconvenience. During our website upgrade, a link was incorrectly ported - a simple typographical error left it pointing to a version of the file that did not exist on the new site.

    I have been in contact with the web developers and I believe that it is fixed now. Could you try downloading again and let us know if it works?

    Thanks for your patience.

    Sean Ellis
  • Note: This was originally posted on 25th January 2013 at http://forums.arm.com

    Hi Sean,

    I've noticed some unexpected behaviour with void extent blocks decoded in srgb mode (i.e. with the '-ds' switch). I expected each channel to just take the top 8 bits of the unorm in the block, but it appears that some rounding occurs so that this is not always the case.

    I presume that this is because the decoder converts the 16 bit unorm to a 16 bit float (astc_decompress_symbolic.cpp line 135) before converting back to an 8 bit integer when the image is written?

    Could you please confirm what the appropriate behaviour is here? My interpretation of the spec was that void extent unorms should be treated in the same way as unorms following interpolation (weight application) for a standard block. i.e. just truncate for srgb mode.

    Many Thanks,

    Pete
  • Note: This was originally posted on 7th February 2013 at http://forums.arm.com

    Thanks for the bug report, Pete. I will be looking into these in the next day or two - hopefully they will be simple to fix once I track down where the rounding comes in.

    The previous error has been fixed in the new version of the codec (v1.2) which is now available for download. Apologies for the delay in publishing - it got stuck in a queue. Now that I know this can happen, I will double-check all future uploads.
  • Note: This was originally posted on 25th June 2013 at http://forums.arm.com

    I have noticed that the ASTC texture file format is not documented. You can see how it works from the code, but for the benefit of everyone else, here it is:

    The ASTC file format is quite simple - there is a header at the  front of the ASTC file, which is 16 bytes in length. It is constructed  as follows:

    Bytes 0..3 are the magic header value 0x5CA1AB13
    Byte 4 is the X block dimension
    Byte 5 is the Y block dimension
    Byte 6 is the Z block dimension (which will be 1 for a 2D image)
    Bytes 7..9 are the X image size (this is a 24-bit value, measured in pixels)
    Bytes 10..12 are the Y image size
    Bytes 13..15 are the Z image size (which will be 1 for a 2D image)

    All multi-byte values are little-endian.

    Immediately following the header is the actual image data, which is a raster of compressed data blocks in X-minor, Z-major order. In OpenGL ES, this is the data that should be passed to  glCompressedTexImage2D.
  • Note: This was originally posted on 25th June 2013 at http://forums.arm.com

    Hi Sean,

    I'm having trouble understanding how to control some aspects of the format using the encoder-

    Basically, I'm looking to encode an image with an alpha-channel that is unrelated to the RGB channels. Under the hood, I want the blocks to be in dual-plane mode, with one plane's color mode devoted only to the Alpha, to maximize its integrity.

    I've looked into the 'alphablend' and 'mask' settings, but the first seems to just be de-prioritizing the RGB as the opacity decreases, and '-mask' (unless I'm misunderstanding it) treats all channels as equally unrelated, which doesn't necessarily prioritize the alpha channel.

    My question is what inputs should I be giving to the converter in order to best achieve this?

    I appreciate any help.
  • Note: This was originally posted on 4th December 2012 at http://forums.arm.com

    Pete,

    The force-rgb switch just strips the incoming image of alpha. The output code detects the presence of non-1 alpha and automatically forces rgba on output. The force-rgba switch forces the same result even if the alpha channel is all-1.

    I have committed the fix to our repository, so this will be in the next release (1.2, release currently unscheduled). I realise that I am tempting fate, but so far, there are no other bugfixes since 1.1.

    Sean.
  • Note: This was originally posted on 4th December 2012 at http://forums.arm.com

    Ok. This is different to the way I had understood the function of those switches. Am I misunderstanding something or is this different to the way they are described in the codec manual?:

    -forcehdr_rgb
          Force the use of HDR endpoint modes. By default, only LDR endpoint
          modes are used. If alpha is present, alpha is kept as LDR.
    -forcehdr_rgba
          Force the use of HDR endpoint modes. By default, only LDR endpoint
          modes are used. If alpha is present, alpha is forced into HDR as well.


    Good to know there aren't any other bugfixes at the moment! (Touch wood  )