Make WordPress Core

Opened 4 years ago

Closed 8 weeks ago

Last modified 5 weeks ago

#51228 closed enhancement (fixed)

Include support for the AVIF image format

Reported by: lukefiretoss's profile lukefiretoss Owned by: adamsilverstein's profile adamsilverstein
Milestone: 6.5 Priority: normal
Severity: normal Version:
Component: Media Keywords: has-patch has-unit-tests commit has-testing-info add-to-field-guide has-dev-note
Focuses: performance, sustainability Cc:

Description

The current MIME type for AVIF images is

image/avif

.
https://github.com/AOMediaCodec/av1-avif/issues/59

Google Chrome in version 85 added support for the AVIF image format and Mozilla Firefox and Safari from Apple will not be that far behind in supporting it.

The AVIF image format provides great file size and compression gains over JPG, PNG and WebP images.

Attachments (4)

51228-avif-compat-php.diff (1.1 KB) - added by adamsilverstein 5 months ago.
51228-avif-compat-php.2.diff (2.0 KB) - added by adamsilverstein 5 months ago.
51228.diff (58.0 KB) - added by adamsilverstein 2 months ago.
51228.2.diff (59.4 KB) - added by adamsilverstein 8 weeks ago.

Download all attachments as: .zip

Change History (94)

#1 @ayeshrajans
4 years ago

I'm on Firefox 81 beta, and I already have avif support. +1 from me, I'll submit a patch if the maintainers agree :).

Last edited 4 years ago by ayeshrajans (previous) (diff)

#3 @ayeshrajans
4 years ago

I submitted a PR to PHPMailer, which apparently I includes a list of mine types. I suppose SimplePie will need an update too. After that, it will be all in core.
I don't think the image editors will be compatible with heic or avif, so adding avif/heic to those wouldn't work out well.

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


3 years ago

#5 @navjotjsingh
3 years ago

It looks like AVIF support has been added to Webkit as well: https://bugs.webkit.org/show_bug.cgi?id=207750

For now, can WordPress at least allow AVIF images to be uploaded via the Media Library?

Last edited 3 years ago by navjotjsingh (previous) (diff)

#6 @adamsilverstein
3 years ago

  • Milestone changed from Awaiting Review to Future Release
  • Owner set to adamsilverstein
  • Status changed from new to assigned

#7 @Tyrannous
21 months ago

AVIF support has landed in Safari Technology Preview 149 (on macOS 13 and iOS 16).

@adamsilverstein, since Microsoft Edge remains the only browser without support (for now), is there any ETA when AVIF support will arrive in core? Thanks!

#8 @adamsilverstein
21 months ago

Hey @Tyrannous - thanks for pointing out this change. I've been following as well and am excited to see AVIF landing - I am hopeful we will see Edge support follow as you mentioned.

