Years ago I remember seeing a progressive image format that was supposed to solve the resolution issue. The loader could stop loading as soon as it figured it had enough quality. This meant that you could have a single, large image file, that could weigh a few KB when displayed as a thumbnail.
It’s 2020 and its mind-boggling that this isn’t a standard behavior already.
Imagine right-clicking on a thumbnail and being able to natively save a 4MB file from it.
Imagine having a single <img> that can be zoomed in all the way to 100% just like your phone’s Photos app can do, without loading the whole image beforehand.
The issue with doing this is not with the basic idea, obviously it would be desirable if we could do it, but with the fact that it's actually much less efficient to encode the entire file this way if you want real progressive loading (i.e. stop at any point). It's much more reasonable at present to just dynamically load a reasonably sized image for the current viewport, even before you get to issues like format support.
That argument ignores everything that new formats and container formats can allow for. And if the argument is to put older formats "first" then you need to download older formats first to get the features of new formats and need to figure out the order of competing modern formats (like JPEGXR vs JPEG2000 vs WEBP).
This is basically a solved problem when people use mime types properly for formats. For sizes we'd need a similar way to mime types to ask for a size, html solves this for images with srcset but I'd rather it be within the transport mechanism rather than in the markup.
Requesting an image should be requesting a image, not a specific representation of that image. The representation should be part of the content negotiation that is already a part of the protocol.
> Requesting an image should be requesting a image, not a specific representation of that image.
This is exactly what I’m saying. The image is one, it’s the browser that decides how much of it to load.
It’s the current picture/srcset-based situation that is “a specific representation of that image”
> For sizes we'd need a similar way to mime types to ask for a size
Now that is complicating things. Suddenly the server has to produce/return different resources based on a header. The solution I described could be delivered by any dumb HTTP2 server, without preprocessing.
Technically what I’m describing is already possible with any progressive format like JPEG; The only missing part is that the browser should pause/resume the loading as it sees fit.
All I want for Christmas is:
<img src="you.jpg" progressive>
The obvious advantage is that if the window size changes, the browser only has to fetch the missing data, not a whole new file.
I think what they were descrbing was more like this: A JPEG uses a Discrete Cosine Transform and then throws away the lower power (higher frequency) values, but does it in a fixed way(blocking). If you re-order the data such that you get all the blocks dc frequency first (rather than all the frequencies for block 0 first) you can stop at any time and you'll have the resolution you "paid" for - ie, your bandwidth is all used for resolution. It's not a bad idea, although I suspect the reason this isn't done is because you don't really need to decided between a 72kb and 73kb image, and in reality there's more to different resolution images than just saving fewere bits (read: interpolation techniques)
Good catch! We were moving quickly trying to get this blog post out before the standard was implemented. We've updated this and it's now a smaller file size.
The .avif file in the example was accidentally saved as larger than the JPEG file which makes it a poor use case. We compressed the .avif file with the correct compression quantizer with avifenc to higlight the difference.
The JPEG file is 112kb and the .avif file is now 55kb.
One thing that's really great about JPEGXL is that it seems to be intended for use at the high end, e.g. larger files, more bits / pixel. Most of these newer codecs are based on the intra frame of video codecs, which are all optimized to look good at the lowest possible bitrate. (And even high bitrate video is usually much lower quality than what we use for static images.) I suspect there are a lot of easy gains to be had here, and actually I wish someone would look at doing a high quality royalty free video codec with the intent to target high bitrate applications. (It's noteworthy that a lot of professional applications like DCP use an image codec, JPEG2000.)
For anyone looking for some image comparisons between AV1 and JPEGXL, someone updated the classic "image format comparison" on Github and added it. [1] Important to note that all these are a little unfair to JPEGXL, because it's explicitly targeting higher bitrates than most of the quality levels you see here, and it still comes out looking pretty good at the higher bitrates.
I find JPEGXL much better at medium and large sizes for the sorts of artifacts that bother me, on most images. For example in this [1] comparison, AV1 is clearly degrained, losing the very fine detail.
Note that achieving high quality results at low bitrates is not really a goal of JPEGXL, or the codecs it's based on. For example the PIK readme contains the following note:
> It prioritizes authenticity, a faithful representation of the original, over aesthetics achievable by by hallucinating details or 'enhancing' (e.g. sharpening/saturating) the input.
So as I noted in the OP, it's not a very fair comparison with bitrates this low, but I think JPEGXL holds its own.
It's a missed opportunity that we can't just one 1 frame AV1 files as images. Had this been anticipated we wouldn't have to push two standards and two implementations everywhere.
There are already a few formats that work just like JPEG but for modern video formats. Some of them even compress better (FLIF). They just haven't caught on at all. JPEG just has so much momentum.
Those other formats weren't developed by huge corporations who can force it into browsers through pure hegemony. That's probably a factor.
The missed opportunity is that AV1 is arriving everywhere and with tiny bit of foresight they could have made that include a new image standard which everyone would then have as well with essentially no additional support needed. Instead we now have to convince all browser vendors and more to support yet another image format that has no widespread adoption.
We're really excited about this image format -- for the same image quality .AVIF compresses 50% smaller than JPEG, 20% smaller than WebP and is free to use.
There is a polyfill for old browsers but our recommendation would be to use the graceful degradation of the <picture> tag which falls back to <img> if .avif or .webp is not supported.
FLIF seems to compress higher but to my knowledge there is no major browser support. AVIF support is scheduled for Firefox 80 and Chrome 85 by the end of this month (August 25).
Nice to note, though, is that FLIF tech will not just be thrown away. FLIF was superseded by FUIF which was then superseded by JPEG-XL. It's doesn't have as great compression in all cases as FLIF, but I'm very optimistic about JPEG-XL being a highly adopted new image format.
It’s 2020 and its mind-boggling that this isn’t a standard behavior already.
Imagine right-clicking on a thumbnail and being able to natively save a 4MB file from it.
Imagine having a single <img> that can be zoomed in all the way to 100% just like your phone’s Photos app can do, without loading the whole image beforehand.