Make WordPress Core

Opened 3 years ago

Last modified 3 days ago

#51228 assigned enhancement

Include support for the AVIF image format

Reported by: lukefiretoss's profile lukefiretoss Owned by: adamsilverstein's profile adamsilverstein
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Media Keywords:
Focuses: 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.

Change History (31)

#1 @ayeshrajans
3 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 3 years ago by ayeshrajans (previous) (diff)

#3 @ayeshrajans
3 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.


2 years ago

#5 @navjotjsingh
2 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 2 years ago by navjotjsingh (previous) (diff)

#6 @adamsilverstein
22 months ago

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

#7 @Tyrannous
11 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
11 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
9 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
9 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 9 months ago by Tyrannous (previous) (diff)

#11 @sabernhardt
8 months ago

#56741 was marked as a duplicate.

#12 @gregbenz
8 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
7 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 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.

Last edited 7 months ago by gregbenz (previous) (diff)

#14 @gregbenz
7 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
7 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
7 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
7 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
7 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
7 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
7 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
7 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
7 months ago

Thanks for all the additional details @gregbenz - fascinating!

#23 @gregbenz
6 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
4 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
4 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
4 weeks 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
11 days ago

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

Last edited 11 days ago by lukefiretoss (previous) (diff)

#29 in reply to: ↑ 22 @gregbenz
4 days ago

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

#30 @jb510
4 days 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
3 days ago

@jb510 That's awesome, thanks!

Note: See TracTickets for help on using tickets.