PVRTexTool library PVRTexture::Bleed comment incorrect?

PowerVR Insider
,
1

Hi,

We’re using the PVRTexTool library to do PVRTC texture compression. I’m finding that the behaviour of PVRTexture::Bleed isn’t what it says in the comment, which is:

/*!***********************************************************************
 @brief     Allows a texture's colours to run into any fully transparent areas.
 @return	True if the method succeeds.
*************************************************************************/
bool Bleed()
...

Instead of allowing a texture’s colours to run into transparent areas, I’m finding that calling Bleed results in the RGB channels being set to 0 where the alpha is low, not even 0.

This seems more similar to the PVRTexToolCLI Alpha Bleed parameter which says “Discards any data in fully transparent areas to optimise the texture for better compression.”

Can someone please confirm the behaviour of PVRTexture::Bleed?
Thank you!

2

Hi shwagger,

Thank you for your message and welcome to the PowerVR Developer Forum!

Could you please attach an example image with the issue mentioned so we can see exactly what the issue is? I will speak to the Tools Team so they are aware of this.

Best regards,
Alejandro

3

Hi, thanks for the quick response. I’ve attached the problematic texture.

ExplosionHeightGreen
ExplosionHeightGreen512×512 353 KB

It has a cloud-like alpha channel.

Using the PVRTexture::Bleed option results in a PVR that has black written to the RGB channels.

That’s not the behaviour we want, and not what I expect from a method that claims to do “Allows a texture’s colours to run into any fully transparent areas.”

Thanks.

1 Like
4

Here is what the output PVR looks like in PVRTexTool.

image
image1009×730 68.6 KB

(I needed a second post due to new user restriction)

5

Hi shwagger,

Thank you so much for the detailed example and explanation, I will go to the Tools Team with this issue and come back to you as soon as I have any news,

Best regards,
Alejandro

6

Hi shwagger,

After asking the Tools Team, it turns out there might be a simpler fix for this issue than expected: Have you tried turning on the Alpha channel in your image before doing the Bleed operation? (the “A” button in lower right corner). I used your attached example image. Doing a Bleed operation with the Alpha channel turned off gives the results you are getting, while doing the operation with the alpha channel on gives the results you might be looking for.

Let me know if this solves your issue or you are still not getting the results you were expecting.

Best regards,
Alejandro

7

Thanks for investigating,

Sorry for not being clear, we are using PVRTexLib library to procedurally batch convert our textures, not using the tool directly. But the results seem to be the same.

I’ve tried your suggestion, and still get black RGB where the alpha is low. You can see from my capture even where the alpha is between 1 and 7, the RGB is set to black. This results black looking fringe, in game.
pvr_bleed

8

Hi shwagger,

Thanks for the clarification, I have notified the Tools Team about it and will come back as soon as I have news.

Best regards,
Alejandro

9

Hi shwagger,

Apologies for the delay.

The Tools Team has corrected the issue in the bleed function. There are still some areas of the texture with alpha being set to zero, but a lot less. You will have this fix in the new version of PVRTexTool in the upcoming release of the SDK. Let me know if you are in a rush so I can handle you an engineering drop (an internal version with the fix).

Best regards,
Alejandro

10

Hi Shwagger,
There is a reason why the function stops ‘bleeding’ after a certain neighbourhood of texels and that is because PVRTC works in overlapping regions of, at most, 7x7 or 15x7 texels for 4bpp and 2bpp modes respectively.

The bleed function was there to fix issues with textures with random or unrelated colours in completely transparent, A=0, texels. However, any A=0 texel that was further away than the above distances wouldn’t be a problem and so there was no need to spend additional effort adjusting the RGB values.

1 Like
11

The issue wasn’t with the bleeding stopping. The problem is the bleed operation changing the colour to black, even where the alpha isn’t zero. i.e. removing valid colour. This causes visible artifacts.

Ultimately we just stopped using bleed. Will check it again with the new SDK.
Thanks.

1 Like