Just curious what you mean by the gamma being "too big". Gamma usually controls contrast so you're saying that colors are exaggerated?

There's no documented/undocumented feature I've seen that controls virtual virtual gamma. You're likely better off investigating this on the OpenStep side. Apple has display profiles (colorsync) in the Displays system preference that controls video gamma. I have no idea what OpenStep might have to configure this.

http://www.normankoren.com/makingfineprints1A.html#QuickGamma

use that. windows gamma values can be adjusted w/o messing with display drivers and whatnot.

ah, i can't believe i missed that. sorry for the OT post.

As is all the other features of the emulated hardware ...


I don't think gamma is any different from everything else you emulate. It's just that probably every guest operating system you officially dealt with has a gamma of 2.2, anyway, so hard-coding this value didn't lead to any specific issues. If Windows in its default settings does look right on Fusion (something I cannot judge since I don't have a Windows copy here) then you obviously do perform a hard-coded gamma conversion to emulate 2.2 for the guest operating system although the Mac OS X host uses 1.8. All OPENSTEP would need would be that this conversion is not performed, since it uses the same gamma as Mac OS X and therefore should look perfect out of the box.

Hm, this would imply that Windows on Fusion looks "washed out" (too little contrast). Is this true? If it isn't, there must be a gamma adjustment somewhere in the chain of layers between Windows and the Mac OS X display driver.


I'm by no means an expert on this, but I don't think this is correct.

AFAIK gamma is not a property of the physical display, but rather of the operating system (specifically, its display drivers). Otherwise, there would be "Mac monitors" and "PC monitors" which just isn't the case. Take any monitor, connect it to a Mac, and images created for gamma 1.8 will look correct. Take the same monitor, connect it to a PC, and images created for gamma 2.2 will look correct.

Therefore, the behavior is not the same as if I was to run Boot Camp, because with Boot Camp, the physical display is directly addressed by the Windows display driver. If Windows runs in Fusion, the Windows display driver actually communicates with the virtual machine which communicates with Mac OS X which communicates with the Mac OS X display driver which addresses the physical display. If Windows still looks correct (identical to Windows running in Boot Camp) although in Mac OS X, System Preferences > Displays > Color is calibrated to use gamma 1.8 (the default), then somewhere in this chain there must be an adjustment of the Windows gamma to the Mac gamma.

A simple proof that the virtual machine has to deal with the gamma of the host OS (and does not bypass it) is that if you change the gamma of the host OS, the colors of the guest OS inside the virtual machine are affected correspondingly. Specifically, if I start OPENSTEP in Fusion and then in Mac OS X, go to System Preferences > Displays > Color > Calibrate... and change gamma from 1.8 to 1.4, OPENSTEP (which uses 1.8) looks correct (whereas Mac OS X looks washed out, of course). So clearly, Fusion adds a gamma of 0.4 to the gamma of Mac OS X for the guest OS. This is a reasonable default since Mac OS X defaults to 1.8 while most (if not all) guest OSes you officially support will default to 2.2.

However, things will not always be this way. There might be guest OSes which use 1.8 (such as OPENSTEP), and some users might use Mac OS X with 2.2 (e.g. web developers who want to see images displayed with the Windows gamma). In both cases, Fusion's hard-coded addition of a 0.4 gamma will fail. So there really should be a gamma calibration for the virtual display.


Problem is, obviously they aretouched now.


I just tried to demonstrate that a conversion already takes place currently, so the situation could probably only get better. Also, I'm not sure the conversion would necessarily have to be lossy. I don't know how you interact with the Mac OS X graphics system, but if you could use ColorSync, you could probably just tell Mac OS X which gamma to use for the visual data you deliver, instead of doing any conversion yourself.


Apart from the fact that this wouldn't help for cases like OPENSTEP (you don't provide VMWare Tools for OPENSTEP, and OPENSTEP has no color management), I would think that this is possibly unnecessarily complicated. If possible, it should be simpler to just let ColorSync (in the case of Fusion) do the work of adapting the data from the virtual machine (that, depending on a virtual machine setting, come with 1.8 or 2.2) to the gamma Mac OS X uses.

I think it just means that at least one of your two displays is not correctly calibrated.

Of course, display hardware vastly differs, from model to model, and not just between two "Mac" and "PC" categories; there's probably as much individual specs as there are monitor models. That's why each monitor has to be calibrated, ideally individually, but at least by assigning the appropriate default color management (ColorSync, in the Mac case) profile. (In the old days of anlog displays, non-professionals might have been content with just tweaking the analog monitor knobs for color and contrast.)

Even Apple's own displays differ a lot in their color reproduction. Mac OS X automatically assignes the appropriate ColorSync profile to an Apple display that is detected at boot time, but if you explicitly specify another ColorSync display profile in System Preferences > Displays > Color afterwards, even one of another Apple display, color reproduction will grossly deviate. If Mac OS X at boot time discovers there's a third-party display connected, it tries to use an appropriate generic profile, but of course, this will not be as precise as the profiles specifically dedicated to a specific Apple display model.

Of course, while using one and the same operating system, dragging an image from one monitor to another must never change color reproduction. It simply means one display (or both of them) are not calibrated correctly.


In this Wikipedia quote, "video" refers to the combination of the graphics card, the corresponding driver, the monitor hardware and the system-wide color management module (if any).

Exactly. Gamma itself is a property of the physical display, not the OS. What the OS is responsible for is gamma correction: The OS is supposed to account for and correct for the display gamma, which is what the color calibration stuff is for. If it's misadjusted, you see the wrong thing. So we all agree here.

But Fusion (and any VMware software) doesn't gamma-correct between the guest framebuffer and what we display on the host. The host OS does, the same way it does for all display output. We're not going to do it: not only would it be lossy as Micah's been saying, but it would also be computationally expensive (in other words, performance would suck). Unless the host OS provides a way to do per-window gamma correction in hardware, which I don't know about.

Anyway, Uli - does OPENSTEP provide a gamma correction facility? If so, that's what you want to use. If not, that's sad... but I'm pretty sure you'd get exactly the same results running OPENSTEP on the same hardware without using virtualization.