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

[Kornel]

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

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.

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

-- 
Kind regards, Kornel

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

[Rik Cabanier]

[Sorry to revive this old thread]
All,

with the advent of DCI-P3 compliant monitors and Apple's Safari doing color
managing to the device, we're seeing some issues in this area.

- Currently, WebKit sets the profile of the canvas backing store to sRGB
regardless of the output device. Because of this, high gamut images are
always clipped to sRGB. [1]
It would be ideal if we can specify that the canvas backing store is in the
device profile.
Alternatively, we could add an API to attach a color profile to the canvas.
- The spec currently states that toDataURL should not include a profile.
However, if the backing store is in device pixels, the generated image
should include the correct profile. Otherwise if you draw the bitmap in a
compliant browser (ie Safari), the colors will look too saturated.

If we agree that canvas is in the device space, I'd like to see the spec
[2] clarified to state that compositing on the canvas should match
compositing on the HTML surface.
Specifically:

The canvas
 APIs
must perform colour correction at only two points: when rendering images
with their own gamma correction and colour space information onto a bitmap,
to convert the image to the colour space used by the bitmaps (e.g. using
the 2D Context's drawImage()

method
with an HTMLOrSVGImageElement

object),
and when rendering the actual canvas bitmap to the output device.

Becomes:

The canvas
 APIs
must perform colour correction at only one point: when rendering content
with its own gamma correction and colour space information onto a bitmap to
the colour space used by the bitmaps (e.g. using the 2D Context's
drawImage()

method
with an HTMLOrSVGImageElement

 object).


ToDataURL and ToBlob [3] should also be enhanced so they include the device
profile if it is different from sRGB.

It would also be great if the browser could let us know what profile (if
any) it was using.

1:
https://github.com/WebKit/webkit/blob/112c663463807e8676765cb7a006d415c372f447/Source/WebCore/platform/graphics/ImageBuffer.h#L73
2:
https://html.spec.whatwg.org/multipage/scripting.html#colour-spaces-and-colour-correction
3:
https://html.spec.whatwg.org/multipage/scripting.html#dom-canvas-todataurl



On Thu, May 22, 2014 at 12:21 PM, Justin Novosad  wrote:

> tl;dr: The color space of canvas backing stores is undefined, which causes
> problems for many web devs, but also has non-negligible advantages. So be
> careful what you wish for.
>
> I saw some confusion and questions needing answers in the "WebGL and
> ImageBitmaps" thread regarding color management. I will attempt to clarify
> to the best of my abilities. Though I am knowledgeable on the subject, I am
> not an absolute authority, so others are welcome to correct me if I am
> wrong about anything.
>
> Color management... To make a long story short, there are two types of
> color profiles : input profiles and output profiles for characterizing
> input devices (cameras, scanners) and output devices (displays, printers)
> respectively.
> Image files will usually encode their color information in a standard
> color space or in a an input device dependent space. If colors are encoded
> in a color space that is different from the format's default, then a color
> profile or a color space identifier must be encoded into the image
> resource's metadata.
>
> To present color-managed image content on screen, the image needs to be
> converted from whatever color space the image was encoded into into a
> standard "connection space" using the color profile or color space metadata
> from the image resource. Then the colors need to be converted from the
> profile connection space to the output space, which is provided by the
> OS/display driver. Depending on the OS and hardware configuration, the
> output space may be a standard color space (like sRGB), or a
> device-specific color profile.
>
> Currently, many color-managed software applications rely on the codec to
> take care of the entire color-management process for image and video
> content, meaning that the decoded image data is in output-referred color
> space (i.e. the display's profile was applied).  There are practical
> reasons for this, the most important ones being color fidelity and memory
> consumption.  Let me explain. The profile connection space is typically CIE
> XYZ or CIE L*a*b. I wont get into the technical details of how these work
> except to say that they are device independent and allow for an accurate
> representation of the whole spectrum of human-visible 

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

[Rik Cabanier]

On Sat, Apr 30, 2016 at 12:38 PM, Kornel  wrote:

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


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


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

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

[Rik Cabanier]

On Sat, Apr 30, 2016 at 4:27 PM, Rik Cabanier  wrote:

>
>
> On Sat, Apr 30, 2016 at 3:25 PM, Kornel  wrote:
>
>>
>> On 30 Apr 2016, at 21:19, Rik Cabanier  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 

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

[Ron Waldon]

What if we could just declare the colour-space that content uses, and allow
the browser to make a best-effort translation if the current display uses a
different colour-space?

This way, we don't need to expose colour profiles or other fingerprinting
details to JavaScript code. That code can just declare that it uses Adobe
sRGB (which might be the default if not specified?), and the browser can
apply a transform as needed depending on the hardware.

The declaration could be a MIME-type parameter, for visual content
delivered via HTTP, or there could be a Canvas attribute or constructor
option. /shrug

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

[Kornel]

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