Issue metadata
Sign in to add a comment
|
Images rendering incorrectly in Chrome
Reported by
rockona...@gmail.com,
Mar 22 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3043.0 Safari/537.36 Example URL: https://imgur.com/a/N8qbH Steps to reproduce the problem: 1. View any image, but the problem is especially noticeable on images with dark colors, especially red, brown, purple, and black. Does not always occur, some things render correctly. Things rendered within a web page seem to render correctly more often than direct image links. 2. Download the viewed image or view it in a non-Chrome/Chromium web browser, there will be obvious degradation and rendering errors on Chrome's side. What is the expected behavior? The image should render correctly without weird blur and compression? artifacts. What went wrong? The image color levels have been wrecked, there's degradation throughout the image, etc. I attached a comparison of the two images; this is porbably obvious, but don't view the comparison within Chromium or the normal image will look the same since it'll be rendered incorrectly in the exact same way. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes unknown, began happening within the past week Does this work in other browsers? N/A Chrome version: 59.0.3043.0 Channel: dev OS Version: 10.0 Flash Version:
,
Mar 22 2017
Actually, disregard the bit about it being exclusive to PNGs, it just seems inconsistent and erratic. These images will display the issue, and are JPGs: https://i.imgur.com/89gmNuu.jpg https://i.imgur.com/bwBlI5r.jpg
,
Mar 22 2017
,
Mar 22 2017
Unable to reproduce the issue on Windows-10,Windows-7,Mac-10.12.3 and Linux Ubuntu 14.04 using chrome stable version 57.0.2987.110 and canary 59.0.3047.4 and reported version 59.0.3043.0 with the steps mentioned in comment#0. Observed same behavior in Firefox too. Please find the attached screen cast and let us know if anything missed here to reproduce the issue. Thanks.
,
Mar 22 2017
Uncertain. I tested the Canary channel (59.0.3047.4) and observed the same messed up image rendering. Chrome 57.0.2987.110 was tried as well, and did *not* have this behavior. Maybe it's related to color space? If it's relevant, my computer is an XPS 15 9550 with an 100% Adobe RGB hidpi screen. Other things I've tried to no avail: * Resetting all settings to their defaults * Clean uninstall/reinstall * Disabling all extensions * Deleting user profile data manually * Disabling rendering-related flags in chrome://flags
,
Mar 22 2017
Thank you for providing more feedback. Adding requester "sureshkumari@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 23 2017
Thanks, I see apparently difference between 2 screenshot PNGs attached, and Chrome one obviously show some mach bands (non-smooth color gradation). I'm not sure about JPGs in comment#2, though. Shotting in the dark to Skia - feel free to reassign appropriate team.
,
Mar 23 2017
Able to reproduce the issue on Windows-10 using chrome canary 59.0.3048.0. This is regression issue broken in M59.Please find the bisect information as below Narrow Bisect:: =============== Good::59.0.3041.0 -- (build revision 456562) Bad ::59.0.3042.0 -- (build revision 456934) After executing the per-revision bisect script , i got the following CL's between good and bad build versions =========================================== https://chromium.googlesource.com/chromium/src/+log/782364b2af9f1c3c7f0a39d5dd9fa1df34cdfb09..24c87c3f418983673089663bb69045451d54f52d Review-Url: https://codereview.chromium.org/2742613002 ccameron @could you please look into this issue if it is related to your change,else please help us in finding the appropriate owner for this issue. Note:Issue is specific to Windows-10 Thanks,
,
Mar 24 2017
kochi, thank you. For the JPGs, the issue with the first (iceberg) picture is especially noticeable in the lower lefthand corner. In the second picture, the issue is very apparent in the shadow of the unicorn floaty's wings.
,
Mar 27 2017
I think I see the issue. In that patch, I change our behavior so that we use the parametric-fit to the ICC profile rather than using the ICC profile directly. It appears that we are not accurate enough. rockonaile, could you attach the following - the original image from https://imgur.com/a/N8qbH - the ICC profile of your monitor (this is so that I can make sure that our parametric fit is accurate enough)
,
Mar 27 2017
Also, kochi, if you have your ICC profile handy, could you upload it as well? The difference before and after r456849 is that if we get an accurate parametric representation, then we use SkColorSpace::MakeRGB instead of SkColorSpace::MakeICC. Accurate here means that the transfer functions are approximated to within 3/256 (which is arguably too leniant around 0/255 and too stringent closer to 255/255, but that can be dealt with later). In the attached download.png, the input color for some of the hair that is clamped down is RGB (23,27,24)/255. In Screenshot (117), the value I see is (23,0,25)/255. So, something very violent happened to the green channel. If I can get the user's ICC profile, I should be able to reproduce this locally, and see how we got to be off by 27/255 (nearly 10x the tolerance).
,
Mar 27 2017
rockonaile: the command to print your ICC profile is xprop -display :0.0 -root _ICC_PROFILE It'll print a really long string. Save that to a file and attach it, and I'll be able to analyze what went wrong.
,
Mar 28 2017
ccameron@ re comment#12, I was just triaging this bug as a sheriff, and confirmed the difference between the screenshots (see comment#7), and I haven't been successful to tell the difference locally. I guess the message was meant for the original reporter rockonaile@, right?
,
Mar 28 2017
ccameron: Since I'm on Windows, I wasn't able to run that xprop command, but I found the ICC file my display is using; I hope that will suffice.
,
Mar 28 2017
rockonaile, thank you -- I can reproduce this bug with your profile. I'll make sure it gets fixed ASAP!
,
Mar 28 2017
Mmh, this is the issue that Matt brought up earlier -- we don't enforce that the approximation be continuous, and, sometimes, the error is minimized by making it discontinuous. The equation for that profile is fA 1.041954 fB -0.050817 fC 0.108722 fD 0.141176 fE 0.018956 fF 0.000000 fG 2.149717 And I've attached a graph of the resulting transfer function. I'll check something in now to fix the image (by just not using the approximation), and then I'll check to see what I can do with the discontinuity.
,
Mar 28 2017
Hmm this is a very cool bug... I haven't done any math, but I'm surprised that the discontinuity caused such noticeable diffs. I guess maybe the green channel is falling off the ledge and "jumping down"? Is that your intuition?
,
Mar 28 2017
I think my approximation code is just getting the wrong answer :/, but only in Chromium. The python version (attached, with this profile's data) converges almost exactly. Each iteration is (1.000000x + 0.000000)^2.000000 + 0.000000 (0.913423x + 0.094409)^2.431910 + -0.009481 (0.958550x + 0.043008)^2.369295 + 0.003108 (0.956538x + 0.045396)^2.375614 + 0.001741 (0.956548x + 0.045384)^2.375600 + 0.001743 The C code, meanwhile, on the same data, does (1.015030x + -0.024796)^2.207001 + 0.021426 (1.043929x + -0.053044)^2.143882 + 0.019440 (1.041836x + -0.050683)^2.149949 + 0.018925 (1.041958x + -0.050822)^2.149709 + 0.018957 (1.041954x + -0.050817)^2.149718 + 0.018956 The Python code doesn't bake in the assumption that T(1)=1, and it also does a full QR factorization (as opposed to just creating the 3x3 normal equations), and it uses doubles instead of floats. So... it's one of those three.
,
Mar 28 2017
Actually ... this data just doesn't fit at 1 -- the best fit doesn't satisfy that constraint -- T(1) for the good fit is 1.00634. So, maybe we should just let that happen...
,
Mar 29 2017
My two cents is that we should get the best fit that we can, while enforcing that T(1) = 1 and that the fn is continuous. I believe we're seeing here that discontinuities can cause images to look weird. And we are always going to have a bit of difficulty with the fit when the monitor profile transfer fn has "corners" - seems like a bad fn to me. Maybe allowing T(1) to be greater than 1 is ok (if we clamp). But allowing it be less than 1 seems really strange - we'll never use 255 as the pixel color. I guess there's no evidence that this looks bad either way - but forcing the end points to be sane makes me a little more comfortable.
,
Mar 31 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/95f83c51ade772da4b9d9aa8b1a6c40ad696a897 commit 95f83c51ade772da4b9d9aa8b1a6c40ad696a897 Author: ccameron <ccameron@chromium.org> Date: Fri Mar 31 20:16:12 2017 color: Do not enforce T(0)=0 and T(1)=1 constraints in approxmation Enforcing these constraints can end up giving us an inaccurate approximation, as some transfer functions overshoot T(1). BUG= 703966 Review-Url: https://codereview.chromium.org/2784673006 Cr-Commit-Position: refs/heads/master@{#461203} [modify] https://crrev.com/95f83c51ade772da4b9d9aa8b1a6c40ad696a897/ui/gfx/color_space_unittest.cc [modify] https://crrev.com/95f83c51ade772da4b9d9aa8b1a6c40ad696a897/ui/gfx/icc_profile.cc [modify] https://crrev.com/95f83c51ade772da4b9d9aa8b1a6c40ad696a897/ui/gfx/icc_profile.h [modify] https://crrev.com/95f83c51ade772da4b9d9aa8b1a6c40ad696a897/ui/gfx/icc_profile_unittest.cc [modify] https://crrev.com/95f83c51ade772da4b9d9aa8b1a6c40ad696a897/ui/gfx/skia_color_space_util.cc [modify] https://crrev.com/95f83c51ade772da4b9d9aa8b1a6c40ad696a897/ui/gfx/test/icc_profiles.cc [modify] https://crrev.com/95f83c51ade772da4b9d9aa8b1a6c40ad696a897/ui/gfx/test/icc_profiles.h
,
Apr 4 2017
Tested this issue on Windows 10 with chrome dev version-59.0.3061.3 as per the below provided in comment#0. https://imgur.com/a/N8qbH Please find the attached screenshot & confirm us on the fix. Thank you!!
,
Apr 6 2017
I can confirm, the issue seems to be fixed as of ccameron's commit. Thanks @ccameron!
,
Apr 6 2017
@ccameron! Could you please confirm us on the fix as per comment#25. Thanks in advance!!
,
Apr 6 2017
Please ignore above comment(27). As per comment#26,reporter confirmed that issue has been fixed. Hence adding TE Verified labels. Thank you!!
,
Apr 6 2017
,
Apr 6 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 Deleted