transparency bug in palettizer?

[meshula]

If I load 24bit pngs instead of palettized pngs, I get this result:

If I modify Convert24ToIndexed as follows:

	/* set colors with palette indexes */
	for (y = 0; y < source->height; y += 1)
	{
		RGBTRIPLE* srccolor = (RGBTRIPLE*)srcscan;
		uint8_t* dstcolor = dstscan;
		for (x = 0; x < source->width; x += 1)
		{
			uint32_t value = PackRGB32(srccolor->r, srccolor->g, srccolor->b);
            uint8_t idx =  set_get_index(&colors, value);
            *dstcolor = !idx ? 0 : idx + 1;  ///<<< preserve palette entry zero as clear color!
			srccolor += 1;
			dstcolor += 1;
		}

		srcscan += source->pitch;
		dstscan += bitmap->pitch;
	}

it shows that we must preserve zero as a clear pixel, however the palette indexing with the +1 is clearly incorrect.

BuildPaletteFromSet hardcodes 0xFFFF00FF in entry zero, which explains why there is a +1 in the algorithm above, and makes me think that we do need to preserve zero as a clear color.

So the remaining question is why are red and blue swapped.

I came across this using stb to load the png, stb unpalettizes, which forces repalettizing.

static TLN_Bitmap LoadPNG (const char* filename)
{
    TLN_Bitmap bitmap = NULL;
    int width, height, bpp;
    uint8_t* data = stbi_load (filename, &width, &height, &bpp, 0);
    if (data)
    {
        bitmap = TLN_CreateBitmap (width, height, bpp * 8);
        if (bitmap)
        {
            int pitch = TLN_GetBitmapPitch (bitmap);
            uint8_t* dst = TLN_GetBitmapPtr (bitmap, 0, 0);
            int y;
            for (y=0; y<height; y++)
            {
                memcpy (dst, data + y * width * bpp, width * bpp);
                dst += pitch;
            }
        }
        stbi_image_free (data);
    }
    return bitmap;
}

If I load the png with stb in the same program, and ask Dear ImGui to draw it, we can see that stb did not corrupt the image:

If I load with libpng, Dear ImGui displays it properly, and it still looks incorrect in game.

[update] The problem with colors turns out to be that I was creating my Metal texture using MTLPixelFormatRGBA8Unorm, using MTLPixelFormatBGRA8Unorm gives me the right colors.

PS, I found #64 which suggests what I am trying is not supported, but since there is a palettizer in the code, I tried it out, hence this report.

[megamarc]

Hi,

I was just taking a look, the BGR/RGB problem may be a bug in Tilengine in 24 bpp conversion interpreting color indexes (RGB vs BGR). I did this feature long ago and I don't remember how I tested it...

Palettes always use index 0 as transparent (like actual 2D chipsets do). The actual RGB value itself is irrelevant, the important piece is that index 0 is skipped when rendering. That's why the palettizer reserves the first index.

The feature that I can assure is woring correctly and that I recommend you to use, is not using 24 bpp but 32 bpp instead. In this case, transparency is extracted from the alpha channel and not from a hadrcoded color value. 2D artists work this way, with 32bpp alpha channel, is much more natural. Just make sure that the whole image uses less than 255 unique colors.

Here I attach the same assets converted to 32 bpp and using alpha channel for transparency. You can drop-in them where the original 8bpp assets are located and you'll see that Tilengine handles them correctly.

Merry christmas!

tf4-32bpp.zip

[meshula]

Merry Christmas!

Thank you for the files! I'll retest with those with my stb loader, I'm confident they'll work as you describe.

My goal is that I want to use stb image, because it's already in my project, and so I didn't want to pick up libpng. As part of that goal I wanted to get your demos working with stb image with the assets in the repo, which they do with the preserve palette entry zero as clear color patch above :)

I'll keep the note about BGR/RGB in mind. My code loads ase_sprites directly using https://github.com/RandyGaul/cute_headers/blob/master/cute_aseprite.h so I will no doubt bump into ordering issues shortly as cute is hard coded to RGBA order (as are a number of other systems I'm using).