PVR1555 encoder sets all alpha bits to 0

This topic contains 5 replies, has 3 voices, and was last updated by  Gordon 7 years, 11 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
  • #29961


    Hello Everyone,


    I’m working on a program that imports various image formats and encodes them into one of several .pvr formats. Although argb8888, argb4444, rgb565, PVRTC2 and PVRTC4 work perfectly, when I encode an image in the argb1555 format all the alpha bytes in my pixel data are set to 0 when I call CompressPVR. This occurs for images that do and do not have transparancy. As you can guess, this makes the image a little useless as it is 100% transparent.


    The pixel data is currently stored as an unsigned char* which is passed to the CPVRTexture when it is initialized. I’m calling setPixelType(MGLPT_ARGB_1555) to specify the format.


    My code looks something like this…

    // To Store the Raw Pixel Data

    unsigned char* pixelData = new unsigned char;

    // Allocate the memory needed for pixelData

    pixelData = (

    unsigned char*) malloc(32*image.width*image.height);

    // Write


    // get the utilities instance

    PVRTextureUtilities *PVRU = PVRTextureUtilities::getPointer();

    // make a CPVRTexture instance with data passed

    CPVRTexture sOriginalTexture( image.width

    , image.height, 0, 1, false, false, false, false, falsetrue, false, eInt8StandardPixelType, 0.0f, pixelData);

    // create texture to encode to

    CPVRTexture sCompressedTexture(sOriginalTexture.getHeader());

    // set required encoded pixel type


    // encode texture


    // write to file specified



    Can anyone explain to me what criteria CompressPVR uses to deturmine if an alpha bit is set to 1 or 0? Or if necessary, could anyone explain how to flip the alpha bits?


    Thank you.



    This is a bug that has already been found and fixed. Unfortunately, I don’t believe the fixed version has been incorporated into a release yet. I completely replaced the encoding system in PVRTexLib at one point and this was essentially a typo that slipped through. Since then I implemented a testing procedure that picked up the problem, but not before it got out “into the wild”.

    CompressPVR is supposed to set the alpha bit to 0 if an input pixel’s alpha is 0 and to 1 if the pixel’s alpha is anything else. Unfortunately this functionality is not present at the moment.

    I’m not entirely certain when a new maintenance release will occur so if this is essential to your pipeline please email devtech@imgtec.com and we can probably get a version of the library to you with the fix in place.

    Alternatively, you can incorporate something like the following into your code as a temporary solution:

    void PF_A1R5G5B5::encodePixel(const Pixel<uint8> *pInput, uint16 *pOutput) const


         *pOutput = (uint16) (     ((pInput->Alpha)?0x8000:0)     |

              ((pInput->Red & 0xF8)<<7)     |

              ((pInput->Green & 0xF8)<<2)     |

              ((pInput->Blue   & 0xF8)>>3)     





    Thank you Gordon. I’ve emailed devtec@imgtec.com and am currently waiting for a reply. I’m glad it wasn’t my own stupidity that was giving me problems. I attempted to incorporate your fix, but I guess I don’t quite understand how it loops through every pixel. I’m also not storring my pixel data as the Pixel<uint8> type and I’m unsure how to convert between the two. However, should I recieve a new version of the library my troubles will be solved anyways. Thanks again. GameKit2009-10-28 15:30:31



    I received the files and reproduced the bug in the version of the library current at the time.

    A new version of the library has now been released on our website os if anyone is having the same problems please try this version first.



    Hello Gordon,

    I’m having this issue with the command line version of PVRTexTool. I tried downloading the latest version of the SDK but i’m still having the same problem.

    Can you release a new version of the tool with this problem fixed?





    I installed the command line version of the tool from the separate download on the website from here: https://www.imgtec.com/powervr/insider/powervr-pvrtextool.asp This produced a correct texture using a line like above. Unfortunately, I’ve just discovered that the GUI from this package won’t decompress them correctly so it appears that they’re still broken when viewing in the program. The development version of PVRTexTool GUI displays them correctly since I applied the last fix and doesn’t seem to have this issue at all.

    This is a bit perplexing for me as I really thought I’d backported the correction fine…

    I’m guessing that the reason the GUI appears to work correctly for you is because you’ve selected an OpenGL/OpenGL ES tab when choosing the format. This is equivalent to using -fOGL1555 from the command line which is treated as a separate format with a separate code path and doesn’t have this issue. Another obvious workaround is to use this option (-fOGL1555 instead of -f1555).

    So the good news is that your textures should be encoded correctly; the bad news is that you can’t view them in the GUI correctly 🙁 I will fix this, but I don’t know if we’ll do another maintenance release before next year. If it is critical to your work path please post further.Gordon2009-11-20 10:23:32

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