If you export an 8 A (8bit alpha) ktx2 file, the output from ktx2check (from Khronos KTX-Software) reports a mismatch between the colour-space of the VK_FORMAT and the header information (I believe the bytesPlane0 can be ignored cuz I had the supercompression checkbox on, but the sRGB error is valid)
Issues in: A8_A.ktx2
ERROR: DFD bytesPlane0 must be non-zero for non-supercompressed
VK_FORMAT_R8_UNORM texture.
ERROR: DFD says sRGB but vkFormat is not an sRGB format.
I don’t think alpha is usually considered in sRGB, so VK_FORMAT_R8_UNORM is probably a better choice than VK_FORMAT_R8_SRGB, but then the Data Format Descriptor shouldn’t indicate sRGB.
Thank you for the bug report! We released Texture Tools Exporter 2023.1.0 today, and I made a change to the KTX writer that should write A8 using VK_FORMAT_R8_UNORM and the linear transfer function. Would it be possible to check if the new version writes A8 KTX2 files with the format you expect?
Thanks for letting me know about the new release. Good and bad news ;)
Good: I exported an A8 format image from NVTT 2023.1.0 and it is writing VK_FORMAT_R8_UNORM. It also passes the ktx2check tool now.
Bad: I also exported a BC1 format (not BC1a) but it still produced blocks with binary alpha pixels. I was using my laptop without a dedicated GPU so no CUDA.
Setting the alpha bias like you suggested does work though…gives a fully opaque BC1 image.
One last note, I could have sworn the ASTC exports weren’t handling alpha properly before. This also seems to be fixed in 2023.1.0 (tested 4x4 and 12x12). Either that or my memory is failing me.
Thank you Tristan! It looks like we fixed it, but then had a regression in a later BC1 compressor modification that broke it in a different way: now 4x4 pixel blocks where all the texels are transparent wind up having transparency set. I’ll work on a fix for this. Thank you for checking it!
