HEIF is the Nokia-developed, MPEG and ISO-blessed container for image sequences and transforms, which is published as MPEG-H Part 12, and is based on the good-old ISOBMFF, which you typically recognize as the ".MP4 container". HEIF's most wide deployment right now is on Apple iPhones, where it's the new default capture format for still images and 'live' images (effectively, a short video on either side of a high-res still).
AV1 is the AOMedia-developed, Google/ex-On2/Xiph.Org/Cisco consensus video format that's the evolution of the VP8/VP9 line and Daala.
This format takes the nice royalty-free state-of-the-art MPEG container and puts a royalty-free payload in it, making it a useful best-of-both-worlds.
Visually, I think AV1 adds less DCT-ish noise, but tends to blur small, low-contrast details a little more than x265. (Compare the ends of tree branches on the default image, Crepuscular Rays, or faraway tiles and details in Mercado dos Lavradores. Haven't done objective measurements though--you may disagree.) I, personally, like AV1's tradeoffs better, at least from what I see there. Patches of ringing draw attention, whereas slight blurring is something we're used to ignoring since it comes from lots of things besides codecs; natural vision and camera images aren't completely sharp either. (Dunno why AV1's that way, but might be that it does more aggressive deringing with that filter Monty's posting about next.)
The photo caption on the comparison in this story suggested the same conclusion re the detail vs. noise tradeoff, for what it's worth: https://www.cnet.com/news/google-mozilla-av1-photo-format-co...
The paper on the deringing filter included subjective tests, and it suggests that test subjects liked its results more consistently than you might guess from the changes in objective metrics--small sample size though: https://arxiv.org/pdf/1602.05975.pdf
Sometimes you may want x265's bias towards more detail; in the Tiger image, AV1 "cuts" the whiskers near the top of the image shorter than x265 does. Tricky to 'teach' encoders that some detail is more important than others despite both being equally low size or contrast.
Given they're both a ton better than JPEG, the big advantage to AV1 for a random developer is the openness; we can use it w/out needing to either take a legal risk or lean on the implementation of some company that's dealt with the HEVC patent mess for us.
Once I get past that, some of the test images look better on AV1, and some look better on x265. Some of them kill detail here, some of them kill detail there. I think this is a victory -- both of them perform really well, considering, and allocating a bit more bits to get it looking nice is always an option.
It's good to have a royalty-free codec that's actually good, and with much more profile and fanfare than just a weird garage-band secret project like VP9 was. And with widespread hardware support, it may actually make a dent in JPEG's marketshare.
It's confusing how people seem to use HEIF to mean container. And if HEIF is actually the container, then what is the payload in Apple's case, and what exactly is HEIC?
HEIC is an ISOBMFF 'brand' to be used inside the container to indicate that the payload's codec is HEVC (in 'Main' profile or 'Main Still Picture' profile), and that it's one still-image and not a sequence .
In most of the cases where the payload is the HEVC codec, the corresponding file extension is encouraged to be .heic and the MIME-type follows as well. Apple has a note about this in their transcript at WWDC 2017 .
 https://nokiatech.github.io/heif/technical.html  https://mpeg.chiariglione.org/standards/mpeg-h/image-file-fo....  https://developer.apple.com/videos/play/wwdc2017/513
HEIF/AVIF is a complex kitchen sink of all the features that a mobile camera app may dream of, so it supports arbitrary collections of images and videos, e.g. "live" photos, tiles, bursts, subtitles, multiple layers, multiple versions.
FLIF is reported at 59.57% avg space savings
AV1 (2018-02-22) is reported at 66.02% avg space savings
Does anyone know about this?
The print production world doesn’t need war file formats. It rarely operates in a bandwidth restricted environment. And any new image format would take years to be sufficiently supported by all relevant software packages.
For most images most the time, conversion to CMYK should be a last minute operation that takes into account source and printer profiles. The only immediately obvious exception I can think of is graphic artwork which should be stored as vectors anyway (with embedded pixel graphics where necessary).
This is all entirely in the hands of Adobe.
My point still holds for CMYK though — bandwidth optimisation is rarely a concern for intermediary files. In fact, it's common to see compressed files rejected for being "low quality" based on file size and with no regard for the actual image fidelity. In this industry, formats like TIFF are sufficient.
If one was to propose a replacement for TIFF, it would need to support a lot more than just CMYK. Off the top of my head, it would need full alpha, embeddable profiles, 16 bit support, arbitrary channels, spot colours and vector clipping paths.
(As for CMYK conversion: even if you are touching up photographic colours for CMYK, this should be performed within the RGB space and soft proofing. The final conversion to CMYK should occur at print-time unless there's an excellent reason otherwise, e.g. if you are applying CMYK-inspired graphic art effects.)
The print/prepress industry has a long history of devices with asymmetric resolution, or higher resolution in monochrome versus color (similar to 4:2:0 pixel format used in digital video).
Considering professional print/prepress machines last 20 or more years in-service you have to handle just about everything.
For example, an image with pixel dimensions of 1800 by 1200 and a “DPI” metadata value of 300 will print with a physical dimension of 6.00 by 4.00 inches.
Many film scanners for instance are say 2400 dpi vertically and then some other DPI value horizontal depending on the film or picture format. Anamorphic lenses are used to scale a wide-aspect image onto a 4:3 sensor.
Some scanners and printers even have different DPI for different color components.
If you want to print, PDF is probably still your best bet.
Since there are plenty of reasons you don't care about this metadata (e.g. to reduce the transfer size on images that are requested millions or billions of times by a web browser), as much as possible it should be left optional.
But all of this seems to be pretty much draftware at the moment, so we'll see how things shake out.
Keep it separate: make something that encodes image data separately and then use some container that to wrap it nicely. Same shit that works for jpeg should be reused IMO, it just works (all that metadata), simply replace coded image data with a better encoder (AV1)
I mean, it's not as if media is going 3D and VR right this moment (or even in the last few years) or anything...