Make WordPress Core

Opened 2 years ago

Last modified 15 months ago

#54356 assigned enhancement

Determine and apply best default quality settings for WebP images

Reported by: adamsilverstein's profile adamsilverstein Owned by: adamsilverstein's profile adamsilverstein
Milestone: Future Release Priority: normal
Severity: normal Version: 5.8
Component: Media Keywords: has-patch dev-feedback has-unit-tests early
Focuses: performance Cc:

Description (last modified by sabernhardt)

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

Attachments (2)

54356.diff (1.4 KB) - added by adamsilverstein 20 months ago.
54356.2.diff (3.2 KB) - added by adamsilverstein 20 months ago.

Download all attachments as: .zip

Change History (26)

#1 @sabernhardt
2 years ago

  • Description modified (diff)

#2 @kirasong
2 years ago

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.

#3 @adamsilverstein
2 years ago

Some resources:

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.

This ticket was mentioned in Slack in #core-media by mike. View the logs.


2 years ago

#5 @flixos90
2 years ago

  • Milestone changed from Future Release to 6.0

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).

#6 @peterwilsoncc
2 years ago

  • Focuses performance added
  • Keywords needs-patch added

#7 @costdev
2 years ago

  • Milestone changed from 6.0 to Future Release

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.

#8 @adamsilverstein
20 months ago

@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.

#9 @adamsilverstein
20 months ago

  • Keywords has-patch dev-feedback has-unit-tests added; needs-patch removed
  • Milestone changed from Future Release to 6.1
  • Owner set to adamsilverstein
  • Status changed from new to assigned

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?

This ticket was mentioned in PR #3115 on WordPress/wordpress-develop by adamsilverstein.


20 months ago
#10

…arameter in get_default_quality

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

#11 @kirasong
20 months ago

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.

#12 @adamsilverstein
20 months ago

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

#13 @davidbaumwald
19 months ago

  • Milestone changed from 6.1 to Future Release

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.

#14 @adamsilverstein
19 months ago

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?

#15 @kirasong
19 months ago

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?

#16 follow-up: @adamsilverstein
19 months ago

  • Keywords early added
  • Milestone changed from Future Release to 6.2

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.

#17 in reply to: ↑ 16 @kirasong
19 months ago

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).

#18 @adamsilverstein
19 months ago

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!

#19 @adamsilverstein
17 months ago

@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.

#20 @kirasong
17 months ago

Thanks @adamsilverstein, that's great!

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

#21 follow-up: @ironprogrammer
15 months ago

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?

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


15 months ago

#23 @audrasjb
15 months ago

  • Milestone changed from 6.2 to Future Release

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.

#24 in reply to: ↑ 21 @kirasong
15 months ago

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.

Note: See TracTickets for help on using tickets.