Jump to content
jacmaes

Webp support

Recommended Posts

I just downloaded the newest dev version and upgraded my website, but image fields does not support WebP. I replaced wire folder, index.php and .htaccess.
Invalid image (in /wire/modules/Inputfield/InputfieldFile/InputfieldFile.module line 821)

Apache2 / PHP7.0 has GD and ImageMagick enabled.

Share this post


Link to post
Share on other sites
1 hour ago, anttila said:

but image fields does not support WebP. I replaced wire folder, index.php and .htaccess.
Invalid image (in /wire/modules/Inputfield/InputfieldFile/InputfieldFile.module line 821)

Do you mean you tried to upload a WebP image to an Images field? If so that's not supported - the blog post explains that WebP is an output format only:

Quote

WEBP is an output format

WEBP images are fundamentally different from other image formats you have used in ProcessWire. WEBP is purely an output format, not an input format. That’s because you still need a fallback JPG or PNG for any WEBP image that you serve, as not all browsers will be able to consume the WEBP images.

In addition, WEBP images have a type of compression that makes them unsuitable for any further manipulation or transformation, so PNG and/or JPG images should still be the standard for any images you upload to your site. All the WEBP images delivered by ProcessWire are automatically generated from source PNG or JPG images.

 

  • Like 1

Share this post


Link to post
Share on other sites

I have WebP support enabled in GD (PHP 7.3), but

$image_field->webp->url

still returns a JPEG file. Anything I'm missing? Is there something to add in the config.php file?

gd.png

Share this post


Link to post
Share on other sites
Just now, jacmaes said:

still returns a JPEG file

Did it create the WEBP version? Maybe the JPG was smaller so it served that up instead. In my limited experience, it's quite common that the webp version is actually larger :)

Share this post


Link to post
Share on other sites

@adrian That's what I first thought too, but no, it's not generated in the corresponding "files" folder. Digging a bit further, it looks like it does not work with @horst's CroppableImage 3 Module, at least in the way I expected it should. So:

$page->image->first->getCrop('landscape')->webp->url;

does NOT work. But:

$page->image->first->webp->url;

does generate a Webp variant correctly.

Share this post


Link to post
Share on other sites

Hello @horst,

first of all thank you for all your efforts to bring WebP support to ProcessWire. 🙂

I have installed ProcessWire 3.0.132 and implemented this code to almost every image:

<?php $image = $image->size(1600, 900); ?>
<picture>
    <source srcset="<?=$image->webp->url?>" type="image/webp">
    <img src="<?=$image->url?>"
         width="<?=$image->width?>"
         height="<?=$image->height?>"
         alt="<?=$image->description?>">
</picture>

Of course with more variations. This is just an example code.

My issue is, that my local MAMP server doesn't support WebP and my webhosting does support it. On the webhoster the WebP variations get generated and everything is fine. But on my local MAMP server, ProcessWire can't generate the WebP variations and tries to generate them on every page load, which leads to a server timeout.

I saw a condition $image->hasWebp in your early drafts. Can I use this for environments that don't support or should ProcessWire better not try to generate WebP variations at all, if there is no WebP support? 😉

Regards, Andreas

Share this post


Link to post
Share on other sites
44 minutes ago, AndZyk said:

My issue is, that my local MAMP server doesn't support WebP and my webhosting does support it.

Have you tried following these instructions to add WebP support to MAMP?

Share this post


Link to post
Share on other sites

I have tried, but don't have pecl installed on my macOS High Sierra and don't know how to install it. I have tried to install pear, but have not managed yet to get it running.

I have contacted the MAMP support and they will consider enabling WebP in a future update. 😉

Share this post


Link to post
Share on other sites

With some help and the instructions I have now managed to install a newer version of Imagick for MAMP and now the WebP support is also working local for me fine.

But is it possible to detect on the server side if WebP is supported so it doesn't try to generate WebP variations on every page load on environments with no WebP support? It think this would be a good addition. 🙂

Share this post


Link to post
Share on other sites

