blending color with non-zero alpha over same color alpha 1 does not result in constant color
Reported by
kilianva...@gmail.com,
Jun 14 2016
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0 Example URL: http://codepen.io/Kilian/pen/pbyaqv Steps to reproduce the problem: 1. Open linked codepen 2. Observe that we use the same RGB values in both the ::before and ::after situation, just that for ::before we go from RGBA to RGB, and in the ::after, from RGBA to RGBA 3. Observe that there is a slight darkening of the color near the turn in the gradient. What is the expected behavior? expected behaviour would be to see no color difference/color banding at all: The gradient goes from a specific color fully transparent, to the same color fully opaque, on a background of the same fully opaque color. This is true for both ::before (RGBA->RGB) and ::after (RGBA->RGBA). What went wrong? The only difference is the use of RGB instead of RGBA. In both variants I expect the color to remain consistent #002B36. However in the RGBA->RGB variant, there is banding near the turn of the gradient resulting in a stroke of #002A36 and a stroke of #002B35. 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: 50.0.2661.94 (64-bit) Channel: stable OS Version: ubuntu 16.04 64 bit Flash Version: Shockwave Flash 11.2 r202 If we switch the RGB values to 255,0,0 then the banding is not visible, so this might be related either to the brightness of the used colors, or possibly the hue.
,
Jun 17 2016
,
Jun 17 2016
You've got a better monitor than me to see any color banding. Given the visually imperceptible nature of the error, this is not a high priority to fix. The test case doesn't show the bug, as far as I can tell. I can't see the ::after element at all. Could you produce a better test case?
,
Jun 19 2016
This is on a Macbook pro, so hardly an uncommon monitor. You are correct in stating you can not see the ::after element at all. The initial case accidentally had the ::after overlapping the before which led me to believe rgba -> rgba did not show the banding. This was incorrect. I realise I have been both unclear and incorrect in my initial bug report. There are two situations in the test case: 1) the ::after: rgba -> rgba 2) the ::before: rgba -> rgb Contrary to my initial bug report, *both* gradients show banding. I have updated my test case: http://codepen.io/Kilian/pen/pbyaqv
,
Jun 19 2016
Thank you for providing more feedback. Adding requester "schenney@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 1 2016
The issue is in blending the gradient with the fixed color background. In the process of doing that, we should get constant color alpha = 1 but we do not. It's easier to understand the problem if you set the fiddle colors to be, say rgba(50,50,50, 0 or 1). Looking at the gradients with no background color, the result looks right with no banding. But when the background color matches the gradient color, there is one row that ends up with pixel values one lower than expected: 31,31,31 instead of 32,32,32 according to my color picker. The most likely cause is a loss of alpha during the blending, but maybe it's something else.
,
Jul 3 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 7 2017
,
Jul 7 2017
I can't reproduce this now. I'm guessing it's fixed. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by haraken@chromium.org
, Jun 15 2016