JPEG VS AVIF - The Battle of Compression

[@I922sParkCir]

As a professional photographer, I prioritize color accuracy over file size. I really like JPEG XL and would love it if everyone one could switch to it. I want my cameras to shoot in Raw+JPEG XL and browsers and my gallery software supported it. JPEG XL is free so all it would cost is development time. Not cheap, but a big step forward.

[@Yay295]

The iPhone 16 supports JPEG XL in their ProRAW container, though I suppose you're probably not using an iPhone for professional photography.

[@I922sParkCir]

@@Yay295 I was excited for that! More adoption! I wish there was an option for all of the iPhone shooting modes. Hopefully Sony and Fujifilm (my camera systems) adopt JPEG XL.

[@Gameplayer55055]

​@@Yay295I don't have an iphone, but it looks like macos understands jpeg xl

[@NeXMaX]

Yes, please!

[@rand0mtv660]

@@Gameplayer55055 yeah Safari supports it as well since version 17. That should be the Safari version released roughly a year ago with macOS Sonoma. Downside is that it doesn't fully support the format. It only supports still images, but not animated images. Animated images are part of JPEG XL format, so it's basically a replacement for GIF as well.

[@isaacdies]

It's a shame Chrome won't implement JPEG XL

[@Levi_OP]

@@isaacdies not only do they not implement it, they have refused the prospect of implementing it in the future, claiming "it lacks interest" or some BS

[@TheMinipasila]

reimplement* (because they actually supported it previously)

[@ReddoFreddo]

It's also strange considering JPEG XL was developed in part by Google

[@magicalhobo3000]

@@TheMinipasila They never actually "supported" it in the technical sense, they just had "experimental support" as an option that tech-savvy users could enable, but they never ended up supporting it by default.

[@tamius-han]

@@Levi_OP I mean they're right, the only companies who expressed interest are small startups like Facebook and Adobe and Guardian and Shopify, just some small and irrelevant names most people probably haven't even heard o- no I can't finish that statement with a straight face.

[@ded5351]

Philip you've been a gateway into me being passionate about things no other tech channel has even remotely made me interested in with these rant/comparison videos (and the rest tbf), and I think that's kinda neat. Bonus points for making your stuff super easy to understand so I can sound like I know things on stuff I *don't* end up researching either.

[@qudruplem8570]

couldnt have said it better myself

[@katnax3059]

I wanted to say simmilar thing. It's like a woman in love is listening to bf's rants and interests. Phillip makes interesting content about niche things and it's so calming to listen.

[@MermaidTyrone]

PLEASE talk about HDR images!! It's so fascinating and most people don't know about them!

[@valley-artifact]

he's got an older video called "HDR is a hot mess" where he talks about it quite a bit

[@MermaidTyrone]

@@valley-artifact Yeah but things have changed since then, now many Android phones support them as do iPhones also Instagram, and there's also something we all love, competing standards

[@MarvoldX]

and i want him to include HDR10 and the screens with max brightness of 400nits i want to see what can i do with my screen to make it work, or whats the stuff that could work with it? what settings effect, ...etc, and nah i watched yt, its not very useful, 1 video of kliks worth thousands videos on yt

[@KopfdesRiesen]

@@MarvoldXHDR400 is mostly useless on standard ips/tn/va panels. Honestly you either need OLED or Local dimming for real HDR

[@GameBacardi]

HDR is crap, you need correct hardware. Most hardwares do not meet those specifications for HDR.

[@ordinarryalien]

All my homies prefer JPEG XL.

[@Petch85]

I too am a big fan of compression algorithms. JPEG, 7-zip, FLAC etc. It is just such fun. I love to use lossless formats, but I think the lossy algorithms are the most fun. But the balance between data size, encryption speed, decryption speed and quality is just such a fun problem to me. 💕

[@tarakivu8861]

That you havent mentioned zstd is a crime against compression

[@Petch85]

@@tarakivu8861 I wish I would say it got lost in the lossy compression of a yt comment... But honestly I have never heard of zstd 🤷‍♂. I made a quick google and it looks to me to be an optimized version of the zip format. I will see if I can find a good description of the algorithm somewhere. Maybe I have bin missing out 🙂

[@Silverdev2482]

@@tarakivu8861 about to say that. People may hate me for it but my tar archives are zstd compressed.

[@Sopel997]

@@tarakivu8861 yep. zstd with maximum window size (2GB) absolutely blows away all other compressors for a lot of types of content (for example a lot of files that share content. My zstd-based skyrim save compressor gets roughly 5-10x better compression than slowest 7-zip. A simple tar->zstd is 3-5 times). I guess it's not very well known because it's not an end-user format specification.

[@cno9984]

Did you mean encoding and decoding?

[@2dozen22s]

There's a neat bit regarding web stuff and archiving, you can losslessly convert JPEG to JPEG-XL so you can mass convert your old images without quality loss. JPEG-XL is a really impressive format tbh in both quality and features. Also on either being used for high quality images, its important to note AVIF tops out at 10bit vs JPEG-XLs 32, and AVIF has a res cap of either 4k or 8k iirc? Exceeding it you can have issues at the edges of blocks. jxl has a nonsensically high max cap tho.

[@vadnegru]

Shortcoming of a format made for video

[@alangeisse]

May I ask what to use for the conversion of JPG to JXL? Thanks

[@AlexanderPrussak]

@@alangeisse it saves space and you can theoretically serve both files (jxl -> jpeg conversion is most likely a lot faster than jpeg -> jxl conversion)

[@NutchapolSal]

@@alangeisse search for "codepoems xl converter". they use the term "JPEG Recompression" so look for that in the manual

[@ArvFlash]

@@AlexanderPrussak im pretty sure hes asking for what software to use, which i recommend libjxl

[@handlemonium]

*GOOD NEWS:* Apple bakes-in JPEG XL as an image format save option on the iPhone 16 family.

[@WinterPhoenix8780]

iPhone 16 Pro only, as a ProRAW option

[@Xaymar]

I found through months of testing that AVIF tends to hallucinate things in to or out of existence. This hallucination problem would continue until the lossless preset with all available encoders. And the darkness issue with avif is also a significant problem.

[@Xaymar]

I tested sRGB, wsRGB, Bt2020 and various other things, in 2k, 4k, 8k and 16k. Overall, jpeg-xl was ahead in compression speed, decompression speed, PSNR. AVIF was ahead in VMAF and SSIM, but due to the hallucinations tended to fall behind. Both are definitely trying hard, but for overall use cases i currently prefer jpeg-xl over AVIF.

[@MoireFly]

I suspect the dark-crush AVIF issue is a matter of encoder tuning. This kind of stuff is very sensitive to the psychovisual tuning, and since AVIF originates in video codecs, it's plausible it's crushing blacks more because in motion they're even less discernable than in stills. It's quite possible a different encoder (or future version of this one) will do better. But these kind of comparisons are hard to interpret without a heavy emphasis on the encoder (not just the codec) used. Even for hyper-legacy JPEG there are very considerable quality differences between encoders, and surely for AVIF and JXL there are tunable knobs and version-dependant details that matter quite a bit.

[@kajojo2399]

I feel that with how cheap SSDs and other storage hardware has become, compression has become more obscure to the average user, most don't know that PNG is losless and JPEG is lossy, let alone what AVIF and JPEG-XL are. Its good to see a gaming oriented youtuber cover this topic.

[@GreenJalapenjo]

Every user feels the effects of different compression formats though, since size is still important for images on the web.

[@li_tsz_fung]

So much of our life is on the cloud, and enterprise level network price

[@alphex-is]

this has nothing to do wuth storage, its bandwidth thats the concern.

[@gr.4380]

wait till apple hears about how cheap storage is

[@aprofondir]

SSDs still haven't become "cheap", they've been hovering around the same price per gigabyte for the past five years or so

[@Legitti]

Been using AVIF as web dev for few years already. Very good 🎉

[@EuropaYou]

One of the reasons why I prefer JPEG XL over AVIF is the speed of converting JPEG to JPEG XL. Another reason is that converting image files from JPEG to JPEG XL does not noticeably change the quality. Since your previous JPEG-XL video, there has been a development that Firefox and Chrome will support JPEG-XL in the upcoming Rust with a secure, performant, compact and compatible JPEG-XL implementation.

[@leeroyjenkins0]

I don't think there's been any talk about that for chromium. I know the google research team is planning on *trying* to merge a fast/secure implementation into Firefox but I don't think Chrome team has changed its mind yet. I don't even think chromium can integrate rust code at all, unless they expose C bindings just for chrome *shrugs*

[@EuropaYou]

@@leeroyjenkins0 It's still a new format, if big companies like Apple and Adobe continue to keep supporting it, it *will* eventually be supported.

[@jkm4505]

Wow, for one single time doom scrolling actually helped! Love to be early :) I'm hoping for JPEGXL to live and get put into mirrorless cameras!

[@safebox36]

I'm glad someone is talking about JPEG XL, I stumbled upon it a few weeks ago but people I've spoken to seem conflicted on its perceived benefits of having one format that handles one scenario vs multiple formats that handle different ones.

[@yuro1337]

yo should've used the encoders directly via cmd instead of photoshop as they are usually outdated in third party software

[@johnathanmcdoe]

This also makes it possible to switch on some features individually and to look at what these presets actually do. You can for example do the AVIF artificial grain trick in JXL at low quality, which would have done a lot of heavy lifting. And encoders are still under heavy development.

[@rand0mtv660]

I think this is a more realistic scenario where a user might use some 3rd party software for this work. Although, if a more scientific comparison was the goal, using encoders directly would be better.

[@Razerblue6]

​@@rand0mtv660Right, but it's more so the problem that third party software don't often update the encoders/decoders used. Photoshop and almost every other piece of software still use the reference encoder/decoders, just outdated versions. What I'm trying to convey is that what is shown in the video is not a limitation of the format, the difference between v0.9 and v0.10 of the JPEG-XL reference encoders is already big enough as example.

[@retrocomputing]

@@rand0mtv660chances are, you haven't encoded any webp yourself, but used webp on hundreds of websites already. So the more realistic scenario is that images are encoded by web apps/CMS and not desktop software.

[@EmergedFromReddit]

Yeah, the AOM AV1 encoder has had huge updates recently. AV1 encoders and decoders are moving at lightning speed. The dark region problem is already solved by SVT-AV1 but it is only for video. AOM is yet to fix it

[@numberlessconglomerate]

Good to see image format comparisons. There is a big hype arround AV1 and VVC, but not many people seem to talk about elephant in the room - image formats. Maybe that's because of Google drama with JXL. JPEG-XL is obviously superior for the web. AVIF would be a good format for archiving images at lower filesize (with lower quality). I doubt there are many people doing that. Visually lossless is probably to-go solution for anyone trying to archive images. I did recently test couple of those "modern" image formats with monochrome PNG image, and JPEG-XL did worst: both lossless, and visually lossless. WEBP and AVIF were superior when it comes to size. I didn't test WEBP enough tho. I only did tests on default settings, and despite file not being much smaller than AVIF I have noticed very little visual artifacts. Got to do more tests!

[@tteqhu]

archiving images at a lower quality? But why? Buying more HDDs is probably cheaper than converting millions of images by newer codecs.

[@pawepiat6170]

How is JPEG-XL superior for the web? The smallest 200 KB photos were much better looking in AVIF for the low cost of few discolored pixels. Only in 500, and 1500 KB range JPEG-XL might have won (but I can barely notice a difference in 1500 photos anyway personally, both look good). The 500 KB smoshing of dark areas might be bad for pixel peeping, but I wonder how it looks in real life on cheap LCDs and stuff. At 200 KB the progressive loading is a negligible benefit since even old HSPA+ can do over 1MB/s. Only the oldest GPRSM would struggle at like 20KB/s, and even then 10s for a better looking photo VS it being worse but faster is a crappy choice. But then again with wide LTE rollout we can easily stuff our web with 2MB per photo and call it a day. At that point both formats perform the same for me. Apparently JXL has better colors, but I don't see it and would rather have a cheaper device since AVIF is royalty free (JXL has a free implementation, but you can't check it since the standard isn't free lmao) Modern websites can embed multiple formats, perhaps leaving it up to (power) users' choice could be possible? Also, waiting for webp comparasion thats surely coming from Philip one day :D Edit: I commented one minute before the end and now I see the sandwitch lol. I was writing on the assumption that saving bandwith for the user is important, but as I noted those are laughable file sizes anyway, and progressive decoding might make JXL worthwhile. Still mad about licensing and ISO though...

[@EmergedFromReddit]

@@pawepiat6170 There's a workaround to adding progressive decoding to AV1: It's by making an animated AVIF that contains two frames: The first frame being an ultra low quality image and the second being the high quality one. Once the second image loads, the animation will go to the next frame and stop, effectively giving you progressive decoding.

[@what42pizza]

Dude I watched the miracle of video compression literally yesterday

[@marvinochieng6295]

me watching in 360p : "hmm... yes it is an improvement"

[@benpeach23]

Watching this video at a specific distance (based on your phone screen wise and w/e) and defocussing your eyes makes it like a magic eye! Trippy

[@Chrissi33004]

Is anyone else shocked that were able to compress a 10mb png file to 180kb and still recognize whats displayed?

[@leeroyjenkins0]

Sufficiently advanced compression is indistinguishable from magic! AVIF looks crazy at high compression!

[@taukakao]

It's such a shame that browsers dropped JPEG XL. Progressive decoding is a perfect match for the web. Also, it's one of the obvious features that at least I have thought about in the past and didn't realize that it already exists.

[@Catzzye]

I LOVE JPEG-XL! LET'S GO JPEG-XL! For the people that say JPEG-XL is dying and browsers are dropping support for it, think again! iPhone 16 shoots in JPEG-XL under certain conditions and there will soon be avalanche of JPEG-XL images ready to be shared online, so I expect the browsers to reimplement the deprecated features very soon. Great video, looking forward to more

[@Veriflon88]

one of the coolest features imo that you didn't mention: you can recompress existing jpegs with no quality loss. You can even get the byte-for-byte original jpeg from such a jpeg-xl-file. You won't get the smallest possible file size in this mode, but it's impressive cool nonetheless

[@leeroyjenkins0]

No but you still get a substantial reduction in size and getting the original byte for byte is invaluable in some scenarios. It's also very fast as far as recompression goes in that mode.. Moving all my archived jpg files to jxl was not a difficult decision. The only reason not to is if you need web support or for sharing.. *chrome womp womp noises*

[@alangeisse]

@@leeroyjenkins0 May I ask what did you use for the conversion to JXL? Thanks

[@leeroyjenkins0]

@@alangeisse cjxl (compress/encode JXL), it's based on the reference implementation. It usually comes as libjxl-tools or something like that in package managers. If you run it on a jpeg the default should be to preserve quality and exif data, but I would still check the manual

[@Speechrezz]

Great video! I love seeing these kinds of comparisons. Would also be interesting to compare the WEBP format to these two.

[@DiThi]

Something worth comparing is also how much computation it needs to decode. JXL is the clear winner in that regard. AVIF relies on hardware decoding of AV1 to be efficient, while JXL is very efficient in any device.

[@volz0r]

Good video! I only wish you had done a pixel-to-pixel difference heatmap compare between the formats and the original. It would have been a really great way to quantify the actual differences, in a way that anyone can understand.

[@priyanshusharma1812]

I didn't know I needed to know about photo compression formats until you posted, awesome content

[@kylek29]

For anyone who wants to do a comparison .. you can use Photoshop's (or any graphics editor) layer blending modes to compare the changes visually. Set the base image as the original, then put a layer of the compressed one directly above it and the blending mode to "Difference" -- the more the compression, the more you'll see (no-changes is all black). It's a quick way if you're trying to find the best looking codec.

[@alexmathewelt7923]

Actually, that's only half of the picture 😂 since jpg works with fourier transforms, it is possible to have negative and positive differences. In GIMP there's another mode (which i forgot) with no change at 50% gray and negative/positive differences mapped accordingly to 0-50 and 50-100%. Maybe there's also a mode for absolute difference, since than we would have good contrast from black to any small change

[@Petch85]

Omg. I would love it if signal (the messing app) converted images to JPEG XL when sending them. I feel like most images would be fine at ~500kb and 1080p (maybe 1440p). If I am just taking a picture on vacation and want to show people what I am experiencing.

[@YgorCortes]

Awesome video! Can't wait dor the HDR comoarison!

[@spotsies]

I personally find these things interesting to scratch at, but ultimately I just want people smarter than me to come up with good standards and use them, implement them in easy, straightforward ways. Informatics and especially mathematics is just so obscure and hard to warp my head around.

[@YoutubePizzer]

I’m an AVIF enjoyer personally. AV1 encoding is dope enough that I think it’s really cool to kinda unify the compression formats for images and video, specifically for the web.

[@maxmustsleep]

Lol I love how the progressive jpeg goes from greyscale to Shrek before showing the actual person

[@jyz]

Moritz Firsching has fixed this in Chrome a few years back.

[@TheSyntheticSnake]

For encoding AVIF, if you want the encoding performance you want to use the SVT-AV1-PSY fork on Tune 4, it's still largely experimental hence it not being merged into the mainline, but it is the best.

[@EmergedFromReddit]

But doesn't SVT-AV1 suck for still images?

[@channel11121]

AVIF's Film Grain Synthesis really carries it! (THIS COMMENT IS INCORRECT! I DO NOT BELIEVE AVIF'S FILM GRAIN SYNTHESIS WAS USED IN THIS COMPARISON.)

[@uzefulvideos3440]

What? The noise synthesis feature was not used in any of the AVIF examples here, nor is it really used elsewhere for AVIF, as current implementations are severely flawed.

[@channel11121]

@@uzefulvideos3440 There's no way it retained such grain pattern at those filesizes [without it]. Maybe Adobe's implementation is superior to the ones you're familiar with? EDIT: I do believe you're correct, and that there isn't any Film Grain Synthesis happening. It seems such grain can only be uniform throughout the image, and it doesn't appear to be so here. Anyway, it is then extremely impressive how well AVIF performs here [compared to JXL], knowing that it isn't leaning on grain synthesis. I wonder how much of this is down to the encoder (maybe quality of encoder, but especially what features it prioritizes), rather than the format itself. P.S.: Thank you for the correction. :) P.P.S.: I am quite sure that JXL's noise synthesis would work quite well with this particular image, if it was enabled.

[@channel11121]

@@uzefulvideos3440 Rewatching and looking more into it, I do think you're right. AVIF is really impressive, then - even without that feature. I wonder how much of this improvement to the grain quality [vs JXL] is down to the encoder (both in quality of implementation, and what it prioritizes), rather than the formats themselves.

[@uzefulvideos3440]

​@@channel11121 Oh, I think it's perfectly possible. Aomenc is quite well perceptually optimized for allintra (unlike for video). And If even very light noise synthesis was used, you wouldn't get this extreme smudging in the dark areas. And Adobe definitely does not have its own AV1/AVIF encoder, I bet they use aomenc in some way, be it through avifenc or some other way.

[@channel11121]

@@uzefulvideos3440 i wrote a second reply but it got removed :(

[@gargean1671]

Philip - a man of compression and upscaling of all things alike.

[@exotericidymnic3530]

You really ought to be including WebP in this comparison

[@Dorumin]

webp is avif

[@JoubaMety]

@@Dorumin WebP is not AVIF. WebP codec is derived from VP8 codec while AVIF format uses AV1 codec.

[@EmergedFromReddit]

WebP is still king for lossless

[@sacb0y]

Looking forward to the HDR one!

[@Valla451]

Missed your videos like this! :)

[@unselected3245]

Also you can losslessly convert JPG to JPGXL (transcoding). This mean you can convert JPG -> JPGXL -> JPG without losing quality while reducing the file size.

[@petrkdn8224]

I wouldn't object to have few more videos comparing JPEG XL and AVIF (high resolution, HDR etc.)

[@YOEL_44]

Great, now we need to store chroma as JPEG-XL and luma as AVIF, that has cleared my doubts!! Now for real, use PNG-Gauntlet to reduce the fluff of your PNG files, that will provide you the absolute highest quality, but it will remove all the metadata so if you want to edit it, you might wanna do it before using the gauntlet.

[@27370]

iPhone 16 Pro is now capable of shooting ProRAW to JPEG XL, which is much appreciated.

[@Petch85]

I hope that JPEG XL soon becomes a widely used standard, maybe ARM chips and GPU's could get an encoder/decoder for it. Such that it can be done super efficiently. I would love a world where most images and videos are JPEG XL and AV1. I am thinking youtube, instagram, Facebook, twitter, twitch, websides, phones, cameras etc. We can still have special formats for special things but it would be nice if everything just used JPEG XL and AV1 as default. Maybe JPEG XL need a shorter name like JXL if we all need to use it in everyday speak. 😂

[@TheSniperWho]

Coincidentally, jxl is the extension for JPEG XL files.

[@Maxoverpower]

JXL is already what many people call it. Is for the GPU thing, - hardware decoders have historically not been used for images because they're just not worth it, and that applies even to AVIF.

[@Petch85]

@@Maxoverpower You are probably right. But how we use images have changed a lot over the last 30 years. A modern smartphone show a lot of images every day. Just think of a modern webpage, Instagram, youtube thumbnails etc. I know it still is a lot less than video so it might not be worth it to take up even a little space on the SoC.

[@EmergedFromReddit]

@@Maxoverpower but AVIF can be hardware decoded using a AV1 decoder since it's just AV1 video with only intra compression

[@stellated]

One of the cool things about JPEG XL is it has lots of room to grow. Just look at JPEG XL art for example, it really demonstrates the power of the prediction tree. Just like JPEG encoders have improved over time, JPEG XL encoders can too.

[@Somewhat_Unknown]

I don't work with pictures much but still a really interesting watch. Might tell my dad about it, he's a lot more busy with image preservation. Also nice to catch a vid early!

[@kapelski104]

Just realized that I'm "rooting for" AVIF against JPEG-XL while looking at these comparisons. Why is my brain doing this?

[@YOEL_44]

Because everyone hates JEPG by default.

[@gr.4380]

AVIF looked better for the file size IMO. I think phillip just wants JPEGXL to win the comparison. Like is it really better for the image to be overall a little mushy, or for it to be mostly great with a few mushy areas? I would go with the second, and that's what AVIF offers. However, I would still prefer the gradual decoding from JPEGXL for the web.

[@FelipeJaquez]

The million dollar marketing campaign from Google is working. You didn't notice it, but your brain did.

[@YOEL_44]

@@gr.4380 To be honest colors seemed to be more accurate with JPEG-XL, is just that our eyes are more trained for contrast than color.

[@pshufb]

@@gr.4380The mushiness was unfortunately a choice here. JPEG XL was compared with film grain preservation not enabled :(

[@2Burgers_1Pizza]

1:22 JPEGXL filters out shadow noise when AVIF doesn't. AVIF is closer to PNG file, but I like the cleaner look of JPEGXL.

[@ggbirdymill1618]

Maybe I should convert my JPEG files to JPEGXL and PNG to AVIF. There doesn't seem to be a one format to rule them all yet.

[@OllieWille]

Impressed with how well noise is retained in AVIF. I wonder how "accurate" the noise actually is.

[@stevethepocket]

I still want to see someone invent a compression algorithm that has multiple ways of compressing portions of the image and runs it through multiple passes to figure out which method is best for which part. And then still decompresses quickly. It's still images; we can afford to spend some extra processing time on optimization.

[@Splarkszter]

Same thought. Dynamic compression. I mostly thought about it for video too.

[@stevethepocket]

​@@Splarkszter I'd be hesitant to recommend such a thing for video. The algorithm already has to examine much more data even per frame because it's comparing adjacent frames as well as nearby pixels. Think about how much time it already takes to "render" a video nowadays, and now imagine making it having to take several times longer. With still images, it probably took you more time to open the save dialog and type in the name than the computer will spend actually compressing and saving it.

[@SomebodyHere-cm8dj]

All (well, most) image formats have speed vs quality trade-offs. If you want something that "brute-force" checks all parameters, you can use pngcrush to do that for PNGs.

[@cheesecake4lyfe196]

youtube compression made some of the full screen comparisons hard to read but no shade to you Awesome comparison

[@itchylol742]

Would have liked to see HEIC files since some phones let you save pictures from the default camera app in HEIC format instead of JPEG

[@vadnegru]

AVIF is very similar to HEIC but better. And have same downsides of a format made for videos.

[@hakijin]

Jpegxl will keep more detail of the images in my naughty folder

[@uzefulvideos3440]

There are no JPEG XL or AVIF encoders that have these quality levels, they are just an abstraction by whatever weird software you used to encode them.

[@atemoc]

Indeed. With CJXL straight from the command line, I get quality from 1 to 100 (or distance) and effort from 1 to 9, though apparently 10 and 11 are a thing for the people crazy enough to try it. In my testing, I also don't see the lack of grain problem at lower file sizes that he got, so it may be down to how Photoshop handles it.

[@uzefulvideos3440]

​@@atemoc The blurrying issue definitely is a thing with JPEG XL at low quality. Reason for that is the strong focus on fidelity over appeal, and the focus on distance metrics like butteraugli or ssimulacra2 as the optimization target, which works extremely well for near-transparent quality due to them being very robust, but for lower quality it's not ideal at a normal viewing distance.

[@mbsfaridi]

ffmpeg?

[@uzefulvideos3440]

@@mbsfaridi He used Photoshop apparently. Ffmpeg options are not much different from the standalone encoders.

[@mbsfaridi]

@@uzefulvideos3440 It apparently can do both AVIF and JPEG XL from PNG since couple of years.

[@ThisIsNotWhatItLooksLik]

Looking forward to the new video codec comparisons.

[@Maxoverpower]

"Check out this video to see me ..." and no video to be seen anywhere. A 2024 Classic

[@channel11121]

I wish you had also included the Jpegli encoder.

[@jyz]

Jpegli is effective only in the mid-high to high quality (above q75 if libjpeg-like quality definition, perhaps somewhere around 1.5 bpp and above). At lower quality the results are similar to libjpeg, libjpeg-turbo or mozjpeg.

[@tobcyxob]

3:52 It's weird how it reminds me of some very old image I still have somewhere in my homework folder. The bottom part never fully loaded, leaving some grey lines, probably due to dial-up disconnecting, or I ran out of pre-paid time on my scratch card. But I still saved it, and, in fact, it survived several generations of computers.

[@kshitijvarshney]

I would love for you to do some testing for image decode times for various formats to see if any of them have a significant performance impact (specially for older devices for use cases like websites) (yes I did watch Theo's video)

[@apathypeace]

you can put the lossy image on top of the lossless one in photoshop and set the lossy layer to Difference to see the difference.

[@MLWJ1993]

Which doesn't tell you anything usefull...

[@TheTonVeron]

I wonder if you were to save an image over itself around 100 times, which format would produce a cleaner result. This is something that would likely happen on a site like reddit where images get reposted quite often.

[@TeamMuggi]

From what's shown here in the video, I would assume JXL is the better option for the 100th save. AVIF changes the colours too much. I was only off in how slow the two formats degrade, and both still looked "somewhat decent" at 100. It's very different after save 150 though, as JXL almost seems to stop degrading any further. There is a video on Jon Sneyers' (Who also made the progressive decode comparison seen in this video) channel about "Generation Loss" that compares these three and also WEBP. Surprisingly, WEBP degrades just as fast as JPEG but in a different way. Both JXL and AVIF are about equal to a casual observer until around 80 times, but AVIF is less noticeable only because it changes the whole image gradually, while JXL only changes it on certain spots while keeping the rest more accurate. The video goes up to 1000 saves. JXL is the only one of the four that doesn't seem to blatantly change after save number 50.

[@leeroyjenkins0]

By design JXL should be better at this because it's designed with the goal of reducing the actual distance from the original image, where AVIF is designed for visual fidelity (hence the "fake grain" feature). I don't think it's a major thing to worry about in either case.

[@ThompYT]

AVIF presevers the "grain" better because the AV1 video format is able to remove the grain from videos (making them vastly more efficient to store) and then later resynethsize it so it actually keeps the same look without looking soft or muddy

[@EmergedFromReddit]

It isn't used here.

[@vladde]

i've now decided to switch my worldview on avif and jpeg-xl based entirely on this video

[@r4microds]

A video you never asked for, but glad you clicked on

[@justitgstuff5284]

Since you mentioned videos, I'd be really interested to see how well the two do with motion frames, especially at the lower bitrates that YT uses :)

[@zen_xenomorph]

AVIF is far superior here because it's based on the AV1 video codec, which is also better than the popular H.264, VP9 and H.265 video codecs.

[@Sarsour_]

Awesome and unique content!

[@maxdeathlore]

Thanks man! If you didn't exist I would have to try to do this myself, so im thankful for your time. I have been converted to a JPEG XL believer!

[@ShonkV]

i love watching these kind of videos!

[@MrGencyExit64]

I've developed encoding and decoding for Ultra HDR, JXL and AVIF, as well as PNG for my own HDR image editing software (SKIV). Might blow your mind to learn there's a format based on JPEG (the original JPEG, not JPEG-XR or JPEG-XL) for HDR. Personally, I prefer JXL when compression and decompression speed matters, and AVIF's good for getting maximum compression (provided your image is first converted to YUV, since it's basically video compression).

[@LetrixAR]

The only problem than AVIF has is the processing time. You can enconde 10~20 images with JPEG-XL in the same time as 1 AVIF image

[@leeroyjenkins0]

On the other hand AVIF should ultimately be able to use hardware encoders/decoders that will definitely be inside newer electronics for AV1 So it will probably end up being faster

[@Skorm88K]

JPEGXLMafia

[@LemSportsinterviews]

jpeg mafia but fat

[@ericdanielski4802]

Nice comparison.

[@Levi_OP]

You didn't even watch that shit bird

[@retrokilroy2506]

*Nice compression

[@Krownss]

​@@retrokilroy2506❤🎉

[@GAGPalia]

Win 11 24H2 brought Lightroom HDR AVIF support but for life of me I can't read Lightroom's HDR JPEG XL's please someone help me.

[@jessejayphotography]

JPEG XL is a big step forward for both standardization, image quality, and web features. It also serves as a great upgrade for DNG Lossless RAW files.

[@juliobbv]

Interesting video! Have you tried command line products to encode these files? For AVIF, it's avifenc, and for JPEG XL it's cjxl. Keep in mind that bundled solutions (like in Photoshop) can be old, outdated and with non-optimal defaults, so you'll end up leaving some efficiency on the table. I'd be curious if you're interested into uploading the lossless picture for us to do our own testing.

[@EVPointMaster]

Would JPEG XLs progressive decoding allow the user to select the different image quality levels all from a single file? For example a webpage would only load the JPEG XL image up to Low or Medium quality version by default and had a button to load the full quality image, streaming in the rest of the data of the image, all in one single file that didn't need to load seperate images for multiple quality levels. Or instead of a button, just load the rest of the data for the highest resolve when the user zooms in. That would certainly save a lot of online storage space and bandwidth if it was possible from a single file, since you don't need multiple versions of the image and it would only need to load in a part of the full image in most cases.

[@mitchelstewart9969]

technically yes, but implementing this is... not impossible, but hard.

[@xura7CB]

Nope, I think it does not make sense. Probably you could implement by fetching the for a full quality image and then stop at some threshold (which can be continue, if needed), but it requires complicated back and forth between your website code and image library.

[@mitchelstewart9969]

@@xura7CB It's not really that complicated. If everything is single threaded and you are starting the encoder up and waiting, then it could very well be an issue. but if you are doing things asynchronously it's not that bad at all.

[@EmergedFromReddit]

It is possible with AVIF and some sites already implemented it. It's done by making an AVIF animation where the first frame is the low quality version and the second is the high quality one. When you enlarge the image, the second frame is loaded.

[@EVPointMaster]

@@EmergedFromReddit I see. but is it effective in reducing the amount of data needed compared to using 2 separate images?

[@espi742]

Progressive decoding is a massive win. Anyways, I wonder whether Photoshop encodes the AVIF images with 8 or 10 bit color. Representing detail on dark scenes is extremely hard thanks to banding, so artificially more data is required. Using 10 bit color avoids banding and allows better quality at lower sizes (even though more data is used for storing color).

[@cmentarnikPL]

They do look pretty good even with small sizes, but I feel like it would be cool to see how well they handle being compressed multiple times. After all the biggest claim to infamy of JPEG wasn't the bad quality of initial image, but what happens after an image has been on the internet for a while. I really wonder if it's possible to create a decent compression system that could be cropped and recompressed without any additional loss of information, and maybe if drawing something on an image could result in losses only around modified pixels. (Creating a bad compression algorithm that satisfies this is pretty easy - lowering the amount of possible colors or merging multiple pixels together for example)

[@vadnegru]

You could fit JPEG into JPEG-XL without recompression. But when you want to resize the image, deep-fry is inevitable.

[@Maxoverpower]

This recompression from "being downloaded" or "being on the internet" is the result of being uploaded to services and messengers that recompress it for bandwidth/compatibility reasons, and they're not usually among the first to switch to newer formats, so we might be stuck with JPEG for a while even if they accept AVIF/JXL input files. But if they were to switch, JXL and AVIF are both much better than their predecessors in terms of the rate of degradation after repeated compression passes. You can find demos for by searching for JXL generation loss.`

[@deRNmEpRrMm]

If you make another video about HDR images I'd love a comparison of the histograms to maybe gauge how faithfully the overall tone and color is preserved. Color and luminance accuracy is definitely more important to me than detail retention.

[@Barmem]

Thank you Philip, it's very fascinating

[@faytruefireside]

I mean AVIF standardization was finalized in 2019, jpeg XL standardization was finalized in 2022. AVIF got global browser support in over 2023-2024, jpeg XL has not gotten global broswer support yet. I dislike people saying that something(Chrome or Firefox) hasn't been supporting it when the standards weren't even finalized and the thing they are comparing it to got support slowly (after 4-5 years).

[@Koffiato]

AVIF is absurd. Preserves everything that matters even at 200KB, damn.

[@staiain]

i find jxl files that i export from camera raw to display weird colour banding and compression artifacts once imported into photos library on apple devices, this doesn't happen with avif at all, i've tried hdr and no hdr, and different colour spaces, am i doing something wrong? I've tested lossless and lossy as well, same slight colour shift and weird subtle blocky compression artifacts.

[@Loanshark753]

Could there be some kind of noise reduction that removes dithering from smooth gradients.

[@bebobo1]

some image viewing programs automatically load compressed copies of photo raw formats for faster browsing. panasonic rw2 files for example have low quality jpeg files embedded to act as previews. nomacs has a poor quality (but fast) raw processor for this purpose, which can be turned on or off in the settings.

[@Matticitt]

Really even the original jpg is perfectly fine for what it was meant to be - for photos. It get's a bad rep because of people using it to save computer-generated graphics, compressing the photos too much and reposting the image over and over. Considering how cheap storage is these days I've no issue with jpg. If I have 100 000 photos weighing 4MB each on avg that's 400GB. What can AVIF do? save me 150GB? That's not nothing but it's the size of a single videogame these days. And that's my entire library of photos taken in the past 20 years. Still I appreciate it for video compression. H.265 is just so much better than H.264 it's crazy.

[@leeroyjenkins0]

Considering JXL can transcode jpeg losslessly, I don't see a reason not to take the free 150GB assuming you don't share them online. Storage is fairly cheap but if we can avoid being wasteful why not. That's assuming you store all these personal photos as jpeg already, which I probably wouldn't do. But I have large folders of online materials I've converted. These are also mostly meant to reduce bandwidth, and loading speed.

[@liegon]

Excellent comparison, thanks!

[@salvosuper]

Please do the follow-up about HDR and higher resolution

[@MoireFly]

Which encoder and versions did you use? For new codecs like JPEG XL and AVIF that might matter quite a bit. Also, does the encoder surface the complexity knobs? Given how notoriously slow both codecs are, I could imagine the encoder may not be encoding at maximum complexity (i.e. it's trading encoding/decoding speed for quality/filesize)

[@Dapplication]

500kb modern compression versions are impressive for 1/20th of the original size. Props to the engineers behind them.

[@graealex]

AVIF being supported in every modern browser should be the deciding factor when it comes to very small file sizes and content delivery.

[@Dribbleondo]

The sooner AVIF can be used on Vegas, the better.

[@jyz]

could it be that metadata is present in JPEG XL but not in AVIF? -- usually there is no such strong difference between JPEG XL and AVIF even at the low quality shown here are the binary files available somewhere for inspection?

[@suductivewalrus6462]

I just realised I watched the whole video in 240p

[@travian821]

Im now a fan of JPEG XL file format, will use it.

[@toyotagaz]

Would really love to see you do video formats

[@SCtester]

From my testing it looks like Adobe has extremely fast JXL encoding presets, trading quality for speed. This results in some strange outcomes - for example when I converted a RAW file to lossy JXL using Camera Raw 16.4, it actually came out larger than the original RAW file. On the other hand, exporting it to lossless JXL was significantly smaller than the RAW file. Clearly there's something off with their lossy encoding settings. Using XL Converter as a point of comparison, the export took longer, but using the highest quality lossy preset the result was far smaller. Converting to AVIF, also using XL Converter, resulted in a larger file size, longer export time, and to my eyes a slightly worse result, as it introduced some color noise into the shadows as you observed. File size comparison: Original RAW file: 43.6MB Exported to lossy JXL from Adobe Camera Raw (12/13 quality setting) : 59.5MB Exported to lossy JXL from XL Converter (99/100 quality setting, effort 9): 18.3MB Exported to lossy AVIF from XL Converter (99/100 quality setting, speed 0): 21.4MB It doesn't look like you experienced the same particular issue with the high quality lossy file being larger than the original, but my point is, it's entirely dependent on the encoder used, and I don't think it's necessarily a fair comparison to use just one particular exporter which has arbitrary encoding settings applied. Using XL converter would allow for controlling more variables.

[@TavishMcEwen]

fantastic comparison!! What viewer are you using?

[@ArvFlash]

im pretty sure that both image formats have an "effort" property, with which you can trade off encoding time for lower file sizes, the photoshop exporter seems limited, i feel like this would work better by just exporting as png and then using ffmpeg to convert the png to avif and jpegxl with the most cpu power used, (e.g. for converting to jpegxl with the highest effort: ffmpeg -i input.png -c:v libjxl -effort 9 -distance 1 test.jxl ) distance being the deviation to the original image, 0 being lossless and 15 being most compressed, and effort being a number from 1 to 9 with 9 taking the longest to encode

[@KaiSoDaM]

Yesss. Keep those coming

[@ymi_yugy3133]

I really want JPEG XL to succeed. Yes it might be a little worse at small file sizes, and maybe it's decompression is a little more computationally expensive, but there are just so many advantages. From color depth to file sizes jxl supports them all, on top you get goodies like progressive loading and as if not more important lossless transcoding from jpeg. If only browsers would support it.

[@ToyKeeper]

I'd also like to see the QOI format become more widely supported. It's similar to PNG except it's much much faster and simpler.