The image rendering engines have gotten a method / check if and which supports webp creation. I think you best drop an issue at pw github, so that ryan gets knowledge about it. 

If I find time I try to check this too. 

  • Like 2

Share this post


Link to post
Share on other sites

Hi,

I have a strange problem as below:
 

Linux box
Chrome always serves jpg files instead of webp files but Firefox does serves the webp files.

Mac Bookpro
Both Chrome and FireFox serve jpg files only.

Any clues??

Gideon

P.S. Solved. Seems like it is a browser cache problem.

Share this post


Link to post
Share on other sites

I understand thats it's crucial to save bandwith. That's why we have webP now, finally.

But there is one line in PagefileExtra.php that delivers the normal image url instead of the webp version, if the webp filesize is larger.

In my case and I think on other sites too this is an unwanted behaviour, as quality and colors are different if you compare a jpg and a webp image.

To illustrate this I attached this image, where you can see that the first three products which are being delivered as JPGs because the filesize is smaller are really different looking than the next 3 which are in webp format , especially in the logo area. This is somewhat hard to see here, but on my development site it looks really bad and is a showstopper for me to use webp.

What I ask for is an option to skip the filesize check and maybe the option to enter a treshold value when to use the smaller image.

I created a github issue "make the fallback optional if pagefile->url is smaller than webp"

EDIT: This is already possible if you use  following code:

//_init.php
// output webp version for all $image->url() calls, skip SVG's
if($page->template != 'admin') {
  $wire->addHookAfter('Pageimage::url', function($event) {
    static $n = 0;

    if(++$n === 1) {
      if (strstr($event->object->filename, '.svg') === false){
        $event->return = $event->object->webp()->url(false);
      }
    }
    $n--;
  });
}

chrome_2019-06-12_10-36-09.thumb.png.a4b82c4cb239290161640c47f0b3e418.png

 

Edited by jens.martsch
Solved
  • Like 4

Share this post


Link to post
Share on other sites

What about PNG images with transparency? The transparent areas are appearing as black in the webp images. Any special settings for those?

  • Like 2

Share this post


Link to post
Share on other sites
On 9/27/2019 at 3:31 PM, kalimati said:

What about PNG images with transparency? The transparent areas are appearing as black in the webp images. Any special settings for those?

I've had this problem for quite some time, even without WebP. Somewhere I think there is a bug in the ImageSizers. This happens with compressed PNGs, which were previously compressed via tinypng.com, for example.

Share this post


Link to post
Share on other sites
1 hour ago, David Karich said:

I've had this problem for quite some time, even without WebP. Somewhere I think there is a bug in the ImageSizers. This happens with compressed PNGs, which were previously compressed via tinypng.com, for example.

@David Karich & @kalimati Which PW version(s) do show this behave? AND: which ImageSizerEngine(s) have you enabled there? (GD | IMagick)

We had a change in what image types are supported by IMagick and need to revert back some sorts of PNGs, especially 8bit PNGs are not correct supported by IMagick, and in very rare cases there also was wrong handling for some 8bit-PNGs in GD-Engine.

Maybe you can provide the informations plus one or two of the (original uploaded) images in a ZIP to me?

  • Like 1

Share this post


Link to post
Share on other sites

It may have something to do with the graphics conversion engine installed. I corrected the problem on my local server by installing ImageMagick.

Share this post


Link to post
Share on other sites
On 10/2/2019 at 1:03 PM, horst said:

@David Karich & @kalimati Which PW version(s) do show this behave? AND: which ImageSizerEngine(s) have you enabled there? (GD | IMagick)

We had a change in what image types are supported by IMagick and need to revert back some sorts of PNGs, especially 8bit PNGs are not correct supported by IMagick, and in very rare cases there also was wrong handling for some 8bit-PNGs in GD-Engine.

Maybe you can provide the informations plus one or two of the (original uploaded) images in a ZIP to me?

This one is converted to webp with black background by GD on my localhost. I tried another one it behaves the same way. Is there any requirements on GD version or php?

