My hot take on image formats

I think about image formats too much. Now you have to as well. webp is great! jpeg-xl is cool but not ready. AVIF is fine. png and jpeg need to stop being our defaults.

SOURCES

S/O Ph4seon3 for the awesome edit 🙏

[hatchibomb]

This comes off poorly. You haven't given any evidence to suggest a massive difference in loading/rendering speeds between JPEG-XL and alternatives and even at 33:07 you show a diagram suggesting the decode speed of JPEG-XL is better than alternatives. Supporting JPEG-XL in the browser makes sense.

[FunctionGermany]

JXL could save TONS of bandwidth by losslessly converting JPEG to JXL by the platforms / web hosts. and according to cloudinary, decoding is also fast. theo talks a lot about CPU but i'd love to see some data comparing WEBP and JXL decoding performance. also a lot of websites, including many image boards, don't have lowres/blurry versions, so progressive loading as part of the image format is a blessing in my opinion.
some forums have tons of huge images but slow bandwidth and browsing threads with massive PNGs is a bit painful.

[Winnetou]

On the Google doesn't support JPEG-XL because CPU costs... that's a cop-out. They've been asked multiple times, including by companies like Adobe, to implement it and they just straight up refused also acting like nobody cares about JPEG-XL. You can say whatever you want, but if you read the chromium thread about it, it's clear as day that Google DECIDED against both JPEG-XL and the community with no technical reasoning. Of course, they didn't say out loud why.

Also, the CPU costs of JPEG-XL cannot be the only reason of rejecting it. There's loads of other use cases. Not to mention the forward looking of, JPEG XL is alone in the amount of features it provides/support that is outside of just some 300x300 images on a random website. You can have wide color gamut and HDR in it. People taking high-detail high resolution photos, can put the original images directly as jpegxl. But Google directly jumped in to say "nope, cannot see that directly in the browser. Think of the children in Africa!". I'll stop, my blood is starting to boil. I see that close to the end of the video these extra features were mentioned, so at least I'm at peace that Theo saw that.


- I'm totally on the webp that it is good and it should still be supported as the bridge to JPEG XL.
- AVIF has nice features, but it's a dead-end technology, we shouldn't bother putting more effort into it.
- JPEG XL is truly the next generation of image formats and what we will use for decades. Hence why it's so infuriating of Google actively being against it and slowing massively its adoption. No, I'm not buying out the CPU cost argument. That's not the browser support problem. In a world where a website has a 6.6 MB JPEG with .png extension image, there's PLENTY of room for JPEG XL.


Lastly, I really want to see benchmarks of just how slow JPEG XL supposedly is. I found out a benchmark, apparently from 2020 which unfortunately doesn't have a comparison to webp. And just citing X or Y MB/s is meaningless when you don't webp on the same exact hardware, as the numbers can differ massively from one CPU to another. Not to mention that 4 years have passed, things might've changed.


EDIT:
Initially mentioned about JPEGXL being lossless, but Theo corrected that very quickly.


Also mentioned about PNG: PNG not being compressed ? Duuuude .... It's not a good compression for photographs (hence why people still use JPEG for that, it looks basically the same to a human, if you don't need to zoom in, and it is a smaller size as a JPEG). But PNG itself totally has compression. And multiple ways in which you can reduce the file size. There's a reason TinyPNG exists (or existed, didn't check recently)

[canadianavenger]

This was really hard to watch. I normally enjoy your videos and insights. However in this one right of the gate you made some pretty serious technical mis-statemets that really diminished your credibility on the subject.

Firstly PNG files are compressed, in fact they do not support uncompressed pixel storage. Lossless does not mean uncompressed, and compressed does not mean lossy like jpeg, if it did general purpose compression like ZIP couldn't exist as it would be garbage out on the other end. PNG uses a lossless compression scheme similar to that of zip files, which is why it will not really compress significantly further if you try to stuff it into a compressed archive (in fact you are likely to see expansion). But make no mistake the PNG file is meaningfully compressed from its raw uncompressed form.

SVG really shouldn't have been included as it is a vector based format. Also note that it can be compressed, using gzip compression internally IIRC, (you do NOT want lossy compression on a vector format). SVG files will be much smaller than the png or jpeg equivalents, provided it is actually a vector graphic being represented. (anyone using a SVG to encapsulate a bitmap really needs to look for a new career) While a SVG can encapsulate a bitmap image, doing so would not be efficient. I wouldn't recommend doing so unless you were operating in a hybrid form where you needed a vector based overlay or (vector based) clipping region, and in both cases this could be better accomplished by other means.

Bottom line, every format has its place and purpose. JPEG is great for photographic images, but sucks when pixel clarity is needed (like a screen capture), or where colour accuracy is required. PNG on the other hand excels at maintaining both pixel clarity and colour accuracy. SVG is for when you want a vector based representation that can be scaled to any resolution without loss in clarity.

