Determine and apply best default quality settings for WebP images

[adamsilverstein]

In ticket:35725 we added core support for the WebP image format. On the ticket, we discussed studying the best compression level ("quality") setting to use for WebP images (comment 152, comment 124, comment 117, comment 101). In the end we decided to use the same default quality as JPEG images use for our initial pass.

However, given the differences between the formats (and in anticipation of even newer formats), we should consider what the best default quality setting would be for WebP images.

Some details on how we can test compression settings and arrive at an ideal level are ​outlined in this post.

Related: #53669

[kirasong]

Hey, thanks for opening this! It's been on my mind as well, but haven't got to testing quite yet.

So far, I've discovered that DSSIM values ​do change based on version, so we probably need to do new comparisons.

One potential image set ​can be found here -- my understanding is that this is the one that was used for the resizing quality tests/comparisons.

[adamsilverstein]

Some resources:

• dssim compares visual quality: ​https://github.com/kornelski/dssim (or brew install dssim on a mac)
• ​https://www.industrialempathy.com/posts/avif-webp-quality-settings/ includes some interesting details and data tables with compression levels for jpeg, avig and WebP formats - including one table showing jpeg quality 80 being ~ the same as webp quality 82. my read of this article is that WebP settings should be pretty close to jpeg, so we may be fine with the same or close to the same value for the default WebP quality.

one other interesting point in Malte's article was that the compression level (for a given format) chosen might depend on the image size. I feel like this is something we might want to look into on a separate ticket.

[flixos90]

