Why your Web content will look darker on Snow Leopard
blogs.adobe.com
blogs.adobe.com
> ... wondering why Apple would change the Mac to match Windows after 25 years of using gamma 1.8 ...
No, the original Mac had only black & white. No gray (or any other colors besides black & white), and thus no gamma. The earliest Mac for which gamma would have had any meaning was the Macintosh II, introduced in 1987, and that's 22 years ago, not 25. This is no big deal, of course, but then he repeats the error:
> Macintosh, in 1984, introduced us to desktop publishing and to displays with shades of grays.
Nope.
Again, no big deal, but seeing that he got the unimportant facts wrong, gives me rather less confidence is his important facts. Caveat lector.
I'm trying it out myself right now. Seems very different, not sure which gamma I like more.
With a gamma of 1.8 I found that on other machines using 2.2, light colours I chose tended to look white and dark colours looked black.
I would say that this will, for the most part, benefit web developers as it will put everyone on the same page.
I'd prefer the base2 display, as I think it's confusing for example when exchanging USB keys with Windows machines. Furthermore OS X now is inconsistent with file size display, because not all OS X programs use base10 at the moment (for instance QuicktimeX).
The Mac 1.8 gamma was a better match for print output but it's increasing irrelevance makes it only natural to increase the gamma for better video/image viewing.
Gamma explained: http://www.thehelpful.com/gammaexplained.html
γ is mainly a way to align the metric in our color space with human perception: humans adapt to varying light levels, even in small areas of the visual field, and our judgment of color differences is relative (i.e. relative to magnitude, logarithmic) rather than absolute (linear).
Any operation that requires interpolating between arbitrary colors (e.g. image rotation, scaling, or compositing with transparency) will have errors introduced by any γ ≠ 1.0, so careful image processing applications should convert to γ = 1.0, perform whatever operation, and convert back, but in practice none of them do, because with sufficient pixels, especially if they're mostly opaque, users don’t know they should care.
But storing colors in 8-bit color with γ = 1.0 would be a disaster, because we’d be devoting half of our storage space to the very bright colors, while leaving the dark colors only a few levels of distinction: the darks would end up extremely noisy.
Incidentally, this last is the reason that digital cameras, even though they collect 10 or 12 bits per channel of data, end up with noise in the blacks: cameras gather photons and store them linearly, meaning that the light parts of the image are silky smooth because we can make many fine color distinctions, but not the darks. Hence the general advice to “expose right.”
Soon enough, we’ll just be storing and manipulating images in γ = 1.0 floating point, and thereby get the best of both worlds: operations are technically linear, but the encoding space is assigned logarithmically.
There are plenty of sites where you can learn more about camera noise.
This is an incredibly confusing subject, thanks to the overlap of gamma as an encoding technique with all the other issues around color management. Poynton's Gamma FAQ is one of my favorite resources ( http://www.poynton.com/GammaFAQ.html ), but even after five years working on image processing software I still have to make an effort to wrap my head around it all.
Edit: Here is a paragraph that, at least, supports where I got this memory from:
Taken from http://www.bberger.net/rwb/gamma.html
"Some display systems such as NeXT's and SGI's contain hardware lookup tables that correct for monitor gamma. On these systems the frame buffer values provided by the application are corrected for the gamma of the CRT by a lookup table in the display controller, producing a display system gamma of 1.0 which linearly maps frame buffer values into intensity."
Maybe something like this:
<link rel="icc-profile" href="profile.icc" type="application/x-icc-profile" />
Which would allow color-proofed output on web. SVG afaik already supports ICC-profiles, maybe HTML could take some hints from there.edit: Oh, apparently there is some work done towards this in CSS3, but I'm not sure of it's status
Note that Firefox does (or can) actually do proper color management of CSS/HTML colors, unlike any other browser.