Share this post


Link to post
Share on other sites

What about a scenario when client upload a webp image (.webp renamed to .jpg)?
I just had that case with one of my clients on pw 3.0.123. With processwire 3.0.123 I am able to edit and view the page with uploaded webp image. Only drawback: no thumbnails are generated.

Now, reproducing that scenario with pw 3.0.141, whenever I try to edit or view a page containing uploaded webp image, I'm getting 500 internal server error.
Tracy says: ProcessWire\WireException webmimage-9.0x260.jpg - not a supported image type
Source file: File: .../dev/wire/core/ImageSizerEngine.php:574

574:                throw new WireException(basename($filename) . " - not a supported image type");

Its the same error with either GD (2.1.0 compatible) or ImageMagic (6.9.4-10 Q16 x86_64 2017-05-23).
PHP version: 7.2.22

------

@Ivan Gretsky, I was able to convert your image to webp with GD and ImageMagic (libraries, php and pw version same as above).

webp.png.ec35444d3e2d6cfba86e05257975f0cf.png

(blue background is from a css style)

  • Like 2

Share this post


Link to post
Share on other sites

Thanks, @johndoe!

The conversion did not work on my local xampp with some php 5.6, but did work on a live server. I can guess some requirements are not met on localhost. It would be nice to know those requirements, bit for now I know that I should try to keep the server environment as fresh as possible (which is a good thing anyway)))

Share this post


Link to post
Share on other sites

Is it just me who don't understand the percentage for the webp generated variation? Original is 311k, webp is 62k, how do I get 80% ? That means webp is 80% smaller than original? And if webp is bigger than original, I get (webp -20%). And while here, how do I delete webp variation?

Screenshot.png

Share this post


Link to post
Share on other sites
13 hours ago, matjazp said:

That means webp is 80% smaller than original?

I think that's just about it: 62k is ~20% of 311k, so the conversion has shaved off 80% of the size of the original source image. Kind of seems to me that in this context displaying the size of the WebP image in comparison to the source file (20%) could've made more sense, but I guess it depends on how you like to think about it 🙂

About deleting a WebP variation – I've no idea.

Share this post


Link to post
Share on other sites
8 hours ago, teppo said:

but I guess it depends on how you like to think about it

Yeah. Maybe simple text like "80% smaller" or "20% larger" would make more sense. Or maybe no info at all. I'm also confused with the word "Original"...

Share this post


Link to post
Share on other sites

Hi,

On desktop everything works fine: Chrome, FF, Edge shows webp
On mobile (IOS) nothing works at all: no webp and no fallback jpg/png in no browser

PW Version: 3.0.142
.htaccess: AddType image/webp .webp
config.php:
$config->useWebP = true;
$config->contentTypes('webp', 'image/webp');

ImageMagick 7.0.8-25

Cleared cache!

Any ideas??

Thank you

Share this post


Link to post
Share on other sites
On 10/2/2019 at 12:03 PM, horst said:

@David Karich & @kalimati Which PW version(s) do show this behave? AND: which ImageSizerEngine(s) have you enabled there? (GD | IMagick)

We had a change in what image types are supported by IMagick and need to revert back some sorts of PNGs, especially 8bit PNGs are not correct supported by IMagick, and in very rare cases there also was wrong handling for some 8bit-PNGs in GD-Engine.

Maybe you can provide the informations plus one or two of the (original uploaded) images in a ZIP to me?

@horst Sorry for the later feedback, but here's the summary.

PW Version: 3.0.143 (dev, from 28. October 2019)
IMagick Image Sizer: 0.0.3
PHP imagick: 3.4.3
PHP: 7.2.x and 7.3.x

Otherwise no other image modules activated. I think that problem with PNG8 has occurred since the change in the module from 7.6.2019 or 6.7.2019. However you formatted the comment. I deactivate the ImageSizerEngineIMagick, and GD takes over, I have no problems.

In the attachment two test PNGs, one without compression (which works) and one compressed with tinypng.com (this one will change from a transparent background to a black background when resizing).

