We keep hearing different variants of "webp should take over because now it has good browser support". But that is not nearly enough for an image format to reach widespread adoption.

People want to be able to open the images anywhere (what about watching photos in a smartTV? or an old tablet? what about digital picture frames?). They want to edit the images in any program (what about this FOSS editor? what about the many people stuck in pre-subscription Photoshop versions?).

They also want to ensure far future access to their precious photos, when formats like JPEG2000 or even WebP might be long gone. I mean, webp was made by Google and we know how many of their heavily promoted creations are dead already...

How in the world do people store images / photos nowadays?

Just as there is a clear winner for video - av1 - there seems to be nothing in the way of "this is clearly the future, at least for the next few years" when it comes to encoding images.

JPEG is... old, and it shows. The filesizes are a bit bloated, which isn't really a huge problem with modern storage, but the quality isn't great.

JPEG-XL seemed like the next logical step until Google took their toys and killed it despite already having the support in Chrome, which pretty much makes it dead in the water (don't you just love monopolies making decisions for you?)

HEIC is good, as long as you pinky promise to never ever leave Apple's ecosystem, ie HEIC sucks.

AVIF seems computationally expensive and the support is pretty spotty - 8bit yuv420 might work, but 10b or yuv444 often doesn't. Windows 10 also chokes pretty hard on it.

Alternatives like WebP might be good for browsers but are nigh-unworkable on desktops, support is very spotty.

PNG is cheap and support is ubiquitous but filesizes become sky-high very quick.

So what's left? I have a whole bunch of .HEIC photos and I'd really like if Windows Explorer didn't freeze for literal minutes when I open a folder with them. Is jpeg still the only good option? Or is encoding everything in jpeg-xl or avif + praying things get better in the future a reasonable bet?

Of course there are tons of better formats than JPEG but it needs to be understood that the most important feature of JPEG is to be exchangeable. It doesn't matter what your shiny new web browser supports, JPEG is considered supported everywhere and all editorials actually refuse to accept anything other than JPEG. You can't just break everyone's workflow because Google decided to force WebP (for purely selfish reasons, of course). The web browser is actually one of the least important platforms for JPEG. To day JPEG still executes its mission perfectly and with huge bandwidth increases it doesn't even matter how large the file is.

Beyond the compression (which is amazing), JPEG is also extremely fast when implemented well. I'm not aware of any other image format that can encode at 60fps+ @ 1080p on a single CPU core. Only mild SIMD usage is required to achieve this. With dedicated hardware, the encode/decode cost quickly goes to zero.

I struggle to understand the justification for other lossy image formats as our networks continue to get faster. From a computation standpoint, it is really hard to beat JPEG. I don't know if extra steps like intra-block spatial prediction are really worth it when we are now getting 100mbps to our smartphones on a typical day.

Because JPEG just works. It is not the best by far, but everybody supports it, and it is usually not worth saving a few bytes in exchange for worse support, added complexity and extra processing.

Lossy compressed images are usually not the most significant consumers of bandwidth and disk space. Videos are. That's why there have been a lot more focus on video formats than anything else, there is a lot to gain here, not so much with still images.

JPEG-XL is super-complicated because it supports plenty of things most people don't really need.

Webp is somewhat better supported because it is backed by Google, it is also what is essentially a single frame video, so if you did the hard work on video (where it matters), you get images almost for free, and it saves Google a tiny bit of bandwidth, and "a tiny bit" is huge at Google scale.

We are seeing the same thing with audio. MP3 (1991) is still extremely popular, the rest is mostly M4A/AAC (2001). We pretty much have had the perfect audio format now, which is Opus (2012) and yet, we don't even use it that much, because the others are good enough for what we make of them.

The article only briefly mentions the real problem: outside of browsers, proper support for .webp files is very, very low. That's why JPEG is still king and probably still be for a long time.

I loved the article, but it overlooks one important point: although the JPEG format is frozen, encoders are still evolving ! Advances such as smarter quantization, better perceptual models, and higher-precision maths enables us achieve higher compression ratios while sticking to a format that's supported everywhere :)

This takes me back to when the goal of a webpage was to be less than 1Mb. At the time, the only reason to use PNG (such luxury) was when you needed transparency.

The variable compression of JPEG was very important. In Photoshop you could just grab an image and choose the file size you needed and the JPEG quality would degrade to match your design constraints.

While the article is mostly good one glaring technical error annoys me.

"The stronger the cosine transformation, the more compressed the final result" is simply wrong.

DCT (and the inverse DCT) are transforms that transform between "sample" and "frequency" domains, it's well defined should be perfectly reversible without compression (iirc the one in JPEG should be lossless given as many bits as the samples themselves).

The trick of DCT based compression is that humans don't notice when information disappears from higher frequencies(also in _natural images_ there is often little data in high frequencies, often lots of 0 that can be immediately cut).

So harder compression means removing more high frequency data from storage without it being too noticeable when reconstructing samples from the frequency domain at decompression.

Conversly however, if you have "sharp edges" in the sample data you need more higher frequencies to reproduce the sharp edges without "ringing" artefacts (this is why you will see noisy blocks around text in highly compressed JPEG's with text since it runs out of bandwidth to adjust).

The frequency domain values, and how compression affects removing various frequencies(black and white in the filter images) can be illustrated on the wikipedia filter comparsion example image below. (low frequencies are in the upper-left corner of the filter and spectrum images whilst higher frequencies horizontally are to the right and higher vertical frequencies are towards the bottom).

https://en.wikipedia.org/wiki/File:DCT_filter_comparison.png

https://en.wikipedia.org/wiki/Discrete_cosine_transform (Mainly "Example of IDCT" section towards the bottom but also the preceding ones).

We started using AVIFs recently in picture elements with fallback to JPEG, and I'm a pretty big fan. The compression is good, the tooling is decent. They're supported by most things natively.

Browser support for AVIF is nearly good enough that you might not need the fallback in reality. The only real problem I have encountered is that animated AVIFs are super stuttery in Safari for some reason.

The amazing thing about JPEG is people are still squeezing out backwards compatible compression improvements 30 years later. Mozjpeg is well known by now, but Jpegli was just published last year and does even better at high bitrates[1]. It's hard to want to adopt newer formats when they keep getting squeezed by further improvements to good old JPEG.

[1] https://opensource.googleblog.com/2024/04/introducing-jpegli...

EDIT: I was wrong, and had PNG and JPEG formats backward. As others correctly pointed out PNG is lossless where as JPEG is lossy. PNG is better for marketing / UI / artistic imagery and JPEG for photographs due to the tolerance for JPEGs lossy encoding with photographs, seems to be the generally accepted opinion now.

Regardless, since the picture tag[0] was introduced I’ve used that for most image media by default with relevant fallbacks, with WebP as default. Also allows loading relevant sized images based on media query which is a nice bonus

[0]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

The single biggest things that could be done to remedy this in order

1) snipping/clipping/screenshot tool outputs webp

2) convert to webp on ctrl-c ctrl-v from browsers

3) whatsapp/messenger/discord support. People will say these work fine, in my experience its a gamble, which is shouldn't be. It should be seamless, literally no edge cases

> These days, the format is similar to MP3 or ZIP files—two legacy formats too popular and widely used to kill.

Are MP3's not dying out gradually, like, say, WAVs have? I mean, do people/organizations actually encode anything to MP3 rather than AAC, these days?

The reason JPEGs still rule is because Google Chrome removed support for JPEG-XL, the actually better photo format, because the Google guys who did AVIF decided they don't want competition.

I love how the article implies there's something flawed about webp at the end ... but if you click the link the only "flaw" reported is that webp isn't ubiquitous enough yet, so some sites don't support it

Perfect logic: let's not switch to webp because it's bad. Why is it bad? Not everyone has switched to it yet.

> These days, the format is similar to MP3 or ZIP files—two legacy formats too popular and widely used to kill.

While killing MP3 might be difficult, the vast majority of people aren't handling audio files themselves these days, so probably not hard to phase out fairly rapidly.

I have written a JPEG, GIF, and PNG decoder. All easily weekend projects. As for the other two I've attempted the same for:

JPEG2000: insanely complex and nonintuitive, especially the edge-cases and overly flexible encoding decisions

WebP: also complex, and effectively Google-proprietary

JPEG-XL on Chrome is a perfect example of why Google should have Chrome taken away from it.

> It’s been difficult to remove [old JPEG] from its perch. [...] the formats AVIF and HEIC, each developed by standards bodies, have largely outpaced [JPEG]

I'm currently sticking to JPEG because, last time I tried, JPEG came out as the best format. Referencing my memory at https://chaos.social/@luc/113615076328300784

- JPEG has two advantages on slow connections: the dimensions are either stored up front so the layout doesn't jump, or maybe the renderer is better; and it loads a less-sharp version first and progressively gets sharper

- JPEG was way faster when compressing and decompressing

- on the particular photo I wanted to optimise in this instance, JPEG was also simply the best quality for a given filesize which really surprised me after 32 years of potential innovation

Regarding AVIF, my n=1 experience was that it "makes smooth gradients where jpeg degrades to blotchy pixels, but at decent quality levels, jpeg preserves the grain that makes the photo look real". Gradients instead of ugliness at really small sizes can be perfect for your use-case, but note that it's also ~80 times slower at compression (80s vs. <1s)

JpegXL isn't widely in browsers yet so I couldn't use it

> These days, the [JPEG] format is similar to MP3

The difference with mp3 is that Opus is either a bit better or much better, but it's always noticeably better.

You can save ~half the storage space. For speech (audio books) I use 40kbps, and for music maybe 128kbps which is probably overkill. And I delete the originals without even checking anymore if it really sounds the same, I noticed that I simply can't tell the original apart in a blind test, no matter what expensive headset setup I try

TFA attributes it to a simple "they were first" advantage, but I think this is why "Why JPEGs still rule the web": no file format is better than JPEG in the same way as Opus is better than MP3; in that you don't have to think about it anymore and it's always a win in either filesize or quality

That said, Opus is also annoyingly hard to get into people's minds, but I've done it and you also see major platforms from compress-once-serve-continuously video (e.g. Youtube) to VoIP (e.g. Whatsapp) switching over for all their audio applications

I want to add a slightly off topic point here.

This submission was originally shown as [dead]. I have no idea why, I read some of the content and seems decent enough, especially in the current state of things when JPEG-XL is blocked because of AOM / Google Chrome. I vouched for it and upvoted, then somehow it is on the front page.

I wonder if dead means somehow flagged it. If so, then why? If not, why is it dead?

I'm surprised some multi-encoder container format didn't take over by now, seeing as there is no one size fits all clear winner so far.

I'm sure that I'm not the only person here being reminded by this that over 30 years ago they were being amazed by viewing JPEGs on their Amiga using HAM mode...

The actual issue is that this is not an issue for the users. Only global providers, so they were the ones pushing "obscure" solutions. Music fidelity was more of a consumer problem, so formats like FLAC found a foothold besides the go-to one.

I notice webp produces images about 20% smaller than mozilla jpeg while appearing slightly sharper. I use a <picture> element to offer webp versions first but always include jpeg versions for future-proofing.

I've no single clue as to the future of image formats. All or them (or almost) have merits and stuff they suck at. I've been building a service which makes no judgement about it but tries to provide all the choices. JXL will be added soon:

https://kraken.io

JPEG: No active patents, universal support, good enough.

HEIC: Have fun licensing this.

WebP: Slightly better than JPEG maybe, but only supports 1/4 chroma resolution in lossy mode so some JPEGs will always look better than the equivalent WebP.

AVIF: Better than JPEG probably, but encoders for AV1 are currently heavily biased towards blurring, even at very high bitrates. Non-Chrome browser support took a while.

It's the VHS of digital image compression and storage.

DO NOT USE WEBP

JPEG-XL is the superior format. The only reason WebP exists is not because of natural selection, but because of nepotism (Google Chrome).

https://www.reddit.com/r/AV1/comments/ju18pz/generation_loss...

> Thirty-eight years later, we’re still using the GIF—but it never rose to the same prevalence of JPEG. > The GIF was a de facto standard. The JPEG was an actual one

I know this is IEEE but seriously? JPEG won because it was a formal standard?

Didn't JPEG win because it supported more than 256 colours and, with the lossy compression, greatly reduced file size and bandwidth needs for our cat photo and porn collections?

While proposed replacements ... solve what problems?

There are only two kinds of image file formats: the ones people complain about and the ones nobody uses.

How come jpeg 2000 never became popular?

As others have pointed out, JPEG is just fine. It's "enough" in the best sense of the word and gets its job done. It's supported on every device, in every browser, image viewer and whatnot. It. Just. Works.

Maybe there are formats that compress better or lossless, but thanks to advancements in disk space and transfer rates (I know, not everywhere but penetration and improvement will happen...) the disadvantages of JPEG can be handled and we can just enjoy a very simple file format.

In an era where enshitification lingers around every corner I'm just happy that I don't need to think about whether I have to convert _every digital picture I've ever taken_ into some next-gen format because some license runs out or whatnot. It just works. Let's enjoy that and hope it sticks around for 30 more years.

The last part of the article about jpeg being outpaced seems anecdotal or unsubstantiated, it needs context.

There is an photo example for quality levels throughout the article but instead of classical JPEG compression artifacts it just seems to get progressively more posterized. What's up with that.

So there are two use cases for public image dissemination:

1. Lossy: JPEG fills this role;

2. Lossless: this was GIF but is now PNG; and

3. Animated: GIF.

So for a format to replace JPEG, it must bring something to the table for lossy compression. Now that JPEG is patent-free, any new format must be similarly unencumbered. And it's a real chicken-and-egg problem in getting support on platforms such that people will start using it.

I remember a similar thing happening with Youtube adding VP9 (IIRC) support as an alternate to H264, which required an MPAA patent license. The MPAA also tried to cloud VP9 by saying it infringed on their patents anyway. No idea if that's true or not but nobody wants that uncertainty.

Anyway, without total support for VP9 (which Apple devices didn't have, for example) Youtube would need to double their storage space required for videos by having both codecs. That's really hard to justify.

Same goes for images. You then need to detect and use a supported image format... or just use JPEG.

“Because it has a 30 year head start. And there are better, new, formats coming all the time; but everyone supporting them hates each other.”

I'm trying to replace jpeg with avif in my use cases, but some sites still don't handle avif.

Even Github! Though the latter doesn't support IPv6 either.

Nothing supports WebP.

Most websites break with WebP. Desktop tools choke on WebP.

It sucks, because it's a good format.

I think it's about time we switched from JPEGs to Rust.