Support » Alpha/Beta/RC » WebP very large filesize [5.8 RC2]

  • Testing the new WebP functionality.

    While the uploading works, and various sizes are created. They are very large. Much larger than their jpg counterparts, even as i have the jpg quality set to 90%. After uploading the same image in both JPG and WebP format, this is what i got:

    WebP @ 2400px: 1.63MB (original)
    WebP @ 2048px: FAIL
    WebP @ 1536px: 1.97MB
    WebP @ 1240px: 1.33MB
    WebP @ 800px: 609kb
    WebP @ 300px: 97kb

    The largest 2048px image likely fails because it was to be over 2MB.

    JPG-95 @ 2400px: 1.65MB (original)
    JPG-90 @ 2048px: 1.11MB
    JPG-90 @ 1536px: 681MB
    JPG-90 @ 1240px: 462MB
    JPG-90 @ 800px: 211kb
    JPG-90 @ 300px: 41.5kb

    A script was used in Snippets to set the JPG quality, but i also tried uploading the WebP with it turned off and it made no difference.

    Any way to tweak WebP’s quality settings?

Viewing 15 replies - 1 through 15 (of 15 total)
  • Thread Starter mmxxi

    (@mmxxi)

    There is an article about it after all:

    WordPress 5.8 adds WebP support

    After using the example as shown (while increasing 75 to 90):

    // Use a quality setting of ## for WebP images.
    function filter_webp_quality( $quality, $mime_type ) {
      if ( 'image/webp' === $mime_type ) {
         return 90;
      }
      return $quality;
    }
    add_filter( 'wp_editor_set_quality', 'filter_webp_quality', 10, 2 );

    The results are the same, except now it also managed to create:

    WebP @ 2048px: 3.31MB
    WebP @ 1568px: 2.04MB

    So it very much seems to ignore any compression setting.

    According to this article, there is a way to tweak WebP’s quality settings, but it doesn’t seem to help with the problem you’ve discovered.

    I noticed the same thing. I uploaded a 1240 x 682 WebP image that is 76.4 KB, created locally by using Imagemagick from a JPEG using a quality setting of 50.

    Without touching WP’s WebP settings the filesizes after upload are:

    test-150×75.webp 17.7 KB
    test-300×150.webp 57.7 KB
    test-768×385.webp 293.3 KB
    test-800×401.webp 313.3 KB
    test.webp 76.4 KB

    The smaller-dimension images created by WP are larger in size than the original. Just out of curiosity, I added the following to my functions.php to alter the quality from the default to 50:

    
    // Use a quality setting of 50 for WebP images.
    function filter_webp_quality( $quality, $mime_type) {
        if ('image/webp' === $mime_type) {
            return 50;
        }
        return $quality;
    }
    

    After that, I re-uploaded the same file and got the same file sizes as before.

    I verified that I have ImageMagick/Imagick installed on my server:

    
    ### wp-media ###
    
    image_editor: WP_Image_Editor_Imagick
    imagick_module_version: 1692
    imagemagick_version: ImageMagick 6.9.12-17 Q16 x86_64 2021-06-25 https://imagemagick.org
    imagick_version: 3.5.0
    file_uploads: File uploads is turned off
    post_max_size: 8M
    upload_max_filesize: 8M
    max_effective_size: 8 MB
    max_file_uploads: 20
    imagick_limits: 
    	imagick::RESOURCETYPE_AREA: 62 GB
    	imagick::RESOURCETYPE_DISK: 9.2233720368548E+18
    	imagick::RESOURCETYPE_FILE: 768
    	imagick::RESOURCETYPE_MAP: 62 GB
    	imagick::RESOURCETYPE_MEMORY: 31 GB
    	imagick::RESOURCETYPE_THREAD: 1
    imagemagick_file_formats: 3FR, 3G2, 3GP, AAI, AI, APNG, ART, ARW, AVI, AVS, BGR, BGRA, BGRO, BIE, BMP, BMP2, BMP3, BRF, CAL, CALS, CANVAS, CAPTION, CIN, CIP, CLIP, CMYK, CMYKA, CR2, CR3, CRW, CUR, CUT, DATA, DCM, DCR, DCX, DDS, DFONT, DNG, DOT, DPX, DXT1, DXT5, EPDF, EPI, EPS, EPS2, EPS3, EPSF, EPSI, EPT, EPT2, EPT3, ERF, EXR, FAX, FILE, FITS, FRACTAL, FTP, FTS, G3, G4, GIF, GIF87, GRADIENT, GRAY, GRAYA, GROUP4, GV, H, HALD, HDR, HISTOGRAM, HRZ, HTM, HTML, HTTP, HTTPS, ICB, ICO, ICON, IIQ, INFO, INLINE, IPL, ISOBRL, ISOBRL6, J2C, J2K, JBG, JBIG, JNG, JNX, JP2, JPC, JPE, JPEG, JPG, JPM, JPS, JPT, JSON, K25, KDC, LABEL, M2V, M4V, MAC, MAGICK, MAP, MASK, MAT, MATTE, MEF, MIFF, MKV, MNG, MONO, MOV, MP4, MPC, MPG, MRW, MSL, MSVG, MTV, MVG, NEF, NRW, NULL, ORF, OTB, OTF, PAL, PALM, PAM, PANGO, PATTERN, PBM, PCD, PCDS, PCL, PCT, PCX, PDB, PDF, PDFA, PEF, PES, PFA, PFB, PFM, PGM, PGX, PICON, PICT, PIX, PJPEG, PLASMA, PNG, PNG00, PNG24, PNG32, PNG48, PNG64, PNG8, PNM, POCKETMOD, PPM, PREVIEW, PS, PS2, PS3, PSB, PSD, PTIF, PWP, RADIAL-GRADIENT, RAF, RAS, RAW, RGB, RGBA, RGBO, RGF, RLA, RLE, RMF, RW2, SCR, SCT, SFW, SGI, SHTML, SIX, SIXEL, SPARSE-COLOR, SR2, SRF, STEGANO, SUN, SVG, SVGZ, TEXT, TGA, THUMBNAIL, TIFF, TIFF64, TILE, TIM, TTC, TTF, TXT, UBRL, UBRL6, UIL, UYVY, VDA, VICAR, VID, VIDEO, VIFF, VIPS, VST, WBMP, WEBM, WEBP, WMF, WMV, WMZ, WPG, X, X3F, XBM, XC, XCF, XPM, XPS, XV, XWD, YCbCr, YCbCrA, YUV
    gd_version: 2.3.2
    gd_formats: GIF, JPEG, PNG, WebP, BMP, XPM
    ghostscript_version: unknown
    

    I’m not sure what the issue is with the large files.

    Thread Starter mmxxi

    (@mmxxi)

    Seems like it is either defaulting to 100% quality or even lossless compression.

    For reference in Site Health > Info > Media Handling i find:

    Active editor	WP_Image_Editor_Imagick
    ImageMagick version number	1802
    ImageMagick version string	ImageMagick 7.0.10-10 Q16 x86_64 2020-07-09 https://imagemagick.org
    Imagick version	3.4.4
    File uploads	Enabled
    Max size of post data allowed	8M
    Max size of an uploaded file	2M
    Max effective file size	2 MB
    Max number of files allowed	20
    Imagick Resource Limits	
    area: 377 GB
    disk: 9.2233720368548E+18
    file: 491520
    map: 377 GB
    memory: 189 GB
    thread: 1
    ImageMagick supported file formats	WEBP [..many more]
    GD version	2.2.5
    GD supported file formats	GIF, JPEG, PNG, WebP, BMP, XPM
    Ghostscript version	9.25
    linux4me2

    (@linux4me2)

    I’m wondering if the large images that are generated are due to our server environments? Surely, the WP developers would have noticed if they were creating smaller-dimension images that are four times the file size of the originals?

    I downloaded the WebP images created by my test, and they do show they are of the type “image/webp”.

    I SSH’d into an account on my server and ran the Imagick “identify” command to see what I’d find, and it doesn’t show WebP capability:

    
    $ identify -version
    Version: ImageMagick 6.9.10-68 Q16 x86_64 2021-02-24 https://imagemagick.org
    Copyright: © 1999-2019 ImageMagick Studio LLC
    License: https://imagemagick.org/script/license.php
    Features: Cipher DPC Modules OpenMP(3.1) 
    Delegates (built-in): bzlib cairo fontconfig freetype gslib jng jp2 jpeg lcms ltdl lzma openexr pangocairo png ps rsvg tiff wmf x xml zlib
    

    Next, I set up a test script to output the PHP Imagick formats supported on my test site using the example here.

    The table it output does not list WebP under the supported PHP Imagick formats, so that tells me that WP’s report that my server supports WebP via Imagick is probably incorrect.

    I uploaded a test JPEG file to the server to try conversion to WebP via the command line with Imagick’s convert command, and I found something interesting that may be part of the problem. When I ran the convert command, I got the following error:

    
    convert: delegate failed 'cwebp' -quiet %Q '%i' -o '%o' @ error/delegate.c/InvokeDelegate/1928.
    

    That makes it look like Imagick’s convert command is using CWebP to do WebP conversions, and CWebP’s command structure is different than Imagick. I wonder if I removed CWebP (libwebp) from the server, if it would fix the issue with the large file sizes WP creates with WebP, and/or no longer list WebP as a compatible format for Imagick?

    Do you happen to have libwebp installed on your server?

    linux4me2

    (@linux4me2)

    It turns out that libwebp is a red herring. It’s installed as a dependency for a number of necessary packages on my system. Cwebp is part of libwebp-tools for me, which is not installed, and I think only relevant for the command line. I also checked on an account running PHP 8.0 via phpinfo() that WebP is supported in PHP, and tested again with WP 5.8, but I still got the large file sizes for the images it creates.

    Can see this too. When uploading a lossy WebP image the scaled down images are much larger than the original. Looks like they are saved as lossless. In my case a 2.5 MB 3000 x 2000 WebP image resulted in a 5.9 MB 2560 x 1707 image.

    Opened https://core.trac.wporg.ibadboy.net/ticket/53653 for this. Please keep an eye on it and test any PRs or patches if possible.

    • This reply was modified 4 months ago by Andrew Ozz.
    Thread Starter mmxxi

    (@mmxxi)

    Good work guys. No change yet in RC3.

    IrfanView indeed shows the converted images as being true WebP (lossless).

    So that’s actually some pretty decent compression considering. 😉

    Adam Silverstein

    (@adamsilverstein)

    Hey @mmxxi – thanks for reporting this.

    What tool did you use to create the original WebP image you uploaded to WordPress?

    Thread Starter mmxxi

    (@mmxxi)

    @adamsilverstein

    Most likely it was XnViewMP (on windows), but i could try something else.

    Quality 90
    Method 6
    Filter 0
    Sharpness 0
    Keep Metadata
    • This reply was modified 4 months ago by mmxxi.

    Thanks @mmxxi, @linux4me2, @adamsilverstein. The fix is now committed to trunk. Please test/confirm it if you can. Expecting it’s going to be merged to the 5.8 branch (added to WP 5.8) before RC4 tomorrow.

    Thread Starter mmxxi

    (@mmxxi)

    @azaozz @adamsilverstein @linux4me2

    Compression now works in RC4-51447, however the scaling algorithm is quite dirty. While i have the quality set to 90, the image ends up softer than it should be.

    When using something like IrfanView or XnViewMP, even selecting the ‘worst’ scaling algorithm produces a much more refined result.

    Any idea if it can be tweaked beyond the quality setting?

    Edit: Seems it’s more than just scaling. There’s just a lot less detail in general even compared to the jpg versions created through WordPress. Which was already not very good compared to using a third party program.

    • This reply was modified 4 months ago by mmxxi.
    linux4me2

    (@linux4me2)

    I also tested with 5.8-RC4, and the compression at default settings is now much better; I got the following with a 76.4 KB, 1280 x 642 pixel, original WebP image:

    800×401.webp 51.0 KB
    768×385.webp 48.2 KB
    300×150.webp 10.9 KB
    150×75.webp 4.2 KB

    However, if I attempt to change the quality to 50%:

    
    function filter_webp_quality($quality, $mime_type) {
        if ('image/webp' === $mime_type) {
            return 50;
        }
        return $quality;
    }
    add_filter('wp_editor_set_quality', 'filter_webp_quality', 10, 2);
    

    I’m still getting the same file sizes, so it looks like it’s not possible to set the quality in my child theme’s functions.php with that code snippet.

    Thread Starter mmxxi

    (@mmxxi)

    I tested 60%, and they definitely came out smaller than at 90.

    Simply dropped the script in the Code Snippets plugin, no child themes.
    Snippet set to ‘run everywhere’.

    • This reply was modified 4 months ago by mmxxi.
    linux4me2

    (@linux4me2)

    I switched themes to a child theme of Twenty Twenty, and the snippet worked, so I think that particular problem was at my end.

    We describe two types of evaluations. In the first case, we study the additional compression achieved by WebP at the same quality level of JPEG. In particular, we generate WebP images of same quality (as per SSIM index) as the JPEG images and then compare the file sizes of WebP and JPEG images. In the second case, we analyze SSIM vs bits per pixel (bpp) plots for WebP and JPEG. These plots show the rate-distortion trade off for WebP and JPEG.

    Online click counter assists you to count several things like the number of sit-ups while performing an exercise or also much other stuff. You can do all just by clicking on a mouse or a button of mobile phones.

Viewing 15 replies - 1 through 15 (of 15 total)
  • You must be logged in to reply to this topic.