I was talking with fbeaufort@ about this. Firstly, I couldn't reproduce this significant color difference in my linux station, ss attached. Also, he told that he cannot reproduce this issue with regular video. Only video in pip results in this. So it is CrOS and pip specific. lethalantidote@ do you have any guess to what is happening differently in that case?

Also, note that we do not transfer colorspace information from SkImage? That can be added quickly but I don't it would have platform/pip specific effects.
https://cs.chromium.org/chromium/src/content/renderer/media_capture_from_element/canvas_capture_handler.cc?type=cs&sq=package:chromium&g=0&l=160

Deleted: Screenshot from 2018-12-05 12-37-17.png 87.8 KB

	Screenshot from 2018-12-05 12-37-17.png 87.8 KB View Download

I can't repro on Linux too. We may want to check on Mac and Windows to see if that's Chrome OS only.

+edcourtney@ +oshimo@ FYI and in case of they can think of anything CrOS specific.

On macOS, according to "Digital Color Meter" app with "Display in sRGB" selected:

   canvas color RGB is [159,166,162] 
PiP video color RGB is [160,167,162]

Note that I personally didn't notice that much difference. It may be a result of the RGBA > YUV conversion.

On Window 10, here's what I get:

   canvas color RGB is [159,168,163] 
PiP video color RGB is [159,167,164]

Same as macOS, I personally didn't notice that much difference. It may be a result of the RGBA > YUV conversion.

On Chrome OS, values that actually make a real difference to my eyes are:

   canvas color RGB is [157,166,162] 
PiP video color RGB is [159,169,163]

When running Chrome with --disable-features=UseMonitorColorSpace in Chrome OS, the difference in colors is not noticeable anymore as you can see:

   canvas color RGB is [159,168,163] 
PiP video color RGB is [159,169,163]

A given <canvas> and a <video> fed with a <canvas>.captureStream() produce
the same colors; but a <canvas> and a PiP <video> fed with a
<canvas>.captureStream() do not, so we're probably not sending the PiP
the raster ColorSpace information as we do for the "normal" <video> element.

lethalantidote@, ccameron@ do you know how is this PiP <video> associated
LayerTree(HostImpl) created? I think we need to plug the RasterColorSpace
info there (like we do in 
https://cs.chromium.org/chromium/src/content/renderer/render_widget.cc?type=cs&q=+GetRasterColorSpace%5C(%5C)&sq=package:chromium&g=0&l=1575
)

Argh!

According to https://beaufortfrancois.github.io/sandbox/media/picture-in-picture-timer?canvas-and-video-visible where canvas, video, and pip video are shown to the screen:

- video and pip video are the same color
- only canvas is different 

See screenshot attached.

Deleted: Screenshot 2018-12-06 at 4.26.55 PM.png 85.8 KB

	Screenshot 2018-12-06 at 4.26.55 PM.png 85.8 KB View Download

I will transfer SkImage colorspace to media::VideoFrame as I mentioned in #1 as the first step. Based on the last test, that might explain why <canvas> is different than others. Still, I would expect us to lose a bit of accuracy between <canvas> and <video> because of RGBA->YUV conversion.

WIP at https://chromium-review.googlesource.com/c/chromium/src/+/1372564