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 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 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 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 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.
@@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.
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.
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.
@@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
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
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.
@@alangeisse it saves space and you can theoretically serve both files (jxl -> jpeg conversion is most likely a lot faster than jpeg -> jxl conversion)
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 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 🙂
@@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.
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.
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*
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.
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.
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.
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.
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.
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.
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
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.
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.
@@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.
@@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.
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
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.
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
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 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
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!
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...
@@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.
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.
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.
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.
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.
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
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.
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.
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 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.
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.
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.
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.
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.
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.
@@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.
@@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.
@@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.
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.
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. 😂
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.
@@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.
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.
@@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.
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!
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.
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)
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
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).
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.
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.
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.
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.
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)
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.`
I keep saying that progressive decoding is an extremely important feature for the web, but the AVIF fanatics keep finding ways to ignore it. I'm so tired of the blurry placeholder thing that people have been doing for years, and I really hope that JPEG-XL becomes the primary format simply so we can get rid of that practice altogether. Just a further note, JPEG-XL actually has the capability to specify which part of the image to prioritize when loading progressively. So you can tell it to load the most important part of the image first, reducing that perceived full loading time even further.
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.
For lossless, it's more interesting to compare drawings and illustrations, than a photo. JPEG-XL lossless is better and can do things like gradients and blurs.
The name “JPEG XL” probably doesn’t help with uptake from regular users - it sounds like a format designed specifically for saving large scale images rather than a general-use successor to JPEG. I certainly wouldn’t have assumed that saving a regular sized image in that format would actually save you space. Apparently the XL stands for “Long Term” (as in long term successor format to JPEG) rather than “Extra Large” which isn’t confusing at all.
There's a workaround to adding progressive decoding to AVIF. It's by making a non looping AVIF animation where the first frame is an AVIF encoded at very low quality so it loads fast and the second image is the high quality one. Also, AVIF's lossless compression is worse than WebP. WebP is still king for lossless
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.
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.
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.
One thing I heard is that you can take an existing jpeg and convert it to jxl, compressing it at least 20% further but not changing the quality at all - so, server-side it’s automatically the superior technology
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
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.
HEIF is based on the older H.265 video codec. AVIF is newer and is based on the modern AV1 video codec, which offers better compression and image quality. HEIF is basically a worse version of AVIF. AVIF is also royalty free, unlike HEIF under some circumstances.
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).
Interesting Video! Excited about AVIF gaining more historical depth in web browsers and becoming something I could actually serve users on a webpage (Probably only 1-2 Years away from that) Would've loved to see WebP in the comparison as it has become the de facto standard in modern websites in recent years (As it's the currently only widley supported format that isn't completely ancient)
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.
The iPhone 16 supports JPEG XL in their ProRAW container, though I suppose you're probably not using an iPhone for professional photography.
@@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.
@@Yay295I don't have an iphone, but it looks like macos understands jpeg xl
Yes, please!
@@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.
It's a shame Chrome won't implement JPEG XL
@@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
reimplement* (because they actually supported it previously)
It's also strange considering JPEG XL was developed in part by Google
@@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.
@@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.
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.
couldnt have said it better myself
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.
*GOOD NEWS:* Apple bakes-in JPEG XL as an image format save option on the iPhone 16 family.
iPhone 16 Pro only, as a ProRAW option
PLEASE talk about HDR images!! It's so fascinating and most people don't know about them!
he's got an older video called "HDR is a hot mess" where he talks about it quite a bit
@@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
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
@@MarvoldXHDR400 is mostly useless on standard ips/tn/va panels. Honestly you either need OLED or Local dimming for real HDR
HDR is crap, you need correct hardware. Most hardwares do not meet those specifications for HDR.
All my homies prefer JPEG XL.
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.
Shortcoming of a format made for video
May I ask what to use for the conversion of JPG to JXL? Thanks
@@alangeisse it saves space and you can theoretically serve both files (jxl -> jpeg conversion is most likely a lot faster than jpeg -> jxl conversion)
@@alangeisse search for "codepoems xl converter". they use the term "JPEG Recompression" so look for that in the manual
@@AlexanderPrussak im pretty sure hes asking for what software to use, which i recommend libjxl
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. 💕
That you havent mentioned zstd is a crime against compression
@@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 🙂
@@tarakivu8861 about to say that. People may hate me for it but my tar archives are zstd compressed.
@@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.
Did you mean encoding and decoding?
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.
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*
@@leeroyjenkins0 It's still a new format, if big companies like Apple and Adobe continue to keep supporting it, it *will* eventually be supported.
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.
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.
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.
Been using AVIF as web dev for few years already. Very good 🎉
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.
Every user feels the effects of different compression formats though, since size is still important for images on the web.
So much of our life is on the cloud, and enterprise level network price
this has nothing to do wuth storage, its bandwidth thats the concern.
wait till apple hears about how cheap storage is
SSDs still haven't become "cheap", they've been hovering around the same price per gigabyte for the past five years or so
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.
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.
Dude I watched the miracle of video compression literally yesterday
me watching in 360p : "hmm... yes it is an improvement"
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!
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
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
Is anyone else shocked that were able to compress a 10mb png file to 180kb and still recognize whats displayed?
Sufficiently advanced compression is indistinguishable from magic!
AVIF looks crazy at high compression!
yo should've used the encoders directly via cmd instead of photoshop as they are usually outdated in third party software
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.
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.
@@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.
@@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.
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
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.
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
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*
@@leeroyjenkins0 May I ask what did you use for the conversion to JXL? Thanks
@@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
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!
archiving images at a lower quality? But why? Buying more HDDs is probably cheaper than converting millions of images by newer codecs.
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...
@@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.
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.
Great video! I love seeing these kinds of comparisons. Would also be interesting to compare the WEBP format to these two.
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.
I didn't know I needed to know about photo compression formats until you posted, awesome content
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.
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.
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
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.
But doesn't SVT-AV1 suck for still images?
Awesome video! Can't wait dor the HDR comoarison!
Looking forward to the HDR one!
Philip - a man of compression and upscaling of all things alike.
Lol I love how the progressive jpeg goes from greyscale to Shrek before showing the actual person
Moritz Firsching has fixed this in Chrome a few years back.
You really ought to be including WebP in this comparison
webp is avif
@@Dorumin WebP is not AVIF. WebP codec is derived from VP8 codec while AVIF format uses AV1 codec.
WebP is still king for lossless
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.
iPhone 16 Pro is now capable of shooting ProRAW to JPEG XL, which is much appreciated.
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.
Same thought. Dynamic compression.
I mostly thought about it for video too.
@@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.
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.
Missed your videos like this! :)
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.
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.
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.
I wouldn't object to have few more videos comparing JPEG XL and AVIF (high resolution, HDR etc.)
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.)
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.
@@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.
@@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.
@@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.
@@uzefulvideos3440 i wrote a second reply but it got removed :(
youtube compression made some of the full screen comparisons hard to read but no shade to you
Awesome comparison
Just realized that I'm "rooting for" AVIF against JPEG-XL while looking at these comparisons. Why is my brain doing this?
Because everyone hates JEPG by default.
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.
The million dollar marketing campaign from Google is working.
You didn't notice it, but your brain did.
@@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.
@@gr.4380The mushiness was unfortunately a choice here. JPEG XL was compared with film grain preservation not enabled :(
Jpegxl will keep more detail of the images in my naughty folder
"Check out this video to see me ..." and no video to be seen anywhere. A 2024 Classic
Impressed with how well noise is retained in AVIF. I wonder how "accurate" the noise actually is.
i've now decided to switch my worldview on avif and jpeg-xl based entirely on this video
Looking forward to the new video codec comparisons.
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. 😂
Coincidentally, jxl is the extension for JPEG XL files.
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.
@@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.
@@Maxoverpower but AVIF can be hardware decoded using a AV1 decoder since it's just AV1 video with only intra compression
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.
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.
@@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.
ffmpeg?
@@mbsfaridi He used Photoshop apparently.
Ffmpeg options are not much different from the standalone encoders.
@@uzefulvideos3440 It apparently can do both AVIF and JPEG XL from PNG since couple of years.
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!
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.
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.
What kind of tool do you use to compare the images? Looks nice.
could be Nvidia ICAT
i think he said at some point he uses icat by nvidia
@@justroc6350 Such an underrated tool
I use FastStone Image Viewer and it can compare up to 4 images.
img sli on web
Nice comparison.
You didn't even watch that shit bird
*Nice compression
@@retrokilroy2506❤🎉
A video you never asked for, but glad you clicked on
Awesome and unique content!
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!
500kb modern compression versions are impressive for 1/20th of the original size. Props to the engineers behind them.
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.
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)
I just realised I watched the whole video in 240p
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
It isn't used here.
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.
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.
Which doesn't tell you anything usefull...
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).
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.
AVIF is absurd. Preserves everything that matters even at 200KB, damn.
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.
AVIF being supported in every modern browser should be the deciding factor when it comes to very small file sizes and content delivery.
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 :)
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.
The sooner AVIF can be used on Vegas, the better.
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.
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.
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)
You could fit JPEG into JPEG-XL without recompression. But when you want to resize the image, deep-fry is inevitable.
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.`
I keep saying that progressive decoding is an extremely important feature for the web, but the AVIF fanatics keep finding ways to ignore it. I'm so tired of the blurry placeholder thing that people have been doing for years, and I really hope that JPEG-XL becomes the primary format simply so we can get rid of that practice altogether.
Just a further note, JPEG-XL actually has the capability to specify which part of the image to prioritize when loading progressively. So you can tell it to load the most important part of the image first, reducing that perceived full loading time even further.
Im now a fan of JPEG XL file format, will use it.
i love watching these kind of videos!
I wish you had also included the Jpegli encoder.
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.
For lossless, it's more interesting to compare drawings and illustrations, than a photo. JPEG-XL lossless is better and can do things like gradients and blurs.
Excellent comparison, thanks!
JPEGXLMafia
jpeg mafia but fat
The name “JPEG XL” probably doesn’t help with uptake from regular users - it sounds like a format designed specifically for saving large scale images rather than a general-use successor to JPEG. I certainly wouldn’t have assumed that saving a regular sized image in that format would actually save you space.
Apparently the XL stands for “Long Term” (as in long term successor format to JPEG) rather than “Extra Large” which isn’t confusing at all.
Thank you Philip, it's very fascinating
Would really love to see you do video formats
There's a workaround to adding progressive decoding to AVIF. It's by making a non looping AVIF animation where the first frame is an AVIF encoded at very low quality so it loads fast and the second image is the high quality one.
Also, AVIF's lossless compression is worse than WebP. WebP is still king for lossless
fantastic comparison!! What viewer are you using?
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.
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.
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.
finally philip answers the real questions gamers have
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
AVIF is very similar to HEIC but better. And have same downsides of a format made for videos.
One thing I heard is that you can take an existing jpeg and convert it to jxl, compressing it at least 20% further but not changing the quality at all - so, server-side it’s automatically the superior technology
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
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
Yesss.
Keep those coming
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.
Should've also included HEIF, it's amazing
HEIF is based on the older H.265 video codec. AVIF is newer and is based on the modern AV1 video codec, which offers better compression and image quality. HEIF is basically a worse version of AVIF. AVIF is also royalty free, unlike HEIF under some circumstances.
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).
Interesting Video! Excited about AVIF gaining more historical depth in web browsers and becoming something I could actually serve users on a webpage (Probably only 1-2 Years away from that) Would've loved to see WebP in the comparison as it has become the de facto standard in modern websites in recent years (As it's the currently only widley supported format that isn't completely ancient)
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.