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
>