# PVR1555 encoder sets all alpha bits to 0 **URL:** \ **Category:** PowerVR Insider\ **Tags:** pvrtextool\ **Created:** [October 27, 2009, 7:57pm UTC](https://forums.imgtec.com/t/pvr1555-encoder-sets-all-alpha-bits-to-0/514 "2009-10-27T19:57:10Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![gamekit](https://avatars.discourse-cdn.com/v4/letter/g/f08c70/32.png) [@gamekit](https://forums.imgtec.com/u/gamekit)\ **Post date:** [October 27, 2009, 7:57pm UTC](https://forums.imgtec.com/t/pvr1555-encoder-sets-all-alpha-bits-to-0/514/1 "2009-10-27T19:57:10Z")
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 image.writePixels(pixelData); // 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, false, true, false, eInt8StandardPixelType, 0.0f, pixelData); // create texture to encode to CPVRTexture sCompressedTexture(sOriginalTexture.getHeader()); // set required encoded pixel type sCompressedTexture.setPixelType(MGLPT\_ARGB\_1555); // encode texture PVRU-\>CompressPVR(sOriginalTexture,sCompressedTexture); // write to file specified sCompressedTexture.writeToFile(outFile); * * *   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. ---
**Author:** ![GordonMaclachlan](https://avatars.discourse-cdn.com/v4/letter/g/c68b51/32.png) [@GordonMaclachlan](https://forums.imgtec.com/u/GordonMaclachlan)\ **Post date:** [October 28, 2009, 10:52am UTC](https://forums.imgtec.com/t/pvr1555-encoder-sets-all-alpha-bits-to-0/514/2 "2009-10-28T10:52:01Z")
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](mailto: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: Code: void PF\_A1R5G5B5::encodePixel(const Pixel\ \*pInput, uint16 \*pOutput) const {      \*pOutput = (uint16) (     ((pInput-\>Alpha)?0x8000:0)     |           ((pInput-\>Red & 0xF8)\<\<7)     |           ((pInput-\>Green & 0xF8)\<\<2)     |           ((pInput-\>Blue   & 0xF8)\>\>3)                ); } ---
**Author:** ![gamekit](https://avatars.discourse-cdn.com/v4/letter/g/f08c70/32.png) [@gamekit](https://forums.imgtec.com/u/gamekit)\ **Post date:** [October 28, 2009, 2:12pm UTC](https://forums.imgtec.com/t/pvr1555-encoder-sets-all-alpha-bits-to-0/514/3 "2009-10-28T14:12:41Z")
Thank you Gordon. I’ve emailed [devtec@imgtec.com](mailto: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\ 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 ---
**Author:** ![GordonMaclachlan](https://avatars.discourse-cdn.com/v4/letter/g/c68b51/32.png) [@GordonMaclachlan](https://forums.imgtec.com/u/GordonMaclachlan)\ **Post date:** [November 11, 2009, 4:39pm UTC](https://forums.imgtec.com/t/pvr1555-encoder-sets-all-alpha-bits-to-0/514/4 "2009-11-11T16:39:47Z")
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. ---
**Author:** ![willyrc](https://avatars.discourse-cdn.com/v4/letter/w/f0a364/32.png) [@willyrc](https://forums.imgtec.com/u/willyrc)\ **Post date:** [November 19, 2009, 6:44pm UTC](https://forums.imgtec.com/t/pvr1555-encoder-sets-all-alpha-bits-to-0/514/5 "2009-11-19T18:44:50Z")
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? Thanks, William ---
**Author:** ![GordonMaclachlan](https://avatars.discourse-cdn.com/v4/letter/g/c68b51/32.png) [@GordonMaclachlan](https://forums.imgtec.com/u/GordonMaclachlan)\ **Post date:** [November 20, 2009, 9:22am UTC](https://forums.imgtec.com/t/pvr1555-encoder-sets-all-alpha-bits-to-0/514/6 "2009-11-20T09:22:54Z")
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](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