captureVisibleTab distorts colors on Linux
Reported by
dskl...@gmail.com,
Feb 6 2018
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36 Steps to reproduce the problem: 1. Install my screenshot extension: https://chrome.google.com/webstore/detail/look-at-my-screen/djhnfddpapijahbecdbdokhhlmkjijoo 2. Use it to take a screenshot 3. Compare screenshot to original What is the expected behavior? Screenshot looks the same as original What went wrong? The colors are distorted. Like there is a white film on top of the screen. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 63.0.3239.132 Channel: n/a OS Version: Flash Version: On my Chromebook Pixel, the problem doesn't happen.
,
Feb 6 2018
Let me be more specific. I implemented the extension and therefore know it's not malicious. I'm not a security engineer so I don't know for sure if it's safe. It does store the screenshot on Google Cloud storage with a hard-to-guess URL, and it deletes screenshots after 2 weeks.
,
Feb 6 2018
Sounds related to color correction that was shipped.
,
Feb 6 2018
,
Feb 16 2018
dskloet@ Thanks for the issue. Tested this issue on Windows 10 and Ubuntu 14.04 on the reported version 63.0.3239.132 and the latest Stable 64.0.3282.168 and unable to reproduce the issue by following the steps given above. On adding the extension, capturing a screen shot and comparing to the original, can see no difference. Attached is the screen cast for reference. Request you to please check and confirm if anything is missed from our end in triaging the issue. Also request you to retry the issue by updating Chrome to the latest Stable and on a new profile without any flags/extensions and update the thread with the observations. Thanks..
,
Feb 18 2018
This still repros for me on Chrome 64.0.3282.119 on Ubuntu 14.04 LTS.
,
Feb 18 2018
Also, the page you use in the screen cast is almost entirely black and white so you wouldn't see any color distortion. Try something like https://www.google.com/search?q=colorful&source=lnms&tbm=isch&sa=X&ved=0ahUKEwj07a2Twq_ZAhUN36QKHfo7BdwQ_AUICigB&biw=1855&bih=965
,
Feb 18 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 21 2018
I suspect that this is an interaction between captureVisibleTab and the color profile that is installed on the current monitor. In theory, the results of captureVisibleTab shouldn't be affected by the output monitor color space, but it may be that they are.
,
Feb 21 2018
Is there anything I should do to verify that?
,
May 16 2018
ccameron@ - Gentle ping...!! Could you please respond to comment #10. Thanks...!!
,
May 18 2018
Please attach an image and a test URL, or a video, so we know what to look for. Also print the contents of about:gpu as a PDF and attach it.
,
May 18 2018
I just noticed that the same happens with the internal snipit extension. If I go to google.com and take a screenshot with snipit, I get this: go/captureVisibleTab-bad-colors If I go back and forth between the screenshot and google.com, the colors on the screenshot look noticeably bland. about:gpu PDF attached. Actually, I just tried making a screenshot with GIMP to compare. It looks much better in GIMP, but when I open that screen shot in Chrome, it looks bad as well. And when I open the bad screenshot (made with Chrome) in GIMP, it looks good there. So maybe the problem is not with taking the screenshot but with rendering the PNG in Chrome? I've attached a screenshot made with GIMP of how Chrome renders the screenshot PNG. There you should be able to see the bland colors regardless.
,
May 18 2018
This is a consequence of issue 758057, at some level. When the screenshot is taken, it is taken of content in the monitor's color space. This color space is not sRGB (the "default" color space) when using a calibrated display. Something is consuming this screenshot and is ignoring the color space. - If the tab capture API being used is being given an image, then the bug is that that image has not had the appropriate color profile attached to it. The fix is to attach the appropriate color profile to the image. - If the tab capture API being used is being given raw bytes for the image, then the bug is that those bytes are assumed to be sRGB, but are not. The fix is to convert the image to sRGB. miu@ may know how to route this.
,
May 18 2018
Actually, I now really think the problem is with the rendering and not with the capturing. Because of the following scenario that maybe wasn't entirely clear from my previous comment: 1. Open google.com in Chrome. 2. Capture a screenshot in Chrome. 3. Look at the screenshot in Chrome. Colors look bad. 4. Save the image. 5. Open the image in GIMP. Color look good in GIMP. So if I can open the image in GIMP and the colors look good, then the problem can't have been with the capturing, right?
,
May 18 2018
re c#14: Yes, this is a TODO that's nearing the top of my priority list, and I'll be addressing it soon. Basically, anything that does capture from the compositor (anything using CopyOutputRequests) is ignorant of color space. In the recent re-implementation, the necessary APIs/stubs were put in place to allow for fixing this. I don't know whether this bug is being caused by bug 758057 and bug 810131 , but nobody could say for sure until we make the screen capture implementation color space aware. :) re c#15: My guess is that the colors look correct in GIMP because it is using the same non-sRGB profile that is being [ignorantly] assumed in the screen capture implementation; and so everything just happens to look right just by luck.
,
Sep 25
,
Dec 11
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/046e446b56764939026ad97d198ff63410f629af commit 046e446b56764939026ad97d198ff63410f629af Author: Yuri Wiitala <miu@chromium.org> Date: Tue Dec 11 18:57:51 2018 Implement SkColorSpace struct traits in skia.mojom.ImageInfo. Completes the skia mojom struct traits implementation for ImageInfo by using Skia's built-in SkColorSpace::serialize() functionality. This allows for exact SkColorSpaces to be efficiently transmitted, alongside things like SkBitmaps, through mojo message pipes. Later work to improve color space management in Chromium will depend on this change. (See crbugs for examples.) Bug: 758057, 809385 Change-Id: I1193f81c727d8663370fd6fd802edd9dd397abff Reviewed-on: https://chromium-review.googlesource.com/c/1357633 Reviewed-by: Robert Sesek <rsesek@chromium.org> Reviewed-by: Chris Palmer <palmer@chromium.org> Cr-Commit-Position: refs/heads/master@{#615611} [modify] https://crrev.com/046e446b56764939026ad97d198ff63410f629af/services/viz/public/cpp/compositing/struct_traits_unittest.cc [modify] https://crrev.com/046e446b56764939026ad97d198ff63410f629af/skia/public/interfaces/image_info.mojom [modify] https://crrev.com/046e446b56764939026ad97d198ff63410f629af/skia/public/interfaces/image_info_struct_traits.cc [modify] https://crrev.com/046e446b56764939026ad97d198ff63410f629af/skia/public/interfaces/image_info_struct_traits.h [modify] https://crrev.com/046e446b56764939026ad97d198ff63410f629af/skia/public/interfaces/test/OWNERS [modify] https://crrev.com/046e446b56764939026ad97d198ff63410f629af/skia/public/interfaces/test/struct_traits_unittest.cc
,
Dec 17
commit ed44fc45d0c3b3675efec4c550d28c5de1569c9d Author: Yuri Wiitala <miu@chromium.org> Date: Fri Dec 14 19:14:24 2018 Complete the screen capture color space plumbing.
,
Dec 18
Just tested a recent trunk build (on Linux), at a position after the above commits. I used this test page: https://www.w3schools.com/colors/colors_picker.asp ...with the Chromium "Test Screenshot" sample extension (that calls the captureVisibleTab API): https://developer.chrome.com/extensions/examples/api/tabs/screenshot.zip The extension, by default, provides a JPEG-encoded image. There are small color differences introduced by lossy compression. To ensure a perfect comparison, I modified the example extension to have the browser produce a PNG instead. I right-clicked/Save As... on the snapshot image, then opened in an image editing app to confirm perfect color accuracy. Attachments: 1) The modification to the example extension to produce a PNG file. 2) The actual PNG snapshot I took. "The web" uses the sRGB color space, and we see that the resulting PNG from the captureVisibleTab extension API also uses the sRGB color space: $ identify -verbose ~/Downloads/captureVisibleTab-color_test.png Image: /usr/local/google/home/miu/Downloads/captureVisibleTab-color_test.png Format: PNG (Portable Network Graphics) Mime type: image/png Class: DirectClass Geometry: 2032x974+0+0 Units: Undefined Colorspace: sRGB Type: TrueColor Base type: Undefined Endianess: Undefined Depth: 8-bit Channel depth: red: 8-bit green: 8-bit blue: 8-bit Channel statistics: Pixels: 1979168 Red: min: 0 (0) max: 255 (1) mean: 225.366 (0.883789) standard deviation: 59.5924 (0.233696) kurtosis: 5.00559 skewness: -2.46851 entropy: 0.304026 Green: min: 0 (0) max: 255 (1) mean: 226.732 (0.889144) standard deviation: 56.9303 (0.223256) kurtosis: 6.34765 skewness: -2.6667 entropy: 0.315925 Blue: min: 0 (0) max: 255 (1) mean: 224.475 (0.880292) standard deviation: 60.282 (0.2364) kurtosis: 4.75 skewness: -2.41037 entropy: 0.314781 Image statistics: Overall: min: 0 (0) max: 255 (1) mean: 225.524 (0.884409) standard deviation: 58.9349 (0.231117) kurtosis: 5.32249 skewness: -2.51081 entropy: 0.311577 Rendering intent: Perceptual Gamma: 0.45455 Chromaticity: red primary: (0.64,0.33) green primary: (0.3,0.6) blue primary: (0.15,0.06) white point: (0.3127,0.329) Background color: white Border color: srgb(223,223,223) Matte color: grey74 Transparent color: black Interlace: None Intensity: Undefined Compose: Over Page geometry: 2032x974+0+0 Dispose: Undefined Iterations: 0 Compression: Zip Orientation: Undefined Properties: date:create: 2018-12-17T16:05:28-08:00 date:modify: 2018-12-17T16:02:26-08:00 png:cHRM: chunk was found (see Chromaticity, above) png:gAMA: gamma=0.45455 (See Gamma, above) png:IHDR.bit-depth-orig: 8 png:IHDR.bit_depth: 8 png:IHDR.color-type-orig: 2 png:IHDR.color_type: 2 (Truecolor) png:IHDR.interlace_method: 0 (Not interlaced) png:IHDR.width,height: 2032, 974 png:sRGB: intent=0 (Perceptual Intent) signature: 1479941ffca4463c4d582f01751ff8bac0b378b0c3e587bd4e30aade1623b186 Artifacts: filename: /usr/local/google/home/miu/Downloads/captureVisibleTab-color_test.png verbose: true Tainted: False Filesize: 246069B Number pixels: 1.97917M Pixels per second: 49.4792MB User time: 0.040u Elapsed time: 0:01.039 Version: ImageMagick 6.9.10-14 Q16 x86_64 20181023 https://imagemagick.org
,
Dec 18
Which release of Chrome should I expect to contain the fix? |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by dskloet@google.com
, Feb 6 2018