Incorrect WebP rendering in some versions of Chrome
Reported by
j...@cloudinary.com,
Oct 11 2017
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Example URL: Steps to reproduce the problem: Some WebP images with a weird color profile render differently depending on the Chrome version/platform. What is the expected behavior? The image is expected to render in the same way on all Chrome versions/platforms, but it doesn't. What went wrong? This issue is described in detail in the libwebp bug tracker: https://bugs.chromium.org/p/webp/issues/detail?id=361 If the problem is related to the interpretation of the color profile, then it is probably not a libwebp issue but rather a chrome issue. 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? N/A Chrome version: 61.0.3163.100 Channel: stable OS Version: OS X 10.12.6 Flash Version:
,
Oct 11 2017
,
Oct 11 2017
Could you please be specific about which version/platform combinations fail and which ones work correctly?
,
Oct 12 2017
Chrome version 59 PC (64-bit) - For both retina and non-retina displays, the WebP image is not the same as the original PNG image. Chrome version 60 MAC - On all screens (retina and non-retina) the WebP image is the same as the original PNG image. PC (32-bit) - On all screens (retina and non-retina) the WebP image is the same as the original PNG image. Chrome version 61 PC (32-bit) - On all screens (retina and non-retina) the WebP image is the same as the original PNG image. PC (64-bit) - For both retina and non-retina displays, the WebP image is not the same as the original PNG image. MAC - Bad on retina, but good on non-retina.
,
Oct 12 2017
Thank you for providing more feedback. Adding requester "schenney@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
,
Oct 12 2017
So where could the problem be? It's not at all clear to me why 32 vs 64 bit builds would differ, or even why HighDPI would matter (although I suppose we scale the image on HighDPI?) Also, jon@, could you attach the webp file? We don't want any ambiguity in our testing.
,
Oct 16 2017
,
Oct 16 2017
@jon-- Could you please respond to comment #6 and update the thread. Thanks!
,
Oct 16 2017
Thank you for providing more feedback. Adding requester "hdodda@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
,
Oct 16 2017
Starting the triage process with the codec end of things to verify that everything happening there is correct. We can move up the stack once we get decoding verified.
,
Oct 16 2017
Very likely related to https://bugs.chromium.org/p/chromium/issues/detail?id=747640#c19 There are lots of WebP images out there that do not set ALPHA_FLAG in WEBP_FF_FORMAT_FLAGS, but yet expect the image's alpha channel to be read. Depending on the color conversion path, Chrome will sometimes read the alpha channel even if ALPHA_FLAG isn't set -- we shouldn't count on that.
,
Oct 23 2017
The NextAction date has arrived: 2017-10-23
,
Oct 23 2017
Marking as available based on comment #c12.
,
Oct 23 2017
Marking as WontFix on the Chrome side -- these are invalid WebP files as per https://bugs.chromium.org/p/webp/issues/detail?id=361 |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by scroggo@chromium.org
, Oct 11 20173.7 KB
3.7 KB View Download