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

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

From: Zack Weinberg <zackw@panix.com>
Date: Sat, 7 Dec 2013 09:47:33 -0500
Message-ID: <CAKCAbMj2HU6WEyd0t-rp4m5H=6GuUgX4NEr76SiSUbhtUPoMrQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
On Sat, Dec 7, 2013 at 1:22 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Sat, Dec 7, 2013 at 4:39 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>> So, should [a tagged image] 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.

If everything is mapped through sRGB internally, doesn't that mean
wide-gamut images will be compressed to the sRGB space even when the
monitor profile would accommodate them?  That seems unlikely to be
what authors of wide-gamut content would want (consider high-end
photographic galleries, for instance).

It would seem more appropriate to me to store images in the *image*
color space until the last moment and then map them directly to the
display space.

(For <canvas>, at least right now, mapping to sRGB upon pixel readback
does seem like the Right Thing, but down the road we may want a way to
establish a different working space...)

Received on Saturday, 7 December 2013 14:47:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:37 UTC