Hi Sean Ellis
I am writing a webgl based html application that uses astc compressed textures to be loaded on my triangle. I would like to know that does there exists a way to know whether the internal format of the compressed astc image(that in my case might be located on a remote web server) is linear or srgb encoded, by parsing the astc header. I can then use that internalFormat information obtained to pass my astc texture to glCompressedTexImage2D(). In other words, for eg. I want to know whether my internal format is "COMPRESSED_RGBA_ASTC_4x4_KHR" or "COMPRESSED_SRGB8_ALPHA8_ASTC_4x4_KHR" from the header of any astc compressed image. Any clues?
Thank you
Regards,
Deepak
> from the header of any astc compressed image
What header? The ASTC payload itself doesn't have a header.
It is possible to wrap your ASTC images in a KTX wrapper (or you could design your own) - that could carry the additional data - for example, but this isn't part of ASTC itself. The reason these constants exist at all at the API level is that the driver implementation cannot determine the format using just the ASTC binary blob .
HTH,
Pete
Hi Peter,
I am using MALI Texture Compression tool to generate astc files from a sample png image. When I read the file as an array buffer via XMLHttpRequest, I do get other relevant parameters like ASTC Magic number, width/height/depth of the image & corresponding,block width/height/depth also. So, then as per your saying, it would be the case that the MALI tool is inserting this header in the generated astc file. If so, then why don't we also have the information in that header to know whether the image is linearly or srgb encoded. Hope, I am not confusing you. Ofcourse, payload would not contain header, but the astc files so generated by the tools do have header information as well. Please let me know if my understanding is not right.
Thanks
Hi Deekap,
Thanks for the heads up, I agree it would be useful to have this information in a header. The ASTC encoder just outputs the texture blob which is passed to the GL, which happens to contain a header with - I assume - necessary information from a driver/hardware perspective. Perhaps the magic number contains some helpful information?
You've prompted me to ask a few questions internally about this, so I'll write back if I learn anything relevant.
Thanks,
Chris
Hi Chris,
Yes sure I strongly think that magic number, color encoding scheme are a few relevant things that should be present in the header outputted in the texture blob by the ASTC encoder.
It makes for more robust applications as we can do necessary validations on the application side itself because letting the Driver hardware figure it out.
Thanks.