When compressing certain textures with ASTC LDR we get corrupted results.
Source image:
Source image (1024x512 lightmap) can also be found attached to post or downloaded here:
https://dl.dropboxusercontent.com/u/7197208/images/lightmap_table-evening.png
When compressed in LDR Linear mode we get corrupted result: top part (2/3rds of image) is clear white and in the bottom source image is repeated 3 times:
When trying to compress image in LDR SRGB we get the following error:
Image is compressed correctly only in HDR mode.
This does not happen with other images, only certain ones (black-and-white lightmaps) are affected by bug.
Tested on Mali Texture Compression Tool versions 4.2.0 and 4.1.0.
Bug prevents us from using compressed ASTC textures in our Android app, its a shame because it provides excellent quality compared to ETC2 full of block artifacts.
Thank you for additional explanation on how color spaces are treated by hardware. Will try compressing textures the way you propose.
Tried compressing with -cl argument and decoding with -dl. This way I get correct result - not flipped and color is intact.
However, on hardware this texture is rendered flipped. Device is Nexus9 @ Android 6.0 preview. I have no access to other devices with AEP support but I can confirm that at least on Nexus9 this has always been an issue with ASTC textures - we've made a preliminary vertical flip of source images before compressing them to ASTC for previous app (later, it was decided to omit ASTC support in it because AEP was not wide spread yet). That'd be really great if you can test this behavior on other GPUs because now I'm not sure whether we can publish our app with ASTC support at all. If this is a bug of Tegra K1 GPU/driver then it will be a more complex problem than just flipping source images before compressing. Now there's at least 3 GPUs on market supporting AEP (Tegra K1, Adreno 4xx, Mali T760) and we have only Tegra test device.
Hi, it looks like this is a "feature" of astcenc, which TCT uses internally. astcenc uses the DirectX coordinate system (where 0,0 is at the top left of the image), so it will invert the image before compressing it, and invert it back again when decompressing it. This is different to other compressors, like etcpack, which do not do this.
You can rest assured that this is NOT a hardware issue. The way to deal with this problem is, as you have been doing, to manually invert your image before compressing it. We recommend using a tool like ImageMagick to automate this. This fix will work on all hardware that supports ASTC (we've tested it on a Galaxy Note 4 and an Nvidia Shield), and will allow you to use the same shader code to sample from ASTC textures as well as ETC1 or uncompressed textures.
For those who want to know how to flip, using imagemagick:
convert -flip <input.png> <output.png>
Thank you for explaining this. We'll use flipped source images.