CroppableImage with WebP support

[Didjee]

Thanks Horst, that works! I need different sizes of the same crop to use in srcset for responsive images.

Quote

I don't understand this. Cannot find the post you mentioned also I'm not aware of resizing issues in general? All versions of CAI, (CAI2, CAI3, CAI4) have created resized variations. ??

I referred to this in your opening post: 

On 3/18/2020 at 5:40 PM, horst said:

C) You can use every known options param. Width, Height, Size is ignored! If you also want create WebPs in one go, please add "webpAdd" => true to the options array, (or webpAdd=1 to the options selector string)!

 

[horst]

@Didjee Ah, now I see. My bad. The part C) explains how to (optionally) pass individual options for the rezising. And in the github readme the second param is described wrong. Its an obsolete function from the CAI3 for creating intermediate AND final images in one go, (what seemed nobody really has understand or used this). Now with CAI4 it behaves more like the core image field. But instead of passing the size|width|height as first argument, you pass the crop name. The second argument can be an individual options array (or for your convenience, a selectorstring representing the individual options). The irritation comes from the old readme. I need to update it to CAI4 changes! Sorry!

[Didjee]

@horst I use the code below in my template to generate different sizes of a cropped image:

<source type="image/webp" srcset="<?= $page->image->getCrop("default")->width(450)->webp->url; ?> 1x, <?= $page->image->getCrop("default")->width(900)->webp->url; ?> 2x">
<source type="image/jpeg" srcset="<?= $page->image->getCrop("default")->width(450)->url; ?> 1x, <?= $page->image->getCrop("default")->width(900)->url; ?> 2x">

After I re-crop the image in the backend the variations of the jpeg version are regenerated, but the variations of the webp version are not regenerated/showed in the frontend.

Is there a way to overwrite the webp variants after the image is re-cropped?

Deleting all variations in the backend before re-cropping the image doesn't solve this issue. See also this post (not related to CroppableImage)

 

[horst]

@Didjee I think this must be an issue with the core. But I'm not able to investigate further ATM.

Maybe there is a possible workaround, or at least some (micro) optimization, with your code example, leaving out the subfile class(es) from the chain.

If you have enabled the $config->webpOptions['useSrcExt'], you can globally enable the creation of webP variations in the base core image engines, directly when creating any jpeg or png variation, by setting $config->imageSizerOptions['webpAdd'] to true. But this can result into a lot of unwanted webP files from intermediate image variations (that are never shown to the front end, but only are variation steps in the building chain)! Therefore better globally leave this setting to false, but pass an individual options array into any image sizer method where appropriate (width(123, $options), height(123, $options), size(123, 456, $options)) with this enabled.

Example:

<?php
	// this create a jpeg AND a webp varition with 900px for the 2x parts
	$imageX2 = $page->image->getCrop('default')->width(900, ['webpAdd' => true]);

	// this reduces the 2x variation to the half size for 1x, (jpeg AND webp at once)
	$imageX1 = $imageX2->width(450, ['webpAdd' => true]);
	
	// now, as you have set $config->webpOptions['useSrcExt'] to true, 
	// every webp variation simply has to get a trailing ".webp" to the jpeg URL:
?>
<source type="image/webp" srcset="<?= $imageX1->url . '.webp' ?> 1x, <?= $imageX2->url . '.webp' ?> 2x">
<source type="image/jpeg" srcset="<?= $imageX1->url ?> 1x, <?= $imageX2->url; ?> 2x">

Given that the issue you encountered  is located in the files / images sub module for webp, the auto refresh now should be working, as you use the older, (but clumpsy) method in the base imagesizer engine.

Have not tested this for quite a few (master)versions, but hopefully it is still true.  ?

PS: De hartelijke groeten aan de naburige stad! ?

[Didjee]

Hi @horst, thanks for your code example, but unfortunately it still doesn't work as expected. See the attached screenshots below, both of the overview of generated variations in the backend. I made an 'extreme' cropping to show the difference with the original image.

1) The image variations before loading the template with your example code in frontend.
I marked the cropped variation with a red border:

2) The image variations after loading the template with your example code in frontend.
I marked the frontend-generated 900 pixel width variants with a red border. The JPG version is OK, but the WEBP version is not ?

Groeten terug uit Maastricht! ??

[horst]

Hi @Didjee, unfortunately you are right. My old code no longer works. ?

