- May 28, 2012 at 3:27 am #30874
I’m trying to get the command line PVRTexTool to generate alpha data using the following command:
PVRTexTool -fA8 -yflip 0 -i test.png
This complains that A8 is an invalid format though it seems to be listed in the documentation. -f8 works, but returns intensity instead of alpha. Am I missing something?
This is on Windows. The main purpose is to have alpha data to work with in conjunction with RGB from ETC1. If there is a better way to do this, do let me know.
EugeneMay 28, 2012 at 9:57 am #35842
Somewhere wires have been crossed and I’m not sure whether this is a documentation problem or if the code base has changed, so I’ll investigate and try to get it updated for the next release.
In the meantime you can use “-fdx10_a8_unorm” to the same effect.
Is there some reason you can’t use PVRTC in this case? As this supports alpha it would provide a more compact + better performing solution.
TobiasMay 28, 2012 at 10:43 pm #35843
Thanks!. Yes, I am using PVRTC for our iOS builds and some Android builds, but ETC1 is the only format supported on some Android models unfortunately.
EugeneMay 30, 2012 at 7:21 am #35844
For the ETC1-only devices, if you want to reduce the memory footprint a bit, you can use ETC to get the alpha texture down to 4bpp. The trick is to create a new texture and to duplicate the A8 data into each of the R, G & B channels, and then compress with ETC1. When you read the texture, use the shader to just copy, say, the G channel into Alpha.
(Note: don’t just copy the A8 into, say, the R channel as ETC does a better job compressing images that have pixel blocks that only vary in ‘luma’)
SimonSeptember 19, 2012 at 10:46 am #35845
RebDevMemberTobias wrote:In the meantime you can use “-fdx10_a8_unorm” to the same effect.
It seems that dx10_a8_unorm is also incorrect – it generates exactly the same output as dx10_r8_unorm.