[webkit-dev] canvas and sRGB

Dean Jackson dino at apple.com
Mon May 2 15:17:09 PDT 2016


> On 3 May 2016, at 8:10 AM, Rik Cabanier <cabanier at gmail.com> wrote:
> 
> 
> 
> On Mon, May 2, 2016 at 2:59 PM, Dean Jackson <dino at apple.com <mailto:dino at apple.com>> wrote:
> 
>> On 3 May 2016, at 7:04 AM, Rik Cabanier <cabanier at gmail.com <mailto:cabanier at gmail.com>> wrote:
>> 
>> 
>> 
>> On Mon, May 2, 2016 at 1:58 PM, Simon Fraser <simon.fraser at apple.com <mailto:simon.fraser at apple.com>> wrote:
>>> On May 2, 2016, at 1:45 PM, Rik Cabanier <cabanier at gmail.com <mailto:cabanier at gmail.com>> wrote:
>>> 
>>> All,
>>> 
>>> with the release of DCI-P3 screen, WebKit began supporting the display of high gamut images.
>>> Specifically, if you have an image with a DCI-P3 profile, its pixels render untouched on the new displays.
>>> 
>>> However, if you try do do any sort of canvas manipulation, you will see that the colors are being compressed to sRGB and you will lose the depth of the color.
>>> 
>>> Was it an oversight to always create the canvas imagebuffer in sRGB? [1]
>> 
>> No, this was a deliberate choice. We can't change author expectations for what getImageData() return.
>> 
>> Now we see different visual output which is also not what an author expects :-(
> 
> Since there is no way to create a canvas element with pixel data that is interpreted to be in anything other than sRGB, this behaviour seems expected to me. I'm not sure what else could happen? We couldn't magically make all the canvas elements in the page use P3. If we did that, they wouldn't match the CSS content.
> 
> I don't see why that would be. CSS colors and tagged/untagged images would be color corrected while being drawn just like it happens in HTML.
> get/putImageData would of course be uncorrected as it works on raw pixels.

That's the problem. If we did what you suggest a paint with rgba(255, 0, 0, 1) would not be the same as putting [255, 0, 0, 255] into the buffer via ImageData, and no page in the world would expect that. And there would also be no way to paint into the canvas to match colours outside of sRGB.

I think we did the right thing for now. The complete solutions are coming.

Dean


>  
> The fix is coming: a way to tag the colorspace of the canvas element.
> 
> That's great! Do you have an idea how far off that proposal is?
>  
>> Can you elaborate what is unexpected with getImageData? Is it that css "red" no longer returns 100% red pixels?
>>> If this is as-designed, how can we work around this limitation?
>> 
>> With possible future enhancements to the canvas spec that allow authors to request backing store with a different format and/or color profile.
>>> 
>>> PS
>>> I asked the same question on WhatWG. [2]
>>> 
>>> 
>>> 1: https://github.com/WebKit/webkit/blob/112c663463807e8676765cb7a006d415c372f447/Source/WebCore/platform/graphics/ImageBuffer.h#L73 <https://github.com/WebKit/webkit/blob/112c663463807e8676765cb7a006d415c372f447/Source/WebCore/platform/graphics/ImageBuffer.h#L73>
>>> 2: https://lists.w3.org/Archives/Public/public-whatwg-archive/2016Apr/0036.html <https://lists.w3.org/Archives/Public/public-whatwg-archive/2016Apr/0036.html>
>> Simon
>> 
>> 
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20160503/f36931ec/attachment.html>


More information about the webkit-dev mailing list