• In countries with software patents it's illegal to use BPG without a patent license for the H.265 codec, and that patent pool is a mess. Someone needs to do BPG with AV1 payload, or just wait for browsers to finish implementing AVIF.
• JavaScript adds significant latency. Browsers request native images before running any JS, so even an infinitely fast JS polyfill already starts from a losing position. On top of that, low-end devices are likely to spend more time and energy on running the JS decoder than on downloading a larger JPEG.
I think you answered your own question right there.
I'm not going to use a dumptruck to bring a single sack of sand to my garden.
I wonder how good the performance of that decoder is, though; if the decoding delay is much longer that the network transfer delay, the approach becomes much less appealing.
That means that in most cases the main driver is lower network transfer and you need to be serving a LOT of images to outweigh the cost of having to support something new and complicated versus something as widely tested and supported as JPEG.
Not to mention it could be feature detected via browser, js and other means as an interim solution. Also, I'm pretty sure the implementation is wasm with a very thin JS shim, at least that would be my presumption as I'm not familiar with this format/project.
AVIF however may have a chance.
Key questions: (1) Is it encumbered by any patents? (2) Does a formal description of the algorithm exists, to allow for independent implementations? (3) Does a MIT/BSD or at least LGPL implementation exist? (4) Has it been submitted for standardization?
Technical merits are of limited value if you can't deploy them.
That said, I do think it's a neat project and can be used if there are proper fallbacks to formats that are natively supported.
Isn't it Fabrice Bellard?
@als0: Thanks for pointing that out.
That's not to say it isn't lower quality, when looking in detail you see it... but for a lot of use cases (and in video) much better experience in general.
Also, the latest news entry:
> (Apr 21 2018) Release 0.9.8 is available
Edit: Spoke too soon. “Official” HEIF JavaScript port measures ~500-600k gzipped, so 56k gzipped is an advantage.
Not so much anymore. The licensing fiasco with HEVC has reduced MPEG's relevance, particularly for web video. Here's what Leonardo Chiariglione, founder and chairman of MPEG, says about it:
https://blog.chiariglione.org/a-crisis-the-causes-and-a-solu...
https://blog.chiariglione.org/stop-here-if-you-to-know-about...
And they're shaping up to make VVC (https://en.wikipedia.org/wiki/Versatile_Video_Coding) licensing just as bad.
Leonardo says there is no longer a united MPEG:
https://blog.chiariglione.org/a-future-without-mpeg/
Why would anyone waste their time on a format with complex and uncertain licensing when they can just implement AV1 with its simple, royalty-free licensing?
https://en.m.wikipedia.org/wiki/High_Efficiency_Image_File_F...
Windows, OSX, iOS and Android have support baked in already
HEIF is just a generic image container format. It’s almost identical in structure to a .mp4/.mov/.av1 file (follows ISO BMFF) and can be parsed in an identical way using a simple tree structure. That’s a perfect fit for wrapping a single video I-frame as an image, the basis of all of these new image codecs.
Note that video I-frames can often only be properly rendered using metadata from outside the bitstream, such as HDR characteristics, color profile, or orientation. Sharing that metadata structure with the codec’s canonical video format is the only way to be forward-compatible.
A HEIF that wraps AV1 frame(s) is an .avif
A HEIF that wraps HEVC frame(s) is a .heic
Codecs will change, but the HEIF container is probably the last bitmap file format that we’re going to need for decades.