PageimageSource

[Stefanowitsch]

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.

[Stefanowitsch]

@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?

[nbcommunication]

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

[Stefanowitsch]

@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.

[nbcommunication]

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

[nbcommunication]

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

[Stefanowitsch]

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.

[nbcommunication]

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

[Stefanowitsch]

@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! 😔

[nbcommunication]

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

[HMCB]

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.

[Stefanowitsch]

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!