The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
Perhaps again? Pixel bug in Mac OS X
Rob Probin
Guest

Hi,

We are using SDL2_image-2.0.0 and having a problem Mac OS X 10.9.1 where
we don't get the same color out that is in the PNG...

PNG (dark pink, used for special effects via a colour keying system):
#330034

SDL_Surface *load_surface = IMG_Load(file_name);

Color in pixel data of surface after load: #360037

This definitely doesn't happen on the Linux build.

A hot pink (used to force transparency sometimes) in PNG: #ee00fc comes
out in the surface the same: #ee00fc ... for some reason untouched...

There was a discussion about something that sounds very much like what
I'm seeing called 'Pixel bug in Mac OS X' on the 21st September 2011.
The general conclusion was that that the PNG was being handed over the
MacOSX which was breaking stuff.
Was this ever fixed?
Could this apply to SDL2_image?
Is this likely to be a libPNG or an SDL2_image problem?
Should I move to something else (e.g. lodepng) and drop SDL2_image entirely?

Regards,
Rob


On 17/02/2014 20:07, wrote:
Quote:
Send SDL mailing list submissions to


To subscribe or unsubscribe via the World Wide Web, visit
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
or, via email, send a message with subject or body 'help' to


You can reach the person managing the list at


When replying, please edit your Subject line so it is more specific
than "Re: Contents of SDL digest..."


Today's Topics:

1. Converting from basic OpenGL to SDL2 Render API (Stephen Anthony)
2. SDL_AddEventWatch ordering (Stefanos A.)


----------------------------------------------------------------------

Message: 1
Date: Mon, 17 Feb 2014 13:58:54 -0330
From: Stephen Anthony
To:
Subject: [SDL] Converting from basic OpenGL to SDL2 Render API
Message-ID:
Content-Type: Text/Plain; charset="utf-8"

OK, first a little history, and sorry for the long(ish) message. I'm
attempting to convert Stella (Atari 2600 emulator) from basic OpenGL to
SDL2 Render API. The only reason I ever added OpenGL support was to work
around deficiencies in software rendering in SDL1.2. Now that SDL2 support
hardware acceleration everywhere, it makes sense to port to it, rather
than continue with OpenGL only.

So, my use case:

I have a class representing a surface (named FBSurface). These surfaces
are basically an array of pixels/SDL_Surface structure that is uploaded to
OpenGL with TexSubImage2D. Scaling is also done where needed. Sometimes
there is scaling/blending/filtering, sometimes not. All surface are drawn
with painters algorithm. The main point being, I want to apply
scaling/blending/filtering per-surface; some will be scaled, some others
won't, etc. I figure I can use SDL_RenderCopy with appropriate src and
dest rects to get the sizes/positions I want.

Some questions:

1) Is it better to use STREAMING or STATIC textures for the FBSurface
(note that currently these change fairly often, where I directly access
the pixels).

2) How do I enable/disable blending/filtering per surface, and not for the
entire renderer?

Thanks in advance for any info,
Steve A.
Stella maintainer


------------------------------

Message: 2
Date: Mon, 17 Feb 2014 18:38:22 +0100
From: "Stefanos A."
To: SDL Development List
Subject: [SDL] SDL_AddEventWatch ordering
Message-ID:
<CAJysdvp-iyAY9Moe9dLsdzmcx3tZraspeOyR25B0gc+O=Xi6=
Content-Type: text/plain; charset="iso-8859-1"

Hello everyone,

Does SDL_AddEventWatch offer any kind of ordering guarantee? For instance,
if I call SDL_AddEventWatch two times in a row, will the event watches be
called in order, reverse order or in random?

The same question applies to SDL_SetEventFilter.

Thanks,
Stefanos
-------------- next part --------------
An HTML attachment was scrubbed...
URL:<http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20140217/9cef08c0/attachment.html>

------------------------------

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


End of SDL Digest, Vol 86, Issue 55
***********************************


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Perhaps again? Pixel bug in Mac OS X
Rob Probin
Guest

There is also a message on 6 Dec 16:04 2013 called 'SDL2 and Mac OSX
Mavericks or XCode 5'.. but I'm using Xcode 326.


