OK
And you write:
> So someone correct me and tell me I'm wrong.
My pleasure. You are all wrong. People who are easily bored may want to
skip the rest of this message, which is just a long and detailed way of
saying "you are wrong".
> Let's look at a recent spec from the W3C:
>
> > All RGB colors are specified in the sRGB color
> > space (see [SRGB]).
Yes. That is correct. Remember that the HTML 3.2 spec,created when W3C
was just starting out, was a retrospective summing up of industry
practice circa 1996. So, it included color specifications given as a
24bit hex triplet in RGB. Nowhere in the original vendor 'documentation'
(I use the term loosely) did it say what these colors *meant*. So they
looked all different on different platforms. This caused the industry in
general and web designers in particular a lot of grief, wasted time and
effort.
So, CSS1 picked a single specification for RGB and used that in the
specification of color for rendering HTML. This meant that it was
possible to relate the specified value to an objective measurement (an
International Standarrd for color measure ment has existed since 1931
and is used throughout all industries in the world that measure color,
like the paint, dyeing, textile, television, print, etc industries.).
Which meant that it was possible to rate browsers etc for how well they
reproduced that color specification.
This color specification was later adopted by HTML 4.0 and also by CSS2.
> > User agents may vary in the
> > fidelity with which they represent these colors,
Damn right they do, especially of course the ones written before we
defined what the color meant ;-)
> > using sRGB provides an unambiguous and
> > objectively measurable definition of what the color
> > should be, which can be related to international
> > standards (see [COLORIMETRY]).
Right. It also happens to be expressed in a way (ICC profiles) which the
entire color management industry has standardised on over the last
couple of years.
> > Conforming user agents may limit their
> > color-displaying efforts to performing a
> > gamma-correction on them.
This is what is called realism. If you set the bar too low, like for
example "here is what the color means but display it anyway you please"
then there is no point. If you set the bar too high, for example
"conforming user agents are required to use a colorimetrically
stabilised monitor which has been calibrated in the last 24 hours and
is in a room with controlled artificial lighting and neutral grey walls"
then also, clearly there is no point because that is not going to
happen.
So, it turns out that gamma correction is the single largest source of
variation and fits the 80:20 rule - 20% of the effort gets you 80% of
the way there. And gamma correction is trivial to implement in software,
you just fill a 256 element lookup table and then push all your R G and
B values through that. So, that is what we require in a conforming CSS
implementation and that is what the various W3C members in the HTML and
CSS working groups agreed should be in the spec as the minimal
conformance requirement.
> > sRGB specifies a
> > display gamma of 2.2 under specified viewing
> > conditions.
Right. 2.2 happens to be the average gamma of a CRT-based monitor,
according to the latest research from Sony etc and also according to the
IEC technical committe looking into color measurement standards for
digital multimedia. And CRT-based monitors are still the most common
display device on the web by far, with LCD displays coming a very
distant second. Plus, the transfer curve of LCD displays is not
adequately characterised by a single gamma number wheras the transfer
curve of CRT-based monitors is.
Also, various tests have been done and reported in the academic press
over the years regarding the number of bits required to adequately
represent color without banding, using various color spaces including
LAB, LUV, XYZ, HLS, YIQ, RGB, etc. And it turns out that the best. most
compact representation is RGB with a gamma of 2.2 which requires between
8 and 9 bits per component; 3*8 is 24 and HTML and CSS use 24bit RGB
with a gamma of 2.2 which is kinda handy since the alternatives all
require more bits.
The phosphor set used by sRGB comes from an international standard for
broadcast television; its the same phosphor set that SMPTE broadcast
monitors use and is supposed to represent an average for CRT phosphors.
The viewing conditions in sRGB come from research into typical lighting
conditions in offices, shops, houses; medium lighting. Not real dark
which gives a big contrast enhancement and not real light which shrinks
the gamut down because of reflected ambient light.
Now in theory we could have picked any handy color space and used that
to define what colors in HTML and CSS meant. After all, given a
definition of what the colors mean, plus a definition of how the display
system behaves, plus a color management system (CMS), the colors can be
displayed correctly.
But many systems do not have an adequate characterisation of the display
system and do not ship with a color management system. Apple Macs have
shipped with one for *years*, and this is why Macs are used all over the
industry wherever precise color measurement is required. Try to buy a
spectrophotometer to measure calibration strips at the edge of printed
press output, or a colorimeter to measure the color of the screen, and
you will finsd your choices very limited or non-existent unless you buy
for the mac platform. Also, recent systems from Silicon Graphics ship
with a CMS as standard, and it is possible to get one for Suns (made by
Kodak) although these are rare. On windows - well, windows 98 has the
beginnings of a workable color management system. Windows95, WinNT -
nope.
So given that many systems have no CMS. what is to be done? Pick a
specification for color which, while fitting into 8 bits/component, also
has a reasonable fallback when displayed "as is", fired direct at the
screen without further processing. That is what sRGB does - if you just
throw it at the screen, it looks OK. Not precisely correct, but okay. If
we had picked, say LAB, then *every* system would have displayed it
wrong in all existing browsers. Hardly practicable.
> > User agents should adjust the colors
> > given in CSS such that, in combination with an
> > output device's "natural" display gamma, an
> > effective display gamma of 2.2 is produced. See the
> > section on gamma correction for further details.
Well that part seems clear enough and follows on as a logical
consequence of the previous section. If the colors are specified with a
gamma of 2.2 then clearly you hhave to display them such that the
overall system gamma is 2.2
Like I said the natural gamma of a CRT-based monitor is 2.2. So the only
times that you need to do anything to achieve conformance (ie, broadly
acceptable display) is on platforms which incorporate some sort of look
up table to alter the natural gamma of the display. This means Macs,
SGI workstations, and NeXT machines. Everything else - PCs running
Windows, BeOS, Linux, FreeBSD, whatever; Suns, HPs, DEC Alphas, IBM
RS6000s, Macs running BeOS, Macs running MKLinux, etc - has no such
lookup table and so there is no correction required *for gamma* so they
are minimally compliant already without doing anything.
The major platforms that are not minimally compliant by default - Macs
running MacOS, and SGI workstations - are also the ones that can do
something about it because they have a CMS.
> > Note that only colors specified in CSS are affected;
> > e.g., images are expected to carry their own color
> > information.
Right. Images can carry their own color space information, depending on
the format; and this is basically sayingthat the CSS spec covers CSS and
the image format specs cover images, which is only logical.
> My take on this is the W3C has rolled over for Ms and their use of sRGB.
My take on this is that you need to read up a little before making
foolish assertions in public.
> So
> if you have a Mac/Sun/Linux (I'm guessing
we notice.
> because I can't seem to get an
> answer)
You could try reading more of the spec that you quoted, because that is
one place that has the answer. Or you could try searching on the Web for
the information, which is readlly available.
> you are not going to see the colors or going to see different
> colors in CSS than what some flub on his Packard Bell Win'98 box gets.
Duh. Sun and Linux (I take it you mean PC linux but all the others are
the same anyhow) also use CRTs for the most part, and those CRTs have a
gamma of 2.2 which is set by the laws of physics, which were not
invented by Bill Gates last time I looked.
So, every platform that uses a CRT will be seeing approximately the
right colors, apart from two particular exceptions which are both
already capable of dealing with the differences and displaying just the
same as everything else, in fact they can do a better job because they
can compensate for phosphor differences etc.
> Worse the flub on his Packard Bell will be seeing the correct colors.
Not quite correct. The monitor phosphors will likely be not exactly the
average (there is clearly some spread of values) and the viewing
conditions will not be exactly those specified. But these are second
order effects; the most important effect is the gamma.
> Let's read on:
>
> > Values outside the device gamut should be clipped:
> > the red, green, and blue values must be changed
> > to fall within the range supported by the device.
>
> Yep that is what it seems like to me.
Sigh. So, clipping to the device gamut is an evil microsoft plot, is it?
Tell you what, given the following colors on a 0..255 scale what would
you do to display them?
red: -36
green: 84
blue: 287
I think you might have to change these to fall into the range supported
by the deviced, no? Because that minus 36 is going to be kinda hard to
display otherwise, no?
Turning now to some more reasoned arguments against sRGB, which Tim does
not raise because he doesn't seem to have read around much on the
subject but which some of you may have come across. It may seem as if I
am arguing against mtyself here - well, since Tim didn't do a very good
job attacking sRGB I thought he could use some help ;-)
There has been some adverse commentary amongst the pre-press folks that
sRGB has a limited gamut, in particular that it does not encompas all
the colors that are withing gamut of a SWOP printing press (or indeed a
Euroscale press for the Europeans). In fact this is true of any three
color additive primary system, because its cgamut will always be a
triangle on a chromaticity diagram wheras a printing press has a
smaller, irregularly shaped and partially overlapping gamut. This also
means that these are on-screen colors that cannot be represented on a a
SWOP printer, of course.
Now it turns out that *any* visible color can be represented in *any*
additive color space that has three distinct primaries - provided that
negative values and values greater than 100% are allowed. When converted
to a target gamut, these values will change and if they are withing the
target gamut - well, thet are in-range and will not be clipped.
So in CSS we allow values that are less than 0% and greater than 100%
for that very reason. The CMS can take, say, a pantone color for the
company logo and get the sRGB values for it and if it falls outside the
sRGB gamut then fine, CSS can still represent it. And then (assuming a
CMS is present) if when the color is transformed to the eventual output
device be that a screen or a printer or something more exotic, if it
falls within the device gamut then that color can be reproduced;
otherwise, the color will shift(likely losing saturation) as it is moved
inside gamut.
There has also been some commentary in the press about the use of sRGB
as a color space in Photoshop 5. Now the issue there is that Photoshop
only really handles 8bits/sample images. You can convert to
16bits/sample byut then all the filters dont work and generally you
can't do anything much except play with the curves a little. So
Photoshop has limited resolution. Now some folks have correctly pointed
out that the sRGB gamut does not completely enclose the SWOP gamut
(which is all they are interested in since they are US-based,
print-oriented folks). And that have suggested using extremely wide
phosphors that are spectrally pure and correspond to no known output
device, to get the widest possible gamut. You can do that, but ata price
- the limited resolution available in Photoshop get s stretched out to
cover the wider gamut, so the representable colors are spaced further
apart. And that gets you banding, particularly in critical near-neutral
colors such as natural tones, skin tones, etc.
The problem that many web designers are finding with that mythical beast
the "browser safe color cube" is that there is a lack of near-neutral
tones, so they are having to dither these colors to get the neutrals.
Kinda funny for a color space that is supposed to stop dithering, but
there we are. Clearly, stretching out to a wider gamut would exacerbate
this problem.
Using unrealistic spectrally pure primaries for a color space
definition would clearly not work on the Web, for the same reason and
also because the backwards compatibility would be lost. So, it can be
shown that sRGB is a good chhoice there too. We use a smallish gamut,
sRGB, which happens to map well to real-world dvices so there is a
backwards compatibility story for (broken, IMHO) platforms with no CMS.
But we allow colors outside that gamut to be specified - we get the best
of both worlds.
As I hope I have shown, there was actually quite a lot of thought that
went into the choice of sRGB as the defined colorspace for W3C
specifications with simple, 24bit color representations. The fact that
Microsoft happens to be associated with it is irrelevant except in so
much as they that they (and HP, who are in fact the main company
promoting sRGB) are W3C members. But then so are Apple and SGI.
Look out for better, more compliant CSS in the Mac version of
forthcoming CSS-enabled browsers, using the native CMS buit into the Mac
OS.
-- Chris Lilley, W3C http://www.w3.org/ Graphics and Stylesheets Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)492 387 987 06902 Sophia Antipolis Cedex, France