> On 30 Apr 2016, at 21:19, Rik Cabanier <caban...@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:


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.

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

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

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.

Kind regards, Kornel

Reply via email to