The PVRTexTool premultiplies alpha into the rgb channels. I’m encoding single channel textures that happen to have an alpha channel of 0. Even though I set -alpha Image0001.png,a to force alpha=1, but apparently the data has already been lost. This is on OSX. I suspect you’re not passing the correct flags to OSX when you decode the image.
rgb*a,a. 100 x 0,0. <- tool is loading and doing premul
rgb*a/a, a. 000, 0. <- lost the data in conversion back from premul
rgb,1 <- -alpha sets a=1 (but really now 000,1 should be 1001)
Also this will result in lower precision than the original image even for RGB and RGBA images. I don’t have -l on the command line (premul option).
- When ASTCMxN,UBN,sRGB mode is used, the colors of my PNG are blown out to super bright (they’re RGB color space). The only thing this should do on an image is set the SRGB_ALPHA version of the ASTC constant into the KTX file. This should have no affect on the imported pixels.
These two bugs make the PVRTexTool unusable for any kind of production work. It’s a very useful tool with a lot of great options. I supposed ImageMagick could be used to force the alpha to 1 before it hits PVRTexTool for the 1/2/3 channel case. That won’t fix data loss in the 4 channel case with alpha that are within 0 to 1.
Since -red/…/-alpha apparently set the value after the premul load, you can use the copied image with alpha set to 1 (to get past premul load), and then use -alpha originalImage.png to set the alpha from the original.