W3C home > Mailing lists > Public > www-style@w3.org > December 2013

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

From: Rik Cabanier <cabanier@gmail.com>
Date: Fri, 6 Dec 2013 22:48:11 -0800
Message-ID: <CAGN7qDAVvHD2FE=84C0iDg57C16BHU3oOj5jREL7dOtoOVyGwg@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Dean Jackson <dino@apple.com>, Chris Lilley <chris@w3.org>, www-style list <www-style@w3.org>
On Fri, Dec 6, 2013 at 10:22 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Sat, Dec 7, 2013 at 4:39 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> > On Fri, Dec 6, 2013 at 9:07 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> 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.
> >>
> >> > 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?
> >>
> >> 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.
> >
> >
> > So, should it go directly to the monitor profile, or use sRGB as an
> > in-between?
> > It makes a big difference.
>
> Sorry, my answer had a parallel structure to your question, so I
> assumed it was clear.
>
> The colors should be sRGB internally, until the last moment when
> they're sent to the display.
>
> Trying to store colors in a monitor profile before that is just
> terrible, as it means you have to do tricky things when a window moves
> between monitors (or crosses them!).
>
> It also means that things that can examine the colors, like a <canvas>
> with an image painted into it, see a weird result, which is also a
> pretty major entropy link for fingerprinting purposes.
>

Great! That is the right approach.

For reference, Adobe's applications *roughly* do the following for a color
managed workflow:
1. colors can come in with a profile. If a color has no profile, it is
tagged with the device colorspace
2. colors are then mapped to the device colorspace. If the profiles match,
this is a no-op.
3. compositing/blending happens in the device colorspace. The end result is
a bitmap with the device profile.
4. For display, this bitmap is then mapped to the monitor colorspace and
displayed.


>
> >> > Can you specify the rendering intent anywhere?
> >>
> >> I don't think there's a need to?
> >
> > Maybe not, but you need to define it somewhere if there's mapping between
> > colorspaces. Perceptual is probably a reasonable default.
>
> Ah, yeah, definitely.
>
> ~TJ
>
Received on Saturday, 7 December 2013 06:48:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:17 UTC