   LodePNG and alpha channels
  Hi dudes!Just a question.Is it possible to load alpha channels if I use LodePNG library?http://members.gamedev.net/lode/projects/LodePNG/Thanks for help.   
  Hi,Yes it is possible, it supports 32-bit RGBA, and by default loads images with alpha channel included.   ;Quote:Original post by LodeHi,Yes it is possible, it supports 32-bit RGBA, and by default loads images with alpha channel included.Thanks for reply.Only some easy questions:*pngs have premultiplied alpha channel, as far as I know. if I send decoded data to glTexImage2D (with height and width), is it going to be right?*Must I Y-inivert pixels or there are any option over there?*How can I know more info about the loaded image, I mean, at least I should know how many channes the image has in order to pass this info to opengl. (using picoPNG)Thanks a lot.[Edited by - riruilo on April 10, 2009 12:29:23 PM];  If you decode an image with LodePNG with the standard settings, you get a 32-bit RGBA texture in a buffer. You don't have to do any calculations at all on the result. You can just create an OpenGL texture with alpha channel straight from that buffer.AFAIK the alpha channel isn't premultiplied in PNG and also not in OpenGL textures, so no conversion needed.About Y inverting, I'm not sure what you mean. The buffer starts with the top left pixel.With picoPNG, the result is *always* 32-bit RGBA, no matter what the source image was. It gets converted to RGBA. It's not possible to know what format the original image was, but you know the format of the resulting buffer is always the same.   ;Quote:Original post by LodeIf you decode an image with LodePNG with the standard settings, you get a 32-bit RGBA texture in a buffer. You don't have to do any calculations at all on the result. You can just create an OpenGL texture with alpha channel straight from that buffer.AFAIK the alpha channel isn't premultiplied in PNG and also not in OpenGL textures, so no conversion needed.About Y inverting, I'm not sure what you mean. The buffer starts with the top left pixel.With picoPNG, the result is *always* 32-bit RGBA, no matter what the source image was. It gets converted to RGBA. It's not possible to know what format the original image was, but you know the format of the resulting buffer is always the same.Hi!Thanks for reply.Your library works perfectly on the iPhone! (I'm doing a texture loader in C++)After I invert Y and remove unused alpha values from 3-channel images. Morever, as XCODE modify PNG files, I have to rename them to PN2 or PNX.Works like a charm.Thanks for your library.   ;  I forget it. OpenGL texture origin is at the bottom, and PNG origin is on the top. So, I have to flip Y in order to see the loaded texture properly:    unsigned char* pixels=(unsigned char*)malloc(decoder.getWidth()*decoder.getHeight()*decoder.getChannels());// flip Y and remove unused alpha pixels from original loaded imageunsigned int pos=0;for (unsigned int r=0; r&lt;decoder.getHeight(); r++) {for (unsigned int b=0; b&lt;decoder.getWidth()*4; b++) {// copiamos el byte si es una imagen de 4 canales, y en caso de ser 3, ignoramos el alfaif ((decoder.getChannels()==4) || (decoder.getChannels()==3 && (b+1)%4!=0)) {pixels[pos]=image[(decoder.getHeight()-r-1)*decoder.getWidth()*4+b];pos++;}}};  Personally I don't have to do the Y invert per pixel in my code in OpenGL.I draw the texture on screen as a quad, with the 4 points of the quad in this order, where 0 means left or top and 1 means the width or height of the quad:*) 0 0*) 1 0*) 1 1*) 0 1And it is not Y inverted.What system to you use to draw the texture with GL?   ;Quote:Original post by LodePersonally I don't have to do the Y invert per pixel in my code in OpenGL.I draw the texture on screen as a quad, with the 4 points of the quad in this order, where 0 means left or top and 1 means the width or height of the quad:*) 0 0*) 1 0*) 1 1*) 0 1And it is not Y inverted.What system to you use to draw the texture with GL?Really? You should see the texture inverted.OpenGL texture origin is at the bottom (in your example, too), and PNG and others formats, origin is at the top.   ;  Oh yes, you're right! Now I know what it is: It's because I set up a 2D view in OpenGL with the Y inverted in the projection matrix. For that I use the code from here:http://www.opengl.org/resources/features/KilgardTechniques/oglpitfall/Item 13 in that link "Setting Your Raster Position to a Pixel Location".But also very interesting it Item 12 above that, which talks about OpenGL's origin and this:Quote:Another common pitfall related to 2D rendering APIs having an upper left-hand coordinate system is that 2D image file formats start the image at the top scan line, not the bottom scan line. OpenGL assumes images start at the bottom scan line by default. If you do need to flip an image when rendering, you can use glPixelZoom(1,-1) to flip the image in the Y direction. Note that you can also flip the image in the X direction. Figure 4 demonstrates using glPixelZoom to flip an image.Note that glPixelZoom only works when rasterizing image rectangles with glDrawPixels or glCopyPixels. It does not work with glBitmap or glReadPixels. Unfortunately, OpenGL does not provide an efficient way to read an image from the frame buffer into memory starting with the top scan line.;  Works very nice your lib.BTW, it would be even better if you add a function like char* GetErrorStringFromCode(int error_code)XCODE modifies PNG headers and I was an hour to realise that.Thanks for your lib.   