Re: [css3-color] ICC implementation

On Jul 11, 2008, at 5:54 AM, Bert Bos wrote:
>
> I'm told that neither Firefox nor Safari support the color profile  
> properties and their implementers can't say when they will.
>
> As far as I know, they have code for handling embedded color  
> profiles, but no code to override those profiles with CSS  
> properties. Maybe, despite what we thought a few years ago, such CSS  
> properties aren't actually needed. We'll see...

The color-profiles property does not need to be implemented, in my  
view. The spec just needs to specify the assumed color space for all  
untagged content is sRGB. This is already the aimpoint for content on  
the web, so it's not changing anything except putting into a spec what  
is already widely in practice.

>
>
>> And then also that there has been no implementation of gamma  
>> correction, and still there is no implementation of gamma (only)  
>> correction, Section 3.1.1 which remains in the spec?
>
> We have to keep backwards compatibility with existing  
> Recommendations. Even though CSS1 dates from a time when the W3C  
> process was less rigorous, it has been published and that implies a  
> promise to keep it stable for as long as possible (unless there are  
> errors, such as internal contradictions, but that is not the case  
> here). There may be implementations that we don't know about, but  
> that rely on the stability of W3C's specifications.

No, it is hideously flawed and never should have been put in the  
specification in the first place. I can easily change the tone  
reproduction curve on a Macintosh to be defined by gamma 2.2, or a  
Windows machine to be defined by gamma 1.8. Oops - now the CSS spec is  
totally invalid on those particular machines if it were implemented.

Many Macintosh based web designers change the TRC for their display to  
be defined by gamma 2.2 for obvious reasons. A tool for doing this is  
included in the system.

Displays also don't all have the exact same tone reproduction. They do  
vary.

The correction needed on a particular machine is not knowable, and not  
definable. What W3C should be defining is what is known and definable,  
and that is the assumed source space for the content. How to preserve  
the resulting color appearance defined by that color space, is an  
implementation issue that involves details like the behavior of the  
display attached to the system (which can be derived through  
measurement or EDID, etc.) things that are out of scope for the CSS  
spec.

Yet the spec, as written makes this about the operating system which  
is simply not appropriate. What happens to your specification if an  
operating system decides to change the system tone reproduction? What  
happens when I connect a different display? What about as we have  
moved to different display technologies, such as CRT to LCD?

The spec, as written, is in direct conflict with any web browser's  
implementation of color management. If I have an image encoding with  
gamma 1.8, and an ICC profile is embedded in the image stating as  
such, section 3.1.1 explicitly demands the wrong compensation for that  
image on *all* platforms.

Anyway, it should be removed from the spec.


>> Gamma correction has been standardized now TWICE even though it has  
>> not been implemented. And color management which is now implemented  
>> (albeit not by default and not exactly as originally proposed for  
>> CSS3) cannot go into the spec? Seems backwards to me.
>> Now, as the spec was written, I have just two (major) problems.
>> 1.  with the rendering-intent property "auto" (default) behavior.  
>> It causes the browser to defer to the intent flag in the embedded  
>> ICC profile. This is unreliable. The spec needs to specify an  
>> intent, that's all. No options. And it needs to specify an intent  
>> anyway because most images do not have embedded profiles, therefore  
>> there is no intent flag.
>> A future spec could allow explicit ways for content creators to  
>> override that, and specify another intent on a per object basis.
>> 2. with the color-profile property value set to anything except  
>> auto. When set to anything other than auto, the web browser is  
>> compelled to ignore all embedded profiles, which is a color  
>> management heresy. This is only bad, there is no good reason for  
>> doing this, and it amounts to a kind of data loss and sabotage of  
>> the original intent of the images with embedded profiles.  So  
>> again, the spec needs to specify just the auto behavior, that's  
>> all. No options.
>
> We'll see, but I think it is likely that we need some way to ignore  
> the embedded profile of images and that probably even has to be the  
> default behavior, because there is probably quite a bit of content  
> currently on the Web that has the wrong color profile.

How are these wrong profiles being embedded into images? By what  
mechanism are there embedded ICC profiles in images, that should not  
be in those images?

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?

>
>> This all seems to be rather straightforward. It doesn't require  
>> content creators to do anything differently than they are now. The  
>> entire burden is on the web browser and that is all but wrapped up  
>> in Firefox and Safari (flip the switches for default).
>> As you point out SVG is color managed, and now so is Flash 10. I  
>> don't see why CSS3 should be relegated to effectively saying that  
>> monitor RGB is acceptable. If cyan is a close enough approximation  
>> to blue, in the view of the W3C, then OK I will relent. Because  
>> that is the difference between quite a large percentage of LCD blue  
>> compared to sRGB blue.
>
> Not sure what you mean by that.
>
> Even in the previous draft, the CSS color module didn't have a  
> rendering intent for the color of text. If some CSS rule specifies a  
> color that only exists on a printer and then you try to view it on a  
> screen, it will be approximated. CSS doesn't specify *how* a UA  
> should remap colors that are out of gamut for a device.

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.


> But if the rule specifies a color that the LCD device *can* render,  
> you should get that color, assuming the device is reasonably  
> calibrated.

Wrong. That does not happen even if the display is calibrated. You  
must have a color management system performing display compensation in  
order to get this. No web browser do this by default. There is no  
compensation at all for tone reproduction or the differences in  
primaries between sRGB and the display.


> (Difficult for LCD, but let's assume ideal circumstances...) I  
> assume mapping from sRGB to the device's profile is nowadays done  
> automatically by the OS or the graphics toolkit, requiring no work  
> from the browser.

Well you assume incorrectly. No web browser does this by default on  
any platform.

That is what is such a big deal about FireFox, even though it's not on  
by default yet, their stated goal is to turn it on by default with  
FireFox 3.1. What is increasingly obvious to people who turn it on is  
how radically different in many cases, the results they get between  
color management on and off.

CSS is way behind the curve on this.


Chris Murphy

Received on Friday, 11 July 2008 17:45:20 UTC