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

On Sat, Dec 7, 2013 at 12:03 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> On Sat, Dec 7, 2013 at 6:47 AM, Zack Weinberg <zackw@panix.com> wrote:
>> 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.
>> >
>> > The colors should be sRGB internally, until the last moment when
>> > they're sent to the display.
>>
>> 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.
>
> If you want to display a web page in a higher gamut, the right way to do so
> is to change the device profile from sRGB to one that has the higher gamut.
> If you then display this on an sRGB device, the colors will become dull
> again but since the mapping is perceptual, the general impression of the
> page colors will stay the same.

I don't understand what you mean by 'device profile' if it's not the
same thing as 'display profile'.  Regardless, if images always get
mapped from their own profile to sRGB as the first step in the
pipeline, changing anything downstream of that logically cannot
recover any wider-gamut information; it's already been thrown away.
So I don't see how this could possibly help.

> [Mapping directly from image to display space] is one way of doing it.
> However, then you as an author would not be able to tell what the image
> is going to look like. It would look dull on an sRGB device but bright on a
> high quality device or a 5 color printer.

This assertion also doesn't make any sense to me.  Perceptual mapping
directly from image to display space should not be able to produce a
*worse* result than a sequence of N>=2 perceptual mappings, some of
which may discard information due to limited gamut and/or bits per
component available.

>> (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...)
>
> I don't think you want to do that. Canvas pixels should be in the device
> color space so there's no mapping on reading or writing.

This won't fly because of what Tab said earlier:

>> > 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 [leak] for fingerprinting purposes.

You may be unfamiliar with the constellation of issues surrounding
device fingerprinting, so to put it as bluntly as possible, it is a
*security flaw* to reveal the device color space to page JS.

zw

Received on Saturday, 7 December 2013 17:23:50 UTC