Moving this to the 6.0 milestone, based on the recent quality and size analysis by @mikeschroder (see ​https://docs.google.com/spreadsheets/d/1n-ead6aea2MTIk9Dpcs0HrtfU6Z5nMSZrzgIZ220Qhk/edit#gid=1245219304).

[costdev]

After discussing this ticket with @adamsilverstein in Slack, the exact value still requires further research. With 6.0 Beta 1 happening today, moving this off the 6.0 milestone to Future Release.

[adamsilverstein]

@mikeschroder - after your research on ​https://github.com/WordPress/performance/issues/7 and my own research on image formats, I would like to formally suggest we adjust the WebP compression quality default to 82, matching the value used for JPEGs. We can leave the filter in place so developers can still fine tune compression levels by MIME as they can now.

My reasoning can be summarized as follows: WebP was/is developed explicitly to provide a smaller file size and similar image quality (across testing methodologies) as well as compression resource consumption at the same quality setting. Since we already chose 82 for JPEG, we should use the same for WebP.

Choosing this value will give WebP generation the most consistently improved performance profile vs. JPEG, though of course individual image results will vary depending on a wide range of factors including image type, quality and size

Worth noting that this ticket was opened based on discussion on the original ticket adding WebP support, however I couldn't track down why we chose the current default of 86 for WebPs.

[adamsilverstein]

In 54356.2.diff​:

• Adjust get_default_quality function to always return a default quality of 82.
• Deprecate the $mime_type parameter for get_default_quality since it no longer does anything.
• Adjust tests to validate 82 quality set for WebP.

Q: Should we deprecate the entire get_default_quality function or warn if a $mime_type parameter is passed?

…arameter in get_default_quality

Trac ticket: https://core.trac.wordpress.org/ticket/54356

[kirasong]

Including my comment from the ​testing ticket here as well, for context:

Hi @adamsilverstein ! Sorry for the wait here.
I'm working on testing this, but having a hard time getting trunk to respect the filter. It's possible it's a local environment issue, but I'm not sure yet.

In the meantime, I thought it'd be helpful to provide my current thoughts.
TL;DR: Based on testing so far: I'm not strongly opposed to 82, but I prefer a value a little higher: 84.

The mean / median in the testing were very close to 82.
However, they included an an image that was an outlier, and very easy to compress (72 quality required).
If this is removed, the mean/median become 84.

The image in the tests (a portrait) that required the highest value to match its equivalent 82 JPEG needed a WebP quality of 90.

For this image, and similar ones, the quality of the resizes will be lower than it was previously.

I like the idea of matching the intent behind WebP's design, but I think we should make sure that aligns with the quality users currently expect from JPEG resizes (Side-wondering: Do you know if that design was based off of resizing from lossless images rather than JPEGs?).

I also don't know where 86 came from, but it seems remarkably close to the value required for JPEG resizes into WebP!

All of that said, I'm going continue another visual test, like you asked previously, and I'll follow up again.
I'm going to verify that the editors we're using actually generate a different size based on 82 / 84, and see if those would be visually distinguishable, regardless of the better DSSIM.

[adamsilverstein]

Data point from today's performance meeting:

Tachyon uses 82 for both JPEG and WebP: ​https://github.com/humanmade/tachyon/blob/a0301091844a204baaebd888b3ed20b1a2bd2850/index.js#L214-L228

[davidbaumwald]

After chatting with @flixos90 and the revert(r54226) of the main WebP generation feature for 6.1, moving this to Future Release for continued work.

[adamsilverstein]

After chatting with @flixos90 and the revert(r54226) of the main WebP generation feature for 6.1, moving this to Future Release for continued work.

We may still be able to land this change in 6.1, it is aimed at addressing the correct default quality level for WebP images, which are already part of core since v5.8.

The goal is to reduce the default quality value for WebP quality in core so users who chose to use WebPs get the maximum benefit. I propose using the same quality we use for JPEGs which has the added side benefit of simplifying our code.

@mikeschroder how do you feel about the value we landed on here? are you ok with the proposed 82 value in 54356.2.diff​ or would you rather see a higher value like 83 or 84? or do you think we should shelve this for now and leave the current default of 86?

[kirasong]

Hi @adamsilverstein!

As far as this ticket is concerned, I'm currently (with WebP as it exists in core) most comfortable with either leaving the current value, or changing to 84. I can imagine this being different if/when we're only converting certain sizes, at which point I'd be more comfortable with 82.

At this point in the cycle, I'm thinking it would make sense to leave it the same, and commit a change after the branch for 6.2.

Is there a reason you think this should be categorized as a bug rather than an enhancement / otherwise get committed during beta?

[adamsilverstein]

Is there a reason you think this should be categorized as a bug rather than an enhancement / otherwise get committed during beta?

Mostly because I think the current value is a bit (subjectively) "wrong" so it feels like a bug. I'm fine punting to 6.2 and a settling value of 84; I'll plan to commit this when the branch opens.

[kirasong]

Replying to adamsilverstein:

Mostly because I think the current value is a bit (subjectively) "wrong" so it feels like a bug. I'm fine punting to 6.2 and a settling value of 84; I'll plan to commit this when the branch opens.

Understood; thank you for explaining! Sounds good, and let's keep chatting about this after the change!

I wonder if it would make sense to test 82 in the performance plugin / WebP by default plugin, to see how users perceive the change, when combined with the rest of the approach (like picking optimal sizes for WebP strategically).

[adamsilverstein]

I wonder if it would make sense to test 82 in the performance plugin / WebP by default plugin, to see how users perceive the change, when combined with the rest of the approach (like picking optimal sizes for WebP strategically).

Good idea. I'll suggest that in an issue over there. Landing #56442 will make that actually work!

[adamsilverstein]

@mikeschroder - quick update that we have landed the 82 quality test in the Performance Lab plugin and we should have some data for the size of those images in the next few months (as users upload new images and they are picked up in the dataset). Curious to see if there is any feedback about image quality.

The filter fix in #56442 also landed; outstanding here is settling on a value for core for WebP quality, if we can lower that some it will help overall reduce file sizes.

[kirasong]

Thanks @adamsilverstein, that's great!

Will be really interested to learn about the user feedback from having it set at 82.

[ironprogrammer]

Hi, @adamsilverstein and @mikeschroder -- as noted in comment:19, should this ticket be moved to 6.3 to allow more time for the Performance Lab data collection and analysis?

The chief concern is how it may decrease visual quality as perceived by users, so it seems a safer bet to collect the feedback and not rush this update -- especially given that the 6.2 feature freeze is just a few weeks away. What do you think?

[audrasjb]

As per today's bug scrub, let's move this ticket to Future Release, waiting for extensive testing and field data from the Performance Lab plugin.

Feel free to move it to milestone 6.3 when it's ready to ship.

[kirasong]

Replying to ironprogrammer:

The chief concern is how it may decrease visual quality as perceived by users, so it seems a safer bet to collect the feedback and not rush this update -- especially given that the 6.2 feature freeze is just a few weeks away. What do you think?

Thanks for the ping!

As far as I am aware, there hasn't been a lot of user feedback yet. I agree with @audrasjb's assessment that having that would be ideal -- especially if the preference is to move to a lower quality setting, like is being tested in the performance plugin.