brightness() filter does not work according to spec in wide gamut screens
Reported by
leave...@gmail.com,
May 31 2018
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36 Steps to reproduce the problem: 1. Open testcase on a wide gamut screen, such as a 2016 or later MacBook Pro. Testcase is also online here: http://dabblet.com/gist/dc345818446262073deec3e41209a02d 2. Look at it What is the expected behavior? The square should be red, since brightness() is defined as a multiplier on R, G, B components https://www.w3.org/TR/filter-effects-1/#brightnessEquivalent and no multiplier can make 0 positive. What went wrong? Square is white on wide gamut screens, and red on sRGB screens. Here is a twitter poll with specs by people who can reproduce the bug: https://twitter.com/LeaVerou/status/1002107259416084482 Note that at least one person sees yellow. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 69.0.3446.0 Channel: canary OS Version: OS X 10.13.4 Flash Version: I suspect one possible explanation would be that the zeroes in rgb(25, 0, 0) are internally being represented as numbers slightly > 0, so the multiplier is able to eventually get them to 255. As indicated by the yellow, that residual might not even be the same for Green and Blue.
,
Jun 1 2018
I *think* color correction falls under Paint. If not, please assign back to CSS and I'll find an owner.
,
Jun 1 2018
,
Jun 1 2018
Not sure if this is related, but this also produces different results in wide gamut screens in Chrome: http://dabblet.com/gist/79f8941d95f5afabdd3e6093d3660973 In wide gamut screens, the patch is greenish (hue of around 175), in smaller gamut screens it matches the background (hue of 185, as expected with 120 + hue-rotate(65deg)). If not related, let me know and I'll file a different issue!
,
Jun 1 2018
ccameron@ for a first pass (as someone who might have the hardware to investigate).
,
Jun 2 2018
This is issue 726509 -- our working color space is the monitor's color space, not sRGB. I tested on Safari (because they *did* the same sort of thing), but they end up as red as well. A thought was to only ever rasterize into sRGB or extended-sRGB (as half-float), as outlined in issue 719735. That comes at a substantial power cost on macOS (home of most of the wide gamut displays), which is why we've avoided it so far.
,
Jun 4 2018
Able to reproduce the issue on reported chrome version 69.0.3446.0 and on the latest canary 69.0.3448.0 using Mac 10.13.1. Considered the square with red colour as good and with white colour as bad, while in the process of bisecting it further we have seen another(...third type) colour(yellow) apart from red and white in one of the M62 builds. Attaching the screen shot for reference. @Reporter: Could you please have a look at the screen shot and let us know whether to consider this behaviour as either good or bad. Any further inputs from your end may be helpful. Thanks!
,
Jun 4 2018
@vamshi.kommuri Yellow is still wrong, but less so I guess. The starting color is rgb(25, 0, 0), so no multiplier should be able to make the G and B components positive. Yellow is rgb(255, 255, 0), so somehow, multiplying the 0 G by 100000% made it 255, but at least the B component remained 0, so that's something! I would suggest you also review my testcase in comment 4, which seems to also have to do with paint producing different results in wide vs narrow gamut screens, and is a more common use case (just a hue-rotate() filter) than a brightness of 100000%. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by susan.boorgula@chromium.org
, May 31 2018