Include support for the AVIF image format

[lukefiretoss]

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.

[ayeshrajans]

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

[lukefiretoss]

Mozilla Firefox
​https://www.mozilla.org/en-US/firefox/80.0/releasenotes/

Google Chrome
​https://www.chromestatus.com/feature/4905307790639104

[ayeshrajans]

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.

[navjotjsingh]

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?

[Tyrannous]

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

• Release notes: ​https://webkit.org/blog/12998/release-notes-for-safari-technology-preview-149/
• WebKit PR: ​https://github.com/WebKit/WebKit/pull/1717

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

[adamsilverstein]

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

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

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.

[Tyrannous]

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?

[sabernhardt]

#56741 was marked as a duplicate.

[gregbenz]

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.

[gregbenz]

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 likely in time).

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.

[gregbenz]

@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)?

[adamsilverstein]

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

[jb510]

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.

[gregbenz]

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

[gregbenz]

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.

[adamsilverstein]

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

[adamsilverstein]

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/

[gregbenz]

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.

[adamsilverstein]

Thanks for all the additional details @gregbenz - fascinating!

[gregbenz]

@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

[gregbenz]

Adobe has added support now for AVIF exports as well: ​https://gregbenzphotography.com/other/acr-v15-1-adds-avif-exports-and-hdro-support-for-windows/

[nickpagz]

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

[gregbenz]

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/

[gregbenz]

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.

[lukefiretoss]

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

[gregbenz]

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

[jb510]

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.

[gregbenz]

@jb510 That's awesome, thanks!

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

[adamsilverstein]

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.

[gregbenz]

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

[nickpagz]

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

[JavierCasares]

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

[JavierCasares]

Also, FYI (2023-06-24)

IMAGE FORMATS

• 83.97% ​AVIF
• 20.36% ​JPEG 2000
• 0.00% ​JPEG XL
• 0.43% ​JPEG XR
• 0.00% ​HEIF/HEIC
• 0.00% ​MNG
• 0.00% ​FLIF / FUIF / PIK
• 0.00% ​BPG
• 96.63% ​WebP

VIDEO FORMATS

• 70.25% ​AV1
• 96.66% ​WebM
• 36.03% ​Ogg/Theora
• 97.40% ​MPEG-4/H.264
• 88.31% ​HEVC/H.265

[gregbenz]

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

[gregbenz]

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

[gregbenz]

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

[nickpagz]

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

[gregbenz]

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

[jb510]

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

• 70.25% ​AV1
• 96.66% ​WebM
• 36.03% ​Ogg/Theora
• 97.40% ​MPEG-4/H.264
• 88.31% ​HEVC/H.265

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.

[adamsilverstein]

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?

[gregbenz]

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

[gregbenz]

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

[adamsilverstein]

#59686 was marked as a duplicate.

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

[adamsilverstein]

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.

[adamsilverstein]

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.

[gregbenz]

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

[adamsilverstein]

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

[gregbenz]

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