Jump to content

Webp support


jacmaes

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.

Link to comment
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
Link to comment
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 :)

Link to comment
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.

Link to comment
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

Link to comment
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. 😉

Link to comment
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. 🙂

Link to comment
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
Link to comment
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.

Link to comment
Share on other sites

  • 2 weeks later...

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
Link to comment
Share on other sites

  • 3 months later...
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.

Link to comment
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
Link to comment
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?

Link to comment
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
Link to comment
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)))

Link to comment
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

Link to comment
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.

Link to comment
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"...

Link to comment
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

Link to comment
Share on other sites

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

Link to comment
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);
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
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Robin S
      Select Images
      An inputfield that allows the visual selection and sorting of images, intended for use with the FieldtypeDynamicOptions module. Together these modules can be used to create a kind of "image reference" field.

      Integration with FieldtypeDynamicOptions
      InputfieldSelectImages was developed to be used together with FieldtypeDynamicOptions (v0.1.3 or newer):
      Create a Dynamic Options field. Choose "Select Images" as the "Inputfield type". Select Images appears in the "Multiple item selection" category but you can set "Maximum number of items" to 1 if you want to use Select Images for single image selections. Define selectable options for the field via a FieldtypeDynamicOptions::getSelectableOptions hook. See some examples below. FieldtypeDynamicOptions is recommended but is not a strict requirement for installing InputfieldSelectImages in case you want to use an alternative way to store the field data.
      Selection of Pageimages
      In this example the field allows selection of Pageimages that are in the "images" field of the home page.
      The field will store URLs to the Pageimages so it works as a kind of "image reference" field. You can use the "Format as Pagefile/Pageimage object(s)" option for the Dynamic Options field to have the formatted value of the field be automatically converted from the stored Pageimage URLs to Pageimage objects.
      $wire->addHookAfter('FieldtypeDynamicOptions::getSelectableOptions', function(HookEvent $event) { // The page being edited $page = $event->arguments(0); // The Dynamic Options field $field = $event->arguments(1); // For a field named "select_images" if($field->name === 'select_images') { $options = []; // Get Pageimages within the "images" field on the home page foreach($event->wire()->pages(1)->images as $image) { // Add an option for each Pageimage // When the key is a Pageimage URL the inputfield will automatically create a thumbnail // In this example the label includes the basename and the filesize /** @var Pageimage $image */ $options[$image->url] = "{$image->basename}<br>{$image->filesizeStr}"; } $event->return = $options; } }); Selection of image files not associated with a Page
      When not working with Pageimages you must add a "data-thumb" attribute for each selectable option which contains a URL to a thumbnail/image.
      In this example the field allows selection of image files in a "/pics/" folder which is in the site root.
      $wire->addHookAfter('FieldtypeDynamicOptions::getSelectableOptions', function(HookEvent $event) { // The page being edited $page = $event->arguments(0); // The Dynamic Options field $field = $event->arguments(1); // For a field named "select_images" if($field->name === 'select_images') { $options = []; // Get files that are in the /pics/ folder $root = $event->wire()->config->paths->root; $path = $root . 'pics/'; $files = $event->wire()->files->find($path); // Add an option for each file foreach($files as $file) { $basename = str_replace($path, '', $file); $url = str_replace($root, '/', $file); // The value must be an array with the following structure... $options[$url] = [ // The label for the image 'label' => $basename, 'attributes' => [ // An image URL in the "data-thumb" attribute 'data-thumb' => $url, ], ]; } $event->return = $options; } }); The field values don't have to be image URLs
      The values stored by the Dynamic Options field don't have to be image URLs. For example, you could use the images to represent different layout options for a page, or to represent widgets that will be inserted on the page.
      Also, you can use external URLs for the thumbnails. In the example below the options "calm" and "crazy" are represented by thumbnails from placecage.com.
      $wire->addHookAfter('FieldtypeDynamicOptions::getSelectableOptions', function(HookEvent $event) { // The page being edited $page = $event->arguments(0); // The Dynamic Options field $field = $event->arguments(1); // For a field named "calm_or_crazy" if($field->name === 'calm_or_crazy') { $options = []; // Add options that are illustrated with thumbnails from placecage.com $options['calm'] = [ // The label for the option 'label' => 'Nicolas Cage is a calm man', 'attributes' => [ // An image URL in the "data-thumb" attribute 'data-thumb' => 'https://www.placecage.com/260/260', ] ]; $options['crazy'] = [ // The label for the option 'label' => 'Nicolas Cage is a crazy man', 'attributes' => [ // An image URL in the "data-thumb" attribute 'data-thumb' => 'https://www.placecage.com/c/260/260', ] ]; $event->return = $options; } }); Field configuration
      You can define labels for the button, notices, etc, that are used within the inputfield if the defaults don't suit.

       
      https://github.com/Toutouwai/InputfieldSelectImages
      https://processwire.com/modules/inputfield-select-images/
    • By Robin S
      Process Images
      A basic, proof-of-concept Textformatter module for ProcessWire. When the Textformatter is applied to a rich text field it uses Simple HTML DOM to find <img> tags in the field value and passes each img node through a hookable TextformatterProcessImages::processImg() method.
      This is a very simple module that doesn't have any configurable settings and doesn't do anything to the field value unless you hook the TextformatterProcessImages::processImg() method.
      Hook example
      When added to /site/ready.php the hook below will replace any Pageimages in a rich text field with a 250px square variation and wrap the <img> tag in a link to the original full-size image.
      For help with Simple HTML DOM refer to its documentation.
      $wire->addHookAfter('TextformatterProcessImages::processImg', function(HookEvent $event) { // The Simple HTML DOM node for the <img> tag /** @var \simple_html_dom_node $img */ $img = $event->arguments(0); // The Pageimage in the <img> src, if any (will be null for external images) /** @var Pageimage $pageimage */ $pageimage = $event->arguments(1); // The Page object in case you need it /** @var Page $page */ $page = $event->arguments(2); // The Field object in case you need it /** @var Field $field */ $field = $event->arguments(3); // Only for images that have a src corresponding to a PW Pageimage if($pageimage) { // Set the src to a 250x250 variation $img->src = $pageimage->size(250,250)->url; // Wrap the img in a lightbox link to the original $img->outertext = "<a class='lightboxclass' href='{$pageimage->url}'>{$img->outertext}</a>"; } });  
      GitHub: https://github.com/Toutouwai/TextformatterProcessImages
      Modules directory: https://processwire.com/modules/textformatter-process-images/
    • By spercy16
      These issues should be fairly easy for any intermediate to advanced ProcessWire developer to answer. I'm new to PHP and relatively new to ProcessWire and just need a bit of help. What I'm trying to do is bring in a couple of cards from my Projects page to display on my home page. I finally got the code right to bring in the cards but right now they're using my original images instead of my resized "variations". So firstly, I would like to know how to reference the variations of my images instead of using the original. Secondly, I need to grab only four of the cards from the Project page and not import in all ten. It should be just two small changes to my code to do these things (I would imagine). Here is the code I currently have for that section:
      <?php // https://processwire.com/api/arrays/ // check if the array of images has items if (count($pages->get("/projects/")->images)) : // get array of images from the field $images = $pages->get("/projects/")->images; $count = 0; // iterate over each one foreach ($images as $image) : $count++; $sectionText = $pages->get("/projects/")->get("paragraph_$count"); $img = $image; $buttonCode = $pages->get("/projects/")->get("url_$count"); ?> <span id="card<?php echo $count?>" class="card"> <img class="cardThumb" src="<?php echo $img->url; ?>" alt="<?php echo $image->description; ?> Thumbnail" /> <div class="cardBody"> <div class="cardText"> <h2><?php echo $img->description; ?></h2> <?php echo $sectionText; ?> </div> <div class="primaryBtn"> <a href="https://www.paypal.com/donate?hosted_button_id= <?php echo $buttonCode; ?> &source=url"> <button> <i class="fas fa-donate"></i> Donate </button> </a> </div> </div> </span> <?php endforeach; endif; ?> Thanks in advance for any help!
    • By skeltern
      WebP image support is great and works fine. But once created I've issues to get rid of all API generated WebP variations.
      The backend image field variations "Delete" works and I can remove all variations JPEG plus WebP. Image list is clean but all WebP API variations are still stored in file system (for instance files/12345/84.900x675.webp etc). I can only use ImageSizer with temp 'force' option to request fresh WebP variations or have to delete WebP files from folders. No other way so far. Tested with 2 sites and latest master PW 3.0.165.
      Is there somewhere a "magic button" or config/setup thing to solve my sticky WebP issue?
    • By psy
      I've searched, and maybe missed, the solution. I have a 'normal' images field and uploading images with a file size greater than 10Kb is fine. Any image size smaller results in the never-ending spinner and no upload.
      No min/max width/height set on image uploads in admin, ie just the defaults.
      Any ideas on how to fix?
      Using:
      PW: 3.0.175
      PHP: 7.3
      Marking it as "Resolved" rather than "Solved" as it auto-magically fixed itself. No idea whether PW, PHP, or just an internet hiccough... All good now 🤞
×
×
  • Create New...