View Full Version : Mac problem - brightness/contrast.
Phil Steinmeyer
01-10-2006, 04:05 PM
It's been pointed out to me that in the Mac version of my game, the colors are a little brighter and a bit lower contrast, on average, than in the Windows version.
I'm not actively doing anything to encourage this. I'm using SDL to load JPEGs and such for my images, then blitting them to the screen. I believe I had to do a byte reversal for the Mac, but I doubt anything I did there would cause subtle contrast/lighting issues - if you get that stuff wrong, it's really obvious (all your blues are green, etc.).
I used the 'Grab' utility on the Mac to grab screenshots and transfer them to my Windows PC to do a photoshop comparison against identical screens from the Windows version. But when I open up the tiff that the Mac generated, Photoshop gives me a warning about the colorspace and says it will be using the one embedded in the image. So I'm not sure I can trust my photoshop comparison, but, FWIW, that DOES show differences in the colors of given pixels.
Interestingly, the colors are not arbitrarily brighter or darker on the Mac, but rather, each channel is a bit off, some higher, some lower depending on the pixel.
So is this some known issue that I'm not doing right on the Mac? Is there any way to get a screen grab on the Mac, bring it on the PC, and compare to a PC screen grab where I can be certain no behind-the-scenes remapping is going on?
AFAIK, I haven't done anything special on my miniMac or on my PC (ATI x300) to futz with the default color spaces and such. And other users are reporting the same issue - it's visible to the naked eye, but subtle.
soniCron
01-10-2006, 05:04 PM
Phil,
The Windows and Mac platforms have different internal gamma settings. Gamma affects the brightness and contrast of the display. Windows gamma is 2.5 and Mac is 1.8. (I believe.) Because of these differences, a lot of care has to be taken with regards to color consistency when traversing between the two platforms. (Taking it to television is an even bigger jump with saturation levels through the roof!) If you're using different monitors, they may have their colors calibrated to different levels. If not (if you're using a KVM switch), then I suspect you may have a software adjustment working for you. If you've got Photoshop, then there's a "Gamma Correction" utility in the Control Panel. I'm not sure about Mac, but I'd suspect the same thing is happening there. Try Googling for "windows mac gamma" (http://www.google.com/search?q=windows+mac+gamma)
Tom Cain
01-10-2006, 05:06 PM
I believe the problem is that Mac uses a default gamma of 1.8 and Windows uses 2.2. I've had to deal with the problem for years when building for both platforms, most recently with my own new Mac site. It can be frustrating.
If this is the problem you're having and you don't want to adjust gamma by platform in your code, the only option I've found is to adjust your graphics so they look okay on both platforms. You can do this in Photoshop:
Set your RGB Color Settings to sRGB.
Select View > Proof Setup > Macintosh RGB to proof it with Mac gamma.
Select View > Proof Setup > Windows RGB to proof it with Windows gamma.
Use the middle slider of Image > Adjust > Levels to tweak the graphic until it looks okay in both proof settings.
You'll want to adjust all graphics with the same Levels setting. I would work on one main graphic first to get the setting, then use Photoshop's Actions automation to batch-adjust everything else. I'll be glad to answer any questions about the process if you need to go this route, I've done it a lot.
Robert Cummings
01-10-2006, 05:29 PM
surely it's better to adjust the gamma of your render?
Phil Steinmeyer
01-10-2006, 05:37 PM
Well, my images are already done - I'm just trying to wrap up the mac port.
I'll have to analyze the files a bit more closely, but I assume I could tweak each image a bit as it's loaded on the Mac, right? Since I'm already running pixel-by-pixel over each loaded image on the Mac (to reverse byte order), this would only be adding a few lines of code and a neglible speed hit (it's only done once at load time).
What algorithm, if any, would I apply to the pixels to tweak them?
mr n00b
01-11-2006, 12:39 AM
The output intensity can be approximated by:
I = pixel_intensity ^ gamma
where pixel_intensity is in the range to [0, 1].
For the Mac and PC pixels to be similar you have:
I = pc_pixel_intensity ^ 2.5 = mac_pixel_intensity ^ 1.8
=>
2.5 log (px_pixel_intensity) = 1.8 log (mac_pixel_intensity)
=>
mac_pixel_intensity = exp( (2.5 / 1.8) log(pc_pixel_intensity))
There might be some cutoff in the values though.
/mr n00b
Trick
01-12-2006, 01:29 AM
You might find the SDL_SetGamma (http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fSetGamma) function helpful (although you should note that using this may affect the entire display when the window is active, not just the window contents .. does that in Linux/X, at least).
lexaloffle
01-12-2006, 05:13 AM
I don't know if this is relevant, but I had a similar problem when I was porting to OSX with sdl. The colours weren't slightly off though - they were extremely overlit and consequently with very little contrast. I could get something which looked more normal by arbitrarily setting the gamma to something like 0.5. I discovered that it only happened when the game was in fullscreen 8 bit mode though, and as I started running everything in 32 bit colour anyway (because of problems I was having with newer monitors), the problem became moot and I didn't look into it any further.
So, just out of curiousity.. what kind of video mode are you using?
Phil Steinmeyer
01-12-2006, 01:49 PM
Hmm, there is definitely a gamma diff between Mac and PC - that's the root of the problem.
Using SDL_SetGamma, I found my PC (w/ ATI x300), has a default gamma of 2.0.
My miniMac is about a 2.25 (couldn't quite pin it down EXACTLY, but it was between 2.2 and 2.3).
I'm not sure if there's further variations across Mac versions and/or across PC card vendors.
The SDL_SetGamma command DOES work, but it scares me in a couple ways:
1) In windowed mode, it changes the gamma of the whole screen, not just your window.
2) What if a user has his gamma set a special way for some valid reason.
Unfortunately, there's no SDL_GetGamma, for whatever reason...
I can't decide whether to
1) Ignore it - let the Mac port be a little brighter/washed out (it's not too glaring)
2) Use SDL_SetGamma only in full screen mode
3) Use SDL_SetGamma all the time
4) Do a one time software gamma adjust when images load (works for all bitmaps, but not for a limited number of dynamic effects I have)
5) Do a software gamma adjust every frame, pixel-by-pixel (using lookup tables).
I'd lean towards 1, 2, or 4. What do you guys think, and/or what's the standard practice?
soniCron
01-12-2006, 02:15 PM
I'd lean towards 1, 2, or 4. What do you guys think, and/or what's the standard practice? It depends on how your codepath works, but adjusting gamma on images being loaded should be easy and safe. Many image formats (like PNG) embed the gamma info directly into the file so that it can be displayed with the correct gamma, so adjusting pixels isn't uncommon.
mr n00b
01-13-2006, 01:17 AM
Hmm, there is definitely a gamma diff between Mac and PC - that's the root of the problem.
Using SDL_SetGamma, I found my PC (w/ ATI x300), has a default gamma of 2.0.
My miniMac is about a 2.25 (couldn't quite pin it down EXACTLY, but it was between 2.2 and 2.3).
I'm not sure if there's further variations across Mac versions and/or across PC card vendors.
The SDL_SetGamma command DOES work, but it scares me in a couple ways:
1) In windowed mode, it changes the gamma of the whole screen, not just your window.
2) What if a user has his gamma set a special way for some valid reason.
Unfortunately, there's no SDL_GetGamma, for whatever reason...
I can't decide whether to
1) Ignore it - let the Mac port be a little brighter/washed out (it's not too glaring)
2) Use SDL_SetGamma only in full screen mode
3) Use SDL_SetGamma all the time
4) Do a one time software gamma adjust when images load (works for all bitmaps, but not for a limited number of dynamic effects I have)
5) Do a software gamma adjust every frame, pixel-by-pixel (using lookup tables).
I'd lean towards 1, 2, or 4. What do you guys think, and/or what's the standard practice?
1) If your customers dont have a problem with, why not. I suspect many small developers (and even some big ones do this).
2) This is what most big semiold commercial games does.
3) I wouldn't do this, suddenly your applications behaviour intrudes on the rest of the desktop.
4) If you get away with it this is probably your best shot, as you said it won't give 100% correct result when you do things like alpha blending or multitexturing though.
5) I wouldn't recommend this, it will be slow as hell. However, if your target minspec allows it you could do it with programmable graphics hardware (i.e pixel shaders/programs).
/mr n00b
Phil Steinmeyer
01-13-2006, 08:15 AM
I went with option 2 - definitely the easiest to implement.
soniCron
01-27-2006, 12:38 AM
I just had a thought: If you're using PNG and libpng, then I believe there's some functionality to set gamma when loading.
vBulletin v3.6.0, Copyright ©2000-2008, Jelsoft Enterprises Ltd.