[wp-trac] [WordPress Trac] #35725: Add WebP support.
noreply at wordpress.org
Thu Mar 18 16:09:38 UTC 2021
#35725: Add WebP support.
Reporter: markoheijnen | Owner:
Type: enhancement | Status: assigned
Priority: normal | Milestone: 5.8
Component: Media | Version: 3.5
Severity: normal | Resolution:
Keywords: has-patch needs-testing has-unit- | Focuses:
tests needs-dev-note dev-feedback |
Comment (by mikeschroder):
Sure! Replies inline as well:
Replying to [comment:107 adamsilverstein]:
> It should for sure, that is the intended behavior. I may have the logic
wrong now and haven't carefully tested this. I've been doing all my
testing with PHP v8 so far, and need to test with earlier versions,
imagick & gd, with and without webp support to validate the correct
behavior. As you stated, in any case where the platform does not support
WebP behavior should be unchanged (the original format should be used).
Okay, cool, thanks! I must have misunderstood when reading. Testing sounds
> > What do the DSSIM differences look like between the existing JPEG
resizing, both with Imagick and GD?
> Great question. I don't know enough about the format to answer that
question, I did find this article:
https://developers.google.com/speed/webp/docs/webp_study and @marylauc may
be able to add some details.
> Would you expect much difference between Imagick and GD, wouldn't they
both rely on the same underlying code?
Good question! I don't know if they have any code in common, but they both
act in different ways, and the settings used change the outcome.
image-compression-in-wordpress/ This make post] from when WP compression
settings were changed last and the
imagemagick/ linked research] talk a bit about some of the concerns, ways
to test, and research re: acceptable DSSIM scores.
Given that, one way to test would be to take the same full size images (or
a set of them), and use DSSIM to compare the originals to the resizes of
the JPEGs generated (GD+Imagick), then the same with WebP implementations
(GD+Imagick). That should give a good idea of the starting point, and how
much optimization of settings are or aren't necessary to match.
> Absolutely, this is critical! I think WebP quality is well established,
let's validate that.
Sounds good! To be clear, I don't mean to question whether the format can
generate quality images -- it's validating that the methods and
resize/compression settings we're using give the same quality output as
users currently get with JPEGs, if that makes sense?
> > Are color profiles respected with this method? I.e. Will users end up
with the same colors with the original JPEG as with the other sizes?
> There is a fundamental difference here you rightly flag - "Webp only
supports 4:2:0 chroma subsampling.". This was discussed a bit above
https://core.trac.wordpress.org/ticket/35725#comment:82 and I tend to
agree this should not affect the vast majority of use cases. The existing
filter could be used to fine tune the behavior, for example opting out for
certain image types.
I think that might be something different, if I understand properly.
I did a search and it looks like color profiles are supported:
So might be a matter of checking to see whether they're passed through
with the same methods we use for Imagick, or it'd need extra handling?
> > What does the resource use look like when profiled compared with
existing resizing methods for images of the same dimensions? (this is re:
your question -- I think host response depends on what the difference is)
> In my initial testing with twentytwenty which has nine total image
sizes, switching to WebP reduced my files sizes by ~25%.
Sorry, I should have been more specific -- I meant profiling the server
side, in terms of CPU time and memory used to do the resizing to WebP,
compared to current JPEG resizing.
I see this higher up (thank you @marylauc!):
> Regarding CPU/memory requirements, webp generally uses about 40% less
memory than jpeg encoding, but is 2x to 3x more cpu intensive."
So essentially, interested in specifically what this looks like for
WordPress (both GD and Imagick):
How much memory is used/saved, and how much time it takes compared to JPEG
to resize -- especially on shared hosting.
This isn't as big of a problem as it used to be now that WordPress can
resume/retry generating sizes, but it would be relevant if it has a large
enough time increase that it either can't generate a size in a single PHP
request's time, or it adds enough time that WordPress is likely to run out
of retry requests.
CPU time and memory usage is also dependent on settings, for JPEG+Imagick
resizing, at least. I don't know how much it changes based on WebP
> Right, this is working as expected now. Here is what it looks like when
I upload and insert a WebP or a jpeg image:
Ticket URL: <https://core.trac.wordpress.org/ticket/35725#comment:109>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac