Repository navigation
transparency issues with some .webp images #2528
Description
Activity
For some reason the
bugged_image.webpseems to be encoded as an animated webp with a loop count of 1, which does not make alot sense to me.webpinfo bugged_image.webp File: bugged_image.webp RIFF HEADER: File size: 60214 Chunk VP8X at offset 12, length 18 ICCP: 0 Alpha: 1 EXIF: 0 XMP: 0 Animation: 1 Canvas size 874 x 874 Chunk ANIM at offset 30, length 14 Background color:(ARGB) ff ff ff ff Loop count : 1 Chunk ANMF at offset 44, length 60170 Offset_X: 98 Offset_Y: 0 Width: 663 Height: 869 Duration: 0 Dispose: 0 Blend: 1 Chunk ALPH at offset 68, length 30006 Chunk VP8 at offset 30074, length 30140 Width: 663 Height: 869 Alpha: 0 Animation: 0 Format: Lossy (1) No error detected.If I first convert the image to be a normal lossy webp (not an animated webp), the issue goes away. Unfortunatly my usually approach to compare the decoding result to the reference implementation does not work here, since
dwebpdoes not support decoding aniamted webp.I thing the background color
(ARGB) ff ff ff ffplays a role with the issue, but I am not sure about it.Most viewers/decoders seem to just ignore the background color.
- Irfanview shows it as black color
- gimp as transparent color
- xnview also transparent color
- firefox/edge/chrome show it as gray
- even
vwebpwhich is the official tool from libwebp to decode and show webp images ignores the background color
I tried changing the color to blue:
bugged_image_blue_background.zipSame result, no decoder cares about it.
The specification of webp is unclear on how to use the background color. ANIM specViewer applications SHOULD treat the background color value as a hint and are not required to use it. The canvas is cleared at the start of each loop. The background color **MAY** be used to achieve this.Thanks for looking at this @brianpopow
I would say we are doing the correct thing by honouring the background color encoded in the image then.
@JimBobSquarePants I would also say we do it right, but it can be irritating for user, that only ImageSharp handles animated webp in that way and other viewers/decoders dont. It's really frustrating that the spec is so vague on this.
What do you think, would a decoder options to ignore the background color make sense?@Lovrenc how did you create the image? It seems wrong that an animated image would only contain one frame. Also if you want the image background to be transparent, you should choose a transparent color for the background, not opaque white.
Hey,
I did not create the image, I took some random images from random customers to try ImageSharp out. I will track the customer and ask about the method and intentions and come back to you.
Considering what you wrote though, I expect them to just be used to some method that is at its core wrong (and encodes opaque background into an image) but produces what they want in the viewers they are accustomed to.
What do you think, would a decoder options to ignore the background color make sense?
@brianpopow We'd have to change
WebPDecoderto inheritSpecializedImageDecoder<TOptions>and introduce a customWebPDecoderOptionstype containing a configuration property. I would use an enum.BackgroundColorHandlingor similar with two optionsStandardandIgnore. I have no issue with that for v3.1@JimBobSquarePants Ok, I will give it a try in the next days
@Lovrenc how did you create the image? It seems wrong that an animated image would only contain one frame. Also if you want the image background to be transparent, you should choose a transparent color for the background, not opaque white.
Got a response:
I took an existing webp file and then ran an ffmpeg command on it to make it square.
ffmpeg -i ${inputFilePath} -vf pad="max(iw\\,ih):ow:(ow-iw)/2:(oh-ih)/2:[email protected]" ${outputFilePath}@Lovrenc would it be ok, if I use the image you have provided in a unit test?
Sorry for the late reply.
I do not object to it, but I do not hold a license to the artwork (though I doubt that could ever be an issue for a unit test).
Reacted by Brian Popowwith #2547 merged it is now possible to ignore the background color with a webp decoder option. Closing this now
@brianpopow This is probably outside of the scope of the ticket.
Can you guide me a bit please? I can see the flag inWebpDecoderOptions, and that works fine, I cannot however find a way to set it as a global/default behavior so it would get picked byImage.Loadfor instance.What am I blundering?
Hello!
It seems I have a similar issue:
From left to right
FILE.png?width=360&height=0&format=png&quality=100
FILE.png?width=360&height=0&format=webp&quality=100
FILE.pngWe're using Umbraco.CMS.Imaging.ImageSharp 13.1.1, SixLabors.ImageSharp.Web 3.1.0 & SixLabors.ImageSharp 3.1.3
Attaching original file, togheter with png and webp in zip
webptests.zipMaybe I should submit this as a Umbraco ticket?
@seanhakbb may be unrelated but I have to check the file. I want to show you something weird though....
Here's the image displayed in Edge on my laptop screen.
And when it's dragged to my external screen.
Reacted by seanhakbb@seanhakbb may be unrelated but I have to check the file. I want to show you something weird though....
Here's the image displayed in Edge on my laptop screen.
And when it's dragged to my external screen.
I get the exact same thing, do you think this has something more to do with the original image itself? I have never seen anything like this before
I need to investigate the WebP and check what’s going on.
Reacted by seanhakbbOk I’ve figured it out. We’re not updating the VPX8 chunk to show that there is alpha transparency in the image. This got broken when we introduced animation. I need to do some refactoring.
Reacted by seanhakbb
Prerequisites
DEBUGandRELEASEmodeImageSharp version
3.0.2
Other ImageSharp packages and versions
/
Environment (Operating system, version and so on)
ubuntu 20.04, win 11, ryzen
.NET Framework version
7.0
Description
Most images work fine, but some will replace part of the transparent background with white background (but not all of it, a small rectangle around the image stays transparent).
Here are the results as viewed in an image viewer.
Original:
Result:
Steps to Reproduce
Images
bugged_image.zip