Bleeding over the edge in PVRTC compression (PVRTexTool)

This topic contains 6 replies, has 4 voices, and was last updated by  Dark_Photon 2 years ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #51841

    Hi,

    When I compress textures into PVRTC it bleeds from one side to the other. Is there a way to fix that? I’ve read recommendations of adding borders, but that doesn’t work for me, because I would have to rescale the image, which means loosing some quality.

    Why is there this limitation? I though problem is only in the tool that does compression, or is it hardware design (i.e. uncompression) that causes this problem?

    Thanks!

    #51842

    Ganesh
    Member

    Hi Paulius,

    It is the PVRTC compression format which causes it to bleed, this is true for any GPU compression format. You can read more about why it is so in PVRTextureCompression documentation.

    Are you trying to compress textures with hard edges ? Then you have to leave borders there is no way around this.

    GPU Compression formats are designed so that texture data is not unpacked when stored on the GPU, this is very friendly for memory bandwidth which is one of the most precious resources on mobile SOC.

    An Example

    A PNG(32bpp) image of 1024×1024 is 1024x1024x4 = 4,194,304 bytes which is 4MB.
    A PVRTC(4bpp) image of 1024×1024 is 1024×1024/2 = 524,288 bytes which is 0.5MB.
    A PVRTC(4bpp) image of 2048×2048 is 2048×2048/2 = 2,097,152 bytes which is 2MB.

    If you cannot leave borders you may want to double the texture size and then leave borders , this is still a lot more efficient than using an uncompressed texture format.

    Best Regards,
    Ganesh

    #51851

    > It is the PVRTC compression format which causes it to bleed, this is true for any GPU compression format.
    > You can read more about why it is so in PVRTextureCompression documentation.

    Could you point me to more specific part in the documentation? I’m having hard time understanding which part specifically causes this bleeding and why it is impossible to solve it. For example ETC compression doesn’t have this problem. Why does PVRTC have it?

    #51859

    Simon Fenney
    Moderator

    Hi Paulius,

    PVRTC doesn’t use “blocks” in the traditional Block Truncation Coding sense in the way ETC or S3TC/DXTC do, i.e. where each 4×4 block of texels is compressed completely independently of any other block.

    Most of the time, the pixels on either side of these artificial block boundaries are usually very similar. PVRTC aims to make use of this correlation by not actually using blocks – instead it shares information between overlapping neighbourhoods of pixels.

    A problem can occur at the edge of the textures. When PVRTC1 was developed, to save costs in the really small (in terms of gates) mobile devices of circa 2000, it was assumed that the textures would typically tile seamlessly and so the left edge shares information with the right and, similarly, the top edge with the bottom. Usually this is not much of an issue unless the boundaries are completely different which unfortunately may be the case for your textures.

    PVRTC2 was developed not long after and, amongst other benefits, is able to locally relax this interpolation rule but unfortunately is not exposed by the drivers in some popular devices.

    #51871

    Really great info, Simon. Quick follow-up:

    PVRTC2 was developed not long after and, amongst other benefits, is able to locally relax this interpolation rule but unfortunately is not exposed by the drivers in some popular devices.

    On devices for which it is exposed, what is the procedure for disabling the implicit GL_REPEAT wrap filtering, both on the texgen side as well as the realtime side?

    1) On the texgen side are there any special arguments to provide to force CLAMP instead of REPEAT filtering?

    2) On the realtime side, is it sufficient to specify a GL_CLAMP* wrap filter instead of GL_REPEAT?

    Thanks.

    #51885

    Simon Fenney
    Moderator

    Hi Dark_Photon,
    Currently there is no interface to the compressor to force the disabling of the toroidal wrapping (it’s not really GL_REPEAT, per se).

    Instead –provided the quality is setting for the compressor is set high enough** – the compressor will try options with/without the interpolation and choose whichever scores better from an RMSE/PSNR point of view. Note also the interpolation can be turned off away from the borders as well.

    For example the following is a 32×32 test image that has both continuous and discontinuous regions.

    leaf-test-scale

    This has been compressed with both PVRTC1 and PVRTC2:
    leaf-test-TC1-scale …. leaf-test-TC2-scale

    With PVRTC2 most of the green areas are being treated as ‘continuous’ by the compressor but it switches to other modes around the red/blue stripes etc.

    Also, just for fun, I tried the same with DXT1
    leaf-test-DXT1-scale

    Having said this, it would be useful to add a feature to force the discontinuous mode at the edges of a texture so that they can more easily be assembled “on the fly” into atlases at runtime.

    **I need to confirm this, but IIRC the lowest quality doesn’t try the “don’t wrap” modes***
    ***This may change in future versions

    Attachments:
    #51897

    Thanks, Simon. Your response was very helpful!

Viewing 7 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic.