Incorrectly handled image alpha channel

By disciplex Date 2011-11-10 10:24

I just ran a test with Ruby 1.9.3 and Gosu 0.7.38 using the code below and it worked fine.

image = Gosu::Image.new(self, 'forest.png', false)
image.draw(0, 0, 1)

Maybe some code would help?

By Jamer Date 2011-11-10 10:50

I'm using C++, but I would expect the Ruby gem to perform the same. The following code invokes the bug:

#include <Gosu/Gosu.hpp>

class GameWindow : public Gosu::Window
{
Gosu::Image image;

public:
GameWindow()
: Window(640, 480, false),
image(graphics(), L"forest.png")
{
}

void update()
{
}

void draw()
{
image.draw(0, 0, 0);
}
};

int main()
{
GameWindow window;
window.show();
}

By jlnr (dev) Date 2011-11-10 10:48

Oh, it's a 8-bit (palette) PNG. It sounds as if FreeImage has the same bug that Gosu had when it used libpng directly. Maybe you can check if there has been anything in the FreeImage changelog recently.

24-bit PNGs should be safe until then. :)

By jlnr (dev) Date 2011-11-10 10:49

I was curious and checked myself:

http://freeimage.sourceforge.net/changeslog.html

Version 3.11.0 last mentions palette images and transparency. What version of FreeImage do you use?

By Jamer Date 2011-11-10 10:54

Ooh, I'm using the packaged 3.10.0 in Debian Testing. Thanks for the response, I'll investigate newer versions. In the mean time, I'll be sure to convert to 24-bit PNGs. :)

By jlnr (dev) Date 2011-11-10 13:46

Good grief, the fix is from July 28th, 2008. :D

By erisdiscord Date 2011-11-10 15:04

See what I mean about Linux distributions dragging their asses? I barely expect Ruby 1.9 to become the standard version across distributions by 2013. C:

By RavensKrag Date 2011-11-16 07:17

It'll become the standard version by the time we're ready to all use 2.0 :D

By Jamer Date 2011-11-10 10:59

Thanks, jlnr!

By Jamer Date 2011-11-11 02:20

Unfortunately, I cannot get even the latest version of FreeImage to process it correctly. Maybe they just don't handle transparency in indexed PNGs?

By jlnr (dev) Date 2011-11-11 05:18 Edited 2011-11-11 05:31

Right, reproduced it on the latest Ubuntu. It actually contains transparency handling code, see this diff:

http://freeimage.cvs.sourceforge.net/viewvc/freeimage/FreeImage/Source/FreeImage/PluginPNG.cpp?r1=1.24&r2=1.25

The code has been cleaned up in the meantime (look for png_get_tRNS):

http://freeimage.cvs.sourceforge.net/viewvc/freeimage/FreeImage/Source/FreeImage/PluginPNG.cpp?revision=1.35&view=markup

This is the FreeImage function they use, not sure if you have to activate it with a flag or something?

http://www.scribd.com/doc/57942051/29/FreeImage-SetTransparencyTable
(see code snippet on following page)

The crappy docs of libpng don't say much either:

http://libpng.org/pub/png/libpng-1.2.5-manual.html

It looks like FreeImage is doing everything exactly as the very last version of Gosu's custom PNG loader was doing it, and that one was fixed to work with GIMP's files:

https://github.com/jlnr/gosu/commit/588fa5c5dea60862e0e83d4759b81258964a5d3c#diff-8

Can you easily pry into FreeImage with gdb?

By Jamer Date 2011-11-20 02:36

I'm not sure if it's a bug in their code, but they don't reference the transparency table when just calling FreeImage_ConvertToRawBits. Here's a patch that calls FreeImage_ConvertTo32Bits first, which acknowledges the transparency table. It requires a version of FreeImage that contains the proper transparency handling code as you've identified above.

https://github.com/jamer/gosu/commit/46c8fc6d523b37c6e77335deebb51b4df0b1cb20

By jlnr (dev) Date 2011-11-20 10:16

Thanks for the analysis, I merged the commit. I guess the world were too easy if libraries just had a Give_Me_The_R8G8B8A8_Buffer_Of_This_Image(const char*) function. :)