Re: [whatwg] Canvas and color colorspaces (was: WebGL and ImageBitmaps)

On Sat, Apr 30, 2016 at 4:27 PM, Rik Cabanier <cabanier@gmail.com> wrote:

>
>
> On Sat, Apr 30, 2016 at 3:25 PM, Kornel <kornel@geekhood.net> wrote:
>
>>
>> On 30 Apr 2016, at 21:19, Rik Cabanier <cabanier@gmail.com> wrote:
>>
>>>
>>> > It would be ideal if we can specify that the canvas backing store is
>>> in the device profile.
>>>
>>> How would the website know what profile this is? If it's just a boolean
>>> setting, then I don't see how it would make it possible to use such canvas
>>> correctly, e.g. convert a XYZ color to canvas' color space.
>>>
>>
>> This is how content is drawn today. A website doesn't know what profile a
>> browser is using.
>> Introducing this would make canvas drawing match HTML which is what the
>> spec is intending and users want.
>>
>>
>> I think HTML colors being interpreted as colors in device color space is
>> a bug. It makes it hard/impossible to get consistent colors across HTML,
>> GIF and JPEG/PNG on wide-gamut displays:
>> https://kornel.ski/en/color
>>
>
> I don't see why that would be the case. The device color space doesn't
> imply that it is uncalibrated.
>
>
>> IMHO HTML/CSS and unlabelled image colors should be interpreted as sRGB
>> colors. That makes all content displayed consistently and without
>> over-saturation on wide gamut displays. That's what Safari does, and I
>> really like that behavior.
>>
>
> That is incorrect. With the advent of the DCI-P3 devices (iMac retina and
> iPad Pro), Safari switched to rendering using the monitor profile.
> So, if you place a DCI-P3 image on a web page, it will display with all
> its colors on the new devices; while it will look more washed out on the
> other devices.
>

Sorry, after rereading my message it looks like we're talking about
different things.
Yes, Safari's behavior is great. We should keep that and hopefully push all
browser towards this model.
We DO want compositing in the the output device color profile though so we
can use all available colors.


> Is device profile exposed somewhere in the platform yet? If not, I think
>>> it'd be better to leave it hidden to avoid adding more fingerprinting
>>> vectors.
>>>
>>
>> I'm unsure how this would contribute to fingerprinting.
>> If browser start following the spec wrt icc profile conversion, you could
>> infer the profile by drawing an image and looking at the pixels.
>>
>>
>> User may have a custom, personal monitor calibration, e.g. in OS X system
>> Preferences -> Color -> Calibrate does this. This is likely to create a
>> very unique profile that can be used as a supercookie that uniquely
>> identifies the user, even across different browsers and private mode.
>>
>> Implementations must avoid exposing pixel data that has been converted to
>> display color space at any time, because it is possible to recreate the
>> profile by observing posterization.
>>
>> Therefore to avoid creation of a supercookie, by default canvas backing
>> store must be in sRGB, unlabelled images rendered to canvas must be assumed
>> to be in sRGB too, and toDataURL() has to export it in sRGB.
>>
>
> No. Canvas is defined to render like HTML so this needs to stay consistent.
> Also, we should hardcode such a limitation in the platform; if I have a
> nice monitor, I'd like to my web browser to use it.
>

That is: we should NOT hardcode such a limitation :-)

> Setting the canvas to a website-supplied profile seems OK to me. It'd mean
>>> the website already knows how to convert colors to the given colorspace,
>>> and the same profile could be passed back by toDataURL().
>>>
>>
>> That would indeed be the ideal solution. My worry is that it introduces a
>> lot of changes in the browser (ie see Justin's email that started this
>> thread) and I'd like to see a solution sooner than later.
>>
>>
>> I'd rather not see any half-measures for mixed device RGB and sRGB.
>>
>
> This is not a half-measure. This is getting everyone to agree on the
> basics so authors can design websites that look consistent and that can
> take advantage of high gamut display.
> More advanced features can be added later (and this is something the css
> wg is working on)
>
>
>> Color handling in Chrome and Firefox is currently problematic on
>> wide-gamut displays, not just in canvas, but everywhere. It's just not
>> possible to have a photo that matches CSS backround and doesn't have orange
>> faces on wide gamut displays. It's very frustrating from author's
>> perspective (I'm a developer of web-oriented image optimizers for Mac, so
>> I'm hearing from many new iMac users annoyed with Chrome).
>>
>> If you must implement a quick fix, then perhaps render everything in the
>> browser in sRGB color space internally, and then if needed convert to
>> device RGB as the very last step (in GPU/by the OS)? It would make all
>> current web content render consistently as expected. Support for the niche
>> use case of true display of full gamut of wider-than-sRGB profiles can be
>> added less urgently.
>>
>
> I agree that having output look consistent is a very good goal (see my
> proposal here:
> https://lists.w3.org/Archives/Public/www-style/2016Mar/0336.html)
> However, this request is about being able to detect and use high-gamut
> content.
>
> As Dean Jackson from Apple stated:
>
> …  in the majority of cases: developers just want to know if the hardware
> and software stack on the user's computer supports "better"
> colours than today's typical hardware.
>
> We are definitely in that camp.
>
>

Received on Saturday, 30 April 2016 23:58:37 UTC