Two CSS filter hue-rotate() with reverse value get an incorrect result
Reported by
yujianr...@gmail.com,
Apr 11 2016
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36 Example URL: https://jsbin.com/pixaqe/10/edit?js,output Steps to reproduce the problem: 1. Set background-color of a DIV to rgb(255, 193, 7) 2. Add a css filter hue-rotate(140deg) on the parent node 3. Add a css filter hue-rotate(-140deg) on the DIV What is the expected behavior? The color of the DIV should looks like the original color rgb(255, 193, 7) What went wrong? The color of the DIV is far different to the original color. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? No Does this work in other browsers? No reproducible on Firefox 44 of OSX and Safari 9.0.3 Chrome version: 49.0.2623.87 Channel: stable OS Version: OS X 10.11.3 Flash Version: Shockwave Flash 21.0 r0 Please visit https://jsbin.com/pixaqe/10/edit?js,output for the demo. The issue had been reported in https://bugs.chromium.org/p/chromium/issues/detail?id=237524 , but the conclusion in the old issue is INCORRECT. In our case, inaccurate result of one hue-rotate is acceptable, but two hue-rotate with negative value must result to the original value. In my demo. you will see: Group 1. The incorrect result of two hue-rotate. Group 2. Do the hue-rotate(-140) from the CALCULATED COLOR of hue-rotate(140), GET THE CORRECT COLOR! Group 3. Use the color calculation code in https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/graphics/filters/FEColorMatrix.cpp to calculate the two color hue-rotate but still GET THE CORRECT COLOR So I believe something wrong happened when two hue-rotate used at the same time.
,
Apr 12 2016
Your third element in the first row is applying the "hue-rotate" to the parent element and "reverse-rotate" to the child. Filters are applied in the reverse order: the filter in the child node is applied first, followed by the filter in the parent node. So in order to match the other samples, you have to apply "hue-rotate" to the child, and "reverse-rotate" to the parent. Here's a fixed version: https://jsbin.com/cuyuqofiru/1/edit?html,css,js,output. Secondly, the result will still be different than the original color, due to clamping to the [0,255] range in between passes. I've added a clamp() function to your JS example to simulate this. (There was also a missing "filter" on the "reverse-rotate" example, giving a different result in Firefox, which I've fixed.) The results should now match. Note that they still differ in luminance from the original color, which is the bug you referenced, crbug.com/237524 . I believe we're spec-correct here. The hue rotation transform is not reversible; see http://stackoverflow.com/questions/19187905/why-doesnt-hue-rotation-by-180deg-and-180deg-yield-the-original-color or this spec discussion: https://lists.w3.org/Archives/Public/public-fx/2013OctDec/0004.html
,
Apr 12 2016
Sorry, that should be https://jsbin.com/woqasahico/1/edit?html,css,js,output
,
Apr 13 2016
Thank you very much. Now I know it's a bug of the spec, which use an inaccurate algorithm to do the color transform. For us we cannot rely on the filters to do some accurate transform...
,
Apr 5 2017
|
|||
►
Sign in to add a comment |
|||
Comment 1 by f...@opera.com
, Apr 11 2016