The official WebP tools [1] correctly decode the picture so it looks like a bug in Chrome itself since both projects supposedly use libwebp.

  [1]: https://developers.google.com/speed/webp/

tejesh.mehta@ Thanks for the issue...

Tried to reproduce the issue on reported chrome version 69.0.3497.100 using Mac 10.13.6. Attaching screencast for reference.
Steps: 
------
1. Launched reported chrome 
2. Navigated to given url in the " https://codesandbox.io/embed/405j8pv4v0?view=preview "  
As we are observed that the same behavior from M-60 to latest chrome 71.0.3570.0.

@Reporter: Could you please review the attached screen-cast and confirm if anything being missed here. Could you please elaborate on the same by providing expected/actual behaviour along with the test steps. Any further inputs from your end may be helpful.

Thanks.!

Deleted: WebP.png 89.8 KB

	WebP.png 89.8 KB View Download

phanindra.mandapaka@, as you can see the second image border is not smooth (look around the cup and below the phone). Chrome never displayed it correctly. It should be just as smooth as that on the first image.

Yes that is correct. It seems that webp images containing gradients over transparency render white instead of transparent. There seems to be a bug with rendering the alpha channel. I can provide more webp images that repro the issue if it helps. Let me know. Thanks!

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This image reports conflicting transparency markers. The VP8X chunk says that the image does *not* contain transparency, but the VP8L chunk says that it *does*.

In this case, we respect the VP8X chunk [1] (as retrieved by the format flags from WebPDemuxGetI(demux_, WEBP_FF_FORMAT_FLAGS) [2]). According to the discussion here [3], it sounds like we should probably look at the WebPIterator's has_alpha field instead, which would take the VP8L chunk into account, too.

I've attached a modified version of the file that corrects the VP8X chunk, and it displays as expected in Chromium. (Which is not to say that we shouldn't fix the code.)

[1] https://chromium.googlesource.com/chromium/src/+/6038a3e922224f989856fb9f77f1b155f273c719/third_party/blink/renderer/platform/image-decoders/webp/webp_image_decoder.cc#589
[2] https://chromium.googlesource.com/chromium/src/+/6038a3e922224f989856fb9f77f1b155f273c719/third_party/blink/renderer/platform/image-decoders/webp/webp_image_decoder.cc#285
[3] https://groups.google.com/a/webmproject.org/d/msg/webp-discuss/2rFPKOzxuSM/JTbEouVQBQAJ
[4] https://chromium.googlesource.com/chromium/src/+/6038a3e922224f989856fb9f77f1b155f273c719/third_party/blink/renderer/platform/image-decoders/webp/webp_image_decoder.cc#490

Deleted: cuppy-phone-with-alpha.webp 15.5 KB

	cuppy-phone-with-alpha.webp 15.5 KB View Download

Interesting find! Going to look into this on our end. Also note, our team discovered this bug when seeing differences between the way that chrome and libwebp render webp files. Regardless of correctness, IMO (and as you indicated) I may be best if chrome and libwebp render webps consistently. I can provide more info on the libwepb version if necessary (lmk). 

In the meanwhile, we will definitely fix our invalid webps. I am going to investigate other webps where we see alpha inconsistencies and see if they have the same mismatching VP8X and VP8L data.

Some more info: Some of my colleagues have created these problematic webps by converting images using Android Studio, so it may be a common problem.

Thanks for the note about the origin of the images. I think the workaround in comment #8 was discussed previously in  crbug.com/747640#c19 . We had an issue in cwebp for a time like this [1].

If I remember correctly Android Studio was using a simple java wrapper for libwebp, it would be good to double check their setup. What version of Android Studio were you using?

[1] https://bugs.chromium.org/p/webp/issues/detail?id=361

We may have a found an issue in some of our webp scripts, so there may not be a problem with Android Studio. Let me investigate, and I will report back. Thank you for your promptness.

> I think the workaround in comment #8 was discussed previously in
>  crbug.com/747640#c19 .

Almost - my suggestion was not quite right; it is the lack of premultiplication that's causing the problem (as pointed out in the bug referenced here); not whether we tell the image it has alpha. (Though we call SetHasAlpha with a "wrong" value for this image, too.)

I was also mistaken in my belief that WebPIterator.has_alpha takes the format_flags_ into account. I've attached another modified version of the file, where the VP8X is correct, but the VP8L is not (the reverse of the original file). Chromium renders that "correctly" today, but if I just consider WebPIterator.has_alpha, it renders it "incorrectly".

If we want to be the most permissive possible, the code would look something like:

    WEBP_CSP_MODE mode = outputMode((format_flags_ & ALPHA_FLAG || webp_frame.has_alpha)
                                    && premultiply_alpha_);
    ...
    buffer.SetHasAlpha(webp_frame.has_alpha || format_flags_ & ALPHA_FLAG
                       || frame_background_has_alpha);

I can see the plus side of either fixing or not fixing; currently Chromium looks bad (on what seems to be a relatively uncommon type of inconsistency within the image), since this image looks as intended elsewhere, so +1 for fixing. On the other hand, I see the argument for keeping the decoder strict so the encoders will be fixed. In the above bug, we decided *not* to be more permissive (see  crbug.com/747640#c21  and  crbug.com/747640#c35 ), but the solution proposed there was slightly different. That solution was to premultiply even if *both* markers said it had alpha; here I'm suggesting we only premultiply if either one claimed there was alpha.

Deleted: cuppy-phone-with-alpha-conflicting.webp 15.5 KB

	cuppy-phone-with-alpha-conflicting.webp 15.5 KB View Download

Following up here. It looks like one of our scripts was incorrectly setting the VP8X value. Resolving the bug in our script, solves our problem. To be clear: Android Studio conversion does not seem to have any issues. 

I guess the only question that remains is: why does chrome render webps differently from libwebp, and should they be consistent?

Thanks for the help everyone!