Re: [css-color] Safari 7 is color-managing CSS colors?

On Sat, Dec 7, 2013 at 9:53 PM, Chris Lilley <chris@w3.org> wrote:

> Hello Tab,
>
> Saturday, December 7, 2013, 6:07:50 AM, you wrote:
>
> > On Sat, Dec 7, 2013 at 3:31 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> >> Can you tell me where the color workflow is defined?
> >> For instance, it is defined that all CSS colors should be tagged with an
> >> sRGB profile. Image can optionally have a tag as well.
>
> > Not quite.  It's currently allowed for CSS colors to be unmanaged, if
> > untagged images are also unmanaged, and so they just get blasted into
> > the monitor's gamut without adjustment.  It's just tagged images that
> > have to be managed right now.
>
> To clarify: its defined (since CSS1) that the colours are in the sRGB
> colourspace. In CSS1, the minimum level of management required was not
> screwing up the gamma (this was when Macs and SGIs used a non-2.4
> gamma). It turned out that even that was not reliable. So yes, the
> source data is defined to be in sRGB and the minimal conformance level
> is treating that as device RGB and throwing it at the screen.
>
> The advent of wide gamut monitors (plus the generally better color
> management capabilities of platforms and the increasing awareness of
> colour quality (remember that when CSS1 came out, most people still
> used indexed, 256-colour screens)) has meant that throwing data at the
> screen results in an eye searing experience.
>
> So if the monitor has a gamut less than or similar to sRGB, treating
> sRGB as device RGB is not tooo bad. If the gamut is wider, treating
> sRGB as sRGB is a much better idea (and gives more consistency). Once
> you can do that, its a small step to allowing, say, images in AdobeRGB
> to be actually displayed correctly and then, allowing authors to
> specify colours in other colour spaces, like AdobeRGB.
>
> >> How are those colors actually mapped when going to screen?
> >> I believe that in the case of Core Graphics, everything is drawn into a
> sRGB
> >> device which is then mapped to the output device.
> >> So, a tagged imaged would go: Image profile -> sRGB -> monitor profile.
> >> Assuming that the output device is properly calibrated, you would get
> the
> >> same colors everywhere.
> >>
> >> Is this how it's supposed to work? Or is a tagged image supposed to go
> to
> >> the monitor profile directly?
>
> Currently, that is how its supposed to work (modulo some hand-waving
> about supporting sRGB colours with components < 0.0 or greater than
> 1.0, which is underspecified  in terms of transfer function and not
> actually compatible with modern CMS). Clearly is the source and
> destination spaces are large compared to sRGB this results in gamut
> clipping which need not have been done.
>
> That is why SVG2 introduces the idea of other intermediate spaces for
> computation (including LAB, so there will be no clipping except what
> is actually needed for the destination gamut).


I'm unsure if we should promote Lab as a working colorspace. I would be
more in favor of using RGB profiles since that would be easier to hook up
in the browsers.
Also, apart from Photoshop, are there any graphical tools that can work in
Lab?


> > That's how it's supposed to work, yes.  Anything else is really bad,
> > because it means you're leaking color profiles all over intermediate
> > stages.
>
> > Colors should be treated like Unicode is.  Good hygiene means
> > converting bytes to codepoints as soon as they enter the system, and
> > not turning them back into bytes until they leave.  Same with colors -
> > bytes should be turned into a managed colorspace as soon as they
> > enter, and not turned into monitor profile until they leave the
> > system.
>
> >> Can you specify the rendering intent anywhere?
>
> > I don't think there's a need to?
>
> There is a need to specify the rendering intent, yes. Either
> explicitly in the style sheet or implicitly in the specification, as a
> default.
>
> Its currently unspecified and needs to be. For testability and
> consistency, i would say the default rendering intent should be
> relative colorimetric. There should also be an option to specify a
> different intent.


Yeah, you should be able to override it.
According to our documentation [1], Japan uses perceptual while Europe and
the US opt for relative colorimetric.

1: http://adobe.ly/1fdy9U5