On Mon, May 2, 2016 at 2:59 PM, Dean Jackson <d...@apple.com> wrote: > > On 3 May 2016, at 7:04 AM, Rik Cabanier <caban...@gmail.com> wrote: > > > > On Mon, May 2, 2016 at 1:58 PM, Simon Fraser <simon.fra...@apple.com> > wrote: > >> On May 2, 2016, at 1:45 PM, Rik Cabanier <caban...@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. > 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 >> 2: >> https://lists.w3.org/Archives/Public/public-whatwg-archive/2016Apr/0036.html >> >> >> Simon >> >> >> > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev