[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 marylauc):

 Replying to [comment:109 mikeschroder]:
 > Replying to [comment:107 adamsilverstein]:
 > > 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.

 Both imagemagick and GD use the libwebp encoder, so they should give very
 similar results. At most they might be using slightly different versions
 of the library or use different default settings.

 The default quality setting (75) is the value we usually recommend for
 webp, but testing on a dataset and choosing a quality value that gives the
 DSSIM you want sounds like a great idea.

 The cwebp encoder has a -print_ssim option, from which you can compute
 DSSIM = (1-SSIM)/2, but note that it doesn't take into account the loss
 from the 420 chroma subsampling. That means it's slightly inaccurate for
 images with bright color transitions. Otherwise, you can use webp's
 get_disto tool
 (https://github.com/webmproject/libwebp/blob/master/extras/get_disto.c),
 or the the compare tool from imagemagick 7, and I'm sure there are other
 ones.


 Replying to [comment:114 atjn]:
 > Replying to [comment:112 blobfolio]:
 > > Testing for WebP compatibility (a la Modernizr) requires the ability
 to inject a data-uri image into the DOM. Sites with CSP restrictions
 prohibiting script-generated data: sources won't be able to execute the
 tests.
 >
 > Great point, although this seems like a very specific issue. Wouldn't a
 filter to disable WebP be good enough for this? Or everything could just
 be a try:catch block and then load the shim if the code fails.

 The recommended way to test for webp  support is to use the "accept"
 request header. Browsers that support webp should list "image/webp", even
 for the initial page request (not just when requesting images). Chrome,
 Firefox and Safari definitely do this.  https://developer.mozilla.org/en-
 US/docs/Web/HTTP/Content_negotiation/List_of_default_Accept_values says
 that Edge does not, but I checked Edge on macOS and it does send
 image/webp. I'm not sure about the windows version. So using only this
 method, you might in theory get some false negatives, as you rely on the
 browser sending "image/webp" for html requests. But if "image/webp" is
 indeed present, you can be sure the browser supports it and you don't need
 to include any polyfill.

 See also
 https://developers.google.com/speed/webp/faq#how_can_i_detect_browser_support_for_webp
 if you haven't already.

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