P.S. A Big sorry for copying the whole digest into my original message.
What a noob error.


On 17/02/2014 22:28, Rob Probin wrote:
Quote:
Hi,

We are using SDL2_image-2.0.0 and having a problem Mac OS X 10.9.1
where we don't get the same color out that is in the PNG...


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Perhaps again? Pixel bug in Mac OS X
LordHavoc


Joined: 05 Feb 2014
Posts: 23
Location: USA
As a rule of thumb, tranparency keys should be 0xFF00FF or similar colors, which are not going to be tampered with by gamma correction.

IMG_Load is clearly hitting some APIs in the operating system that deem it worthwhile to gamma-correct the loaded png file for the user's current monitor calibrations.

How/why this is happening and how to prevent it I am not certain, but please use a better key color - it must consist only of 00 and FF in some combination Smile

That said, png is also capable of storing alpha, you may have better luck with that.

As another variant of a color key hack, you could require that the image have the transparent color in a specific pixel (such as the top left) and take whatever color that is and use it as your
transparency key, some CAD software such as Bentley Microstation has done this in the past when transparency is turned on.

I am quite concerned by the implications of IMG_Load modifying png image gamma on load however, as it could have drastic impacts on the appearance of games that do lighting math (even if they do it
properly with use of GL_EXT_texture_sRGB).

On 02/17/2014 02:28 PM, Rob Probin wrote:
Quote:
Hi,

We are using SDL2_image-2.0.0 and having a problem Mac OS X 10.9.1 where we don't get the same color out that is in the PNG...

PNG (dark pink, used for special effects via a colour keying system): #330034

SDL_Surface *load_surface = IMG_Load(file_name);

Color in pixel data of surface after load: #360037

This definitely doesn't happen on the Linux build.

A hot pink (used to force transparency sometimes) in PNG: #ee00fc comes out in the surface the same: #ee00fc ... for some reason untouched...

There was a discussion about something that sounds very much like what I'm seeing called 'Pixel bug in Mac OS X' on the 21st September 2011. The general conclusion was that that the PNG was being
handed over the MacOSX which was breaking stuff.
Was this ever fixed?
Could this apply to SDL2_image?
Is this likely to be a libPNG or an SDL2_image problem?
Should I move to something else (e.g. lodepng) and drop SDL2_image entirely?

Regards,
Rob


--
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Perhaps again? Pixel bug in Mac OS X
R Manard
Guest

How are you testing the color before and after load?
Perhaps again? Pixel bug in Mac OS X
Rob Probin
Guest

Quote:
As a rule of thumb, tranparency keys should be 0xFF00FF or similar colors, which are not going to be tampered with by gamma correction.
IMG_Load is clearly hitting some APIs in the operating system that deem it worthwhile to gamma-correct the loaded png file for the user's current monitor calibrations.


Yeah, there was two possibilities that I thought of: 1. gamma
correction, 2. Alpha pre-multiplication. For the later, since the Alpha
is all 0xff (100% opaque), then it doesn't seem likely to be (knowing
nothing about pre-multiplication really) that high values would be left
alone, but low values would not.

This is not the only time I've had a problem with MacOSX messing about
with colours - Preview (the standard image viewer) took at straight
#0000FF blue and displayed as purple. Worst still, it saved the data as
purple after modification! Later on, for some reason (maybe restart), it
didn't exhibit same behaviour. I thought I was going mad!!! (I'm
guessing some application changed the monitor color profile).

I'm sure this makes absolute sense in the publishing world, or with
normal desktop applications. But it just drives me nuts.
Quote:
How/why this is happening and how to prevent it I am not certain, but please use a better key color - it must consist only of 00 and FF in some combination Smile

Yeah _normally_ :-) I'm using all 0xFF combinations (it's Spectrum clone
of a game called Gulpman - see http://gulpman.net ) - although at the
moment not in source data - so I wanted to avoid those for my own sanity
when debugging :-)
Quote:
That said, png is also capable of storing alpha, you may have better luck with that.


