We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Created attachment 435 [details]
correct behaviour (1.2.13)

Created attachment 436 [details]
wrong behaviour (1.2.14 + 1,3)

Created attachment 437 [details]
correct behaviour with background red channel as alpha

Created attachment 438 [details]
another (more evident) screenshot of the wrong behaviour

Are you able to reproduce this with showimage, or is this a problem in your application?

There were a few color issues in some games that turned out to be the game assuming the order of the RGB channels, but once they started checking the masks in the screen->format, everything was fine.

(In reply to comment #5)
> Are you able to reproduce this with showimage, or is this a problem in your
> application?
> 
> There were a few color issues in some games that turned out to be the game
> assuming the order of the RGB channels, but once they started checking the
> masks in the screen->format, everything was fine.

We're quite sure that the order of the channels are correct because the other images are displayed correctly -- the problem only arise when images with alpha are blended.

a similar issue was found here http://forums.libsdl.org/viewtopic.php?p=19729 where opacity is applied in two different ways on OSX and win.

btw our application is located at http://www.hedgewars.org/ and you can read the source here http://fireforge.net/scm/viewvc.php/trunk/hedgewars/?root=hedgewars (the IMG_Load is in uStore.pas)

hm we noticed that by stripping color profiles from the png helped with the background image.
perhaps our theory was wrong, but does sdlimage handles color profiles correcly in the new backend?

Ok, dumping the first column of a buggy SDL surface, we noticed an interesting pattern:

A B G R

SDL on OSX
206 | 177 | 131 | 125

GIMP
206 | 220 | 163 | 155


SDL on OSX
14 | 8 | 5 | 4

GIMP
14 | 157 | 92 | 84

Pattern seems to be that if you take:
177 * (255/206) ~ 219

and
8 * (255/14) ~ 146

Now, that 2nd one is not so accurate. But.
157 / (255 / 14) = 8.58 which if truncated is 8.

220 / (255 / 206) = 177.72 = 177

So we could be dealing with some curious modification proportional to alpha and a floor operation to boot.

Fortunately the fix for that is fairly trivial, until SDL is fixed, we can ifdef DARWIN to reverse the damage.
The truncation means some accuracy is lost, but hopefully not too much.

From nemo:

Hey. Turns out the problem was a bit weirder than someone simply messing up RGBA vs ABGR.
http://forums.libsdl.org/viewtopic.php?p=20011#20011

Eric, can you look into this?

is there any update on this?
in the meantime i have updated the workaround code

{$IFDEF DARWIN}   
				tmpP := tmpsurf^.pixels;                                             
				for i:= 0 to (tmpsurf^.pitch shr 2) * tmpsurf^.h - 1 do 
				begin
{$IFDEF ENDIAN_LITTLE}
					tmpA:= tmpP^[i] shr 24 and $FF;
					tmpR:= tmpP^[i] shr 16 and $FF;
					tmpG:= tmpP^[i] shr 8 and $FF;
					tmpB:= tmpP^[i] and $FF;
{$ELSE}
					tmpA:= tmpP^[i] and $FF;
					tmpR:= tmpP^[i] shr 8 and $FF;
					tmpG:= tmpP^[i] shr 16 and $FF;
					tmpB:= tmpP^[i] shr 24 and $FF;
{$ENDIF}
					if tmpA <> 0 then
					begin
						tmpR:= round(tmpR * 255/tmpA);
						tmpG:= round(tmpG * 255/tmpA);
						tmpB:= round(tmpB * 255/tmpA);
					end;

					if tmpR > 255 then tmpR:= 255;
					if tmpG > 255 then tmpG:= 255;
					if tmpB > 255 then tmpB:= 255;

{$IFDEF ENDIAN_LITTLE}
					tmpP^[i]:= (tmpA shl 24) or (tmpR shl 16) or (tmpG shl 8) or tmpB; 
{$ELSE}
					tmpP^[i]:= (tmpA) or (tmpR shl 8) or (tmpG shl 16) or (tmpB shl 24); 
{$ENDIF}
				end;
{$ENDIF}

Oh, it looks like Mac OS X is just pre-multiplying the alpha.  Thanks for the great workaround code!

And of course looking at the code, I see we're explicitly asking for that with kCGImageAlphaPremultipliedFirst.

It turns out that ImageIO only supports pre-multiplied alpha output.  Ugh.
http://lists.apple.com/archives/mac-opengl/2007/may/msg00056.html

Out of curiosity, what does your workaround do to this image?
http://www.w3.org/Graphics/PNG/alphatest.png

Nevermind, this is fixed now, thanks!
http://www.libsdl.org/tmp/SDL_image/SDL_image-1.2.9.tar.gz

ok now it works fine, thanks!
there is just one thing that worries me is that by looking at the code
 Uint8 *p = (Uint8 *)surface->pixels;
 Uint8 A = p[3];
so we are using 8 bits for Alpha, 8 for Red, 8 for Green and 8 for Blue; then we make a division and save it on an eight bit variable

if the result of the operation is something like 99.99 then the result stored would be 99, truncating the .99, making the color a little darker -- not noticable -- but different from an alpha-free surface; every computation on color value would be likely to fail with this code.

What do you think of this possibility?

PowerPC loading is broken

normal pngs work fine but pngs with alpha segfault
showimage's output is

showimage(52993) malloc: *** error for object 0x837200: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug

(attached BlueWater.png)

Created attachment 448 [details]
test image used in showimage to test ppc code

The crash is fixed, thanks!

As for the inaccuracy in the multiplication, we might be able to solve it by using 256 instead of 255, although that might break things the other direction.