I’m experiencing issues when compressing a texture with alpha channel to ETC2. Either I’m missing some new flags, or did the behavior regress?
Particularly, I’m running (on version 5.5) PVRTexTool.exe -ssh -flip y -f ETC2_RGBA,UBN,lRGB -ics lRGB -q ETCNORMAL -i 'tex-with-transparency.png' -o 'etc-encoded.pvr'. Note that I’m not providing -l yet it looks like I still lose the colors in transparent areas the output files are exactly the same, every single byte. Am I missing something? I’m getting a warning that -ssh is ignored, but there’s no mentioning of -l being ignored (on the contrary, though, what I’m seeing is that it’s applied even if not provided …) … Additionally, it looks like the color bleeding itself doesn’t extend as far “into the transparent areas” or is there an argument that should be used to define the range? Using my compressed texture in Unity, I’m seeing some black bleeding back into my texture due to filtering …
For reference, running PVRTexTool.exe -ssh -flip y -f ETC2_RGBA -q etcfastperceptual -i '.\tex-with-transparency.png' -o 'etc-encoded.pvr' on version 4.17 behaved as expected: without -l I get my original color values, with -l I see colors bleeding into transparent areas, and then the remaining transparent pixels turning black.
Definitely! This is the file I was experimenting with:
Looks like it’s nearly invisible here But the file should be just above here, and opening in PVRTexTool GUI for instance should show you some nice salmon-colored stroke in transparent area.
Thank you for looking into this! Just to confirm, what you’re saying is that you’re reproducing the described issues as well? Or you still have to investigate?
If this turns out to be a regression, I would also be helped if you had some idea of how old the regression is (if I should just turn to version 5.4, or if I would have to go back to pre-version5). Ideally, though, it’s just some documentation issue and I’m just using the wrong parameters
Sorry for the lack of clarification, we still need to look into it.
Based on what you are reporting, it does look like a regression. If that is the case, as you well said we will need to find and report back to you the last PVRTexTool version that worked fine.
We looked into the issue and we found the latest PVRTexTool properly supporting this alpha bleeding feature is v4.23 from the 2019.2 release. From the next release (v4.24) onwards, the color bleeding in the alpha channel is much thinner as you pointed out and the tool does not behave differently when specifying the parameter or not.
Regarding the -ssh parameter, it is really -shh and it is currently not used. PVRTexTool command line just warns it is not recognized. According to the documentation it Tells the utility to not output messages of any kind., it is not something you should worry about.
I have reported this issue internally and it will be taken into account for future releases although currently I cannot specify exactly for what release it will be fixed.
Best regards and thanks a lot for reporting this,
Alejandro
Thank you for confirming this! We’ll keep an eye out on the release notes then when new releases arrive.
Final question: is the 2019.2 release still available for download anywhere? When I navigate to “Previous Releases” I can only find down to 2020 R1 … There’s then a link to “Previous release notes” which gives me the older release notes (of 2019.2, for instance) but no links to actually download these, right? Or am I missing something?
You are right. We are currently updating our Developer Portal, I already reported internally the need to allow older versions than 2020 R1 for download of all PVR Tools including PVRTexTool.
If you require the tool as soon as possible, please send an email to devtech.portal@imgtec.com this will raise an internal ticket and I will provide you the installer for PVRTexTool 2019.2
But the file should be just above here, and opening in PVRTexTool GUI for instance should show you some nice salmon-colored stroke in transparent area.