[ElVerdaderoAbejorro]

You started by saying AVIF isn't good because 1) CPU costs and 2) It's suitable to encode videos but not images and that Webp has better quality at decoding images.

The problem is that that benchmark you showed at the end clearly puts AVIF ahead in terms of quality, invalidating point 2 (unless they have nitpicked the data).

As for point 1, I believe you are severely underestimating "shitty CPUs". The whole point is to save on bandwidth. It doesn't matter if the decoding takes a few milliseconds more if you are saving hundreads of milliseconds on the download of the image, you'll still gonna be able to show more images faster with AVIF.

[mauriciabad]

JPEG-XL is not just for the web, you have to consider that too. It can be used for so many things that currently don't have a user-friendly format, such as x-ray scans, 3D images, astrological images, CMYK prints, feature-rich map tile sets, somehow a .psd equivalent, and many more use cases.

Another great use case you don't consider is for storing your photos' library. It supports: HDR, raw, photo bursts, depth map for portrait, live photos, huge storage savings, fast previews, etc.

JXL focuses on being future-proof and versatile, not just web-friendly.

[zyansheep]

I think the issue people find here is not that it is _currently_ better to use JXL, obviosly it is better to use webp due to better support. JXL is a better format technically though, and even the CPU issue is mostly an issue of time. I think people are mad at what they preceive as big browsers not wanting to even _open the door_ for developers to try something better.

[msclrhd]

One of the dichotomies here is that Google created WebP and pushed/forced it on everyone, while with JPEG XL (not created by Google) they are saying that they are not willing to support it for similar reasons that could have been levied at WebP at the time it was introduced. Google are using their browser dominance and market share to force out a potentially better format, despite interest from major players/websites.

[shirkit]

This video shows the strong points of AVIF and JPEGXL and shows that PNG and JPEG are just ancient formats, as well shows that WebP is now starting to get old and should be replaced.

[Nodsaibot]

"google is not some evil company" lmao oh how sweet

[nobodyofconsequence]

5:35 no

no no no no no no no nono

That's a horrible analogy for how svg works.

It's more like an SVG is a cookbook and a JPEG is a cake. One is the finished product and one is instructions to make that product.

[xdanic]

Oh, I came early, but there's already a mistake before the 3 minute mark that people corrected, png IS compressed, but lossless, and does a fantastic job at it, better than gif and better than jpeg when you have flat colors, svg would quality as N/A, since representing shapes with the instructions to draw them can be extremely very efficient, you could even go into wether you can have lossy 4:4:4, webp doesn't have that, jpeg, avif and jxl do, the rabbit hole can go quite deep

[HarrisonBorbarrison]

I hope one day, JPEG XL will be ubiquitous too.

[petrkdn]

16:08 sure but just because Chromium would be able to support JXL doesnt mean EVERY image on the internet has to be JXL. Just because JXL is supported doesnt mean everyone will use it. If you browse the internet, you will know, even though WebP exists and you believe it to be the best one so far, doesnt mean every website will use it. You can see jpg, png, webp, svg on regular basis if you browse the internet, even though according to your research, jpg and png isnt exactly the best..

[hopperelec]

A well-written SVG is generally much more performant than it’s bitmap representation, so I disagree with giving it a cross. If you lazily convert a bitmap to an SVG, then yes it’s probably gonna be worse performance because there isn’t really a good way to convert from bitmap to vector meaninfully. But, if you’re designing an icon, it’s probably much better to export as (or even better, write from scratch) an SVG

[dungeon]

What CPU cost. If you are going to talk about cpu cost so much then at least show us that.

Also browsers shouldn't be the ones deciding which format is used and isn't used. People should have the option to use whatever they want and let the market figure out the rest. Because cpu isn't a reason to not support any file or video format.

[papakamirneron]

Not adopting a format “for the consumers” is the lamest excuse I’ve ever heard, that could at least give us the damn choice, maybe a setting to limit Jxl render quality.

[ElementalCode]

Fun fact: PNG data is kinda zipped. That's why zipping (or gzip) a PNG doesn't do much

[natediven]

So JPEG XL *may* take too much CPU power for _some_ internet users so google is going to favor their own format and not support the other, while also keeping other formats that have the same issue as JPEG XL? This doesn't need to be a war between WEBP and JPEG XL, because we can have both. JPEG XL is undeniably an amazing image format that has tons of use cases on the web. WEBP can be used where it makes sense, and JPEG XL can be used where it makes sense. Developers can choose which image format they want to use on their own.

[lightascend]

2:24 JPEG XL supports lossless, and it's the current best.
31:55 JPEG XL isn't "resource-intensive" as you would believe: it does not require a hardware-accelerated routine to be fast, it's decode times is not that far from WebP. AVIF on the other hand is much more expensive; without dav1d from VLC or hardware acceleration, it's fucked through and through.