Issue metadata
Sign in to add a comment
|
Color clipping in photos and videos
Reported by
tomas.ju...@gmail.com,
Sep 26 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Example URL: https://www.instagram.com/p/BZes1DkB4eb/?hl=en&taken-by=maxaerts Steps to reproduce the problem: 1. open photo or video with dark shades 2. look at the photo or video 3. wonder what is wrong with the browser What is the expected behavior? It all should look pretty and fancy, it doesn't. What went wrong? All darks look like 256 colors on an old PC Does it occur on multiple sites: Yes Is it a problem with a plugin? N/A Did this work before? N/A Does this work in other browsers? Yes Chrome version: 61.0.3163.100 Channel: stable OS Version: 10.0 Flash Version: I'm only having this problem on a Gigabyte Aero 15 notebook, but it's my daily driver and it drives me nuts.
,
Sep 26 2017
Please check to see if you have a color profile installed on that specific machine. Chrome 61 ships with color correction enabled by default and it would likely explain your problem. Otherwise it's a graphics card issue of some kind. Search for "color profile windows" for help with checking your color profile. If you can't find any installed color profile, please go to chrome://gpu and paste the resulting information here.
,
Sep 26 2017
Wow, that's fantastically bad! Please attach the ICC profile that you're using for your monitor so we can analyze it and see what went wrong!
,
Sep 26 2017
,
Sep 27 2017
As for the ICC, it's a N156HCA-EA1 D6800 What puzzles me is this is only problem of Chrome browser, no other. Even after I've checked my uploaded sample photo, it looks equally bad. I've opened the same in IE and no problem. Check the print screens for that. If this would be a problem of a wrong color profile, wouldn't this affect all other apps too? This also affects videos and again only in Chrome. I don't know any other person around me using the same notebook (Gigabyte Aero 15), so cannot verify if this is a common thing or not.
,
Sep 28 2017
Thank you -- could you attach the D6800.icm file to this bug? The file may be in c:\Windows\system32\spool\drivers\color (or it may have a custom path). That's the file that we need to determine what's going wrong with the color settings. In the mean time, in Chrome 62+ you can work around this by setting "force color profile" to "sRGB" in about:flags. In Chrome 61, you will have to disable "color correct rendering". Please do attach the .icm file, because this issue needs to be fixed regardless.
,
Sep 28 2017
,
Sep 28 2017
I've tried to disable "color correct rendering" in about:flags, no improvement. As soon as I've selected "enabled", it all works well now. Previously it was at "Default" setting. After selecting "Enabled" in about:flags > "color correct rendering", this problem is no more. What went wrong?
,
Sep 28 2017
I'm not sure. I installed your D6800.icm, and I consistently see the bug now. I think it has to do with our analytic transfer function approximation.
,
Sep 29 2017
After yesterdays success, I've installed Battlefield 1 and it prompted me to update Nvidia driver to 385.69 No matter which option in "flags>color rendering", I'm back to my previous problem. Pictures and video are off again. Is there anything I could do to help?
,
Oct 2 2017
This is a bug in how we're handling your color profile's transfer function -- the lowest values are slipping below zero. We'll have a fix in Chrome 63, but for now you'll have to work around the issue. Best bet for now is: - in Chrome 61, disable color correct rendering in about:flags - in Chrome 62, force color profile to sRGB in about:flags
,
Oct 2 2017
In particular, the transfer function we're ending up with is: T(x) = (0.960839 * x + 0.044625) ** 2.380216 + -0.005410 The lookup table in the .icm file is <1/255 for all values up to 22/255. In other words, this profile is squashing lots of the darker shades all the way to black. Ending the nonlinear segment where it hits zero is one possible option.
,
Oct 2 2017
Sorry, #12 was bogus -- I was looking at the wrong profile. The issue with this profile is that, when we fit the linear segment of the transfer function, the best linear fit to this data ends up being very negative at 0. I think that the best solution here is to force the linear segment's fit to satisfy two requirements - T(0) = 0 - T be continuous with the nonlinear segment This will give us a more predictable and well-defined result. It may result in a greater error, but that's fine -- if the error is too large, then we'll note that and use a LUT at compositing time. I've attached an image of the transfer function table, its best fit in the old algorithm (which fits the data very well in the linear segment, FWIW) and in the updated algorithm.
,
Oct 2 2017
Issue 770575 has been merged into this issue.
,
Oct 2 2017
,
Oct 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c3dfdcdcba1f5fbd1f95e5e1fa0c6396ad58fbdc commit c3dfdcdcba1f5fbd1f95e5e1fa0c6396ad58fbdc Author: Christopher Cameron <ccameron@chromium.org> Date: Tue Oct 03 19:42:27 2017 color: Make transfer function approximation continuous When approximating the transfer function's linear segment, ensure that - it go through the origin - it be continuous This is in contrast with the previous behavior, which was to do a linear fit. This may result in a greater error than otherwise (e.g, if the table's data didn't go through the origin). That does not matter, because we will then judge the fit by its maximum error, and if the maximum error is too large, we will use a LUT at compositing time. As an opportunistic fix, when doing the nonlinear least squares on the nonlinear segment of the data, assume that all in the domain [0.15, 1.0] be in the nonlinear segment. This is in contrast to the previous behavior, which used the domain [0.25, 1.0]. I found repeatedly that extending this domain resulted in a better fit (and the linear segment starts almost-never-if-not-never above 0.15). Bug: 768724 Change-Id: Id76cf380c08bc8b050bbb4fd7c9668a186fa447e Reviewed-on: https://chromium-review.googlesource.com/695181 Reviewed-by: Fredrik Hubinette <hubbe@chromium.org> Commit-Queue: ccameron chromium <ccameron@chromium.org> Cr-Commit-Position: refs/heads/master@{#506144} [modify] https://crrev.com/c3dfdcdcba1f5fbd1f95e5e1fa0c6396ad58fbdc/ui/gfx/skia_color_space_util.cc
,
Oct 4 2017
Verified the fix on Win-10 using latest chrome version #63.0.3232.0 as per the comment #0 and #7. Attaching screen shots for reference. Observed that after navigating to URL: https://www.instagram.com/p/BZes1DkB4eb/?hl=en&taken-by=maxaerts, the picture looked pretty and fancy on D6800.icm profile as expected. Hence, the fix is working as expected. Adding the verified labels. Thanks...!!
,
Oct 4 2017
,
Oct 4 2017
This bug requires manual review: We are only 12 days from stable. Please contact the milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 4 2017
Thanks for the fix. Confirmed with ccameron@ this is a safe merge. Approving for M62. Branch:3202
,
Oct 5 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f979f378ef8a8aae6500382ec256b78f156e7279 commit f979f378ef8a8aae6500382ec256b78f156e7279 Author: Christopher Cameron <ccameron@chromium.org> Date: Thu Oct 05 19:46:56 2017 color: Make transfer function approximation continuous When approximating the transfer function's linear segment, ensure that - it go through the origin - it be continuous This is in contrast with the previous behavior, which was to do a linear fit. This may result in a greater error than otherwise (e.g, if the table's data didn't go through the origin). That does not matter, because we will then judge the fit by its maximum error, and if the maximum error is too large, we will use a LUT at compositing time. As an opportunistic fix, when doing the nonlinear least squares on the nonlinear segment of the data, assume that all in the domain [0.15, 1.0] be in the nonlinear segment. This is in contrast to the previous behavior, which used the domain [0.25, 1.0]. I found repeatedly that extending this domain resulted in a better fit (and the linear segment starts almost-never-if-not-never above 0.15). TBR=ccameron@chromium.org (cherry picked from commit c3dfdcdcba1f5fbd1f95e5e1fa0c6396ad58fbdc) Bug: 768724 Change-Id: Id76cf380c08bc8b050bbb4fd7c9668a186fa447e Reviewed-on: https://chromium-review.googlesource.com/695181 Reviewed-by: Fredrik Hubinette <hubbe@chromium.org> Commit-Queue: ccameron chromium <ccameron@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#506144} Reviewed-on: https://chromium-review.googlesource.com/703454 Reviewed-by: ccameron chromium <ccameron@chromium.org> Cr-Commit-Position: refs/branch-heads/3202@{#598} Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098} [modify] https://crrev.com/f979f378ef8a8aae6500382ec256b78f156e7279/ui/gfx/skia_color_space_util.cc
,
Oct 5 2017
,
Oct 5 2017
Issue 771006 has been merged into this issue.
,
Oct 5 2017
,
Oct 6 2017
Issue 770056 has been merged into this issue.
,
Oct 9 2017
The NextAction date has arrived: 2017-10-09
,
Oct 10 2017
Issue 773217 has been merged into this issue.
,
Oct 11 2017
Verified the fix on Win-10 using chrome version #62.0.3202.52 as per the comment #0 and #7. Attaching screen shots for reference. Observed that after navigating to URL: https://www.instagram.com/p/BZes1DkB4eb/?hl=en&taken-by=maxaerts, the picture looked pretty and fancy on D6800.icm profile as expected. Hence, the fix is working as expected. Adding the verified labels. Thanks...!!
,
Oct 12 2017
Issue 774052 has been merged into this issue. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by dtapu...@chromium.org
, Sep 26 2017