Help substantiating your claims

Created on 1 March 2025, 3 months ago

Hi there, I created and maintain the ImageAPI Optimize WebP → module, and I saw your project description and accompanying blog post and I have not been able to substantiate your claims. I've researched and tested this diligently and everything I've found points to:

Transformations First:
Applying crop, scale, and other modifications to the original image ensures that you’re working with the best available data. This avoids introducing artifacts that might be compounded by earlier lossy processing.
Conversion Second:
Converting to WebP after transformations allows the conversion process to work with the full detail of your manipulated image. WebP’s encoding routines are designed to optimize both lossless and lossy compression based on the image content.
Compression Last:
After converting, compressing the image (adjusting quality settings) will fine-tune the balance between visual fidelity and file size using the encoder’s optimized compression algorithms for the target format.

I've tested every combo of the above, including what I believe you are claiming in your post and have not been able to match your results. In our solution, we do strongly encourage the users to leave image quality at maximum 100 prior to the derivative being made, and only do compression after the new version is derived. Is there a chance you had misconfigured our module causing double compression?

I appreciate your time, we are working on a much improved image handling solution for Drupal and I'd love to make sure we get this right. Anything you can provide to help us replicate what you are finding would be great.

Thanks!

💬 Support request

Status

Active

Version

1.2

Component

Documentation

Created by

🇺🇸United States michaellander

Live updates comments and jobs are added and updated live.

Comments & Activities

Issue created by @michaellander
Comment 5 days ago →
🇨🇦Canada afoster
Hi, We've been using this module for years now because of the WebP issue https://www.drupal.org/project/webp/issues/3129596 → .

At the time we had to use 100% quality JPGs to allow the derivative WebP to compress from a high-quality source. This made massive JPGs that were never actually viewed by any browsers and wasted lots of space on image-rich sites and added load to the server for output of 2x image files.

I vaguely recall we tried ImageAPI Optimize WebP but as you mentioned, maybe we configured it incorrectly. I don't think we believed we could only export WebP images.

Ideally, we'd create a large number of WebP images at the needed sizes (srcset) and compression and then a single JPG fallback.

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024