The webp version is created from the generated jpg styled version and not from the actual source image. This does double compression introducing artifacts on top of artifacts. It means that if the GD2 toolkit has 60% quality configured and webp has 90% then the artifacts produced from GD2's low quality will be encoded in the webp version.

The only solution to overcome this is to specify 100% global quality in GD2 and then the desired quality (e.g 90%) in webp. But this will mean that clients which cannot view webp (e.g safari) will view a very large filesize images.

This is the case whether I use "GD2 image manipulation toolkit" or "Imagick image manipulation toolkit" in /admin/config/media/image-toolkit.

What I'd expect/want to happen would be that the webp module would either:
- rerun the style steps, and save the file as webp.
- rerun the style steps, save a temp jpg file with 100% quality (without taking into account global jpg quality setting), convert that to webp, delete temp file.

Comments

ioannis.cherouvim created an issue. See original summary.

ioannis.cherouvim’s picture

ioannis.cherouvim commented
Issue summary: View changes
ioannis.cherouvim’s picture

ioannis.cherouvim commented
Issue summary: View changes
alexmoreno’s picture

alexmoreno commented

Hi @ioannis.cherouvim

are you using ImageApi? That is a known issue if so, see https://www.drupal.org/project/webp/issues/3063808

but please confirm in case I am missing something.

Thanks

alexmoreno’s picture

alexmoreno commented
Status: Active » Postponed (maintainer needs more info)
pedrop’s picture

pedrop commented

Confirming this as a major issue for us.
The WebP module creates the webp file as a secondary alternative from the original derivative.
As the image styles are downscaled in most cases and the JPEG lossy compression is applied, the potential quality and/or size benefits of moving to the WebP format this way are essentially wasted.

Steps to reproduce

My relevant software versions: PHP 8.1.6, ImageMagick 6.9.7-4 (CLI), Drupal core 9.3.14, Webp 8.x-1.0-beta6.
Install and enable the imagemagick module, set imagemagick the image processing toolkit and enable debugging output.
I followed the readme, enabled the responsive style module and added the previously used 480x480 only to the wide and added the wide responsive style to the article image display.
I had to hardcode the image toolkit in src/Webp.php to avoid the fallback to GD and stay with imagemagick due to https://www.drupal.org/project/webp/issues/3283040.

ImageMagick convert commands running:

convert '/var/www/web/sites/default/files/2022-05/2012_chevrolet_camaro-1600x1200.jpg' -resize 480x360! -quality 80 '/var/www/web/sites/default/files/styles/large/public/2022-05/2012_chevrolet_camaro-1600x1200.jpg'

convert '/var/www/web/sites/default/files/styles/large/public/2022-05/2012_chevrolet_camaro-1600x1200.jpg' -quality 80 WEBP:'/var/www/web/sites/default/files/styles/large/public/2022-05/2012_chevrolet_camaro-1600x1200.webp'

Proposed resolution

I don't have an easy solution proposal in my mind as this is rather a conceptual problem.
As WebP is already supported by the vast majority of browsers (and growing) I think it would be better to create the webp files as the primary derivative and create fallback to jpeg only if necessary.
I tried to summarize our experiences and linked an alternative module in my blog post: https://www.brainsum.com/blog/webp-right-way-and-wrong-way-drupal.

tdroden’s picture

tdroden commented

I recently noticed this same issue with our image styles and responsive images configuration.

A quick demo would be to upload an image and generate the derived WebP image. Now, go to the /admin/config/media/image-toolkit and drop the image quality settings to something like 10% for your selected image toolkit (We're using ImageMagick). Purge the derivative images and refresh the page. The WebP version of the image will be considerably worse because it is being generated from the styled JPG, not the source JPG.

They should be generated independently of each other, respecting their requisite compression settings, not compounding it.

johnpitcairn’s picture

johnpitcairn commented

Confirmed. Image API is not involved. A webp derivative at 25% appears to be a smeared version of the jpeg at 25%, containing the same artifacts.

johnpitcairn’s picture

johnpitcairn commented
Status: Postponed (maintainer needs more info) » Active