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.
Hi,
We're investigating your issue currently, we'll update you below when we've got some further news.
Thanks,
Ryan
Any update? Have you reproduced bug? Is there some known temporary workaround (may be some options for codec, there's a whole bunch of them)?
Hi keaukraine2,
We have notified the Mali Tools team to this.
Hopefully they will get back to you soon.
Thank you for your patience.
Kind Regards,
Michael McGeagh
Thanks for your report, I can confirm that the problem has been reproduced internally and we are working on it.
In the meantime I would suggest using command-line tool to compress images if it is not a problem. You should find astcenc binary in bin/ subdirectory of the installation dir.
Here is a blog entry that describes how to use it - ASTC Evaluation Codec.
You may also want to use the latest version of the tool - ASTC Evaluation Codec on GitHub - Mali Developer Center.
Hope that helps,
Jacek
I've tried compressing it with both command line tool (latest version from GitHub) and GUI tool.
Here are my two findings so far.
1. According to documentation (p. 1.7.1 of this document http://malideveloper.arm.com/downloads/GPU_Pro_5/Stacy_ASTC_white%20paper.pdf) I used -srgb argument in command line to encode texture in linear RGBA LDR color space.This resulted in way too dark images, about 50% darker than source image. I believe that loss of brightness is not a correct behavior.
2. I've tested textures compressed with GUI tool which uses stock 4.2.0 astcenc command-line tool. No additional options set, compress in LDR Linear mode.
Albeit encoded image appeared broken in GUI preview it was compressed almost correctly, with correct brightness and no white 2/3rds bug. The only problem with output texture was that it was flipped vertically.
So for now, my workaround is to use GUI tool with flipped source images - not convenient but seems to work. I've tested these textures on GPU (I use Terga K1 - Nexus 9 @ Android 6.0 preview). They are rendered correctly.
1) Using -srgb when encoding will indeed make your images appear to be darker, as the flag converts your sRGB image from the sRGB colour space to the linear colour space. Thus, when you then try and view that image on your sRGB screen without doing the correct conversion back, it will appear darker. This is correct behaviour.
2) We've reproduced the 2/3rds white bug - it appears to be just a problem with the way the GUI loads the image; the actual conversion is successful, as you noted. At what point is the image flipped vertically? When you attempt to load it on device, or when you try and view it in the GUI? Do you get the same problem if you do the conversion using the command line tool?
Nik
1. Thanks for explaining how -srgb works. However, as I understand documentation, default is sRGB LDR so to make linear RGB it needs -srgb argument when compressing image. Please correct me if I'm wrong. If possible, could you please provide an example of correct command-line parameters to encode to linear RGB LDR ?
2. I definitely see vertically flipped textures on device (Nexus 9, have no access to any other device with ASTC support), haven't tried decoding it with command line tool to check results. In GUI it is displayed completely wrong - with 2/3rds bug. As I stated before, I don't use command line tool because I get dark images. I'll try running it w/o -srgb argument but as I understand documentation this will result in sRGB texture which is default and I need linear RGB one.
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.