Yeah, for _one_ of the uses that might be true - but that's the bright
magenta which is transparent works just fine. I use the other color key
to generate 15 color versions of the source images by composting SDL
surfaces - which works really well. If I make one colour key and another
alpha-channel transparent, then I think I'm going to have to manually
process the image data - not terrible, and already works with BMP image
files on all platforms. I'll still have the problem that the values will
have been altered, I think.

We've only started using PNG for some files recently - but I guess if
this code gets used for the next project then I'll have to deal with
partial transparencies anyway breaking the color key. There was a good
reason why we switched to PNG, but at this specific hour it escapes me ...

Quote:
As another variant of a color key hack, you could require that the image have the transparent color in a specific pixel (such as the top left) and take whatever color that is and use it as your
transparency key, some CAD software such as Bentley Microstation has done this in the past when transparency is turned on.


Yes, it's definitely possibility to pick the color up from the data. The
top-left glyph in the image (printing value 0) is not used normally.
Quote:
I am quite concerned by the implications of IMG_Load modifying png image gamma on load however, as it could have drastic impacts on the appearance of games that do lighting math (even if they do it properly with use of GL_EXT_texture_sRGB).


Agreed - I think it's horrid.

I'm sure I've noticed that World of Warcraft has different gamma full
screen to windowed mode. I'm not sure that makes sense for a game?
(extreme gamma situations???)


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Perhaps again? Pixel bug in Mac OS X
Rob Probin
Guest

Quote:

How are you testing the color before and after load?


Before load: GIMP (Linux) and GraphicConverter (MacOSX) on image itself.

After load: Linux in game in memory viewer. Mac in game in memory viewer.

Also this was working with a BMP a week ago before we changed to PNG.

(I've just caught up with the latest and added SDL2_image to the MacOSX
version).



Regards,
Rob

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Perhaps again? Pixel bug in Mac OS X
R Manard
Guest

Okay, I'm not sure about any of these viewers, by your other mentions I assume you're saying you saw it on the monitor. Please load in and display your PNG with the code here, and be sure to change the transparent in the code. If this code does not work then I would agree you have a problem. If this code works, please feel free to use it. There should not be a platform where this does not make it work. The only time I ever heard anyone say this does not work is when they press the buttons on the monitor to change the way the color looks , I suppose the platform could change it the same way if the user changes it. You might have a full understanding of the issue currently. I simply add the following for your consideration.
 
whisper8.com/data/TWINDRAGON_SDL2_GAME_EXAMPLE.zip
 
 
 
 
On Feb 18, 2014 12:02 AM, "Rob Probin" wrote:
Quote:
Quote:

How are you testing the color before and after load?
   

Before load: GIMP (Linux) and GraphicConverter (MacOSX) on image itself.

After load: Linux in game in memory viewer. Mac in game in memory viewer.

Also this was working with a BMP a week ago before we changed to PNG.

