PNG images in VS2010 Resource files doing strange things on XP with GDI+

I'm using several 32 bit PNG files in my VS2010 project and loading them into GDI+ bitmaps using LoadResource/LockResource etc. and creating from an IStream. All is working fine and dandy on my Win7 development machine.

However, I'm doing some colour and alpha masking using SetColorMatrix/ImageAttributes which works fine on Win7, but when I run it on XP and call Bitmap::DrawImage with an ImageAttributes parameter, the PNG isn't drawn at all. There don't appear to be any errors at any point to suggest a problem, it just isn't visible.

If I run the same code with the image loaded directly from file instead of from a resource, it works fine on XP and Win7, but I don't really want to bundle PNG files in my installer - it seems a bit of a bodge. To make life that bit more exciting, my XP machine is too slow to even contemplate running VS2010!

Has anyone got any ideas what could be causing this, or suggestions as to track the problem down because I've spent a long time on this and I'm out of inspiration.

Thanks in advance.

Update :

After a load more testing I haven't entirely got to the bottom of this, but there's strong evidence to suggest that using the Bitmap(IStream*) constructor is somehow mangling the alpha channel on PNGs with transparency. I haven't figured out exactly what's going on, but I have found a solution - I'm now using FreeImage to load the PNG from the resource file, then creating the Bitmap object from the raw image data in the FIBITMAP. This is working perfectly, so the evidence is pointing to a problem with that Bitmap constructor.

Update 2 :

The class I created to use FreeImage to load the PNG files f开发者_如何学Gorom resources works great so for convenience I decided to use it to load all my images but it was having trouble loading standard BMP files. After a bit of investigating, it seems that when you include BMP files as BITMAP resources, the first 14 bytes of the BMP file are stripped before they're stored in the resource bundle, which makes it tricky for anything else to load them. Anyway, it's easily worked around - I just changed the resource type of the "BITMAP" resources to "BMP" so it basically treats it as an unknown type and stores the whole file. So now it's all working as intended. Just thought I'd post the experience and hopefully save someone else an hour if they try to do the same thing.

---

Put a bunch of trace statements and run on XP, there must be some error code returned somewhere. Try to not use the MFC wrapper classes and calling the raw underlying win32 API. I've had bad experiences with CImage and friends; what I do is convert png's to 32-bit bitmaps (bmp's), load those with ::LoadImage() and use ::AlphaBlt() to draw them.

Also, try with a png without transparency - all problems I had were with images with per-pixel transparency. If that works, you at least know in what direction to start looking.

---

So I found the answer myself in the end (just updating this so that I can mark it as answered).

There appears to be some sort of bug related to GDI+ and transparency in PNGs in some situations. I got around this using FreeImage to load the PNGs, but this caused another problem with BMPs. It seems that BITMAP resources in VS get 14 bytes stripped off them, presumably as this is redundant information if you've already told VS it's a bitmap. This is normally fine if you then load the resource with LoadImage() or any standard WinAPI function, but if you use another library (as I was with FreeImage), then you need to change the resource type to IMAGE (or something that's not BITMAP) before you try and load it using LoadResource.