Stefanowitsch Posted May 19 Share Posted May 19 25 minutes ago, nbcommunication said: Hi @Stefanowitsch, PageimageSource:srcset() doesn't directly do any evaluation of the file sizes to decide what to return, it is just calling Pageimage::url() if webP is off, and Pageimage::webpUrl if it is on. When I test I'm getting all JPEG if off, and all webP if on. I don't use named size variations myself, quite possible that this is where the issue lies, and I need to implement something additional to handle these. What's the value of $imgFormat? Cheers, Chris @nbcommunication Thanks for the hint. I think there indeed lies my problem. Let me try to explain: I am using the size method to crop images to use the aspect ratio / format that I need for my layout (for example a hero slider uses a 16:9 image ratio). The $imgFormat value in that case would look like this: 'title-img' => [ 'width' => 2550, 'height' => 1440 ] <?php echo $image->size('title-img')->srcset() ?> So then the PageImage module takes this image to create variations based on the set rules in my module settings: 640 1024 1500 1920 2550 So there exists a 2550px version of the image (created by the size method) but I have to include this width in the size set rules, otherwise only the image variations up to 1920px will be used in the srcset attribute in the DOM. And this might be the problem: When adding the 2550px rule the cropped 2550px wide jpg image is used int the srcset attribute and not the wepb version (all other image sizes use the webp version, they just weren't created yet - instead queued - when I testet it lately). So to make it finally work for my case I have to crop the image larger than used in the srcset. For example 3000px wide. In that case the 2550px webp version is generated and used correctly together will the other sizes from the set rules in webp format. Link to comment Share on other sites More sharing options...
Stefanowitsch Posted May 20 Share Posted May 20 @nbcommunication Hello! It's me once again. After excessive testing I found out that the modules webp quality settings were never applied to generated webp iages when outputting the srcset like this: <img srcset="<?php echo $image->size($imgFormat)->srcset ?>" ... The webp versions that were created always used a quality setting of 90%, no matter what I entered as value in the module settings. The solution: I had to place this line in my config.php to kind of "override" the default webOptions of ProcessWire: $config->webpOptions = array(); By the way the default options are set to this: 'quality' => 90 'useSrcExt' => false 'useSrcUrlOnSize' => true 'useSrcUrlOnFail' => true Only then (when the 'quality' option is missing) the entered value from the module settings is applied correctly. I did not test this with the $image->render method, though. Can you confirm if this is the intended behaviour? 1 Link to comment Share on other sites More sharing options...
nbcommunication Posted May 21 Author Share Posted May 21 Hi @Stefanowitsch, I've tested based on the information you've provided and it isn't replicating: <?php // /site/config.php $config->imageSizes = [ 'title-img' => [ 'width' => 2550, 'height' => 1440 ] ]; // output, original pageimage is > 3000px wide echo print_r(explode(', ', $pageimage->size('title-img')->srcset([ 640, 1024, 1500, 1920, 2550, ])), 1); // result Array ( [0] => /site/assets/files/1031/very_large_array_clouds.640x361-srcset.webp 640w [1] => /site/assets/files/1031/very_large_array_clouds.1024x578-srcset.webp 1024w [2] => /site/assets/files/1031/very_large_array_clouds.1500x847-srcset.webp 1500w [3] => /site/assets/files/1031/very_large_array_clouds.1920x1084-srcset.webp 1920w [4] => /site/assets/files/1031/very_large_array_clouds.2550x1440.2550x1440-srcset.webp 2550w ) With module config webpQuality setting at 85 With module config setting at 10 With module config empty (defaults to 90 - there was a bug here, fix to be pushed shortly) The quality setting in the module config is definitely being used in this case. Reviewing the above, I'm quite surprised at the difference in file size between 85 and 90. There has to be something else going on here, maybe the image sizer engine (Imagick used here but that about as far as my knowledge goes on these things). Do you have access to any other server environments to try to replicate the test on? I've run this on a dev server and a production server which have different setups with the same result on both. Cheers, Chris 1 Link to comment Share on other sites More sharing options...
Stefanowitsch Posted May 21 Share Posted May 21 @nbcommunication thanks for testing it out! I tried to replicate the steps you took but my results are still the same. First, outputting the srcset array gives this: array 0 => '/site/assets/files/1651/startbild_architektur.640x361-srcset.jpg 640w' 1 => '/site/assets/files/1651/startbild_architektur.1024x578-srcset.webp 1024w' 2 => '/site/assets/files/1651/startbild_architektur.1500x847-srcset.webp 1500w' 3 => '/site/assets/files/1651/startbild_architektur.1920x1084-srcset.webp 1920w' 4 => '/site/assets/files/1651/startbild_architektur.2550x1440.2550x1440-srcset.jpg 2550w' Note: The webp images are not created in the first place, only after reloading the page they get generated from the -srcset.jpg versions (depending on the current screensize, thats why the array is mixed with jpg and webp images). What I still don't understand is that for the largest image variant - 2500px in width - the webp image variant gets created in the file system but is never ever used in the srcset attribute. I extended my browser window width on > 1920 to make sure it will be loaded. In my case the max size for an image variant hast to be lower than the size given in the config. Only then it will be used in the srcset. That's why I am using 2500px instead of 2550px for the srcset in the module settings. $config->imageSizes = [ 'title-img' => [ 'width' => 2550, 'height' => 1440 ] ]; I entered a webp quality setting of "1" in the module settings but this setting is not applied. All webp variants were created at 90% quality based on the filesize. This behaviour is the same on all of my local DDEV projects and on the live servers. I don't use Imagick though, it's the standard GD engine instead. Link to comment Share on other sites More sharing options...
nbcommunication Posted May 21 Author Share Posted May 21 Hi @Stefanowitsch, I've tested using gd and it is working as expected for me. Could you output phpinfo() and let me know what it says for gd? Here's what's on our dev server: Quote gd GD Support enabled GD headers Version 2.3.3 GD library Version 2.3.3 FreeType Support enabled FreeType Linkage with freetype GIF Read Support enabled GIF Create Support enabled JPEG Support enabled PNG Support enabled WBMP Support enabled XPM Support enabled XBM Support enabled WebP Support enabled BMP Support enabled AVIF Support enabled TGA Read Support enabled Cheers, Chris 1 Link to comment Share on other sites More sharing options...
nbcommunication Posted May 21 Author Share Posted May 21 Hi @Stefanowitsch, Something else that would be worth trying, output this somewhere: <?php echo implode('<br>', [ $pageimage->size(2550, 1440, [ 'webpQuality' => 10, 'webpAdd' => true, 'webpOnly' => true, 'suffix' => 'q10', ])->webp()->filesizeStr, $pageimage->size(2550, 1440, [ 'webpQuality' => 80, 'webpAdd' => true, 'webpOnly' => true, 'suffix' => 'q80', ])->webp()->filesizeStr, ]); Cheers, Chris Link to comment Share on other sites More sharing options...
Stefanowitsch Posted May 21 Share Posted May 21 10 minutes ago, nbcommunication said: Hi @Stefanowitsch, Something else that would be worth trying, output this somewhere: <?php echo implode('<br>', [ $pageimage->size(2550, 1440, [ 'webpQuality' => 10, 'webpAdd' => true, 'webpOnly' => true, 'suffix' => 'q10', ])->webp()->filesizeStr, $pageimage->size(2550, 1440, [ 'webpQuality' => 80, 'webpAdd' => true, 'webpOnly' => true, 'suffix' => 'q80', ])->webp()->filesizeStr, ]); Cheers, Chris The output of both is: "0 Bytes" I then tried this: <img src="<?php echo $image->size(2550, 1440, [ 'webpQuality' => 10, 'webpAdd' => true, 'webpOnly' => true, 'suffix' => 'q10', ])->webp->url; ?>" /> Which results in in a "502 Bad Gateway" error (for the jpg image file path), because the img src in the DOM refers to the "jpg" version: <img src="/site/assets/files/1651/startbild_architektur.2550x1440-q10.jpg" width="2550" height="1440" sizes="auto" alt="" uk-cover=""> The jpg version however is not created (probably because webpOnly is 'true'). The webp version is created in the filesystem (and the quality setting is working!) but this webp version is not used in the src attribute. Link to comment Share on other sites More sharing options...
nbcommunication Posted May 21 Author Share Posted May 21 Hi @Stefanowitsch, Thanks, could you please try the filesizeStr test with the attached image? Using this and gd I get 7.3 kB and 26.8 kB. EDIT: that's using 1000, 500 for the width and height. Cheers, Chris Link to comment Share on other sites More sharing options...
Stefanowitsch Posted May 21 Share Posted May 21 @nbcommunication I found my problem. 🥵 It wasn't your module at all but instead another module that I was using which interfered with the webp image creation for the srcset attributes: Delayed Image Variations I was using this Module because the image variant generation on image-heavy sites (using the size method) took very long and resulting in time out errors of the server. As described in the module thread: Quote Normally when you create new image variations in a template file using any of the ProcessWire image resizing methods, all the new variations that are needed on a page will be created from the original Pageimage the next time the page is loaded in a browser. If there are a lot of images on the page then this could take a while, and in some cases the page rendering might exceed your max_execution_time setting for PHP. After uninstalling the module all the paths in the srcset attribute point towards the webp versions of the image and also the quality settings are applied as set in the module settings page! I am sorry for causing so much work for your tests! 😔 2 Link to comment Share on other sites More sharing options...
nbcommunication Posted May 21 Author Share Posted May 21 Hi @Stefanowitsch, That's great, delighted to hear that! This is been a really useful exercise, I've pushed three bug fixes for the module so I'm happy 🙂 I'll update the README with a note that the module isn't compatible with DelayedImageVariations, and if I ever get around to it will try and figure out what the compatibility issue is. It isn't something I've used before. Cheers, Chris 4 Link to comment Share on other sites More sharing options...
HMCB Posted May 21 Share Posted May 21 I’ve been following this ping pong match for a few days. 😁. Gotta say, I loved it and @nbcommunication, you are awesome. Great developer. Thank you for your contributions to the PW community. 4 Link to comment Share on other sites More sharing options...
Stefanowitsch Posted May 22 Share Posted May 22 14 hours ago, HMCB said: I’ve been following this ping pong match for a few days. 😁. Gotta say, I loved it and @nbcommunication, you are awesome. Great developer. Thank you for your contributions to the PW community. I can't help but agree! 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now