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:
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:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Perhaps again? Pixel bug in Mac OS X |
LordHavoc
|
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:
-- 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
|
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.
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 :-)
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 ...
top-left glyph in the image (printing value 0) is not used normally.
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
|
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:
|
|||||||||||||||
|
Perhaps again? Pixel bug in Mac OS X |
Rob Probin
Guest
|
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:
|
|||||||||||||||||
|
Perhaps again? Pixel bug in Mac OS X |
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:
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:
|
|||||||||||||||
|
Perhaps again? Pixel bug in Mac OS X |
Rob Probin
Guest
|
R Manard wrote:
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:
|
|||||||||||||||
|
Perhaps again? Pixel bug in Mac OS X |
Jonny D
|
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:
it's in some state, I'll post to the list. We can't have SDL enough examples anyway. Jonathan Dearborn wrote:
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
|
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:
-- 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:
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:
Jeffrey Carpenter _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|