Perhaps again? Pixel bug in Mac OS X

Rob_Probin · February 17, 2014, 10:28pm

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,
RobOn 17/02/2014 20:07, sdl-request at lists.libsdl.org wrote:

Send SDL mailing list submissions to
sdl at lists.libsdl.org

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
sdl-request at lists.libsdl.org

You can reach the person managing the list at
sdl-owner at lists.libsdl.org

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: sdl at lists.libsdl.org
Subject: [SDL] Converting from basic OpenGL to SDL2 Render API
Message-ID:<201402171358.54411.sa666666 at gmail.com>
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:

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).

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=w at mail.gmail.com>
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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

End of SDL Digest, Vol 86, Issue 55

Rob_Probin · February 17, 2014, 10:45pm

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:

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…

Forest_Hale · February 17, 2014, 10:54pm

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

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:

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

R_Manard · February 17, 2014, 11:00pm

How are you testing the color before and after load?

Rob_Probin · February 18, 2014, 5:53am

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.

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

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

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 …

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.

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???)

Rob_Probin · February 18, 2014, 6:01am

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

R_Manard · February 18, 2014, 8:52am

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.zipOn Feb 18, 2014 12:02 AM, “Rob Probin” <rob.probin at gmail.com> wrote:

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Rob_Probin · February 18, 2014, 7:01pm

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.
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

R_Manard · February 18, 2014, 8:22pm

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” <rob.probin at gmail.com> wrote:

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.

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

R_Manard · February 18, 2014, 8:37pm

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.

Rob_Probin · February 23, 2014, 9:07am

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
#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);
}

R_Manard · February 23, 2014, 5:38pm

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?

Rob_Probin · February 23, 2014, 7:06pm

R Manard wrote:

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

R_Manard · February 23, 2014, 8:32pm

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” <rob.probin at gmail.com> wrote:

R Manard wrote:

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Rob_Probin · February 24, 2014, 8:30am

R Manard wrote:

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.

R_Manard · February 24, 2014, 2:35pm

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” <rob.probin at gmail.com> wrote:

R Manard wrote:

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

JonnyD · February 24, 2014, 2:48pm

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

Rob_Probin · February 24, 2014, 6:34pm

R Manard wrote:

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:

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:

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

(Thanks for everyone’s help.)

Regards,
Rob

Forest_Hale · February 24, 2014, 8:31pm

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:

R Manard wrote:

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:

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:

The specific colour embedded in the image with a fixed placed pixel (e.g. at known corner)

Use transparency and not alpha channels

Use a full brightness colour key (e.g. #FF00FF).

Use LodePNG or one of the other image frameworks directly (libjpeg, libpng, libgif, libtiff, etc.)

Use SDL_LoadBMP

(Thanks for everyone’s help.)

Regards,
Rob

SDL mailing list
SDL at lists.libsdl.org
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

Gregory_Smith · February 24, 2014, 9:13pm

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.

GregoryOn Mon, 24 Feb 2014, Forest Hale wrote: