How to use the next-gen open-sourced .Avif image format, 50% smaller than JPEG • Hacker News Board

Re: How to use the next-gen open-sourced .Avif image format, 50% smaller than JPEG

#21

Post by SahAssar » Thu, Aug 06, 2020, 8:29 PM UTC

wonderlg wrote: post #16

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…

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.

Re: How to use the next-gen open-sourced .Avif image format, 50% smaller than JPEG

#22

Post by hkmaxpro » Thu, Aug 06, 2020, 9:01 PM UTC

I look forward to JPEG XL that is ever better than AVIF.

See the ImageCon slides and the summary from the top comment in [0], or watch the video there.

JPEG XL’s strengths: better image quality, responsive decoding, totally royalty-free (unlike HEIF container in AVIF [1]), legacy-friendly (easy conversion from JPEG, PNG, GIF).

JPEG XL standardization should be complete by the end of 2021 [1].

[0] https://news.ycombinator.com/item?id=21612708

[1] https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im...

Re: How to use the next-gen open-sourced .Avif image format, 50% smaller than JPEG

#23

Post by bscphil » Thu, Aug 06, 2020, 10:19 PM UTC

wonderlg wrote: post #16

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…

The codec you're thinking of is FLIF. [1]

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.

[1] https://flif.info

Re: How to use the next-gen open-sourced .Avif image format, 50% smaller than JPEG

#24

Post by bscphil » Thu, Aug 06, 2020, 10:26 PM UTC

hkmaxpro wrote: post #22

I look forward to JPEG XL that is ever better than AVIF. See the ImageCon slides and the summary from the top comment in [0], or watch the video there. JPEG XL’s strengths: better image quality, responsive decoding, totally royalty-free (unlike HEIF container in AVIF [1]), legacy-friendly (easy conversion from JPEG, PNG, GIF). JPEG XL standardization should be complete by the end of 2021 [1]. [0] https://news.ycombin…

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.

[1] https://afontenot.github.io/image-formats-comparison/#abando...

Re: How to use the next-gen open-sourced .Avif image format, 50% smaller than JPEG

#25

Post by Traster » Thu, Aug 06, 2020, 10:31 PM UTC

SahAssar wrote: post #21

wonderlg wrote: post #16

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…

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…

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)

Re: How to use the next-gen open-sourced .Avif image format, 50% smaller than JPEG

#26

Post by wonderlg » Thu, Aug 06, 2020, 10:38 PM UTC

SahAssar wrote: post #21

wonderlg wrote: post #16

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…

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…

I think you completely misunderstood.

> 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:

The obvious advantage is that if the window size changes, the browser only has to fetch the missing data, not a whole new file.

Re: How to use the next-gen open-sourced .Avif image format, 50% smaller than JPEG

#27

Post by tormeh » Thu, Aug 06, 2020, 10:56 PM UTC

bscphil wrote: post #24

hkmaxpro wrote: post #22

I look forward to JPEG XL that is ever better than AVIF. See the ImageCon slides and the summary from the top comment in [0], or watch the video there. JPEG XL’s strengths: better image quality, responsive decoding, totally royalty-free (unlike HEIF container in AVIF [1]), legacy-friendly (easy conversion from JPEG, PNG, GIF). JPEG XL standardization should be complete by the end of 2021 [1]. [0] https://news.ycombin…

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 b…

AV1 comes out on top of all of the comparisons to my eye. Seems to be half a step above JPEGXL, i.e. small AV1 is almost as good as medium JPEGXL

Re: How to use the next-gen open-sourced .Avif image format, 50% smaller than JPEG

#28

Post by [deleted] » Thu, Aug 06, 2020, 11:07 PM UTC

wonderlg wrote: post #26

SahAssar wrote: post #21

Earlier quoted context omitted.

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…

I think you completely misunderstood. > 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 co…

[deleted]

Re: How to use the next-gen open-sourced .Avif image format, 50% smaller than JPEG

#29

Post by bscphil » Thu, Aug 06, 2020, 11:11 PM UTC

tormeh wrote: post #27

bscphil wrote: post #24

Earlier quoted context omitted.

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 b…

AV1 comes out on top of all of the comparisons to my eye. Seems to be half a step above JPEGXL, i.e. small AV1 is almost as good as medium JPEGXL

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.

[1] https://afontenot.github.io/image-formats-comparison/#eaglef...

Re: How to use the next-gen open-sourced .Avif image format, 50% smaller than JPEG

#30

Post by FullyFunctional » Fri, Aug 07, 2020, 12:15 AM UTC

sli wrote: post #18

FullyFunctional wrote: post #14

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.

I was apparently not clear enough.

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.