Re: [css3-color] ICC implementation

Chris Murphy wrote:
> 
> Hi Bert,
> 
> Thanks for the informative response. Please indulge me further.
> 
> Where I lose you entirely, is that ICC color profile and intent support 
> was in a May 14 2003 Candidate Recommendation. That's five years ago 
> that it had made it at least that far. So how did it make it that far 
> given it had not been implemented?

A Candidate Recommendation isn't a Recommendation. It represents a call 
for implementations. W3C issues a CR rather than a REC when a 
specification is believed to be ready for a standard, but there are no 
(or insufficient) implementations yet.

This particular call turned out to be a very long one, five years, but 
that was apparently the time needed to get transparency and hsl() 
implemented. If there is still not sufficient support for some feature 
after such a long time, we have no other choice but to remove it before 
making a standard.

It is still possible that there are implementations but that we don't 
know about them. That's also why we announce our intention to drop a 
proposed feature some time before finishing the standard: hopefully 
somebody notices and tells us of the product that we overlooked.

> 
> And now that much of what is desperately needed has been implemented, 
> albeit not enabled yet by default, in two major web browsers, color 
> management is being pulled from the spec?

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

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

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

But if we think there is a new possibility to add the color profile 
properties to CSS, there will be a new draft and a new round of reviews.

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

But if the rule specifies a color that the LCD device *can* render, you 
should get that color, assuming the device is reasonably calibrated. 
(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.

> 
> Also IE Mac did have an option to use ColorSync, it wasn't on by 
> default. If checked it assumed untagged images were sRGB. I don't recall 
> if other content was color managed.



Bert

PS. My example of rgb(0, 0, -0.1) was incorrect, of course. The syntax 
requires either integers or percentages, so that should have been 
something like rgb(0, 0, -10.0%). Sorry about that.

-- 
   Bert Bos                                ( W 3 C ) http://www.w3.org/
   http://www.w3.org/people/bos                               W3C/ERCIM
   bert@w3.org                             2004 Rt des Lucioles / BP 93
   +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Friday, 11 July 2008 09:55:52 UTC