[BurningCycles]

>Likely the format with the best chance of overthrowing the jpg/gif/png incumbents is AVIF

I used to think the same as well, however I now think Jpeg XL is poised to be the 'winner' among next gen image codecs. It's royalty free, great lossy and lossless compression which is said to beat the competition, as well as providing a perfect upgrade path for existing jpeg's as it can losslessly recompress them into the jpeg XL format with a ~20% size decrease (courtesy of the PIK project).

It's slated for standardisation within a couple of weeks, it will be very interesting to see large-scale comparisons of this codec against the likes of AVIF and HEIF.

[marton78]

JPEG XL is a terrible name for something that claims to produce extra small results.

[jonsneyers]

It may not be the best name, but it sure is better than the names of the projects it was based on: PIK and FUIF. At least if you speak Dutch. A "pik" is a penis and a "fuif" is a party, so the combination would be the "penis party" image codec. I prefer "JPEG XL".

The etymology of the name "XL" is as follows: JPEG has called all its new standards since j2k something that starts with an X: XR, XT, XS (S for speed, since it is very fast and ultra-low-latency), and now XL. The L is supposed to mean Long term, since the goal is to make something that can replace the legacy JPEG and last as long as it did.

[stingraycharles]

There might be an explanation around it, but I find it not much better than Apple with their iPhone XS. I agree that XL is a bad name, and I don’t think that “pik fuif” would matter a lot (I’m also Dutch).

Could have been e.g. JPEG PF or JPEG LTS.

[l8rlump]

PIK project is also a terrible name for people who understand Danish.

[gardaani]

I hope that JPEG XL will be simpler than the competitors. If it's compression ratio is similar to AVIF and it can do HDR, then I'll all for it!

AVIF (and its image sequences) seems to be fairly complicated. Here's few comments [1] about it:

"Given all that I'm also beginning to understand why some folks want something simpler like webp2 :)"

"Despite authoring libavif (library, not the standard) and being a big fan of the AV1 codec, I do occasionally find HEIF/AVIF as a format to be a bit "it can do anything!", which is likely to lead to huge or fragmented/incomplete implementations."

Anyway, instead of adding FLIF, AVIF, BPG, and lots of similar image formats to web browsers, I think only one good format is enough and JPEG XR might be it. After something has been added to web browsers, it can't be removed.

Safari hasn't added support for WebP (which is good, there's no need for WebP after AVIF/JPEG XR is out) and it hasn't added support for HEIF (which is weird, considering Apple is using it on iOS), but maybe they know that there's no need to rush.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=960620...

[sk65535]

WebP version 2 is in the work at AOM: https://www.youtube.com/watch?v=zogxpP2lm-o

It is complementary to AVIF (which targets photo capture more than delivery over the web).

WebP2 is like WebP: keep it simple, with only useful and efficient features, no fancy stuff. And aim at very low bitrate, it's the current trend, favoring image size over pristine quality.

Progressive rendering uses ~3x more resources on client side. So, instead, better have efficient 300-bytes thumbnails in the header.

[ksec]

>I think only one good format is enough and JPEG XR might be it.

I think you meant JPEG XL here? JPEG XR [1] is a completely different thing.

[1] https://en.wikipedia.org/wiki/JPEG_XR

[jhabdas]

Browsers don't need the codecs anyway. They just need Wasm and a decoder. Clients can do the work[1] until the hardware supports the goods.

[1] https://git.habd.as/comfusion/fractal-forest/src/branch/mast...

[bscphil]

The example you linked to is pretty telling, because not only do the BPG images decode more slowly than natively supported images, the javascript decoding approach apparently breaks the browser's (Firefox's) color management. I think native support is needed for newer codecs to be viable for more than simple demos.

[spider-mario]

Chrome appears to interpret the canvas as sRGB and to convert from that, but that means that images decoded that way are effectively limited to sRGB until the canvas API allows specifying other colorspaces.

[bscphil]

In Firefox, these canvas images appear stretched into the full gamut of the monitor (oversaturated), even though I have a color profile and have full color management enabled in about:config.

[mceachen]

Interesting. Where have you seen that adoption will be swifter with JPEG XL instead of, say, AV1/AVIF?

(Speaking as someone who's seen several open, licensing-unencumbered image/video/audio formats fail to get traction with a majority of browsers).

[Scaevolus]

This presentation covers why AVIF isn't a great replacement for JPEG-- mostly that it's slow, complicated, and lacks a progressive mode.

https://www.slideshare.net/cloudinarymarketing/imagecon-2019...

[thaumasiotes]

Why would the lack of a progressive mode matter? How is a progressive mode better than a "loading..." spinner?

[TheRealPomax]

I'd by far rather see several full article-appropriately sized sideline image at only progression step 1 or 2 out of 5 or 6, than several empty boxes all showing spinners while the images load in.

Plus I'd love the ability to say "I'm on a low bandwidth, $$$ per megabyte network, stop loading any image after the first iteration until I indicate I want to see the full one" because you almost never need full-progression-loaded images. They just make things pretty. Having rudimentary images is often good enough to get the experience of the full article.

(whether that's news, or a tutorial, or even an educational resource. Load the text and images, and as someone who understands the text I'm reading, I can decide whether or not I need the rest of that image data after everything's already typeset and presentable, instead of having a DOM constantly reflow because it's loading in more and more images)

[jstummbillig]

Progressive mode is better than a loading spinner in the same way that PWAs are better than a loading spinner: By getting mostly usable content in as little time as possible to the user you decrease perceived wait, you decrease time to interactive and you increase perceived loading speed (even though time to full load might be the same or slightly increased).

[supportlocal4h]

Progressive photos always irritate me. The photo comes on my screen all blurry and out of focus and I'm disappointed that the moment I thought I had captured didn't turn out. Then, 3 seconds later, the picture changes and gets slightly better. Then I'm hopeful, but disappointed again. Then i think, "maybe it's not loaded yet", so i wait and hope. Then 2 seconds later it changes again. Is it done? Is it loaded now? Will it get better? Is my computer just dog slow? How long should I wait before I assume it's as good as it's going to get?

I know it's a small thing and doesn't really matter, but I don't like progressive photos.

Edit: This is just one context. There are plenty of other contexts where progressive is very useful.

[TheRealPomax]

On the other hand, it also doesn't constantly change the DOM, moving you across the page because images above what you're reading are getting swapped in and now you're looking at the paragraph above the one you were reading.

and again.

oh, and again.

and-

[ksec]

The progressive mode in Jpeg and JPEG XL is quite different, because the quality is so much better your perception of it changes. Where Progressive Jpeg are literally useless before it finish loading, JPEG XL provides decent quality.

[mrob]

In the common case that you don't actually care about the picture, you decrease actual wait, not just perceived. Progressive mode lets you ignore it before it's fully loaded.

[TheRealPomax]

true progressive mode actually gives you something usable before it's fully loaded, to the point where "not fully loading" can be entirely acceptable. If all images load "first iteration" first, you have a stable DOM that won't need to reflow in any way as each image goes through the rest of its progressive layers. And having a nice setting that says "only load up to X on slow networks" and "require image click to load past first iteration" would be godsend, even on gigabit connections. If I could bring the size and load time for modern webpages back down to "maybe a few 10s of kb" and "immediate" rather than "2.9MB and a second or two", I'd happily turn those options on.

[thaumasiotes]

> Progressive mode lets you ignore it before it's fully loaded.

Huh? It's obviously easier to ignore the spinner than to ignore a low-res image. You've seen the spinner before.

[GoblinSlayer]

Did you confuse terminology? Web progressive is sort of an antonym to graphics progressive.

[jstummbillig]

How so? Progressive JPEGs load in multiple passes. The first pass trades fidelity for speed, successive passes add quality over time. Seems pretty much in line with what PWA is all about.

[thaumasiotes]

> By getting mostly usable content in as little time as possible to the user you decrease perceived wait

See, this is the issue. Progressive images aren't "mostly usable content"; they're vague, ugly blobs.

[spider-mario]

It entirely depends on what progressive steps you define / where you stop loading.

[nathan_long]

Imagine this: you set your browser to download only the first N bytes of each image, showing you a decent preview. If you want more detail on a particular image, you tap it, and the browser requests the next N bytes (or the rest of the file, if you prefer).

And to enable this, the site only needed to create one high-resolution image.

Seems like a victory for loading speeds, for low-bandwidth, and for content creation.

I think FLIF looks incredible.

[edflsafoiewq]

Agreed, but is it likely? Does any browser implement the even simpler feature "Show a placeholder for images. Tap the placeholder to load the actual image"?

[ChrisLomont]

Systems that render low res can download the prefix of the file and show an image, and stop there. Many modern image formats support this for precisely this reason. If you then want higher quality for some particular image, you can download more, not having to start over with a separate image file.

[est31]

The talk is by the FLIF author. One of the big marketing points for FLIF is its progressive mode. Of course every other codec will be criticized for not having one.

[nsomaru]

The theory goes that it’s better to show the user something resembling the final image than showing them a generic loading spinner.

[BurningCycles]

>Interesting. Where have you seen that adoption will be swifter with JPEG XL instead of, say, AV1/AVIF?

Well, it's not finalized as of yet (though it is imminent), so rate of adoption is just pure guesswork at this stage. However, things I deem necessary for a new image codec to become the next 'de facto' standard are:

royalty free

major improvements over the current de facto standards

Both AVIF and Jpeg XL tick these boxes, however Jpeg XL has another strong feature which is that it offers a lossless upgrade path for existing jpeg's with significantly improved compression as a bonus.

[rjvs]

So you're suggesting that the advantage JPEG XL has is that it will compress existing JPEGs better than FLIF or AVIF?

[BurningCycles]

Yes, it losslessly recompresses existing jpeg's into the jpeg XL format, while also making the files ~20% smaller, key point being lossless. Thus it is the 'perfect' upgrade path from jpeg which is the current lossy standard, as you will get better compression and no loss in quality when shifting to Jpeg XL.

This being a 'killer feature' of course relies on Jpeg XL being very competitive with AVIF in terms of lossy/lossless compression overall.

[setr]

I'm assuming this is bidirectional? You can go back from XL to jpeg losslessly as well? If thats the case, I'm having trouble imagining a scenario where you're not correct; it'd be an utterly painless upgrade path

[ubercow13]

Looks like yes [1]

>A lightweight lossless conversion process back to JPEG ensures compatibility with existing JPEG-only clients such as older generation phones and browsers. Thus it is easy to migrate to JPEG XL, because servers can store a single JPEG XL file to serve both JPEG and JPEG XL clients.

[1] https://jpeg.org/jpegxl/index.html

[BurningCycles]

>You can go back from XL to jpeg losslessly as well

I don't think so, but I don't quite see the point unless you are thinking of using it as a way to archive jpeg's, but in that case there are programs specifically for that, like PackJPG, Lepton etc.

[lukevp]

Sounds like it will just take an existing JPEG and reduce the size, but not re-compress it - so even though the original JPEG is lossy, there will be no additional loss introduced, whereas another format not based on JPEG would require a re-encode pass that would lose additional information.

[modeless]

Does it have the feature where the file can be truncated to any size to form its own thumbnail? That would be an incredibly useful feature in so many applications.

[Scaevolus]

It has a progressive mode, but not as aggressive of one as FLIF.

[ralusek]

Surely not any size. It'd have to be squares or something for that to make any sense, right?

[someguyorother]

Some wavelet formats (SPIHT and EZW e.g) have the property that truncating the lossless version at 10% of the size gives you the 10:1 lossy rendering of that picture. That property holds not just for 10% but for any fraction of the file.

It's not quite the same thing, but a very highly compressed high-res picture would probably look okay in thumbnail format.

[Dylan16807]

Some amount of data at the end of the file won't be usable, but it's easy to make a format that's resilient to you chopping anywhere.

[edflsafoiewq]

It sounds interesting, although my initial impression is that it sound like it will suffer from the same daunting complexity that afflicted JPEG 2000.

[janwas]

Good news: the reference software (http://gitlab.com/wg1/jpeg-xl) can decode about 50 Megapixels/s on a single Skylake core, with 3.1-3.7x speedup on 4 cores.

Encoding throughput is configurable from ~1 MP/s to about 50 per core. That's somewhat slower than JPEG, but can be faster with multiple cores.