I feel like we could start work on a patch here for testing, however one big caveat for AVIF is the current lack of default support in PHP until version 8.1 (https://php.watch/versions/8.1/gd-avif). While it is possible for older PHP versions to have AVIF support with an updated GD or Imagick library this probably isn't common.

Landing https://core.trac.wordpress.org/ticket/48116 will help us learn more about the level of server side AVIF support in the ecosystem. Another possibility is moving image compression to the client - libAVIF can be compiled using WASM to run directly in the browser (tracked in https://github.com/WordPress/performance/issues/17).

#9 follow-up: @jb510
19 months ago

This a good example of how WP could adopt progressive enhancement. Start supporting AVIF now for sites that are running 8.1, and accept that those running < 8.1 won't get that feature until they're upgraded.

Personally, I expect AVIF up take to be much faster than WebP has been. It almost seems like we're adding WebP right right as it's passing it's peak usage. That's definitely not factually true, w3twchs tracks this and adoption is still climbing, but it does "feel" a bit late to the party.

It was said many times, WP ought to be pushing web standards forward not being the caboose.

#10 in reply to: ↑ 9 @Tyrannous
19 months ago

Replying to jb510:

This a good example of how WP could adopt progressive enhancement. Start supporting AVIF now for sites that are running 8.1, and accept that those running < 8.1 won't get that feature until they're upgraded.

Yes, I had on my list to ask @adamsilverstein if this is something WordPress would consider: Not trying to implement a feature for all WordPress users at whatever cost (e.g. supporting PHP 5.6 with a complex client-based solution), but instead just adding AVIF on platforms that support it "out of the box".

And I'm glad to see that you actually seem to be considering this: https://github.com/WordPress/performance/issues/11, assuming that the WebP module description ("[…] if supported by the server") also applies to AVIF. Would it make sense to continue the discussion there?

Last edited 19 months ago by Tyrannous (previous) (diff)

#11 @sabernhardt
18 months ago

#56741 was marked as a duplicate.

#12 @gregbenz
18 months ago

AVIF is a critical format for sharing HDR images on the web. To the extent that WordPress processes images (thumbnails, etc), it is important to include some test cases that will preserve CICP / ICC data (along with 10 / 12 bit encoding as appropriate) to ensure any derivative content still shows as HDR.

Awareness of HDR (brighter than white image display) is currently low, but likely to grow quickly with substantial image quality benefits and several recent developments facilitating creation and display of this content. Apple has shipped hundreds of millions of displays with HDR support, Chrome supports it very well now, Photoshop and Affinity can be used to display and edit HDR, etc.

#13 @gregbenz
17 months ago

Here's an example page with several HDR AVIF images. It's a WordPress page, but I had to manually upload all files to my server outside the WordPress media library and link each image as a URL external to WordPress. It's worth doing for a big tutorial page like this, but is definitely a deterrent to using AVIF broadly on a WordPress site because it's much more time consuming than a simple upload to the media library.

https://gregbenzphotography.com/hdr
(view this page in Chrome on an HDR capable screen such as the M1 MacBook Pro to see how incredible HDR can be. Note that Safari currently clips HDR and FireFox renders extremely dark, but it's only a matter of time before we see support. Photoshop, Adobe Camera RAW, Affinity and many other important image creation platforms now support HDR - with many more surely to come.

Note that the images here are HDR, which means that none of the formats in the WordPress media library are suitable (JPG, PNG, etc). And the file savings here are substantial. I've seen anywhere from 30-80% file size reductions going from JPG to AVIF. Having native support for AVIF (including keeping the 10-12bit depth and CICP data to render properly as HDR for any derivative media) would be incredibly useful.

Version 1, edited 17 months ago by gregbenz (previous) (next) (diff)

#14 @gregbenz
17 months ago

@adamsilverstein Any major concerns with PHP v8.1 (vs something probably more common like v7.4)? Is there some significant component, plugin, etc that likely isn't supported? Do you believe that would be a difficult upgrade at this time for many WordPress sites (at least for those motivated enough to adopt AVIF)?

#15 @adamsilverstein
17 months ago

https://gregbenzphotography.com/hdr

Thanks for sharing the link - those images are incredible and this is such a good demonstration of the power of AVIF. Plus the file size is smaller, amazing!

Quick Safari update - support has now landed in WebKit which I believe means Safari will soon support AVIF even on older iOS and MacOS versions that lack OS support. See https://github.com/WebKit/WebKit/pull/5669.

The lack of Edge support unfortunately probably still remains a blocker since we generally only adopt features that all the major browsers support (unless the lack of the feature doesn't negatively impact users). Anything we can do to encourage Edge to add support would be helpful.

Any major concerns with PHP v8.1

Primarily that WordPress isn't fully compatible yet as far as I know (see https://make.wordpress.org/core/2022/01/10/wordpress-5-9-and-php-8-0-8-1/ & open tickets). That said, I believe it is possible to use AVIF on older PHP with a more recent Imagick library.

Server support is less critical here and it would be fine to only support AVIF when the underlying system (server) supports it - we do the same already for WebP. We are also exploring browser based encoding as a possible path forward, since we can now run the full liibavif via WASM.

#16 follow-up: @jb510
17 months ago

The fundamental flaw with the WebP proposal was wanting to convert all existing images/thumbnails by default.

Here the approach should simply be supporting AVIF uploads and generating AVIF thumbnails of those uploads.

The only big hurdle is AVIF that PHP < 8.1 doesn’t support it and WP is still handcuffed to supporting ancient EOL versions of PHP.

The philosophical decision that needs to be made is, is it acceptable to add AVIF support conditionally on installs running PHP 8.1+ or do we need to try to support AVIF on old versions, or worse wait until 8.1 is the minimum support version for WP.

Per above, I vote for progressive enhancement now, where AVIF support is in core but only available when running PHP 8.1+ and those GD/imageavif() functions are available.

#17 @gregbenz
17 months ago

@adamsilverstein I have not tested MacOS 13, but the AVIF support in iOS16 unfortunately does not include HDR AVIF images. Viewing my site on an iPhone / iPad will show the HDR content clipped.

Having HDR AVIF in WebKit ultimately is critical, because it is required for iOS Chrome, etc. Given Apple has shipped hundreds of millions of HDR screens (they are way ahead of the game), I would assume they could flip the switch for HDR image support at any time. Once they do, most Apple devices bought in the last 4 years would support it and I expect that could be something of an inflection point for this to start really taking off.

But, WebKit support for standard AVIF allows significant reduction in file size, which is huge and beneficial for any site.

#18 in reply to: ↑ 16 @gregbenz
17 months ago

Replying to jb510:

Per above, I vote for progressive enhancement now, where AVIF support is in core but only available when running PHP 8.1+ and those GD/imageavif() functions are available.

Agreed, just enable support for those who can migrate to PHP 8.1.

#19 follow-up: @adamsilverstein
17 months ago

@adamsilverstein I have not tested MacOS 13, but the AVIF support in iOS16 unfortunately does not include HDR AVIF images. Viewing my site on an iPhone / iPad will show the HDR content clipped.

Thats unfortunate! Can you use something like picture element to get Safari to fall back to another format?

I'm curious if the recent merge to WebKit will fix that issue and plan to test once the new code lands in Safari Technology Preview.

#20 @adamsilverstein
17 months ago

The fundamental flaw with the WebP proposal was wanting to convert all existing images/thumbnails by default.
Here the approach should simply be supporting AVIF uploads and generating AVIF thumbnails of those uploads.

Thats exactly what we did for WebP in WordPress 5.8; the rejected proposal for "by default" was a follow up to that work.

The only big hurdle is AVIF that PHP < 8.1 doesn’t support it and WP is still handcuffed to supporting ancient EOL versions of PHP.

Plus the lack of support in Edge.

The philosophical decision that needs to be made is,

This decision was made long ago - WordPress image mime type support always depends on the underlying image processing supporting it; it is fine if this is a progressive enhancement.

See this article for more info on core support for 8.1 (currently "beta support") - https://make.wordpress.org/core/2022/01/10/wordpress-5-9-and-php-8-0-8-1/

#21 in reply to: ↑ 19 @gregbenz
17 months ago

Replying to adamsilverstein:

Thats unfortunate! Can you use something like picture element to get Safari to fall back to another format?

It's more complicated than just support for the file type. Safari and Firefox will load the image, but not render it properly. And even if they did, showing an SDR image (could also be AVIF) is more optimal than allowing the browser to tone map an HDR image.

I'm working on a more nuanced test for my own site to load HDR images when both the display and browser will properly support it.

A media query might eventually partially resolve this in combination with something like the picture element. That's probably a ways off based on my testing. And even if that worked, the HDR headroom on 400 nits displays goes to 0 when the screen is at full brightness, so you'd want to show SDR there. There's no great fix for that (but it isn't a big problem, I'm just talking about optimizing things from the perspective of a professional photographer).

There is an experimental JS API to query HDR headroom (see test #8 at gregbenzphotography.com/hdr#tests). That would be the ultimate way to determine which images to show. However, that currently requires a developer flag on Chrome and then user permission. Hopefully user permission won't be required for this long-term, as the headroom data is very useful for optimizing display.

#22 follow-up: @adamsilverstein
17 months ago

Thanks for all the additional details @gregbenz - fascinating!

#23 @gregbenz
16 months ago

@adamsilverstein In case you haven't seen it, there's an excellent (but Windows-only at this time) plugin for Photoshop that adds support to import and export AVIF. It even supports HDR AVIF. https://github.com/0xC0000054/avif-format

#25 @nickpagz
14 months ago

I had to manually upload all files to my server outside the WordPress media library and link each image as a URL external to WordPress

@gregbenz If it helps any, I've had to come up with some code for another site to make that process easier. Drop the code below into a snippets plugin or your child theme's functions.php file and you'll be able to upload to the media library just the same as any other image. Keep in mind there's no thumbnail generation, so you'll need to generate your different sizes offline and manually add each where you need them.

/**
* Add Mime Type
*/

function t51_add_avif_mime_type( $mime_types ) {
$mime_types['avif'] = 'image/avif';

return $mime_types;
}
add_filter( 'upload_mimes', 't51_add_avif_mime_type', 1, 1 );

/**
* Check Mime Type
*/
function t51_avif_upload_check( $checked, $file, $filename, $mimes ) {

	if ( ! $checked['type'] ) {

		$check_filetype  = wp_check_filetype( $filename, $mimes );
		$ext             = $check_filetype['ext'];
		$type            = $check_filetype['type'];
		$proper_filename = $filename;

		if ( $type && 0 === strpos( $type, 'image/' ) && $ext !== 'avif' ) {
			$ext = $type = false;
		}

		$checked = compact( 'ext','type','proper_filename' );
	}

	return $checked;

}

add_filter( 'wp_check_filetype_and_ext', 't51_avif_upload_check', 10, 4 );

#26 @gregbenz
14 months ago

Thanks, @nickpagz, I very much appreciate it. Agreed this is only a partial workaround, it's still very important to get native support in WordPress to be able to manage thumbnails and such.

For anyone else following this thread, there are a few ways to use a workaround like this to upload AVIF images to the media library, here's a pretty good list: https://wphelp.blog/how-to-use-images-in-avif-format-in-wordpress/

#27 @gregbenz
11 months ago

Related topic: AVIF gain maps: https://core.trac.wordpress.org/ticket/58289

This new specification will be a key way to share images which look great on any screen (SDR or HDR) and supporting it with the AVIF format will help ensure the file sizes stay compact.

#28 @lukefiretoss
10 months ago

This is a good update on browser support for the AVIF image format.
https://web.dev/avif-updates-2023/

Last edited 10 months ago by lukefiretoss (previous) (diff)

#29 in reply to: ↑ 22 @gregbenz
10 months ago

@adamsilverstein what about adding media library support for AVIF when ImageMagick is available in the hosting environment?

#30 @jb510
10 months ago

MS Edge was the only current browser without AVIF support. That’s changed last month and Edge 124 (Canary) now supports AVIF, which means it’ll shortly make its way into main.

At which point we can switch to AVIF first, with CDNs substituting Jpegs if the browser doesn’t support AVIF. So yeah, let’s get AVIF support into the media library ASAP.

#31 @gregbenz
10 months ago

@jb510 That's awesome, thanks!

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


10 months ago
#32

  • Keywords has-patch added

#33 @adamsilverstein
10 months ago

MS Edge was the only current browser without AVIF support. That’s changed last month and Edge 124 (Canary) now supports AVIF, which means it’ll shortly make its way into main.

I read this as well although I haven't been able to actually test this version of Canary. And of course, support will need to be in stable to be considered for core.

I have prepped a POC PR to add AVIF support to the media library - this is ready for testing, but certain things may not work as expected. Please test and report results back here!

A few other caveats:

  • the magic numbers file type detection may be incomplete (I only tested a handful of images)
  • unlike the webp implementation, the code can't detect the AVIF compression type - meaning we can't treat AVIF lossless files explicitly as lossless when processing uploaded AVIFs.

what about adding media library support for AVIF when ImageMagick is available in the hosting environment?

Right, AVIF support in the media library remains dependent on support in the underlying media library (or libraries) hooked to PHP. Otherwise you will get an error when trying to upload AVIF files. If you have a supporting environment, the PR linked above should let AVIF images work in the media library.

#34 @gregbenz
10 months ago

@adamsilverstein Understand and agree that a release for WP is best done after Edge is at stable release. Shouldn't be too far out. I saw no issues in my (limited) testing with it and would personally feel very comfortable sharing AVIF as soon as it it's rolling out without a dev flag or anything like that (there will of course be the long tail of people who haven't upgraded, but we're already at about 85% support now without Edge).

#35 @adamsilverstein
10 months ago

  • Focuses performance sustainability added
  • Keywords needs-unit-tests added

#36 @nickpagz
9 months ago

@adamsilverstein I'm doing some local testing on that PR, specifically to see how Imagemagick/GD handles the HDR avifs. What versions of Imagemagick are you using? I'm still working on getting 7.1.1 to run on my local setup.
So far I've only been able to test on 6.9.11 - which works ok for regular avif's, ie. thumbnails are generated and image editing (cropping/scaling) works. However, HDR avif's lose their "HDR" characteristics (I suspected this would be the case), and funky color profiles also won't compute, like the Hato avif versions from this site: https://aomediacodec.github.io/av1-avif/testFiles/Link-U/

Anyways, hoping to get a more recent version of Imagemagick to test this again, and also get GD library up as well, though I fear the same outcome.

I'll report back with more details as soon as I can.

UPDATE: I managed to get my local docker container php version re-compiled with the latest version of Imagemagick and ran the same tests. Unfortunately nothing changed. While avif processing works as expected, "HDR" images will lose their "HDR-ness" with any image manipulation, ie thumbnail generation, scaling, cropping, etc. I'm not sure if this is solvable without custom builds of Imagemagick, if even possible at all. Do we know if Imagemagick is capable of properly handling HDR images outside of WordPress/php? @gregbenz maybe?

I'll attempt to recompile with the latest GD library with avif support and test again, though I wouldn't expect GD to outperform Imagemagick here, but still worth the test.

Last edited 9 months ago by nickpagz (previous) (diff)

#37 @JavierCasares
9 months ago

For those who use Debian / Ubuntu...

check https://github.com/SoftCreatR/imei

git clone https://github.com/SoftCreatR/imei && cd imei && bash imei.sh
  • Compiles the latest ImageMagick release
  • Installs ImageMagick or updates ImageMagick package previously installed (via IMEI)
  • Additional HEIF/HEIC/HEIX support
  • Additional AVIF support
  • Additional JPEG XL support

#38 follow-up: @JavierCasares
9 months ago

Also, FYI (2023-06-24)

IMAGE FORMATS

VIDEO FORMATS

#39 @gregbenz
9 months ago

@JavierCasares FYI that caniuse does not reflect MS Edge Canary, which added support for AVIF a couple months ago. Unless it doesn't make final release (which seems unlikely given the stability of AVIF libraries), I'm assuming MS Edge will support AVIF (not necessarily HDR AVIF) by September. At that point, the remaining gap is basically just people who haven't bothered to update their browsers.

Safari 17 is also adding support for HEIC and JXL (JPEG XL): https://www.macrumors.com/2023/06/28/apple-releases-safari-technology-preview-173/. However, AVIF is clearly the way. These other formats seem far off (if they ever catch on - Google dropped JXL support from Chrome Canary).

#40 @gregbenz
9 months ago

@nickpagz I haven't tested HDR AVIF with ImageMagick. If you're able to confirm a loss of data, please raise a new issue: https://github.com/ImageMagick/ImageMagick/issues

When you say it loses its HDR characteristics, do you know specifically what has been lost? Does it convert and clip HLG/PQ content to a gamma EOTF?
Feel free to give me a shout over email if that's easier: https://gregbenzphotography.com/contact/

#41 @gregbenz
9 months ago

@nickpagz In addition to HDR AVIF, "gain maps" for both AVIF and JPG are key technologies for tools like ImageMagick to support. This new spec enhances existing file formats (JPG, AVIF, JXL) with a secondary (auxiliary) embedded image and some metadata. This allows a single file to render in an optimal way on SDR or HDR displays, and improves tone mapping for modest HDR screens (such as viewing an image mastered for 1600 nits on a 600 nits HDR display).

Adobe has released the specs and sample images, and Chrome Canary (both desktop and under Android 14) support JPG gain maps (under a dev flag). The results are very impressive. This is definitely the future. A JPG with SDR gain map is backwards compatible with all viewers (if your setup does not support HDR or does not understand gain maps, you just see the SDR version). However, image reprocessing by services like ImageMagick need to support it, otherwise the new output just becomes SDR JPG. an AVIF with a gain map is the ideal solution (given 30% size reduction to help offset the size of the auxiliary image) and hopefully isn't too far behind JPG gain map support.

Here's an issue I've raised requesting support for gain maps in ImageMagick: https://github.com/ImageMagick/ImageMagick/issues/6377

From a WordPress perspective, I think we just need WP to allow uploading of AVIF, and ImageMagick can handle HDR AVIF and gain maps for AVIF or JPG. This seems more suited to ImageMagick's strengths/focus and support from both isn't necessary (though a good feature to consider for core support longer term).

#42 @nickpagz
9 months ago

@gregbenz

When you say it loses its HDR characteristics, do you know specifically what has been lost? Does it convert and clip HLG/PQ content to a gamma EOTF?

I'm not sure what that means, lol, but I can share the images. I borrowed the Grand Mosque image from your site and scaled it down (by one pixel) in the Media Library. Both the original and scaled images are in this dropbox link: https://www.dropbox.com/sh/7sxcblgz3fuzvu0/AAAwjXttTkAUbVn5llrUnqZ9a?dl=0

Perhaps you can have a look and let me know.

I think what we're seeing is there's some catching up to be done by the libraries (IM & GD) in order to successfully handle images with these additional "layers" of information (gain maps, alpha channels, etc). Even if the libraries are able to handle some of or a subset of these, hosting companies will still need to compile these libraries to include the support. For example, I reached out to the system folks over at Pressable and requested they compile the GD library included with their PHP8.2 version specifically to be able to handle avif's as the "vanilla" version didn't support it out of the box.

I don't know enough about how core handles the image manipulation process to know if the code would have to change to catch up with the IM or GD library changes, but my guess is that's left up to the libraries to "just handle" the details.

Having said that, the PR by @adamsilverstein works great for "SDR" AVIF's, is a leap ahead of webp's in terms of quality and size of images, and should be merged into core as soon as possible, imo. This would allow you to still use your "HDR" images on your site, but you'd have to be careful to always display the original image in your content (vs having WordPress or your theme use one of the thumbnail/generated sizes). There's different ways to do this. Similarly, you wouldn't want your image CDN to serve manipulated versions either.

EDIT:
A quick comment on browser support. While caniuse shows good coverage for AVIF's, these are mostly for "SDR" AVIF's. For example, Safari shows support, but HDR's display very poorly. Not too long ago the HDR's wouldn't display at all. So if you do plan to use HDR AVIF's on a site, you need to figure out a fallback image to display, or be happy with either nothing displaying, or a poor version of the intended image.

Last edited 9 months ago by nickpagz (previous) (diff)

#43 @gregbenz
9 months ago

@nickpagz The converted version of the image is showing as SDR with some notable changes in metadata:

  • "Color Primaries" was SMPTE EG 432-1 and got stripped out. I believe that's P3-D65 and would be a significant issue for gamut.
  • "Transfer Characteristics" was SMPTE ST 2084, ITU BT.2100 PQ and got stripped out. That's a major issue, as PQ is the HDR EOTF.
  • "Seq Level Idx 0" changed from 1 to 13 (I don't know what this data is or if it has any relevance).
  • "Image Pixel Depth" was 10 10 10 and got stripped out. I don't know if the bad image is 10-bit or now 8-bit, but this seems like a potential issue.

Without digging further, I'm not sure if the pixels were modified or if all the problems are just in the metadata. You could probably play around with something like EXIFTOOL or AVIFENC to try to change the metadata if you need to further isolate why it is a bad conversion.

This source image of mine does not use a gain map, the problems here are with standard HDR AVIF conversion.

Agreed, the caniuse page for AVIF is not helpful for HDR. I have raised issues requesting to track HDR AVIF and HDR JPEG (gain map, aka Ultra HDR JPG):
https://github.com/Fyrd/caniuse/issues/6504
https://github.com/Fyrd/caniuse/issues/6759

Safari's tone mapping is inferior to Chrome at this stage and it does not support HDR as far as I know (does not seem to work in the current Tech Preview 173, unless I'm missing some dev flag to enable it). Chrome itself has improved quite a bit since last year (added support of HDR metadata, improved rendering of saturated HDR colors, added support for JPG gain maps in Canary, etc).

#44 in reply to: ↑ 38 @jb510
9 months ago

Glad to see HDR being talked about. AVIF Animation probably also needs through discussion. I'm personally unclear if ImageMagick properly supports AVIF animation or not.

Finally, a minor note:
Replying to JavierCasares:

Also, FYI (2023-06-24)
[...]
VIDEO FORMATS

I know video is probably a little off-topic here, but should someone reference these stats in the future it's worth noting that WebM is a container (like .mp4, .mkv, .avi, etc), not a codec like the others listed here. WebM most commonly contains VP8 or VP9 encoded video, but it can now also contain AV1 encoded video.

Last edited 9 months ago by jb510 (previous) (diff)

#45 @adamsilverstein
6 months ago

I'm assuming MS Edge will support AVIF (not necessarily HDR AVIF) by September.

@gregbenz no movement from Edge as far as I can tell, this is still behind a flag and only in Canary, right?

#46 @gregbenz
6 months ago

@adamsilverstein MS Edge supports HDR AVIF, but still under that dev flag last I checked.

Edge, Chrome, Brave, and Opera all support HDR JPG gain maps by default now (most of them on Android 14 too). Looks amazing. Support is fairly wide spread now. It's clearly the way to share HDR images now, and HDR AVIF gain maps will definitely be the way to go when there is support given smaller files and higher quality.

Chrome supports AVIF with a gain map under a dev flag. I would think that should naturally make its way to the other Chrome-derived browsers pretty quickly when ready.

#47 @gregbenz
6 months ago

Adobe just released extensive HDR support to every version of Lightroom, including the ability to export AVIF (both HDR and SDR) from any device (Mac, PC, Android, iPad, and iPhone). https://gregbenzphotography.com/hdr-images/lightroom-adds-hdr-edit-and-export/

HDR JPG gain maps are also supported for export.

HDR images can be shared quite easily in a nice-looking gallery easily from LR. When an HDR browser views the page, AVIF is used to deliver the image (otherwise JPG where HDR/AVIF is not supported). Here's an example (click to view large images for the HDR AVIF versions): https://lightroom.adobe.com/shares/99ccfca214f943e5a2fcdb76802676da

#48 @adamsilverstein
5 months ago

#59686 was marked as a duplicate.

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


5 months ago
#49

Enable support for AVIF images when LibGD supports it.

Before this change, WordPress did not properly detect GD support for AVIF when available in PHP 8.1 and above.

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

#50 @adamsilverstein
5 months ago

51228-avif-compat-php.diff expands format support detection for WP_Image_Editor_GD::supports_mime_type to include AVIF which was added in PHP 8.1.

This enables support for AVIF images when PHP's GD supports it.

Before this change, WordPress did not properly detect GD support for AVIF when available in PHP 8.1 and above.

#51 @adamsilverstein
5 months ago

51228-avif-compat-php.2.diff expands GD supports_mime_type tests to include WebP and AVIF

Also in the PR to run tests - https://github.com/WordPress/wordpress-develop/pull/5584

I'm going to break this part of the support out to a separate Trac ticket, then remove from the overall AVIF support patch.

#52 @gregbenz
5 months ago

@adamsilverstein Is WP media library support enabled if WP is using a version of ImageMagick which supports it even if PHP is <8.1? I'm not sure I understand both pathways, but it seems like both would support at SDR AVIF, right?

#53 @adamsilverstein
5 months ago

@adamsilverstein Is WP media library support enabled if WP is using a version of ImageMagick which supports it even if PHP is <8.1? I'm not sure I understand both pathways, but it seems like both would support at SDR AVIF, right?

In general, yes - Imagick AVIF support should be detected - however whether uploads or image generation will work correctly - and if those images will support HDR - is not something I have been able to carefully test. Adding complete support requires the extensive changes in https://github.com/WordPress/wordpress-develop/pull/4612

Last edited 2 months ago by adamsilverstein (previous) (diff)

#54 @gregbenz
5 months ago

@adamsilverstein Sounds encouraging, that's probably all we can ask there on the WordPress front (to support AVIF from ImageMagick, and rely on IM to output the file properly).

A fairly robust way to test HDR output is to use Adobe's Gain Map Demo App (details and a demo late in my video here: https://gregbenzphotography.com/hdr-images/jpg-hdr-gain-maps-in-adobe-camera-raw/). There will be test in the right column stating if the image is detected as HDR. This should be robust for JPG gain maps and standard HDR AVIF (certainly for anything encoded by Adobe). Viewing in Chrome to compare to the source is also an excellent test, as it has robust support for a variety of HDR formats encoded as JPG / AVIF.

#55 @phanduynam
3 months ago

Microsoft Edge 121 officially supports AVIF format and will be released in January 2024.

https://winaero.com/microsoft-edge-121-finally-enables-avif-support-out-of-the-box/amp/

#56 @adamsilverstein
3 months ago

Thanks @phanduynam! I noticed this as well in the release notes that Microsoft added AVIF support in version 1.121, release data Jan 7 2024 - see https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-beta-channel#feature-update

I also confirmed this manually be opening test AVIF images in Edge (Canary) and everything worked as expected...

#57 @phanduynam
3 months ago

So when will WordPress support the Avif image format? I hope WordPress version 6.5 will support it

This ticket was mentioned in Slack in #core-performance by adamsilverstein. View the logs.


3 months ago

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


3 months ago

#60 follow-up: @adamsilverstein
3 months ago

So when will WordPress support the Avif image format? I hope WordPress version 6.5 will support it

@phanduynam yes, 6.5 or possibly 6.6, depending on the timing of an Edge stable release with AVIF support and our beta release - the deadline for committing new features.

In the meantime, I am updating the PR and we need more testing to make sure AVIFs work as expected.

I added unit tests to the PR as well as some test reference AVIFs, these surfaced some compatibility issues with specific file types (transparent and animated AVIFs) which I addressed in the PR. These tests cover the same points as the tests for WebP.

I noticed that our wp_get_avif_info helper function doesn't detect the AVIF type (sizes work fine which is the critical thing). I think we can use the "magic number" approach we use for mime type detection to detect AVIF files on older PHP versions, but I'm not sure how reliable that is and if we really need it.

#61 @adamsilverstein
2 months ago

51228.diff includes all of the latest changes from the PR and includes tests, updated mime detection and also drops support for outputting lossless AVIF images since currently we don't have a reliable way to detect lossless AVIF uploads the way we do with WebPs.

@adamsilverstein commented on PR #4612:


2 months ago
#62

@mukeshpanchal27 - note that it looks like tests broke in `49f4278` (#4612). those variables were used on the next line where the line return compact( 'width', 'height', 'type' ); uses a weird syntax to reference them.

Anyway, that function was poorly structure and had an inconsistent return structure; it already had a default return value set later in the function so I moved that up and return it when the mime type isn't avif in `b492dbf` (#4612)

#63 in reply to: ↑ 60 @samiamnot
2 months ago

Edge 121 was released on Jan 25. I assume that this can make 6.5 now.

Replying to adamsilverstein:

So when will WordPress support the Avif image format? I hope WordPress version 6.5 will support it

@phanduynam yes, 6.5 or possibly 6.6, depending on the timing of an Edge stable release with AVIF support and our beta release - the deadline for committing new features.

#64 @swissspidy
2 months ago

  • Milestone changed from Future Release to 6.5

Let's try to make it happen! :)

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


2 months ago

#66 @adamsilverstein
2 months ago

  • Keywords has-unit-tests commit added; needs-unit-tests removed

@adamsilverstein commented on PR #4612:


2 months ago
#67

Thanks, @adamsilverstein, for the update. I've left some nit-pick feedback and suggestions. Other than that, looks good to me.

Thanks for the careful review and suggestions, I have accepted your suggestions.

#68 @adamsilverstein
2 months ago

  • Keywords has-testing-info added

Testing instructions

  • Verify your WordPress install supports AVIF -- check Tools-> Site Health -> Info tab -> (expand) Media Handling section. Either GD or Imagick must have "AVIF" listed.
  • Upload an AVIF image to a post or the media library. Some test images are available in the libavif repository.
  • Test features like cropping and rotating in the media library and the editor
  • Test viewing post in all supported browsers (Browserstack would be great for that)
  • Test using the image_editor_output_format filter to output AVIF's for uploaded JPEGs, noting JPEG/AVIF file sizes with/without the filter.
Last edited 2 months ago by adamsilverstein (previous) (diff)

This ticket was mentioned in Slack in #core-performance by adamsilverstein. View the logs.


2 months ago

This ticket was mentioned in Slack in #core-performance by mukeshpanchal27. View the logs.


2 months ago

#71 @swissspidy
8 weeks ago

Looking at these testing instructions I feel like it would be a good opportunity to add some decent end-to-end tests for all things media to core.

#72 @adamsilverstein
8 weeks ago

Looking at these testing instructions I feel like it would be a good opportunity to add some decent end-to-end tests for all things media to core.

Great idea! That said, I am still going to get this committed so it can get wider testing; the PR does include extensive unit testing similar to other image formats. Let's work on adding E2E testing for media flows overall in a separate ticket.

#73 @adamsilverstein
8 weeks ago

51228.2.diff contains all of the final changes from the PR and is updated against trunk.

#74 @jorbin
8 weeks ago

Not a blocker, but I wonder if src/wp-includes/class-avif-info.php should be conditionally loaded form wp-includes/compact.php since it is about compatibility for PHP versions below 8.2

#75 @adamsilverstein
8 weeks ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 57524:

Media: enable AVIF support.

Add support for uploading, editing and saving AVIF images when supported by the server.

Add 'image/avif' to supported mime types. Correctly identify AVIF images and sizes even when PHP doesn't support AVIF. Resize uploaded AVIF files (when supported) and use for front end markup.

Props adamsilverstein, lukefiretoss, ayeshrajans, navjotjsingh, Tyrannous, jb510, gregbenz, nickpagz, JavierCasares, mukesh27, yguyon, swissspidy.
Fixes #51228.

#76 @adamsilverstein
8 weeks ago

  • Keywords needs-dev-note added

#77 @adamsilverstein
8 weeks ago

Not a blocker, but I wonder if src/wp-includes/class-avif-info.php should be conditionally loaded form wp-includes/compact.php since it is about compatibility for PHP versions below 8.2

Missed this before commit, but I don't think so because even PHP 8.2 or 8.3 *can* lack AVIF support (my own local MAMP copies of 8.2/3 don't support it for example). I believe there is a flag added during (Apache?) build to enable support. So this is more of a capability check, we fall back to the helper when PHP doesn't return sizes (and to our mime detection when it doesn't recognize the file).

#78 @adamsilverstein
8 weeks ago

In 57525:

Media: fix AVIF tests.

Follow up to r57524. Properly add AVIF images for unit tests.

Fixes #51228.

#80 @stevenlinx
6 weeks ago

  • Keywords add-to-field-guide added

This ticket was mentioned in Slack in #core-performance by joemcgill. View the logs.


5 weeks ago

#82 @adamsilverstein
5 weeks ago

  • Keywords has-dev-note added; needs-dev-note removed

#83 @neo2k23
5 weeks ago

If i upload a avif file in the media no thumbnails are created. Using wp 6.5 beta and php 8.3 with gdlib 2.3.3

imagecreatefromavif fails to create image

https://core.trac.wordpress.org/ticket/60628

Last edited 5 weeks ago by neo2k23 (previous) (diff)

#84 @nickpagz
5 weeks ago

Have you ensured the server php and gdlib was compiled with support for "avif"? The latest versions don't necessarily mean it has avif support. From Adam's post:

AVIF in WordPress depends on support in your web server’s image processing library (WordPress has built-in support for both Imagick and LibGD for image processing). You can check for AVIF support in wp-admin by visiting Tools -> Site Health, clicking the “Info” tab and expanding the “Media Handling” section, then finally looking for “AVIF” in the list of supported formats.

#85 @neo2k23
5 weeks ago

@nickpagz please checkout this image

https://share.zight.com/9Zu4o5qp

it says so.

#86 @adamsilverstein
5 weeks ago

it says so.

@neo2k23 thanks for testing and reporting - a few questions

  • do you also have Imagick support enabled (it would show next to what your screenshot shows)? if so its possible the wrong editor is being used.
  • another possibility is the image isn't being recognized properly. have you tried a few images?
  • where are you uploading, in the media library or in the editor?

#87 @Tyrannous
5 weeks ago

Hi @adamsilverstein, @neo2k23 has since edited his comment and added a Trac ticket describing the problem: https://core.trac.wordpress.org/ticket/60628.

Does it make sense to continue there? TL;DR: AVIF support seems to be a (known?) false positive in his configuration.

#88 @neo2k23
5 weeks ago

@adamsilverstein i tried many different images. I am uploading in the media library.

@Tyrannous i will try ubuntu 22.04 this week and keep you posted.

There is also a known issue on cpanel. Not fixed: https://features.cpanel.net/topic/22319-php-8-1-gd-avif-support

About recompiling with avif support. I did not succeed. I got this message Package 'libavif-dev' has no installation candidate ubuntu 20.04 server

Found this about it on stackoverflow: https://stackoverflow.com/questions/70398133/php8-1-how-do-i-get-imageavif-to-work/78052701#78052701

Thank you all for the feedback. Get back to you once i have a ubuntu server 22.04 up and running

#89 @neo2k23
5 weeks ago

Hi All

I can confirm the issue is resolved installing ubuntu 22.04

Thank you for pointing me in the right direction. It is really appreciated.

Have a great day

#90 @adamsilverstein
5 weeks ago

I can confirm the issue is resolved installing ubuntu 22.04

Good to hear the issue is resolved for you @neo2k23, hope it goes well using AVIFs!

Note: See TracTickets for help on using tickets.