Is there any way to merge two pvrtc textures

This topic contains 4 replies, has 2 voices, and was last updated by  Simon 5 years, 11 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #30692

    Hello everyone,

    The quality of pvrtc compressed texture for png images with alpha channel is not good enough for our game. But that of the pvrtc for png image without alpha (white background) channel is very good.

    So I planed to decompose our png images into a RGB565 images and an alpha channel bitmap. And then compress these two images separately.

    When rendering, I can combine the compressed RGB565 .pvr and alpha .pvr using shader or multi-texture. However, this will cost extract time. I don’t want to combine them each time I render the image. Is there any way to pre-combine these two .pvr together when I initialize opengl and used the result .pvr as the only texture for rendering?

    Thanks!

    #35248

    Simon
    Moderator

    Hi Oliver,
    When PVRTC encodes RGBA, it assumes that there is some correlation between all of the colour channels. If the alpha is doing something wildly different to RGB, then it’s unlikely to do a brilliant job and trying to merge two separately compressed textures 4bpp textures into a single 4bpp is unlikely to help. (Note that PVRTC is not like, say,  the 8bpp DXT5 which, in effect, is two independent 4bpp textures packed together – one containing RGB and the other alpha)

    Having said that, there are some things you can try. Are you using pre-multiplied or non-premultiplied? By the sound of the “… png image without alpha (white background)…” I’m guessing you’re using non-premultiplied and that the RGB values in those regions are white.  If you were to replace the RGB data in transparent or nearly transparent areas with something that was closer to the nearby colours in the non-transparent regions, the compressor might do a better job.

    If that still is not good enough, you might have to use the multi-texture approach but, to get better quality, you could try putting your alpha data into the R or G channels of the second texture (and set B to, say, 0 or 255) as R&G have more precision than the Alpha.

    #35249

    Hi SimonF,

    Thank you for your reply! I will try your recommendation.

    One more question…I found that the PVRTexTool works better on 16bit bmp image than on 24bit bmp image.

    1) I convert my PNG8888 image to a 24bit bmp using phtoshop (img1)

    2) convert PNG8888 to a 16bit bmp (img2)

    And then I compress img1 and img2 using PVRTexTool. I found that the quality of img2 is better than img1. What is the reason? Is it because that when I convert a png8888 to bmp16, some colors will have slightly changes? since 16bit can represent less color than 24bit.

    Thanks!

    #35250

    And, what is the difference between premultiplied alpha image and non-premultiplied? Which one can generate better PVRTC?

    Do you have any tips for generating good quality PVRTC?

    #35251

    Simon
    Moderator
    oliverhuang wrote:
    Hi SimonF,

    Thank you for your reply! I will try your recommendation.

    No worries. It’s just that I’ve had some test textures sent to me in the past where the RGB values in fully transparent areas have been almost “random” (!). The texture compressor tries to do its best to represent them but will struggle. Anything that makes it easier to represent (especially in areas that, in practice, won’t be seen) will help.

    Quote:
    One more question…I found that the PVRTexTool works better on 16bit bmp image than on 24bit bmp image.

    1) I convert my PNG8888 image to a 24bit bmp using phtoshop (img1)

    2) convert PNG8888 to a 16bit bmp (img2)

    And then I compress img1 and img2 using PVRTexTool. I found that the quality of img2 is better than img1. What is the reason? Is it because that when I convert a png8888 to bmp16, some colors will have slightly changes? since 16bit can represent less color than 24bit.

    That sounds very odd and I don’t have an explanation for that at all! Exactly what colour format are you using for the 16bit? Is it RGB 565 or RGBA 4444, or something else? 

    Quote:
    And, what is the difference between premultiplied
    alpha image and non-premultiplied? Which one can generate better PVRTC?

    I’m not sure if you are asking what the definitions of “premultiplied
    alpha2 VS “non-pre…” actually are or what the difference would be with respect to PVRTC.  If it’s just the former (and I do apologise if you already know all this) then maybe these links may be of help:

    In terms of OpenGL-ES, for non-premultiplied you typically use a (SrcAlpha, 1-SrcAlpha) blend, and a (1, 1-SrcAlpha) for premultiplied.

    Now WRT to the 4bpp PVRTC (version 1), I’m not sure I can give a definitive recommendation. It was designed when virtually everyone was using non-premultiplied alpha. The 4bpp version has a special way of encoding fully transparent alpha pixels but it “sort of” assumes that the RGB values of those pixels are similar to the those of the opaque or nearly opaque neighbouring pixels. This choice was made to reduce ugly halo effects that can occur when doing bilinear filtering. 
    Having said that, there potentially are advantages in using premultiplied as it automatically increases the correlation between the alpha channel and the RGB, making it easier to compress.

    For 2bpp, I would imagine that pre-multiplied would nearly always be a better choice.

    Quote:
    Do you have any tips for generating good quality PVRTC?

    As I said, usually the problems occur when a (non constant) Alpha channel is doing something completely unrelated to the RGB channels, but that may be something over which you have no control.

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