I have dived into the issue and filed a github issue with a possible fix. So hopefully Ryan soon will find time to look at it. ?

If you like, as a workaround you can place my new suggestion into the file wire/core/Pageimage.php instead of using the current webp() function there.

	/**
	 * Get WebP "extra" version of this Pageimage
	 *
	 * @return PagefileExtra
	 * @since 3.0.132
	 *
	 */
	public function webp() {
		$webp = $this->extras('webp');
		if(!$webp) {
			$webp = new PagefileExtra($this, 'webp');
			$webp->setArray($this->wire('config')->webpOptions);
			$this->extras('webp', $webp);
			$webp->addHookAfter('create', $this, 'hookWebpCreate'); 
		}

		// recognize changes of JPEG / PNG variation via timestamp comparison
		if($webp && 
			is_readable($webp->filename()) &&
			filemtime($webp->filename()) < filemtime($this->filename)
		) {
			$webp->create();
		}

		return $webp;
	}

 

[Didjee]

@horst Your adjustment of the webp() function fixes the issue! Thanks for diving into this!

[rash]

Hi @horst,

I’ve installed CroppableImage 4 additionally to 3 and everything works fine, except clicking on thumbnails in the image field. The modal window opens and says 'ProcessWire: Unrecognized path' followed by something like 'process didn’t deliver any content' (exactly: 'Der Prozess hat keinen Inhalt ausgegeben'). This happens in fields with CI3 as well as with CI4.  The URL is looking good so far: /page/croppable-image-4/?filename=file-XY.jpg&suffix=square&width=420&height=420&pages_id=1781&field=imgs&modal=1. Before installing CI4 this didn't happen. PW is version 3.0.184.

Edit: Meanwhile I deinstalled both versions and reinstalled V3, that is working as before now. I might wait with V4 until it’s "officially" released.

[ceberlin]

I run into a problem when removing a cropppable element from the image setting:

hauptbild,900,600
quadrat,900,900

Expected: The info for the "quadrat" cuts are removed. No change for anything related to "hauptbild"

What happens (latest PW dev and module 4 version, using WebP):

All crop settings are lost, including "hauptbild". And the default value is not a largest possible crop from the middle (so a 1800x1200 source would produce a proportional small version without crops). Instead a 900x600 upper-left crop from the original image gets cropped. Basically, this means all fine-tuned settings are lost, and the default worsens it.

[horst]

7 hours ago, ceberlin said:

All crop settings are lost, including "hauptbild". And the default value is not a largest possible crop from the middle (so a 1800x1200 source would produce a proportional small version without crops). Instead a 900x600 upper-left crop from the original image gets cropped. Basically, this means all fine-tuned settings are lost, and the default worsens it.

Hi @ceberlin, can we go PM or phone tomorrow or this evening?

[thausmann]

Just want to drop a line that I used CroppableImage 4 on a new project and ran into no problems so far. 

Okay, the issue Didjee mentioned persists, I just didn't run into it during dev phase. I applied your fix. 

[horst]

On 3/30/2022 at 3:47 PM, thausmann said:

Just want to drop a line that I used CroppableImage 4 on a new project and ran into no problems so far. 

Okay, the issue Didjee mentioned persists, I just didn't run into it during dev phase. I applied your fix. 

 

On 12/30/2021 at 9:38 AM, Didjee said:

@horst Your adjustment of the webp() function fixes the issue! Thanks for diving into this!

 

Hi, good news: Ryan has fixed this with a commit today. So if you are able, you should switch to the dev version from today. (And do no longer use my workaround! It adds to much overhead.)

https://github.com/processwire/processwire-issues/issues/1497#issuecomment-1106543260

https://github.com/processwire/processwire/commit/6fcd7a70389450631932aa0fd4a0a703d3ac8804

 

[Didjee]

Hi @horst, I have a setup where I use a Repeater for page sections. Elements can be added within a section using a RepeaterMatrix. When I use a CroppableImage4 field within RepeaterMatrix, it cannot be used by non-superusers (eg users with the 'editor' role). If the user clicks on the thumbnail to make a crop, they get the following error message: "Not editable. The process returned no content".
I have given the user role the "croppable-image-4" permission.

If I use CroppableImage4 in a RepeaterMatrix that is not inside a Repeater, it works fine. So I suspect that the problem only applies when CroppableImage4 is used in a 'nested' RepeaterMatrix.

See attached screenshots for the error message and to give an idea of my setup.