> 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: https://kornel.ski/en/color 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
