
Why your Web content will look darker on Snow Leopard - jwilliams
http://blogs.adobe.com/jnack/2009/09/why_your_web_content_will_look_darker.html
======
ggchappell
A relatively minor correction to make:

> ... 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.

------
rudd
Note that you can bring your mac's gamma up to 2.2 right now without
upgrading: Open System Preferences, Go to "Displays", then the "Color" tab,
then click "Calibrate". This will give you the option of setting your gamma to
2.2.

I'm trying it out myself right now. Seems very different, not sure which gamma
I like more.

~~~
jacobolus
On pre-Snow-Leopard systems, all of the UI is going to look dark and
contrasty, contra system and application designers’ intent. If you like it, go
for it, but I think it looks terrible. With Snow Leopard changing the default,
developers will of course design their apps to fit γ = 2.2, and will lighten
everything up, so that it looks right.

------
ianbishop
It seems that Snow Leopard is Apple's attempt at meeting the standards of
everyone else. Gamma has been changed to Windows configuration and hard disk
space to the standards of manufacturers.

I would say that this will, for the most part, benefit web developers as it
will put everyone on the same page.

~~~
Gibbon
The gamma in OS X has not been changed to "Microsoft's Standard" but rather to
the standard used for the majority of the world's images and video. A gamma
correction of 2.2 is necessary for NTSC video and is more or less equivalent
to the gamma of the sRGB color space.

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>

~~~
jacobolus
It is only natural to switch to _γ_ = 2.2, but mainly to agree with the rest
of the world. Neither is particularly “better” for image viewing – the
difference between the two is trivial and irrelevant, except insofar as it
makes images look different on two different machines.

 _γ_ 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.

~~~
thirdaxle
Much of what you have stated here is incorrect. For example, the encoding of a
photo affects only quantization noise, and has nothing to do with the noise in
the dark pixels (due to shot noise).

There are plenty of sites where you can learn more about camera noise.

~~~
petewarden
No, he's spot on about the advantages of 'linear light' processing. It even
makes a big difference to bilinear interpolation when you're doing texture
mapping.

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.

------
pohl
I have a vague memory in a cobwebbed corner of my mind that the old NeXT
system software had a gamma value of 1. I couldn't find a citation for that,
but if I don't have a misfiring neuron this would be the 2nd time that this
software has gone through a change in gamma.

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."

------
zokier
next step would be some kind of color management system for web, which should
afaik get rid of these kind of problems completely.

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

~~~
jacobolus
As soon as browser vendors decide to add this, it will happen: it’s in CSS3,
but the standards process will neither encourage nor prevent browsers from
doing this themselves.

Note that Firefox does (or can) actually do proper color management of
CSS/HTML colors, unlike any other browser.

