[Will be solved in 2.0.11] PNG w/transparency breaks in SDL 2.0.10 but works in SDL 2.0.9

Hello,
I’ve been struggling with the following problem for some days and I’m hoping for someone to give me a hand.

I recently discovered a problem with SDL 2.0.10 that does not occur with SDL 2.0.9 regarding displaying PNG images with latest SDL_image 2.0.5. Some PNG images with transparency look incorrect in 2.0.10 while they used to work in 2.0.9.

I prepared the following very simple test C program for MSYS2 MinGW (Windows but confirmed it also happens in Linux) to showcase the problem with a sample PNG file attached to this topic:

// Build: x86_64-w64-mingw32-gcc sdl-show.c -o sdl-show -lmingw32 -lSDL2main -lSDL2 -lSDL2_image
//   Run: ./sdl-show.exe <IMAGE_FILE>
#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>
#include <stdio.h>

#define SCREEN_WIDTH 320
#define SCREEN_HEIGHT 240

int main(int argc, char* args[]) {
  SDL_Init(SDL_INIT_VIDEO);
  SDL_Window *window     = SDL_CreateWindow("SDL Image Test",
    SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED,
    SCREEN_WIDTH, SCREEN_HEIGHT, SDL_WINDOW_SHOWN);
  SDL_Renderer *renderer = SDL_CreateRenderer(window, -1, 0);
  SDL_Surface *image     = IMG_Load(args[1]);
  SDL_Texture *texture   = SDL_CreateTextureFromSurface(renderer, image);
  SDL_FreeSurface(image);

  SDL_Rect pos = {
    .x=(SCREEN_WIDTH - image->w) / 2,
    .y=(SCREEN_HEIGHT - image->h) / 2,
    .w=image->w, .h=image->h
  };

  SDL_SetRenderDrawColor(renderer, 0x40, 0x40, 0x40, SDL_ALPHA_OPAQUE);
  SDL_RenderClear(renderer);
  SDL_RenderCopy(renderer, texture, NULL, &pos);
  SDL_RenderPresent(renderer);

  SDL_Delay(5000);
  SDL_DestroyTexture(texture);
  SDL_DestroyRenderer(renderer);
  SDL_DestroyWindow(window);
  SDL_Quit();
  return 0;
}

For the text below, see this Imgur album: https://imgur.com/a/Jg2EXc0

When you run this sample program with the attached PNG file using SDL 2.0.9 or below and SDL_image 2.0.5 you get the expected output (image 1 in album)

However when the same program is run with the same image under SDL 2.0.10 with the same SDL_image 2.0.5, you get an incorrect output (image 2 in album)

As you can observe, the transparency data of the PNG file gets messed up. This only started to happen since I upgraded to SDL 2.0.10 on my machine.

I’m kindda stuck with this at the moment. Anyone has a clue of what can be the problem? Is this a bug in SDL 2.0.10 or maybe SDL_image needs some updates to work with SDL 2.0.10 ? Is there an undocumented change in behaviour? If that is the case, any suggestion to programatically restore the old behaviour?

Thanks a lot for your help!
Hugo


The testing PNG file is attached below (your browser probably renders the transparency correctly too):
title_grump

2 Likes

Here is another example PNG file with a similar problem:

dialog_box

The black area is supposed to be opaque and displays correctly in your browser and SDL 2.0.9 (or below), however when you display it using SDL 2.0.10 the black area becomes transparent because the black color is treated as a transparent color.

Some more information to add.

If you process the affected PNG files with pngcrush [1] using the following command then they display correctly in SDL 2.0.10:

pngcrush.exe -c 6 title_grump.png title_grump_fix.png
pngcrush.exe -c 6 dialog_box.png dialog_box_fix.png

The -c 6 option changes the PNG color-type to 6 (each pixel is an R,G,B triple, followed by an alpha sample).

[1] https://en.wikipedia.org/wiki/Pngcrush

Sounds like a bug to me.

1 Like

Thanks for replying.
Do you think you can give me some tips on where to look at to debug this?
High-level pointers are okay. I have no experience developing SDL2 components.

Hello,

a good start would be to report the image with your test case at https://bugzilla.libsdl.org/

Thanks! Indeed I’ve been thinking on migrating the issue to the bugtracker.
I hope to have time to do this as soon as possible.

I filled a bug now in SDL’s Bugzilla:
https://bugzilla.libsdl.org/show_bug.cgi?id=4798

Hopefully this mystery can be solved sooner than later.

This issue is now resolved (very quickly) by an SDL developer (Sylvain).
The fixing commit is here: https://hg.libsdl.org/SDL/rev/0c66be754e29
And it is scheduled to be included in upcoming SDL 2.0.11.