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.
Tested it without device, by decoding image using latest astcenc from github.
Running
astcenc -c test.png test.astc 8x8 -fast
astcenc -d test.astc test.tga
Results in correct image, brightness is intact. As I understand, this should create COMPRESSED_SRGB8_ALPHA8_ASTC_8x8_KHR texure.
astcenc -c test.png test.astc 8x8 -fast -srgb
Results in correct image but dark because of color conversion. As I understand, this should create COMPRESSED_RGBA_ASTC_8x8_KHR texture.
In both cases decoded tga image is not flipped.
Have no access to work environment, will test if texture correctly works on GPU as COMPRESSED_RGBA_ASTC_8x8_KHR.
You'll probably want to be using:
astcenc -cl test.png test.astc 8x8 -fast
astcenc -dl test.astc test.tga
This is the equivalent of specifying the "Low Dynamic Range (Linear) Compression Submode" in the GUI. You should get correct results if you decode it on device using COMPRESSED_RGBA_ASTC_8x8_KHR.
As far as I understand, there is no actual difference between the file formats created between using sRGB, linear, and HDR modes. The only difference is the data held within the file. The difference between COMPRESSED_SRGB8_ALPHA8_ASTC_8x8_KHR and COMPRESSED_RGBA_ASTC_8x8_KHR is only how the hardware interprets the data (so whether it does an sRGB read or a linear read).
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.