This seems pretty similar to BPG: https://bellard.org/bpg/
HEIF – High Efficiency Image File Format
11–20 of 122 posts
Re: HEIF – High Efficiency Image File Format
#12I wonder how it compares to FLIF, which looks like it has a formal release finally. http://flif.info/
Re: HEIF – High Efficiency Image File Format
#13So HEIF is for HEVC what WebP is for VP9.
Re: HEIF – High Efficiency Image File Format
#14Re: HEIF – High Efficiency Image File Format
#15Earlier quoted context omitted.
Wonder how this will work with random websites' photo upload features. Will all other browsers break because they are serving HEVC user-uploaded content? Or will iOS transcode to JPEG on upload (triggering double lossy encoding?)
How many websites don't already re-encode most of the JPEGs they're handed? Facebook does- Flickr does, though sometimes you can request the original file specifically. Imgur probably does.
Imgur very much does, with a visible loss of quality.
Re: HEIF – High Efficiency Image File Format
#16Why don't we store a url to the decoder inside images and other compressed files for maximum flexibility? I mean, looking at WASM, sandbox technology is sufficiently strong. And performance and availability aren't really an issue either, because for specific cases we can fall back to what we are doing now.
Re: HEIF – High Efficiency Image File Format
#17I wonder how it compares to FLIF, which looks like it has a formal release finally. http://flif.info/
It looks like FLIF doesn't really support lossy well (its sort of fake lossy).
"FLIF does not have a lossy mode, but interlaced files can be decoded progressively so we can simply use something like dd if=lossless.flif of=lossy.flif bs=1024 count=5"
You can see this in the examples where BPG does well in stream loading: https://nokiatech.github.io/heif/technical.html
HEIF would probably be similar to BPG in performance.
Still FLIF looks pretty darn interesting.
Re: HEIF – High Efficiency Image File Format
#18Why don't we store a url to the decoder inside images and other compressed files for maximum flexibility? I mean, looking at WASM, sandbox technology is sufficiently strong. And performance and availability aren't really an issue either, because for specific cases we can fall back to what we are doing now.
> Why don't we store a url to the decoder inside images and other compressed files for maximum flexibility?
Image formats are already some of the biggest attack surface of modern systems, "executable" image formats (hello PDF) have an absolutely ghastly track record there.
And not being able to open an image if you don't have an internet connection sounds dreadful.
Re: HEIF – High Efficiency Image File Format
#19This seems pretty similar to BPG: https://bellard.org/bpg/
The core idea does, but according to the comparison table HEIF seems to go quite a bit beyond BPG.
Re: HEIF – High Efficiency Image File Format
#20This seems conceptually most similar to Fabrice Bellard's proposal 'BPG' [1], which was essentially a lightweight wrapper around an HEVC I-frame. The format got small amounts of attention in encoding circles, but didn't pick up mainstream traction.
The image encoding layer of HEIF is the same HEVC, but the container is MPEG-4 Part 12 (the Quicktime-descendant ISO Base Media Format; the core behind .mp4, .3gp, etc.), which theoretically gives it wide support. In this structure, HEIF supports image sequences, which will help it compete with animated GIF, GIFV (which is really just a short MPEG-4 Part 14 file containing usually an H.264 video track), animated WebP (who uses these?), and WebM.
This format doesn't really blaze new ground (EDIT: it does in the sense that it defines a container format to express image-y constructs like still images and sequences of images in an ISO media container, but see my other comment that asks how this is similar but different to video [3]), but if this repackaging and the resulting code donation and political clout helps it gain traction, we still would gain a lot.
The problem, of course, is always with backwards-compatibility. WebP was aggressively promoted by Google the same way Microsoft used to promote its quirky Windows Media formats back in the early 2000s, but the WebP and non-WebP camps are still largely separate. This is unfortunate, because WebP in my opinion really isn't very good, and a backwards-compatible compressor on top of JPEG, such as Dropbox's Lepton [2] achieves similar results. Any HEVC-based image compressor is necessarily incompatible with JPEG; so broad buy-in would be required from makers of software and hardware products, from operating systems, file managers, image viewers, image editors, cameras, and the like, to really enjoy its improved compression rates, vs. being just another incompatible format that only functions inside controlled ecosystems.
The video codec AV1 currently in development was supposed to be a grand alliance of disparate companies to agree on a common format for the future, and rectify the WebM vs. non-WebM split, but continuing to promulgate sophisticated formats based on work outside of this scope (such as MPEG- or ITU-derived custom formats) just muddies this further.
[1] https://bellard.org/bpg/ [2] https://news.ycombinator.com/item?id=13230805 [3] https://news.ycombinator.com/item?id=14490734