WEBP Image Stored 100x Larger Than it Ought to Be Due to Funky Original Image?

[Nicholas-Westby]

I'm doing some bulk conversions of images (over 10,000 files) and I am expecting each file to be roughly 10KB or less. However, I noticed a few were exceptionally large, with one being 564KB. If I save this same image using Affinity Photo, the file size is 8KB.

I was thinking perhaps a ton of metadata was being kept, but I configured the encoder to skip metadata.

Another theory I have is that there's another channel of data being kept, but I'm not familiar enough with these formats to determine what sort of other data this is or how to avoid it. I'm thinking something like a very large color palette or something exported by a custom tool. Maybe the image even contains something malicious (perhaps data that used to cause a bug on older systems). Could also be a bunch of layers or some sort of 3D data (really just brainstorming possibilities at this point).

Anybody have tips on how I can figure out why these images are so large? And how I can configure ImageSharp to strip out this extra data?

I have 4 versions of the image and here's what the sizes show as in a Finder window:

Here's a zip file with those images (the filenames indicate what is unique about each):

wonky-image.zip

BTW, here's what the ImageSharp WEBP image looks like when I press SPACE on a Mac to preview it:

It looks corrupted in comparison to what happens when I double click to open the image:

So that might be a clue.

BTW, the corruption only appears with the ImageSharp versions (not in the original or in the Affinity Photo version).

Here's the latest code I was using to export (I tried a few variations):

using var imageData = Image.Load(originalPath);
imageData.SaveAsWebp(newPath, new WebpEncoder
{
    SkipMetadata = true,
    Quality = 30,
    Method = WebpEncodingMethod.Level6,
    UseAlphaCompression = false,
    TransparentColorMode = WebpTransparentColorMode.Clear,
    NearLossless = false,
    NearLosslessQuality = 0,
    FileFormat = WebpFileFormatType.Lossy,
    EntropyPasses = 10,
});

I'm using SixLabors.ImageSharp 3.1.3.

[Nicholas-Westby]

This code seems to work around the issue:

using var imageData = Image.Load<Rgb24>(originalPath);
var width = imageData.Width;
var height = imageData.Height;
var pixels = new Rgb24[width * height];
imageData.CopyPixelDataTo(pixels);
using var newImage = Image.LoadPixelData<Rgb24>(pixels, width, height);
newImage.SaveAsWebp(newPath, new WebpEncoder
{
    SkipMetadata = true,
    Quality = 60,
    Method = WebpEncodingMethod.Level6,
    UseAlphaCompression = false,
    TransparentColorMode = WebpTransparentColorMode.Clear,
    NearLossless = false,
    NearLosslessQuality = 0,
    FileFormat = WebpFileFormatType.Lossy,
    EntropyPasses = 10,
});

I'm just loading up a pixel buffer and then storing that as an image. I figured this way it won't keep whatever cruft is being carried along with the original image otherwise.

Still curious why the SaveAsWebp method was making large files when using a JPEG as the source rather than a pixel buffer.

[brianpopow]

There is a very large color profile embedded in the image:

webpinfo shows this:

RIFF HEADER:
  File size: 565678
Chunk VP8X at offset     12, length     18
  ICCP: 1
  Alpha: 0
  EXIF: 0
  XMP: 0
  Animation: 0
  Canvas size 140 x 212
Chunk ICCP at offset     30, length 557176
Chunk VP8  at offset 557206, length   8472
  Width: 140
  Height: 212
  Alpha: 0
  Animation: 0
  Format: Lossy (1)
No error detected.

Note the Chunk ICCP at offset 30, length 557176

[Nicholas-Westby]

Mystery solved! Thanks for the keen insight, @brianpopow!