New issue
Advanced search Search tips

Issue 809385 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 18
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

Blocked on:
issue 758057
issue 810131



Sign in to add a comment

captureVisibleTab distorts colors on Linux

Reported by dskl...@gmail.com, Feb 6 2018

Issue description

UserAgent: 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.
 

Comment 1 by dskloet@google.com, Feb 6 2018

I filed that bug with my personal account.
Commenting with my google.com account to confirm the extension is safe.

Comment 2 by dskloet@google.com, 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.
Cc: ccameron@chromium.org
Components: Platform>Extensions>API
Sounds related to color correction that was shipped.
Labels: Needs-Triage-M63
Cc: susan.boorgula@chromium.org
Labels: Triaged-ET Needs-Feedback
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..


809385.ogv
1.6 MB View Download

Comment 6 by dskl...@gmail.com, Feb 18 2018

This still repros for me on Chrome 64.0.3282.119 on Ubuntu 14.04 LTS.

Comment 7 by dskl...@gmail.com, 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
Project Member

Comment 8 by sheriffbot@chromium.org, Feb 18 2018

Labels: -Needs-Feedback
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
Cc: m...@chromium.org
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.

Comment 10 by dskloet@google.com, Feb 21 2018

Is there anything I should do to verify that?
ccameron@ - Gentle ping...!!

Could you please respond to comment #10.

Thanks...!!
Labels: Needs-Feedback
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.

Comment 13 by dskloet@google.com, 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.
gpu.pdf
142 KB Download
chrome-bad-colors.png
42.8 KB View Download
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.


Comment 15 by dskloet@google.com, 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?

Comment 16 by m...@chromium.org, 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.

Comment 17 by m...@chromium.org, May 18 2018

Blockedon: 810131 758057
FWIW, I'll block this bug on the others I mentioned, and if it's not resolved after those are resolved, at least we'll be in a much better position to root-cause the real problem.
Owner: m...@chromium.org
Status: Assigned (was: Unconfirmed)
Project Member

Comment 19 by bugdroid1@chromium.org, 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

Status: Started (was: Assigned)
commit ed44fc45d0c3b3675efec4c550d28c5de1569c9d
Author: Yuri Wiitala <miu@chromium.org>
Date:   Fri Dec 14 19:14:24 2018

    Complete the screen capture color space plumbing.

Status: Fixed (was: Started)
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

test-screenshot-extension-for-png.diff
766 bytes Download
captureVisibleTab-color_test.png
240 KB View Download
Which release of Chrome should I expect to contain the fix?

Sign in to add a comment