[wp-trac] [WordPress Trac] #35725: Add WebP support.

[WordPress Trac]

#35725: Add WebP support.
-------------------------------------------------+-------------------------
 Reporter:  markoheijnen                         |       Owner:
                                                 |  adamsilverstein
     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
 good!

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

 [https://make.wordpress.org/core/2016/02/22/proposal-increase-the-default-
 image-compression-in-wordpress/ This make post] from when WP compression
 settings were changed last and the
 [https://www.smashingmagazine.com/2015/06/efficient-image-resizing-with-
 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:
 https://developers.google.com/speed/webp/docs/riff_container

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


 > Right, this is working as expected now. Here is what it looks like when
 I upload and insert a WebP or a jpeg image:

 Great, thanks!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/35725#comment:109>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform