You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For WebP images saved in lossless mode (whether a WebP image was saved in lossless mode can be checked using the webpinfo command), ImageOptim should attempt to recompress them using cwebp -z <level>, and replace the source file if the resulting file is smaller.
This also strips the metadata attached to the image, like other lossless PNG/GIF/JPEG optimizers do.
Based on experience, many lossless WebP images in the wild are not compressed using the highest lossless compression level, so it is not surprising for lossless re-compression of losslessly-compressed WebP images to yield a 5-10% drop in file size, obviously without loss in image quality. While it's true that there's only one single WebP encoder in existence, it is also true that the highest compression level (9) is not the default (as the default is 6).
I know that WebP support has been requested before but the reasons provided for rejection do not really hold up to scrutiny, as the points made above should hopefully clarify.
While it's true that there are newer image formats that can perform better, it is also true that WebP is still going to be needed in a number of contexts for the foreseeable future (e.g. Android apps with wide Android SDK compatibility, non-modern browsers, etc.)
The text was updated successfully, but these errors were encountered:
For WebP images saved in lossless mode (whether a WebP image was saved in lossless mode can be checked using the
webpinfo
command), ImageOptim should attempt to recompress them usingcwebp -z <level>
, and replace the source file if the resulting file is smaller.This also strips the metadata attached to the image, like other lossless PNG/GIF/JPEG optimizers do.
Based on experience, many lossless WebP images in the wild are not compressed using the highest lossless compression level, so it is not surprising for lossless re-compression of losslessly-compressed WebP images to yield a 5-10% drop in file size, obviously without loss in image quality. While it's true that there's only one single WebP encoder in existence, it is also true that the highest compression level (9) is not the default (as the default is 6).
I know that WebP support has been requested before but the reasons provided for rejection do not really hold up to scrutiny, as the points made above should hopefully clarify.
While it's true that there are newer image formats that can perform better, it is also true that WebP is still going to be needed in a number of contexts for the foreseeable future (e.g. Android apps with wide Android SDK compatibility, non-modern browsers, etc.)
The text was updated successfully, but these errors were encountered: