Loading indexed images with transparency

[pvallet]

Hello everybody,

I'm working on a SFML + OpenGL project that uses age of empires sprites (with indexed colors) and transparency. However when loading the images some weird artifacts appear. The alpha channel seems to modify the rgb channel on loading.

This is an OpenGL render without glblend where the texture behaves as expected: the transparent pixels have a black color.

See aoe1.png (I'm sorry I don't know how to integrate the image in the post).
The palette can be seen on aoe1_palette.png

But when using age of empires 2 palette, it gives some blue color to the transparent background, as seen on aoe2.png
The palette is aoe2_palette.png

Note that the color of the background is not present on the palette (even though some are close). The same effect appears with a custom palette.

It does work with unindexed color though, and I'll eventually come to using it, but I feel like it's a huge waste of space.

Edit: I'm using SFML 2.4.2 and the bug appears on Linux, Mac OS and Windows

Thanks in advance for your help !

Paul

[eXpl0it3r]

I'm not quite sure I understood your problem.

The background color just seems to be a solid color instead of a transparent (alpha channel = 0) color.
I bet the original sprites weren't saved as PNG anyways.

The best solution is to open the image up in an image editor and replace the background color with a truly transparent color.
The other option is to use sf::Image's masking functionality before passing the image data to a texture.

Btw. make sure your AoEII sprite usage falls under fair use, otherwise you should look for some free sprite sheets.

[pvallet]

Ok I'll try to explain it better.

The images are stored as png, and the transparent pixels are (0,0,0,0) (a truly transparent background). When loading, SFML sometimes converts those pixels to (somebluecolor, 0), which yields the blue background instead of the expected black one (when I render with transparency disabled).

[eXpl0it3r]

And why do you know it's like that?
I mean just look at the images post on the forum here. One has a black (non transparent) background and the other one has a blue (non transparent) background. Same result when I open it in Paint.Net or PhotoFiltre.
So how do you conclude that the background color should be black and transparent?

[pvallet]

These are screenshots from my rendering engine.

Here are the png loaded by the engine

[pvallet]

Oh sorry, these were sprite sheets I converted to avoid indexed colors.

Here are the indexed ones

Edit: I looked at the palettes using GIMP.

I'm sorry about the explanation, I hope it's a bit more understandable now.

[eXpl0it3r]

The indexed and the non-indexed, both work fine for me.

(click to show/hide)

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(1280, 720), "SFML works!");
    window.setVerticalSyncEnabled(true);

    sf::Texture aoe1;
    aoe1.loadFromFile("AoEII-1.png");
    sf::Sprite aoe1s(aoe1);
    aoe1s.setPosition({500.f, 0.f});

    sf::Texture aoe2;
    aoe2.loadFromFile("AoEII-2.png");
    sf::Sprite aoe2s(aoe2);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
            if (event.type == sf::Event::Closed)
                window.close();

        window.clear(sf::Color::White);
        window.draw(aoe1s);
        window.draw(aoe2s);
        window.display();
    }
}
 

[pvallet]

Ok I'll try to come up with a minimal code that reproduces the error. This might take a bit more time as I'm currently using OpenGL only.

[pvallet]

Here it is !
There is a small readme to build it on linux.

It uses a texture array instead of several textures, I hope it is still minimal enough for you. As there are VAOs and VBOs the code also works on OpenGL 3.3 (core) and thus should run on OS X.

[pvallet]

If this is an SFML internal bug should I raise a github issue ?

[Paul]

It does work with unindexed color though, and I'll eventually come to using it, but I feel like it's a huge waste of space.

Indexed palletes are pain from the past. For smaller files or less memory usage you can use PNG with RGBA4444 or use some optimalization like PngOpt.

And you can get better result:
original indexed.png = 24 281 bytes
indexed.png RGBA8888 with opt. level 1 = 23 670 bytes (1:1 with origninal, no losses in qualilty)

[pvallet]

Why is it a pain from the past ? It seems to me that the indexed encoding is a good lossless compression algorithm, and should not be that hard to support.

And you can get better result that with

Ah yes that's pretty neat. I'll check pngcrush (pngopt seems to be only a wrapper of pngcrush).

[Paul]

Why is it a pain from the past ?

I was modding one old game. If game use indexed palettes you never fit into with colors. So your new graphics will looks different and it take lot of time to get similar result as original. And these games don't use 1 palette but many for same kind of objects (or subpalettes based on original colors).. impossible

[pvallet]

If game use indexed palettes you never fit into with colors.

Yes indeed that would be quite difficult to work with game color palettes, but in this case the palettes are stored in each image so I don't need to worry about my colors being modified. I still gain a lot of space though.