Issue metadata
Sign in to add a comment
|
WebGL canvas with premultiplied alpha (default) renders incorrectly for Linux color profiles
Reported by
miika...@gmail.com,
Apr 16 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Example URL: https://jsfiddle.net/aLy27Ljn/1/ Steps to reproduce the problem: 1. Open the jsfiddle URL 2. Compare the two gradients. Both are WebGL rendered white gradients fading from 1.0 to 0.0 alpha. What is the expected behavior? Both left and right side gradient should look identical. What went wrong? On all Linux installations where we have tested this left side gradient appears different. See attached "gradient_alpha.png" screenshots. Windows and Mac and other browsers (Firefox) even on Linux render this correctly. Low alpha values appear with higher alpha than they should and with noticeable banding. This seems to be related to display color profiles that were enabled in Chrome 61. Both gradients look identical if "Force color profile" flag is set to "sRGB" in about:flags. It seems as if the color profile it also applied to canvas alpha, making low alpha values higher. Another possibility I can think of is that color values are adjusted for the color profiles without accounting for the premultiplied alpha, making low alpha colors multiple times brighter when they are un-multiplied by the now unmatching lower alpha. Also see "real_use_case_example.png" for how this affects our real application. In the screenshot you see 3D rendered model with a bloom filter applied on top of it in WebGL. Because of this bug all low alpha values at the fringe areas of the bloom appear multiple times brighter / more visible than they should while also having visible banding. See "real_use_case_correct.png" for how it looks in all other browsers and operating systems. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 65.0.3325.181 Channel: stable OS Version: Flash Version:
,
Apr 16 2018
,
Apr 16 2018
,
Apr 16 2018
> Another possibility I can think of is that color values are adjusted for the color profiles without accounting for the premultiplied alpha Yeah, that: https://cs.chromium.org/chromium/src/components/viz/service/display/shader.cc?rcl=408e3ae7cbd284dced54e426efaab17365a87785&l=968
,
Apr 17 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/827e9487da3870a1e9ef144095a1bf11582d7787 commit 827e9487da3870a1e9ef144095a1bf11582d7787 Author: Christopher Cameron <ccameron@chromium.org> Date: Tue Apr 17 21:14:29 2018 Apply alpha premultiplication before color conversion Add version of conversion tests with and without premultiplied alpha. Bug: 833388 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel Change-Id: I9d269e5867fee62ed70b2f3579a4c4bf524a7103 Reviewed-on: https://chromium-review.googlesource.com/1014631 Reviewed-by: enne <enne@chromium.org> Commit-Queue: ccameron <ccameron@chromium.org> Cr-Commit-Position: refs/heads/master@{#551476} [modify] https://crrev.com/827e9487da3870a1e9ef144095a1bf11582d7787/components/viz/service/display/renderer_pixeltest.cc [modify] https://crrev.com/827e9487da3870a1e9ef144095a1bf11582d7787/components/viz/service/display/shader.cc
,
Apr 18 2018
I'm not sure if that fix works correctly. While both of the color ramps now indeed look the same, they both have now too high alpha and banding on low alpha areas. Notice the gap at the bottom of the color ramp. This new screenshot (color_ramp_gap.png) is taken with forced "Color spin with gamma 2.4" color profile which seems to nicely reproduce the issue on any operating system. I don't think alpha values should be affected by color profiles. If something is 0.01 alpha, it should remain barely visible regardless of which color shade its color is corrected to. Right now very low alpha values at the bottom are clipped to zero causing the gap, first set of appearing alpha values are way more visible than they should be when compared to other browsers or their actual alpha values. (Causing the very sharp line instead of smooth falloff for the ramp)
,
Apr 29 2018
I created another jsfiddle test case that perhaps better visualizes the issue: https://jsfiddle.net/o8jjydqm/ This time right side is a PNG image of a white halo (captured from Firefox canvas) so it looks identical even on affected systems. (PNG images are color corrected correctly) When I'm using default Ubuntu display color profile the WebGL version of the halo renders with a sharp edge, like seen in the "halo_with_ubuntu_color_profile.png". It seems impossible to make WebGL render a alpha mapped white halo that has a smooth falloff on affected systems. Instead a sharp edge near zero alpha values happens. Shouldn't WebGL canvas be color corrected and composited in the same way that PNG image is? So in a way that alpha values remain unaffected.
,
May 1 2018
I broke the path that worked, to make it match the path that was broken... hubbe@ has a fix over at issue 835322 . |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by dtapu...@chromium.org
, Apr 16 2018Components: -Blink Internals>Compositing Blink>Paint