Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for AVIF image conversion #491

Open
3 tasks
maxime-rainville opened this issue May 3, 2022 · 4 comments
Open
3 tasks

Add support for AVIF image conversion #491

maxime-rainville opened this issue May 3, 2022 · 4 comments

Comments

@maxime-rainville
Copy link
Contributor

As a project owner I want access to the latest and greatest image formats.

Acceptance criteria

  • Any image format can be converted to AVIF
  • AVIF images can be uploaded to the CMS.
  • If your hosting environment does not support AVIF, the feature is disabled.

Note

  • Only PHP8.1 support AVIF currently. Most common PHP builds won't even enable it. So testing this might not be trivial.
@kinglozzer
Copy link
Member

Do earlier PHP releases support AVIF through Imagick, if ImageMagick is compiled with support for it?

@GuySartorelli
Copy link
Member

GuySartorelli commented May 3, 2022

If your hosting environment does not support AVIF

How is this defined? You mention PHP < 8.1 doesn't support AVIF, but AVIF is just a file. PHP shouldn't care what the format is of a file - that's up to implementations within PHP to decide how to handle it.

In other words someone could define a custom converter using the conversion API defined in #489 that works in PHP 8.0. I wouldn't want core to say "Yeah but because you're not on PHP >= 8.1 you can't use that."

It would be better, I think, for the conversion API to have a method like canConvert($from, $to). If none of the registered converters can convert to AVIF, then the option can be hidden. But it shouldn't be PHP version dependent.

@maxime-rainville
Copy link
Contributor Author

Do earlier PHP releases support AVIF through Imagick, if ImageMagick is compiled with support for it?

Not sure ... maybe.

I guess one thing we could do is just make support for AVIF one extra module you need to install and its your job to figure if your system supports it our not. The downside is that this requires a conscious choice from developer.

If we ship it in some common module, then you will automatically get it and your site might start generating AVIF images without you even having to think about it.

It would be better, I think, for the conversion API to have a method like canConvert($from, $to). If none of the registered converters can convert to AVIF, then the option can be hidden. But it shouldn't be PHP version dependent.

Just because, you have PHP8.1, doesn't mean you can generate AVIF image. I tried enabling AVIF locally in my environment with PHP8.1. My PHP8.1 version wasn't compiled with AVIF support because a required binary doesn't ship by default with Ubuntu. I was still able to upload AVIF image to the CMS and use them in WYSIWYG. However, the CMS always outputted the original image even when I was telling it to resize it.

I think we would need to check that a specific method exists.

Maybe in the "output images in multiple formats" module we can have conditional check to detect if AVIF is supported and that could call some lower level API like canConvert($from, $to).

@forsdahl
Copy link
Contributor

Shouldn't this just be handled as a manipulation by the Image Manipulation backend? At least that is how we have implemented this. Both GD, ImageMagick and libvips support avif and webp conversion with the correct versions, and all of these can be used as image manipulation backends via the intervention image drivers.
Encoding a file in different formats as an image manipulation does need some changes to SilverStripe\Assets\FilenameParsing\NaturalFileIDHelper and SilverStripe\Assets\FilenameParsing\HashFileIDHelper though, so that the actual files outputted by the manipulation will both include the original file extension in the filename (so that the original filename can be inferred) and the new file extension as the actual extension.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants