Issue metadata
Sign in to add a comment
|
Chrome 61 displays desaturated images and css colors on a wide-gamut monitor with custom profile
Reported by
a...@alibosworth.com,
Sep 29 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Example URL: Steps to reproduce the problem: 1. View an sRGB JPEG in Chrome, Safari, Preview.app on a DELL U2413 wide-gamut monitor with a custom profile created via ColorMunki hardware and software What is the expected behavior? That the JPEG appears the same in Chrome as it does in Safari or Preview.app What went wrong? Chrome displays it slightly differently: desaturated. Before Chrome 61 it displayed everything too vibrant on this monitor, I have been following the bug about better color management which finally landed in 61, however it doesn't work perfectly for some reason on my end and I was advised to create a new ticket here: https://bugs.chromium.org/p/chromium/issues/detail?id=44872#c171 Attached is a screenshot showing Chrome, Safari, and Preview, as well as my monitor ICC profile and JPEG used. Additionally, in case it helps, when the Image is shown in Chrome it is shown with a black background, but the background is no longer solid black, it has some grey parts near the image. There is a screenshot of that attached as well Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes It worked differently in 60 Does this work in other browsers? Yes Chrome version: 61.0.3163.100 Channel: stable OS Version: OS X 10.12.6 Flash Version:
,
Sep 29 2017
ccameron@, another color profile issue to look at. Regardless of the issues, I'm super happy you got this done.
,
Sep 29 2017
HM! thanks for looking into it so quickly. Seeing the versions you tested in your screenshot, I tested non-stable I also can't repro in Canary (63) locally. Here's my stable (61) about:gpu anyways:
,
Sep 29 2017
Oh -- you have all GPU acceleration disabled! GPU process was unable to boot: GPU access is disabled in chrome://settings. We don't support anything besides sRGB rendering (and we may not communicate that clearly to the window server) in software mode. If you go into chrome://settings and re-enable hardware acceleration, does that fix the issue?
,
Sep 29 2017
wow, yes, that resolves it. Thanks kindly and sorry for the bother. Feel free to close!
,
Sep 29 2017
And your bug alerted me to issue 770369 , which was about to land in stable, so it turned out to be really fortunate timing! I'll still double-check software compositing (since, while it's not #1 priority, it still needs to work).
,
Sep 29 2017
Ah cool, thanks again!
,
Oct 1 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7a8be39db8c7bf5eda180ad00718f7d4d24a75bf commit 7a8be39db8c7bf5eda180ad00718f7d4d24a75bf Author: Christopher Cameron <ccameron@chromium.org> Date: Sun Oct 01 03:02:34 2017 Fix bug where GpuMemoryBufferImplIOSurface breaks ICCProfile cache All ICCProfile ids should be generated in the browser process. A bug here caused an id to be generated in the renderer process, resulting in conflicting ids and caches spitting out the wrong data. The issue is that GpuMemoryBufferImplIOSurface::SetColorSpaceForScanout gets the ICCProfile from a ColorSpace, which calls ICCProfile::FromData, which creates a new profile id, potentially conflicting with ids sent from the browser process. Avoid this by having GpuMemoryBufferImplIOSurface query just the profile data directly, avoiding the ICCProfile structure. This area needs cleanup in crbug.com/766736 . Bug: 770219 Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Change-Id: I9d2bd6ac4fd24fbdeb7d073bf5f9f6e9b32d00a6 Reviewed-on: https://chromium-review.googlesource.com/692708 Commit-Queue: ccameron chromium <ccameron@chromium.org> Reviewed-by: Fredrik Hubinette <hubbe@chromium.org> Cr-Commit-Position: refs/heads/master@{#505491} [modify] https://crrev.com/7a8be39db8c7bf5eda180ad00718f7d4d24a75bf/gpu/ipc/client/gpu_memory_buffer_impl_io_surface.cc [modify] https://crrev.com/7a8be39db8c7bf5eda180ad00718f7d4d24a75bf/ui/gfx/color_space.cc [modify] https://crrev.com/7a8be39db8c7bf5eda180ad00718f7d4d24a75bf/ui/gfx/color_space.h
,
Oct 2 2017
,
Oct 2 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a00ea6e4c800171bed2de8e7bc9ad7d6696b6ab8 commit a00ea6e4c800171bed2de8e7bc9ad7d6696b6ab8 Author: Christopher Cameron <ccameron@chromium.org> Date: Mon Oct 02 00:44:55 2017 Fix bug where GpuMemoryBufferImplIOSurface breaks ICCProfile cache All ICCProfile ids should be generated in the browser process. A bug here caused an id to be generated in the renderer process, resulting in conflicting ids and caches spitting out the wrong data. The issue is that GpuMemoryBufferImplIOSurface::SetColorSpaceForScanout gets the ICCProfile from a ColorSpace, which calls ICCProfile::FromData, which creates a new profile id, potentially conflicting with ids sent from the browser process. Avoid this by having GpuMemoryBufferImplIOSurface query just the profile data directly, avoiding the ICCProfile structure. This area needs cleanup in crbug.com/766736 . Bug: 764352 , (originally filed in 770219) TBR=ccameron@chromium.org (cherry picked from commit 7a8be39db8c7bf5eda180ad00718f7d4d24a75bf) Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Change-Id: I9d2bd6ac4fd24fbdeb7d073bf5f9f6e9b32d00a6 Reviewed-on: https://chromium-review.googlesource.com/692708 Commit-Queue: ccameron chromium <ccameron@chromium.org> Reviewed-by: Fredrik Hubinette <hubbe@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#505491} Reviewed-on: https://chromium-review.googlesource.com/694543 Reviewed-by: ccameron chromium <ccameron@chromium.org> Cr-Commit-Position: refs/branch-heads/3202@{#530} Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098} [modify] https://crrev.com/a00ea6e4c800171bed2de8e7bc9ad7d6696b6ab8/gpu/ipc/client/gpu_memory_buffer_impl_io_surface.cc [modify] https://crrev.com/a00ea6e4c800171bed2de8e7bc9ad7d6696b6ab8/ui/gfx/color_space.cc [modify] https://crrev.com/a00ea6e4c800171bed2de8e7bc9ad7d6696b6ab8/ui/gfx/color_space.h
,
Oct 4 2017
ccameron@, Tried to install color profile on Mac 10.13 but we are unable to install successfully. Could you please help us with clear steps to install color profile & to check this issue from TE end. Your help is highly appreciated. Thanks..!
,
Oct 23 2017
,
Oct 23 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by dtapu...@chromium.org
, Sep 29 2017