Re: [css3-color] ICC implementation

On Jul 11, 2008, at 4:33 PM, Bert Bos wrote:
>
>> And then why is this the job of the W3C to create something to fix
>> someone else's error? How would a content creator identify that an
>> incorrect profile is embedded, and should be ignored? How is that
>> easier than simply removing the hypothetic offending profile?
>
> It shouldn't be the job of W3C, indeed, but sometimes there is no help
> for it. We had the same discussion about the image orientation bits in
> EXIF: honor them or ignore them? There are programs that honor them  
> and
> others that ignore them and the result is that images appear on the  
> Web
> that have a rotation set without the user knowing it.

EXIF color space should absolutely be honored. It's not any different  
than if it were an embedded ICC profile. It should not be up to the  
viewing software (web browser in this instance) to doubt the validity  
of such metadata. If there is something wrong with the metadata, then  
it's the fault of the application/product that created that image file  
in the first place. By trying to fix these kinds of aberrations, there  
is a shift in responsibility. Now that vendor thinks, "well it doesn't  
matter than my rendering to Adobe RGB sucks, because no one honors the  
EXIF tag anyway".

That vendors images should suck on screen. Then people will bitch to  
that vendor, or stop buying their products if the images look bad.  
Then the vendor will fix the product, or go out of business. Image  
quality will improve regardless.


> If that is the same for color profiles, the default has to be to  
> ignore
> the profile, because otherwise people surfing with a new browser would
> see broken pages that used to work in their old browser.

Absolutely not. If the metadata is wrong it is not the job of either  
the web browser or the content creator to cause that metadata to be  
ignored.

The reason why color matching is getting worse on the web is exactly  
because web browsers do not do display compensation. Content creators  
are targeting sRGB, but test it on "average displays" which have no  
correlation to sRGB.

You absolutely will hear a lot of content creators complain when color  
management is turned on by default in web browsers because they have  
been using non-sRGB displays, non-calibrated displays, crappy, cheap  
displays because that's what they feel "most of the world" is using,  
which again do not have good correlation to sRGB.

So when color management is enabled, and suddenly it compels displays  
to better emulate an sRGB display, it will be quite different. Most  
content creators are clueless about their practices and assumption  
that there is an "average" display. There isn't. That used to be the  
case with CRTs. It is not the case with LCDs. Each person is  
experiencing a different internet, in terms of color, than anybody  
else. And that is only going to continue to get worse.

Any suggestion that we ignore metadata, and therefore by definition  
favor RANDOM color appearance for a given image that had clear  
instructions on how it should be displayed, is not the domain of  
either the web browser or the W3C.


> But I guess we'll hear from Apple and Mozilla how many bug reports  
> they
> get about pages being broken by their latest browsers. If there aren't
> many or they only mention very few different broken sites, then maybe
> the default *can* be changed.

It needs to be changed anyway, regardless of the complaints. The ideal  
time to act has already passed. The longer we wait in flipping the  
switch the worse this will get.


>
>
>
>> It doesn't even specify how to display colors correctly that *ARE* in
>> gamut. It is out of scope for the W3C spec to specify how out of
>> gamut colors are mapped. Since there is no basis at all for any of
>> the colors in CSS, since no source color space is defined, it's only
>> by common coincidence that 255,0,0 ends up being red on most
>> displays.
>
> All colors specified in CSS itself are in sRGB.

Wow, OK that's good. There is an explicit reference to sRGB in the CSS  
spec? Is it possible for someone to point this out to me?

If that's the case, you can't possibly have color management for CSS  
and allow by default ignoring of embedded profiles in images (ICC or  
EXIF), or you'll get mismatches between identically specified colors -  
say background in CSS and the same color in a JPEG. They'll have the  
same numeric values, but display differently. Bad.


> That has always been the
> case, since the very first CSS specification. The color profile
> properties that we are removing have nothing to do with that, they  
> only
> affected the color profile of linked images.

Untagged = sRGB. If people don't like that, tag their images with  
something else (embedded an ICC profile). And yes the web browsers  
should honor them always, no ignoring.


> But it's true that the Color module says that UAs "should" (rather
> then "must") honor CSS's color space.

It's in their own interest to do this anyway, whether it's a "should"  
or "must". On mobile devices I'm less concerned about image quality as  
it most of the market. That's not static. They will expect better as  
time goes on.

>> CSS is way behind the curve on this.
>
> As you saw, the CSS WG tried, but had to give up because of lack of
> implementations. So you need to direct your ire to the people who
> decide what gets implemented. (Which isn't the WG, although we
> sometimes wished it were...)

Fair enough.


Chris Murphy

Received on Saturday, 12 July 2008 04:45:29 UTC