Please see AVIF (https://en.wikipedia.org/wiki/AV1#AV1_Image_File_Format_(AVI...) for an open, royalty-free alternative with similar or better performance.
And if you must use HEVC-based imaging, consider HEIF which has considerable support.
And if you must use HEVC-based imaging, consider HEIF which has considerable support.
1. The AVIF encoder I was using[0] is based off libaom, which means a 1080p image takes almost 30 seconds to encode. rav1e is supposedly much faster, so I wonder how well it would do for AVIF.
2. Almost no viewer or browser support, and what does is usually some kind of beta or preview. (VLC nightly, Windows 10 AV1 plugin[1])
[0] https://github.com/Kagami/go-avif
[1] https://www.microsoft.com/en-us/p/av1-video-extension-beta/9...
For browser support it should be possible to implement a poly-fill similar to https://github.com/UprootLabs/poly-flif which renders images in the FLIF format (https://flif.info/) into canvas elements.
FLIF as a format might be worth looking at while you are reviewing the area.
https://github.com/Kagami/avif.js
I'd rather keep it simple and not deal with more JS, and I'm OK with using JPEG for now. (I've been using mozJPEG for years)
As you mention, rav1e would help, but HEVC/HEIF is only acceptable in speed due to hardware support.
AV1 is slowly making its way into silicon, though. I'm personally interested in seeing this make its way into cameras - even when I shoot in RAW, I often just use the off-camera JPG. I'd love for that to be AVIF instead.
For that reason I'd say that if you can license HEVC, use BPG, not HEIF. And I'd love to have an AV1-based BPG version.
This is untrue. While anything written by a working group that isn't trying to get to the moon with a below-average calculator will be more complicated than necessary, it is not a kitchen sink.
Both AVIF and HEIF store just a sequence of images with metadata (EXIF, depth maps, animation frame timings, profiles, ...). It's comprehensive, sure, but not a kitchen sink.
The AVIF spec is quite readable: https://aomediacodec.github.io/av1-avif/
> The reference implementation is a ton of C++ code I would not dare to use in a security-sensitive application.
You shouldn't be concerned because the implementation is big—you should be concerned because it is of non-zero length and parsing wild data. You need a safe port regardless if you're going to play the security sensitive card. BGP being C is an equal liability.
I don't want neither BGP nor HEIF to become popular at the cost of AVIF due to being based on HEVC, but I see no significant differentiation between them—HEIF is already established and does the trick.