How the filesize can increase to more than double?
ImageMagick version
6.9.11-60
Operating system
Linux
Operating system, version and so on
Debian GNU/Linux 12
Description
ich have this convert command:
convert originalImage.jpg -resize 1500x1000! -crop 1000x1000+250+0 +repage -quality 100 WEBP:convertedImage.webp
originalImage.jpg: 1440x960 | size 287.64kb convertedImage.webp: 1000x1000 | size 765.17kb
Here's the problem/question: how can the filesize increase that way? I know, we have quality=100% but i can't believe this is the only cause. Besides, in my case, lower quality is not an option.
When i convert with gd instead of imagemagick, this doesn't happen at all. Therefore i thought, maybe it's the metadata. But when i convert with the flag: webp:metadata=none --- there's no difference
I would appreciate any helping thoughts
Steps to Reproduce
see description
Images
Here's the problem/question: how can the filesize increase that way? I know, we have quality=100% but i can't believe this is the only cause.
Your input image is a JPEG, and pixel colours have probably been changed to suit the JPEG compression algorithm (lossy compression). You then take those pixels and write them to WEBP, without loss. Webp lossless compression is different to jpeg lossy compression. It is not surprising that this takes more bytes. Lossless compression generally takes more space than lossy compression.
When i convert with gd instead of imagemagick, this doesn't happen at all.
Is the gd result identical to your input JPEG? What size is it?
But when i convert with the flag: webp:metadata=none --- there's no difference
Where did you get that flag from? It isn't documented on https://imagemagick.org/script/webp.php , or in the code at coders/webp.c.
To remove loads of metadata that you may not need, about 11000 bytes, use -strip".
Hi, thanks for the quick response, here my answers:
Your input image is a JPEG, and pixel colours have probably been changed to suit the JPEG compression algorithm (lossy compression). You then take those pixels and write them to WEBP, without loss. Webp lossless compression is different to jpeg lossy compression. It is not surprising that this takes more bytes. Lossless compression generally takes more space than lossy compression.
Whats the difference between lower quality and, for instance, the flag "webp:lossless=false"? Is the latter one an option, if lower quality is not an option?
Is the gd result identical to your input JPEG? What size is it?
No, its lower: for the given image its 132.03kb (2400x1200)
Where did you get that flag from? It isn't documented on https://imagemagick.org/script/webp.php , or in the code at coders/webp.c.
Sorry, i found that somewhere, nevermind
To remove loads of metadata that you may not need, about 11000 bytes, use -strip".
Tryed it, but there's no significant difference
Whats the difference between lower quality and, for instance, the flag "webp:lossless=false"?
You can use -quality lower than 100, or the webp:lossless define, or both. If you are happy with lossy images, I suggest you experiment to determine your own requirements. For example:
D:\temp>%IMG71138%magick cyclists.jpg -quality 100 -define webp:lossless=false x.webp && dir x.webp
25/03/2025 17:59 333,652 x.webp
D:\temp>%IMG71138%magick compare -metric RMSE cyclists.jpg x.webp NULL:
436.471 (0.00666012)
My rule of thumb for ordinary photos is that an RMSE difference of 1% (0.01) or less, if evenly distributed, is not visible to me.
However, when experimenting, I suggest using a source image that has not undergone JPEG or other lossy compression.
I don't have "gd", or even know what it is. I asked if its output was identical to the input image. For example, what is the text output from:
magick compare -metric RMSE cyclists.jpg from_gd.webp NULL:
For me, -strip removes about 11000 bytes. I don't know why it doesn't for you.
D:\temp>%IMG71138%magick cyclists.jpg x.webp && dir x.webp
25/03/2025 17:49 172,768 x.webp
D:\temp>%IMG71138%magick cyclists.jpg -strip x.webp && dir x.webp
25/03/2025 17:49 161,034 x.webp
For me, -strip removes about 11000 bytes. I don't know why it doesn't for you.
Yes it strips also for me, but 11kb is not worth mentioning when the image size increases this much (anyways, we need the metadata, therefore this isn't an option) -- sorry for the confusion.
However, when experimenting, I suggest using a source image that has not undergone JPEG or other lossy compression.
I'm not sure, but do you advise to not use jpg images? What's the alternative?