Hi all,
(I’ve added Lindsey Glickfeld to this discussion, as she asked a related question not long ago and got a much less detailed response from me.)
After spending a fair amount of time banging my head against the basics of color management and its implementation under OS X, I think I have a good understanding of how MWorks approaches these issues now and how we can improve things in the future.
What we do now
At present, MWorks does nothing to alter or correct color values provided by the user. More specifically, it performs neither full color matching nor simple gamma correction on input colors. Rather, input colors, whether read from image files or specified directly as RGB values, are implicitly treated as belonging to the color space of the display.
This has some unfortunate implications. For one thing, with a typical gamma-2.2 display, the default “medium gray” background (rgb(0.5, 0.5, 0.5)) will produce a luminance significantly less than 50% of maximum. Also, embedded ICC profiles in images are completely ignored, meaning, for example, that MWorks fails its own version of this test quite badly. (On the other hand, sRGB-encoded images should look more or less OK on a typical display, although color blending may be inaccurate.)
On the bright side, MWorks’ inaction means you can use other software to alter the display configuration without MWorks mucking things up. For example, you could use Gamma Control to alter the display’s gamma correction curve on the fly. Alternatively, to accomplish Najib and Romesh’s goal of linearizing the display, you could calibrate your display to gamma 1.0, store the calibration in an ICC profile, and assign the profile to the display in System Preferences.
What we can/should do in the future
There are a number of ways we could improve MWorks’ handling of color. Some are straightforward, while others require additional thought and discussion.
Perform color matching on image files
This seems like a no-brainer: Input images should be converted in to the color space of the stimulus display window. The pervasive awareness of color management throughout OS X and its APIs make doing this simple and straightforward.
Render visual stimuli in a linear color space
As mentioned previously, some operations in OpenGL require linear color to work correctly, so internally MWorks should perform all rendering in a linear color space.
A related but independent issue is the color space of explicitly specified RGB values. I imagine most users would expect rgb(0.5, 0.5, 0.5) to mean “gray at 50% max luminance”, so we should probably treat explicit RGB values as belonging to a linear color space, too. However, this approach has its own potentially negative implications. For example, when you use the standard OS X color picker widget, the RGB values you get out are in the system’s “Generic RGB” color space, which has a gamma of 1.8. If you then feed these values to MWorks, they’ll be interpreted as belonging to a gamma-1.0 color space and will therefore appear brighter than they did in the color picker.
There’s also the question of which linear color space to use. If the user is concerned with matching colors to external standards, then we need a color space with a standardized gamut (probably a “linearized” version of sRGB). On the hand, if it’s more important that the user be able to exercise the full gamut of the display, then we should use a linearized version of the display’s color space (as defined by its ICC profile), with the downside being that the actual colors shown will be device dependent.
Perform calibration/correction within MWorks
In addition to respecting the system-wide display color profile, MWorks could also provide ways to alter the display’s calibration.
Personally, I don’t think MWorks should be in the business of performing full-fledged display calibration and profiling. Other software packages (some open source) already do that job, and MWorks can (and should) make full use of the ICC profiles they generate.
However, we may want to make it easier for users to make display changes outside the scope of standard calibration and ICC profiles. For example, while MWorks would play no role in creating the custom gamma correction tables Lindsey needs for her use case, it could provide a means of loading them (from a file) at run time. Although the loading step could also be performed external to MWorks, clearly it’s easier on the user for MWorks to do so itself.
Getting back to the original question
Now that we’ve done a high-level survey of color issues and MWorks, let’s return to the specific question asked by Najib and Romesh: How can you gamma calibrate your monitor in conjunction with MWorks?
At present, MWorks won’t help you, but it won’t get in your way either. You have to calibrate yourself, using the tools of your choice, and apply the resulting calibration via an installed ICC profile or something like Gamma Control.
In the future, to make this process a little simpler, we could give MWorks the ability to load predefined gamma curves itself.
Alternatively, if MWorks were updated to (1) respect the ICC profiles embedded in image files and (2) treat explicit RGB color values as belonging to a linear color space, then all that would be required of the user would be to (a) provide appropriately linear input images/colors and (b) ensure that the display is accurately characterized by its assigned ICC profile. In that case, MWorks would ensure that the linear input colors are appropriately converted to the display’s color space.
For maximum flexibility, we should probably implement both of the preceding options.
Thus ends my treatise on color handling in MWorks. Please share your thoughts on the various issues and proposed paths forward.
Cheers,
Chris