WebP files seems to sometimes contain ancillary data

[jubilant-enigma]

In my experience, the new WebP encoder (at least in lossless mode) doesn't seem to match the file sizes possible with the official cwebp encoder. I've seen scenarios where the ImageSharp WebP encoder is as much as 50% larger than the cwebp encoder.

Is it planned/in progress for the ImageSharp WebP encoder to be able to match cwebp?

See #1863 (comment)

I'm currently working with ImageSharp 2.0.0-alpha.0.119 from MyGet.

[brianpopow]

The Webp encoder is a port of libwebp (cwebp), so the file sizes should actually be the same. If that's not the case, maybe there is an issue.

Can you provide an example? Also make sure to use the same settings in cwebp and ImageSharp for encoding.

[jubilant-enigma]

I think I misidentified the problem. 99% sure there is an issue though.

src.jpg downloaded from here, since it seems like this issue only happens on higher-resolution images?

using var srcImg = Image.Load(@"src.jpg");

var bmpEncoder = new BmpEncoder()
{
	BitsPerPixel = BmpBitsPerPixel.Pixel32,
	SupportTransparency = true,
};
var webpEncoder = new WebpEncoder()
{
	FileFormat = WebpFileFormatType.Lossless,
	Method = WebpEncodingMethod.BestQuality,
};

{
	using var mstream = new MemoryStream();
	srcImg.Save(mstream, webpEncoder);
	Console.WriteLine($"WebP length before bmp = {mstream.Length} bytes");
}

{
	using var mstream = new MemoryStream();
	srcImg.Save(mstream, bmpEncoder);
	Console.WriteLine($"Bmp Length = {mstream.Length} bytes");
}

{
	using var mstream = new MemoryStream();
	srcImg.Save(mstream, webpEncoder);
	Console.WriteLine($"WebP length after bmp = {mstream.Length} bytes");
}

Output:

WebP length before bmp = 6636902 bytes
Bmp Length = 47040122 bytes
WebP length after bmp = 11005868 bytes

Somehow, saving the image as a bmp causes the size of a webp after it to increase significantly. Perhaps the entirety of some internal buffer is being written to the output, instead of just a slice of it? If I add a srcImg.SaveAsPng() before the second WebP Save(), then the issue goes away and both WebPs are the same size.

[brianpopow]

That's strange, I cant see how the other encoders could affect the WebpEncoder.

[brianpopow]

I can reproduce this, but I cant wrap my head around what this could be. The webp images produced are valid, according to webpinfo.

[JimBobSquarePants]

Hmmm... We're not using the underlying pooled array over a span anywhere in the encoder code are we?

[brianpopow]

Wouldn't this make the image invalid? webpinfo is pretty sensitive about that.

[JimBobSquarePants]

If the data at the end is junk it wouldn’t matter. Any data length is pre described in headers

[brianpopow]

I have opened an issue for this: #1872

I think, i have found the reason for this issue.

Opened a Pull request to fix this: #1873

edit: @jubilant-enigma could you try version SixLabors.ImageSharp.2.0.0-alpha.0.124 to confirm the issue is fixed?

[jubilant-enigma]

Great work, thanks! Alpha 124 seems to resolve the issue on my side.