(I've just caught up with the latest and added SDL2_image to the MacOSX version).



Regards,
Rob

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Perhaps again? Pixel bug in Mac OS X
Rob Probin
Guest

Quote:

Okay, I'm not sure about any of these viewers, by your other mentions I
assume you're saying you saw it on the monitor.
Yeah, as hex values.
Quote:
Please load in and display
your PNG with the code here, and be sure to change the transparent in the
code. If this code does not work then I would agree you have a problem. If
this code works, please feel free to use it. There should not be a platform
where this does not make it work. The only time I ever heard anyone say
this does not work is when they press the buttons on the monitor to change
the way the color looks , I suppose the platform could change it the same
way if the user changes it. You might have a full understanding of the
issue currently. I simply add the following for your consideration.

whisper8.com/data/TWINDRAGON_SDL2_GAME_EXAMPLE.zip

Thanks for this .... it appears to contain only the .cpp file ... I
assume I comment out all the stuff I'm not testing?


Regards,
Rob

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Perhaps again? Pixel bug in Mac OS X
R Manard
Guest

Yep, the loading is bulletproof . If you cut and paste from the loading to the displaying just for testing it really should work. Tons of people on lots of platforms a run this. I knew I would regret putting the windows only part in there for the Windows version. I would use a solid colors for dummy graphics look at the sizes. They are pretty small images. On Feb 18, 2014 1:01 PM, "Rob Probin" wrote:
Quote:
Quote:

Okay, I'm not sure about any of these viewers, by your other mentions I
assume you're saying you saw it on the monitor.
Yeah, as hex values.
Quote:
Please load in and display
your PNG with the code here, and be sure to change the transparent in the
code. If this code does not work then I would agree you have a problem. If
this code works, please feel free to use it. There should not be a platform
where this does not make it work. The only time I ever heard anyone say
this does not work is when they press the buttons on the monitor to change
the way the color looks , I suppose the platform could change it the same
way if the user changes it. You might have a full understanding of the
issue currently. I simply add the following for your consideration.

whisper8.com/data/TWINDRAGON_SDL2_GAME_EXAMPLE.zip
   
Thanks for this .... it appears to contain only the .cpp file ... I assume I comment out all the stuff I'm not testing?


Regards,
Rob

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Perhaps again? Pixel bug in Mac OS X
R Manard
Guest

I wasn't done. My phone sent that while I was editing. Very sorry. There is an alpha hardcoded in the code there be aware. I wanted you to see loading and redundant alpha handling . My phone is wacky, once again Sorry.
Perhaps again? Pixel bug in Mac OS X
Rob Probin
Guest

So, as per my emails on the 18Feb2014, I was having problems loading PNG
files via SDL2_image on MacOSX 10.9.1, specifically 'mid-level' colours
not being loaded into the SDL_Surface as the same colour values as the
code expected from the original file.

R Manard kindly suggested I try loadings with some of his code as the basis:
whisper8.com/data/TWINDRAGON_SDL2_GAME_EXAMPLE.zip

So I did that today, and used two test images (32x32) with the left side
(16 pixels) the bright pink (#ee00fc) and the right side (16 pixels) the
dark pink (#330034) as per my previous email in formats PNG and BMP
called test.png and test.bmp. You can see the code below.

The results are (using SDL_image v2.0.0 and SDL2 v2.0.1 and Mac OS X
10.9), you will notice I get different results between SDL_LoadBMP and
IMG_Load.

If anyone could replicate these results, that would be great...

bitmap(0, 0) = ffee00fc
png(0, 0) = ffee00fc
sdlbmp(0, 0) = ee00fc
bitmap(31, 0) = ff360037
png(31, 0) = ff360037
sdlbmp(31, 0) = 330034

bitmap->format->Rmask ff0000
png->format->Rmask ff0000
sdlbmp->format->Rmask ff0000

bitmap->format->Gmask ff00
png->format->Gmask ff00
sdlbmp->format->Gmask ff00

bitmap->format->Rshift 10
png->format->Rshift 10
sdlbmp->format->Rshift 10

bitmap->format->Gshift 8
png->format->Gshift 8
sdlbmp->format->Gshift 8

(I’m currently using Lodepng in the game rather than SDL2_image, which
gives me the results I expect, but these are not included here for
simplicity.)


// Based on R A Manard "TWINDRAGON_SDL2_GAME_EXAMPLE" whisper8.com
#include <fstream>
#include "SDL.h"
#include "SDL_image.h"
using namespace std;

void exitImageError() { ofstream fout("exitImageError.txt"); fout <<
IMG_GetError() << endl; exit(1); }
void exitError() { ofstream fout("exitError.txt"); fout <<
SDL_GetError() << endl; exit(1); }

Uint32 getpixel(const SDL_Surface *surface, int x, int y)
{
int bpp = surface->format->BytesPerPixel;
/* Here p is the address to the pixel we want to retrieve */
Uint8 *p = (Uint8 *)surface->pixels + y * surface->pitch + x * bpp;

switch(bpp) {
case 1:
return *p;
break;

case 2:
return *(Uint16 *)p;
break;

case 3:
if(SDL_BYTEORDER == SDL_BIG_ENDIAN)
return p[0] << 16 | p[1] << 8 | p[2];
else
return p[0] | p[1] << 8 | p[2] << 16;
break;

case 4:
return *(Uint32 *)p;
break;

default:
return 0; /* shouldn't happen, but avoids warnings */
}

return 0; // also shouldn't happen ... again avoids warnings when inlining.
}


int main(int argc, char** argv) {
ofstream fout("diag_main.txt");
if (SDL_Init(SDL_INIT_EVERYTHING) == -1) exitError();
if ((IMG_Init(IMG_INIT_PNG) & IMG_INIT_PNG) != IMG_INIT_PNG) exitError();

SDL_Window *win = SDL_CreateWindow("whisper8.com", 50, 50, 640, 480,
SDL_WINDOW_SHOWN | SDL_WINDOW_OPENGL);
if (!win) exitError();

SDL_Surface* bitmap = IMG_Load("test.bmp"); if(!bitmap) exitError();
SDL_Surface* png = IMG_Load("test.png"); if(!png) exitError();
SDL_Surface* sdlbmp = SDL_LoadBMP("test.bmp"); if(!sdlbmp) exitError();

if(SDL_MUSTLOCK(bitmap)) { SDL_LockSurface(bitmap); }
if(SDL_MUSTLOCK(png)) { SDL_LockSurface(png); }
if(SDL_MUSTLOCK(sdlbmp)) { SDL_LockSurface(sdlbmp); }

fout << hex;
fout << "bitmap(0, 0) = " << getpixel(bitmap, 0, 0) << endl;
fout << "png(0, 0) = " << getpixel(png, 0, 0) << endl;
fout << "sdlbmp(0, 0) = " << getpixel(sdlbmp, 0, 0) << endl;
fout << "bitmap(31, 0) = " << getpixel(bitmap, 31, 0) << endl;
fout << "png(31, 0) = " << getpixel(png, 31, 0) << endl;
fout << "sdlbmp(31, 0) = " << getpixel(sdlbmp, 31, 0) << endl;
fout << endl;
fout << "bitmap->format->Rmask " << bitmap->format->Rmask << endl;
fout << "png->format->Rmask " << png->format->Rmask << endl;
fout << "sdlbmp->format->Rmask " << sdlbmp->format->Rmask << endl;
fout << endl;
fout << "bitmap->format->Gmask " << bitmap->format->Gmask << endl;
fout << "png->format->Gmask " << png->format->Gmask << endl;
fout << "sdlbmp->format->Gmask " << sdlbmp->format->Gmask << endl;
fout << endl;
fout << "bitmap->format->Rshift " << (int) bitmap->format->Rshift << endl;
fout << "png->format->Rshift " << (int) png->format->Rshift << endl;
fout << "sdlbmp->format->Rshift " << (int) sdlbmp->format->Rshift << endl;
fout << endl;
fout << "bitmap->format->Gshift " << (int) bitmap->format->Gshift << endl;
fout << "png->format->Gshift " << (int) png->format->Gshift << endl;
fout << "sdlbmp->format->Gshift " << (int) sdlbmp->format->Gshift << endl;

if(SDL_MUSTLOCK(sdlbmp)) { SDL_UnlockSurface(sdlbmp); }
if(SDL_MUSTLOCK(png)) { SDL_UnlockSurface(png); }
if(SDL_MUSTLOCK(bitmap)) { SDL_UnlockSurface(bitmap); }

IMG_Quit();
if (win) SDL_DestroyWindow(win);
SDL_Quit();
exit(0);
}

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Perhaps again? Pixel bug in Mac OS X
R Manard
Guest

Where it says in the code that I green screen everything and manually set the alpha to green you would want to manually set it to your pink color using hex value I believe . Are you saying you did use the code and did hardcoded to pink and somehow it did not use pink as the ALPHA?
Perhaps again? Pixel bug in Mac OS X
Rob Probin
Guest

R Manard wrote:
Quote:
Where it says in the code that I green screen everything and manually set
the alpha to green you would want to manually set it to your pink color
using hex value I believe . Are you saying you did use the code and did
hardcoded to pink and somehow it did not use pink as the ALPHA?

Yeah, I have similar code in my project. With SDL_LoadBMP or lodepng
(with a wrapper*) it the hard coded hex value to set works find. With
IMG_Load it doesn't. I have results from a 10.8 machine as well now -
same deal. Fine on Linux in all cases.

Notes (*) = Lodepng wrapper -
http://zedcode.blogspot.com/2014/02/how-to-use-lodepng-to-load-into-images.html


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Perhaps again? Pixel bug in Mac OS X
R Manard
Guest

Can you show me where this is the case? It's not the case in the Code you just showed. Did I miss something? You have to use the full code that I gave you from loading 2 how it displays the image in order to see the benefit of the code. There are redundant places you will not see any other example of code, at least that I've ever seen. On Feb 23, 2014 1:06 PM, "Rob Probin" wrote:
Quote:

R Manard wrote:
Quote:
Where it says in the code that I green screen everything and manually set
the alpha to green you would want to manually set it to your pink color
using hex value I believe . Are you saying you did use the code and did
hardcoded to pink and somehow it did not use pink as the ALPHA?

Yeah, I have similar code in my project. With SDL_LoadBMP or lodepng (with a wrapper*) it the hard coded hex value to set works find. With IMG_Load it doesn't. I have results from a 10.8 machine as well now - same deal. Fine on Linux in all cases.

Notes (*) = Lodepng wrapper - http://zedcode.blogspot.com/2014/02/how-to-use-lodepng-to-load-into-images.html


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Perhaps again? Pixel bug in Mac OS X
Rob Probin
Guest

R Manard wrote:
Quote:
Can you show me where this is the case? It's not the case in the Code you
just showed. Did I miss something? You have to use the full code that I
gave you from loading 2 how it displays the image in order to see the
benefit of the code. There are redundant places you will not see any other
example of code, at least that I've ever seen.

That example was just used to illustrate that the color values get
messed with on load, in a way that others could reproduce, and test on
different platforms. I think this is an SDL_image bug (my SDL_Surface
should have the same color values as the underlying file values),
although I admit this could be underlying OS 'behavior'. (I'd still
consider it unwanted in SDL_image.)

If you think it's worthwhile I'll build up a more complete example
(based on your code as exactly as I can) where the effect is present and
it doesn't affect the alpha channel - and displays something and upload
it somewhere (either my web site or github). Just so I'm clear, what
exactly are we trying to show here?

Regards,
Rob

P.S. I agree there are workarounds - high values (e.g. #FF00FF)
currently don't appear to get messed with and, also, other methods to
load images don't get affected in the same way on Mac OS X.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Perhaps again? Pixel bug in Mac OS X
R Manard
Guest

Unless you build some kind of use case or follow an example that we all can download then I'm not sure anyone can point to it and say yes there is a bug or hates your code or what do you know the OS platform has messed it up somehow or the monitor. Not with certainty. Following part of an example or using part of someone's load is not going to show much. On Feb 24, 2014 2:31 AM, "Rob Probin" wrote:
Quote:
R Manard wrote:
Quote:
Can you show me where this is the case? It's not the case in the Code you
just showed. Did I miss something? You have to use the full code that I
gave you from loading 2 how it displays the image in order to see the
benefit of the code. There are redundant places you will not see any other
example of code, at least that I've ever seen.
   
That example was just used to illustrate that the color values get messed with on load, in a way that others could reproduce, and test on different platforms. I think this is an SDL_image bug (my SDL_Surface should have the same color values as the underlying file values), although I admit this could be underlying OS 'behavior'. (I'd still consider it unwanted in SDL_image.)

If you think it's worthwhile I'll build up a more complete example (based on your code as exactly as I can) where the effect is present and it doesn't affect the alpha channel - and displays something and upload it somewhere (either my web site or github). Just so I'm clear, what exactly are we trying to show here?

Regards,
Rob

P.S. I agree there are workarounds - high values (e.g. #FF00FF) currently don't appear to get messed with and, also, other methods to load images don't get affected in the same way on Mac OS X.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Perhaps again? Pixel bug in Mac OS X
Jonny D


Joined: 12 Sep 2009
Posts: 932
This is a known effect on MacOS and iOS because SDL_image is using the ImageIO backend.  If you peek at one of the mailing list messages that introduced this change, the benefits seem to be easier maintenance, reduced framework size, and more supported file types: https://forums.libsdl.org/viewtopic.php?p=14777



Jonny D
Perhaps again? Pixel bug in Mac OS X
Rob Probin
Guest

R Manard wrote:
Quote:
Unless you build some kind of use case or follow an example that we all can
download then I'm not sure anyone can point to it and say yes there is a
bug or hates your code or what do you know the OS platform has messed it up
somehow or the monitor. Not with certainty. Following part of an example or
using part of someone's load is not going to show much.

Ok, I'll book my code into github later in the week, and extend it. Once
it's in some state, I'll post to the list.

We can't have SDL enough examples anyway.


Jonathan Dearborn wrote:
Quote:
This is a known effect on MacOS and iOS because SDL_image is using the
ImageIO backend. If you peek at one of the mailing list messages that
introduced this change, the benefits seem to be easier maintenance, reduced
framework size, and more supported file types:
https://forums.libsdl.org/viewtopic.php?p=14777

Ah, thanks Jonathan, I hadn't seen that message. Wasn't for lack of
searching... there have been other posts about colour problems.

As long we everyone knows of these effects they can 'engineer' around
them. I've also found 10.7.5 is giving different transformations than
10.9 - which may be to do with the specific gamma/colour space or just
OS differences. This affects all image loading via ImageIO (including BMP).

For the record, work-arounds mentioned on this list (that I took notice
of) were:

1. The specific colour embedded in the image with a fixed placed pixel
(e.g. at known corner)
2. Use transparency and not alpha channels
3. Use a full brightness colour key (e.g. #FF00FF).
4. Use LodePNG or one of the other image frameworks directly (libjpeg,
libpng, libgif, libtiff, etc.)
5. Use SDL_LoadBMP

(Thanks for everyone's help.)

Regards,
Rob


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Perhaps again? Pixel bug in Mac OS X
LordHavoc


Joined: 05 Feb 2014
Posts: 23
Location: USA
Fundamentally this strikes me as a case of the OS affecting SDL program behavior in undesired ways.

There will always be developers who are making a simple image viewer and they want this behavior (the OS did it for a reason after all), and there will always be developers who want a specific color
profile (usually the one that exists on disk if assets were authored correctly).

I'm in the latter camp, so I'm quite put off by the idea that ImageIO can muck with game textures that I load, and this forces me to use a different image library than SDL_image to load those images
because platform-dependent behavior on game textures is completely undesirable, especially in game engines with linear lighting (where the texture is being explicitly decoded as sRGB by the GPU - this
is a specific color profile and all assets need to match that color profile, regardless of operating system).

I tend to think the latter camp is the majority but that's more speculation than anything else.

On 02/24/2014 10:34 AM, Rob Probin wrote:
Quote:
R Manard wrote:
Quote:
Unless you build some kind of use case or follow an example that we all can
download then I'm not sure anyone can point to it and say yes there is a
bug or hates your code or what do you know the OS platform has messed it up
somehow or the monitor. Not with certainty. Following part of an example or
using part of someone's load is not going to show much.

Ok, I'll book my code into github later in the week, and extend it. Once it's in some state, I'll post to the list.

We can't have SDL enough examples anyway.


Jonathan Dearborn wrote:
Quote:
This is a known effect on MacOS and iOS because SDL_image is using the
ImageIO backend. If you peek at one of the mailing list messages that
introduced this change, the benefits seem to be easier maintenance, reduced
framework size, and more supported file types:
https://forums.libsdl.org/viewtopic.php?p=14777

Ah, thanks Jonathan, I hadn't seen that message. Wasn't for lack of searching... there have been other posts about colour problems.

As long we everyone knows of these effects they can 'engineer' around them. I've also found 10.7.5 is giving different transformations than 10.9 - which may be to do with the specific gamma/colour
space or just OS differences. This affects all image loading via ImageIO (including BMP).

For the record, work-arounds mentioned on this list (that I took notice of) were:

1. The specific colour embedded in the image with a fixed placed pixel (e.g. at known corner)
2. Use transparency and not alpha channels
3. Use a full brightness colour key (e.g. #FF00FF).
4. Use LodePNG or one of the other image frameworks directly (libjpeg, libpng, libgif, libtiff, etc.)
5. Use SDL_LoadBMP

(Thanks for everyone's help.)

Regards,
Rob


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org



--
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Perhaps again? Pixel bug in Mac OS X
Gregory Smith
Guest

On Mon, 24 Feb 2014, Forest Hale wrote:

Quote:
I'm in the latter camp, so I'm quite put off by the idea that ImageIO
can muck with game textures that I load, and this forces me to use a
different image library than SDL_image to load those images because
platform-dependent behavior on game textures is completely undesirable,
especially in game engines with linear lighting (where the texture is
being explicitly decoded as sRGB by the GPU - this is a specific color
profile and all assets need to match that color profile, regardless of
operating system).

There is also unavoidable loss reversing the alpha premultiplication
ImageIO does. This affected our use of the alpha channel in PNGs to store
the height map for parallax mapping. In the end, it was important to us to
be able to load the actual data stored in the image file! This seems like
fairly common sense functionality to me ::shrug::

There's an SDL_IMAGE_USE_COMMON_BACKEND preprocessor definition that can
be used when compiling SDL_Image 1.x, which disables the ImageIO stuff and
goes back to libpng etc. We haven't moved to SDL2 yet so I don't know if
it's still in there. If it isn't, we'll have to move to a different image
library too.

Gregory
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Perhaps again? Pixel bug in Mac OS X
Jeffrey Carpenter
Guest

Greetings!

I, too, have been plagued by mysterious pixel data mismatches, using color keying with PNG files (alpha channeled) in SDL2, and am very happy to report that building SDL2_image with SDL_IMAGE_USE_COMMON_BACKEND resolved my issue entirely. All I had to do was to include homebrew's libpng, libtiff & libjpeg dynamic libraries & header files in the Xcode project along with adding "-DSDL_IMAGE_USE_COMMON_BACKEND" to "Other C flags". (I built both SDL2 and SDL2_image as a Framework bundle).

My testing results:

ImageIO
uint32 colorkey: 1854914047
RGBA colorkey: 110, 143, 189, 255

libpng (SDL_IMAGE_USE_COMMON_BACKEND with linking to homebrew's libpng, libtiff & libjpeg):
uint32 colorkey: 1854979839
RGBA colorkey: 110, 144, 190, 255

Note that if you are redistributing SDL2_image.framework with your own library's framework bundle (such as is my case!), you will need to package the libraries within SDL2_image along with install_name_tool patching those extra libraries yourself in order for SDL2_image to find 'em on an end-user's system without homebrew & co installed.

I would love to see this issue resolved upstream somehow. Did SDL1 not use ImageIO backend? Perhaps that SDL2 maintainers chose to move to ImageIO in hopes of simplifying distribution?

Cheers,
Jeffrey Carpenter

On 2014/02/ 24, at 15:13, Gregory Smith wrote:

Quote:
On Mon, 24 Feb 2014, Forest Hale wrote:

Quote:
I'm in the latter camp, so I'm quite put off by the idea that ImageIO can muck with game textures that I load, and this forces me to use a different image library than SDL_image to load those images because platform-dependent behavior on game textures is completely undesirable, especially in game engines with linear lighting (where the texture is being explicitly decoded as sRGB by the GPU - this is a specific color profile and all assets need to match that color profile, regardless of operating system).

There is also unavoidable loss reversing the alpha premultiplication ImageIO does. This affected our use of the alpha channel in PNGs to store the height map for parallax mapping. In the end, it was important to us to be able to load the actual data stored in the image file! This seems like fairly common sense functionality to me ::shrug::

There's an SDL_IMAGE_USE_COMMON_BACKEND preprocessor definition that can be used when compiling SDL_Image 1.x, which disables the ImageIO stuff and goes back to libpng etc. We haven't moved to SDL2 yet so I don't know if it's still in there. If it isn't, we'll have to move to a different image library too.

Gregory
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Jeffrey Carpenter

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org