I wonder, why nobody mentioned Patrice Bellard's BPG[1]. It is based on HEVC and can be supported in any browser via a Javascript. From his website:
BPG (Better Portable Graphics) is a new image format. Its purpose is to replace the JPEG image format when
quality or file size is an issue. Its main advantages are:
* High compression ratio. Files are much smaller than JPEG for similar quality.
* Supported by most Web browsers with a small Javascript decoder (gzipped size: 56 KB).
* Based on a subset of the HEVC open video compression standard.
* Supports the same chroma formats as JPEG (grayscale, YCbCr 4:2:0, 4:2:2, 4:4:4) to reduce the losses during the
conversion. An alpha channel is supported. The RGB, YCgCo and CMYK color spaces are also supported.
* Native support of 8 to 14 bits per channel for a higher dynamic range.
* Lossless compression is supported.
* Various metadata (such as EXIF, ICC profile, XMP) can be included.
* Animation support.
It's great in terms of compression (close to half size of WebP for comparable quality), but:
• 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.
For an image gallery, the balance could be the opposite: a small (56k) download of a decoder allowing to show many large (a few megs each) pictures.
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.
It's also not common to need a ton of huge images all at once — in almost all applications you're either displaying thumbnails and JPEG is fine and will load faster thanks to the browser's preloader getting those requests in faster than the JavaScript can run or you're looking at something like pages where the latency is easily hidden by preloading.
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.
can is not the same as must ... there is absolutely the possibility of adding support as a binary implementation, especially with the relatively short turn around of green browsers. IE11 and Safari are the last of the old guard on this and mobile devices have a 2-3 year burnout in terms of support.
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.
It's extremely ironic then that IE11 and Safari are the only browsers to support HEVC, the rest didn't bother because of the licensing issues (which BPG inherits) severely limiting any chance it has of ever being natively supported.
Thats a great and accurate metaphor. Maybe its not a good metaphor since those compare dissimilar things with common attributes. So, this is just accurate.
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.
I just have to re-affirm I do appreciate the lower quality render path of hevc (blurry) more than the default for jpeg and others (blocky mess). I really don't visually notice the lower quality reductions at much lower quality levels/file sizes than comparable blocky formats.
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.
Of course any format can be decoded in js or wasm, that’s not an advantage and doesn’t tell us anything. The most important thing for a format is probably vendor buy-in. Why would anyone choose this over HEIF, which also uses HEVC (optional), is backed by MPEG (like it or not, MPEG represents the industry), and has vendor buy-in from Apple and Google? (I know it’s not supported in the browsers, at least not yet, but you can also use a library.)
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.
> MPEG (like it or not, MPEG represents the industry)
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:
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?
This is kind of neat, but when I think of "HEVC-based image codec" I think of Apple's .heic format. Unfortunately I didn't see a high-level comparison to HEIC on Bellard's site, so I'm not sure what the advantages of BPG are. Wouldn't I want to use the more common format?
BPG came before HEIF. It was a great proof of concept, but there’s little reason for it to exist now. BPG was an impressive one-man spec; HEIF is based on input from OS developers, camera makers, IC designers, display manufacturers, etc.
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.
