Jump to content

CroppableImage with WebP support


horst
 Share

Recommended Posts

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)!

 

  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 4 months later...

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

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • horst changed the title to CroppableImage with WebP support
  • 2 weeks later...

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:

477618102_Schermafbeelding2021-12-28om14_04_05.png.1e78534be701544f9e2b04fcde2a0ca4.png

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 🤔

376233143_Schermafbeelding2021-12-28om14_05_42.thumb.png.3f865c385584126e7bce37ffe5d4af6f.png

Groeten terug uit Maastricht! 👋🏻

Link to comment
Share on other sites

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;
	}

 

  • Like 4
Link to comment
Share on other sites

  • 1 month later...

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.

Link to comment
Share on other sites

  • 3 weeks later...

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.

Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

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. 

Link to comment
Share on other sites

  • 4 weeks later...
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

 

  • Like 1
Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...