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

On Sat, Dec 7, 2013 at 9:23 AM, Zack Weinberg <zackw@panix.com> wrote:

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


I'm so used to the Adobe color workflow, that I'm confusing the issue :-)
I've attached a screenshot of our color dialog.

The "device profile" (or working space in the dialog) is the profile of the
device that you are emulating.
For Adobe publishing apps, it is usually the profile of your offset press,
but for a web browser, it's always sRGB (I *think*)

This "device profile" is used for all compositing. The end result is then
mapped to your display device/"output profile" so what you see on the
screen matches what you would get on printed output.
You can do the same with RGB. For instance, your device profile could be an
iPad profile so the output of your monitor would match what you'd get on an
iPad.


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

That is correct. Note that I don't say this is how it *should* be.
Right now it's unclear what is supposed to happen and I'm just asking what
is expected.

I'm pretty sure Safari does render everything in sRGB and then maps it to
the output profile.


> So I don't see how this could possibly help.
>

If someone designs a website for a paint store, he would want the same
color on your device as he got on his device. Mapping it to your gamut
would result in different hues.


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

You say "worse"; I say "consistent" :-)


>
> >> (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:
>

Device colorspace = always sRGB today until we allow other profiles.


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

Yes, this is a good reason *NOT* to draw in the output colorspace. So,
mapping an image to the "best" colors would allow fingerprinting.