test-PNGs.zip

Share this post


Link to post
Share on other sites

Has anyone encountered such a problem?

When you generate WEBP via $image->webp (IMagick Image Sizer enabled), files are created, but they are not valid. Accordingly, they do not open in the browser. These files look quite functional, but are not displayed. I can’t understand what kind of images can go bad during generation.

I took one image, generated it in the same formats to get a working webp and a broken one. Google Chrome in the console displayed loading webp images, but did not display it. I downloaded both files. Comparing the files that I discovered a size mismatch for the generated WEBP files. File sizes differed by only 1 byte.
screenshot.

With the help of the HEX editor I looked at what was missing there. It turned out that during the generation of PHP does not append 1 byte to the end of the file, the file is not valid and Chrome can not display it.

Working file;
Broken file;

Having studied the structure of WEBP a bit, I came to the conclusion that all live files always end with byte x00, in addition WEBP continues to work fine if you add any number of x00 to the end. You can check it yourself, everything works fine.

$image = $page->images->first();
$resized = $image->size(1600, 960);
$webp = $resized->webp->url;
$file = fopen($webp, "a+");
fwrite($file, chr(0x00));
fclose($file);

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Peter Knight
      Is anyone here using WEBP as their output image format and what is your server / environment setup?
       I know there's support for it in PW lately and decided to investigate.
      Found it quite difficult to do this on a practical level. IE My current VPS is Cent OS 6 and Plesk and unless I'm wrong, WEBP is not supported by either.
      Which host and setup are you on that allows you to run WebP?
      Cheers
    • By Robin S
      Add Image URLs
      Allows images/files to be added to Image/File fields by pasting URLs.

      Usage
      Install the Add Image URLs module.
      A "Paste URLs" button will be added to all image and file fields. Use the button to show a textarea where URLs may be pasted, one per line. Images/files are added when the page is saved.
       
      https://github.com/Toutouwai/AddImageUrls
      https://modules.processwire.com/modules/add-image-urls/
    • By gebeer
      Hello all,
      sharing my new module FieldtypeImageReference. It provides a configurable input field for choosing any type of image from selectable sources. Sources can be: 
      a predefined folder in site/templates/ and/or a  page (and optionally its children) and/or the page being edited and/or any page on the site CAUTION: this module is under development and not quite yet in a production-ready state. So please test it carefully.
      UPDATE: the new version v2.0.0 introduces a breaking change due to renaming the module. If you have an older version already installed, you need to uninstall it and install the latest master version.
      Module and full description can be found on github https://github.com/gebeer/FieldtypeImageReference
      Install from URL: https://github.com/gebeer/FieldtypeImageReference/archive/master.zip
      Read on for features and use cases.
      Features
      Images can be loaded from a folder inside site/templates/ or site/assets Images in that folder can be uploaded and deleted from within the inputfield Images can be loaded from other pages defined in the field settings Images can be organized into categories. Child pages of the main 'image source page' serve as categories mages can be loaded from any page on the site From the API side, images can be manipulated like native ProcessWire images (resizing, cropping etc.), even the images from a folder Image thumbnails are loaded into inputfield by ajax on demand Source images on other pages can be edited from within this field. Markup of SVG images can be rendered inline with `echo $image->svgcontent` Image names are fully searchable through the API $pages->find('fieldname.filename=xyz.png'); $pages->find('fieldname.filename%=xy.png'); Accidental image deletion is prevented. When you want to delete an image from one of the pages that hold your site-wide images, the module searches all pages that use that image. If any page contains a reference to the image you are trying to delete, deletion will be prevented. You will get an error message with links to help you edit those pages and remove references there before you can finally delete the image. This field type can be used with marcrura's Settings Factory module to store images on settings pages, which was not possible with other image field types When to use ?
      If you want to let editors choose an image from a set of images that is being used site-wide. Ideal for images that are being re-used across the site (e.g. icons, but not limited to that).
      Other than the native ProcessWire images field, the images here are not stored per page. Only references to images that live on other pages or inside a folder are stored. This has several advantages:
      one central place to organize images when images change, you only have to update them in one place. All references will be updated, too. (Provided the name of the image that has changed stays the same) Installation and setup instructions can be found on github.
      Here's how the input field looks like in the page editor:

      If you like to give it a try, I'm happy to hear your comments or suggestions for improvement. Install from URL: https://github.com/gebeer/FieldtypeImageReference/archive/master.zip
      Eventually this will go in the module directory, too. But it needs some more testing before I submit it. So I'd really appreciate your assistance.
      Thanks to all who contributed their feedback and suggestions which made this module what it is now.
       
    • By rushy
      Hi. I've been using Processwire for a few years now and installed it on a few different shared hosting servers without issues, but I'm now running into an issue on a Fasthosts shared server that I've not seen before. The installation goes ok and I have a working default site profile but I am unable to complete any uploads of images. It just hangs at the progress spinner during the upload. I thought it might be a priviledge issue so have temporarily set the dir / file privs. as 777 / 666 just to test that but it made no difference. I have no errors in the wire log. In server error log I have:
      set_time_limit() has been disabled for security reasons in ....htdocs/wire/core/ImageSizerEngine.php on line 1035 and i note in the assets/file dir. where the image is being stored the date on the file being created has a year of 1970 and 0 length. If I leave the page this file disappears and nothing has been stored. 
      Does anyone know how I can enable set_time_limit if this is likely to be the problem? 
      Many thanks! Paul
    • By gebeer
      EDIT: all development and discussion of this module has been moved to Module FieldtypeImagePicker which now contains all features of this module and more. This module will not be maintained any further. The information below remains for pure historical reasons.
      I am happy to present my new fieldtype FieldtypeImageFromPage. It is made up of 2 modules:
      Fieldtype Image Reference From Another Page is a Fieldtype that stores a reference to a single image from another page. The image can be selected with the associated Inputfield.
      Inputfield Select Image From Page is an Inputfield to select a single image from images on a predefined page and it's children.
      And there also is a helper module that takes care of cleanup tasks.
      This module evolved out of a discussion about my other Module FieldtypeImagePicker.  It caters for use cases where a set of images is being reused multiple times across a site. With this fieldtype these images can be administered through a chosen page. All images uploaded to that page will be available in the inputfield.
      When to use ?
      Let editors choose an image from a set of images that is being used site-wide. Ideal for images that are being re-used across the site.
      Suited for images that are used on multiple pages throughout the site (e.g. icons).
      Other than the native ProcessWire images field, the images here are not stored per page. Only references to images on another page are stored. This has several advantages:
      one central place to organize images when images change, you only have to update them in one place. All references will be updated, too. (Provided the name of the image that has changed stays the same) Features
      Images can be manipulated like native ProcessWire images (resizing, cropping etc.) Image names are fully searchable through the API Accidental image deletion is prevented. When you want to delete an image from one of the pages that hold your site-wide images, the module searches all pages that use that image. If any page contains a reference to the image you are trying to delete, deletion will be prevented. You will get an error message to help you edit those pages and remove references there before you can finally delete the image. How to install and setup
      Download and install this module like any other modules in ProcessWire Create a page in the page tree that will hold your images. This page's template must have an images field Upload some images to the page you created in step 2 Create a new field. As type choose 'Image Reference From Another Page'. Save the field. In 'Details' Tab of the field choose the page you created in step 2 Click Save button Choose the images field name for the field that holds your images (on page template from step 2) Click Save button again Choose whether you want to include child pages of page from step 2 to supply images Add the field to any template You are now ready to use the field View of the inputfield on the page edit screen:

      View of the field settings

      The module can be installed from this github repo. Some more info in the README there, too.
      In my tests it was fairly stable. After receiving your valued feedback, I will eventually add it to the modules directory.
      My ideas for further improvement:
      - add ajax loading of thumbnails
      Happy to hear your feedback!
       
×
×
  • Create New...