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

[Justin Novosad]

On May 1, 2016 1:08 PM, "Rik Cabanier"  wrote:
>
> Great to hear!
> Are there minutes posted?

As far as I know, the minutes and mail archives are visible to members
only. I'm working to capture what we have so far and to move the discussion
to a broader and more visible forum.
>
>
> On Sunday, May 1, 2016, Justin Novosad  wrote:
>>
>> There is currently an ongoing discussion with the Khronos Web3D group to
develop a proposal that solves these problems in canvas, over the past few
weeks we have converged on a solution that I think is pretty solid. I am in
the process of writing-up the HTML (non-WebGL) part of the proposal and I
intend to post it to the WICG shortly so that we can incubate it further,
with a broader audience.  When that happens, I will update this thread.
>>
>> On Sat, Apr 30, 2016 at 2:07 PM, Rik Cabanier  wrote:
>>>
>>> [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 

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

[Rik Cabanier]

Great to hear!
Are there minutes posted?

On Sunday, May 1, 2016, Justin Novosad  wrote:

> There is currently an ongoing discussion with the Khronos Web3D group to
> develop a proposal that solves these problems in canvas, over the past few
> weeks we have converged on a solution that I think is pretty solid. I am in
> the process of writing-up the HTML (non-WebGL) part of the proposal and I
> intend to post it to the WICG shortly so that we can incubate it further,
> with a broader audience.  When that happens, I will update this thread.
>
> On Sat, Apr 30, 2016 at 2:07 PM, Rik Cabanier  > wrote:
>
>> [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 

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

[Justin Novosad]

There is currently an ongoing discussion with the Khronos Web3D group to
develop a proposal that solves these problems in canvas, over the past few
weeks we have converged on a solution that I think is pretty solid. I am in
the process of writing-up the HTML (non-WebGL) part of the proposal and I
intend to post it to the WICG shortly so that we can incubate it further,
with a broader audience.  When that happens, I will update this thread.

On Sat, Apr 30, 2016 at 2:07 PM, Rik Cabanier  wrote:

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

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

[Rik Cabanier]

On Sat, Apr 30, 2016 at 6:35 PM, Ron Waldon  wrote:

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

That is pretty much the situation in Safari today.
My original points are about some deficiencies in the canvas implementation
for this workflow.


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

I am not convinced that this is a fingerprinting concern, especially if we
just allow generic names for profiles.
Certainly the additions to CSS wrt color and media queries allow you to
infer the used profile


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

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

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

[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

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)

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

[Justin Novosad]

On Thu, May 22, 2014 at 4:09 PM, Rik Cabanier caban...@gmail.com wrote:


 Well, the issue with not having a standardized intermediate colorspace, is
 that output will look different on different devices.


I theory, that should only be the case when drawing raw values through
putImageData. Everything else (fill styles, stroke styles, images) could be
color-managed and mapped from CSS (sRGB) to the canvas's color space when
drawing to a canvas. Right now, this is not the case in Chrome, which is a
bug. IMHO.


 For most cases, people don't really care about that and are happy will
 vibrant colors and deep blacks. Worse, if you limit the gamut to sRGB on
 wide gamut devices, you lose gray values which will result in banding
 (unless you have a high bit monitor) [1]
 However there are use cases where it is certainly important that what you
 see on screen reflects the actual color. I've certainly try to order
 clothes, paint and furniture online where I did care about the exact color.
 There's currently no way to accomplish this.


It may seem that a proper color managed pipeline may solve that problem,
but it will not.  we cannot solve the problem completely through web
standards for many reasons:
* Most people do not have calibrated monitors, or have only coarsely
calibrated monitors.
* A textile or paint sample viewed on screen will have been photographed or
rendered under illumination conditions that are most likely very different
from the lighting where the output device is located, making it almost
impossible to match colors even with perfectly calibrated devices.
* There is inter-human variability in color perception. The primary colors
we use were chosen based on the average human's perception of color. Even
with perfectly matched illumination conditions and calibrated devices, many
humans will perceive noticeable differences because the models used to
represent colors in computers is not a perfect match for each individual.
 In particular tetrachromats and certain types of color blinds have color
responses that poorly match standard primary colors.

The best we can do is minimize differences caused by inter-device
variability. How well we can do that depends on how well the devices are
calibrated.



 Rik: to answer your question about your experiment: there is no issue
 with a put/getImageData round trip. You will get back the same color you
 put in (at least for opaque colors, but that is another story).  The issue
 is with a drawImage/getImageData round trip.  For the same source image,
 getImageData will return different values depending on the display profile
 of the system you are running on.


 I still am not able to reproduce: http://jsfiddle.net/Dghuh/14/
 Is it just when you have a tagged image that is drawn and is then color
 mapped to the device profile?


Yes exactly, you will only see the problem with a tagged image. When
drawing from a canvas to a canvas, there are no color space conversions in
play. Similarly, there are no color space conversion at play in a
getImageData+putImageData round trip.

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

[Rik Cabanier]

Hi justin,

thanks for this explanation!


On Thu, May 22, 2014 at 12:21 PM, Justin Novosad ju...@google.com 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 colors. This makes it
 possible to map colors from a wide gamut camera to a wide gamut display
 with high color fidelity for all the colors that are located in the
 intersection of the color gamuts of both the input and output devices. If
 we were forced to convert the image to an intermediate sRGB representation,
 the colors in the image would be clamped to the sRGB gamut (which is
 narrower than the gamuts of many devices). Currently, most browsers avoid
 doing that for img, and therefore provide (more or less) optimal image
 and video color fidelity for users of wide gamut devices. Also, an
 intermediate representation in 8-bit sRGB means loss of precision due to
 rounding errors, as opposed to the profile connection space which uses
 higher precision registers for intermediate color values to avoid precision
 issues caused by rounding.  To avoid perceptible precision issues in an
 intermediate sRGB representation, we'd have to increase the bit depth and
 therefore use more RAM for storing decoded image data.

 All of this is to say that there are good reasons for the current
 situation where we deal with decoded images that have the output device's
 color profile pre-applied: color fidelity and memory consumption.

 In the case of 2D canvas, the color space for the backing store is
 unspecified, and many implementations have chosen to use the output
 device's color space, which has many advantages:
 * images and videos are already decoded directly into that space
 * no color conversion is necessary when presenting the canvas on screen
 (good for performance)
 * there is no loss of precision due the use of a limited-precision
 intermediate color space.
 * the color gamut is not constrained by an intermediate color space (like
 sRGB).
 And disadvantages:
 * Compositing operations produce incorrect results because most of them
 (including source-over) are affected by the color space.
 * direct pixel manipulation using put/getImageData exposes data in a color
 space that is undefined, making it extremely challenging to perform many
 types of image processing and image generation tasks in a
 device-independent way.
 * The device-dependent behavior of a drawImage/getImageData round trip is
 a known fingerprinting vector.

 Right now, I am hearing a lot of complaints regarding the lack of a
 standardized color space for canvases, and in particular the impact this
 has on applications that try to do cool things with put/getImageData, or
 generate images procedurally.  I want to make sure everyone understands
 there is a trade-off to fixing this, so be careful what you wish for.

 I am especially concerned about the