it’s so efficient it can fit ẏ̷̛̀̏̎̇͜ǫ̷̼̰̳̹́̆̍̐͜͝ủ̷͉̱̻̤̬̯̈́ŗ̸̒ ̸̨̟͈̳͍̱̀̏̓m̵̺͎̋́u̴͇̥͍͐̇̀̇͊̌̚͝m̸̢̢͕̻̬͙̒͗̽͋͆̕͝ in less than 2GB;
it can be animated;
is more than capable of representing 1:1 any GIF image;
it sucks because the one image viewer I’ve ever had installed by the ubiquitous (= monopolistic) operating system everyone has by default doesn’t support it.
yes, but that is a bit apple specific, and on intel side, they support hwdec since 2021. and since these are just images, even software decoding works (although a bit slower)
I’d say 2021 is still pretty damn recent, most of my computing devices are still pre 2020. It’s also not just Apple, for example the latest Fairphone 6 doesn’t support it either. Images can still be pretty damn big when taken from a high resolution camera, and software decoding defeats the benefit from a format that’s supposed to be efficient. I’d say that it will probably take another decade for avif to become mainstream.
IMO AVIF works really well at making convincing looking results at really high compression ratios, it’s worse at pretty much everything else.
And occasionally the ‘convincing looking’ results aren’t actually very accurate to the original image…
But those results really do look very convincing.
And IMO one of the most compelling features of JPEG-XL is its’ great lossless compression, although it is generally good all-around. AVIF is pretty terrible at lossless compression, usually well-behind WebP and only a bit better than PNG.
Anyways, for photos, if you want to compress them a ton then maybe AVIF is best, but if you want high quality JXL is probably best.
do you mean in sense of lossy or lossless? if so, in theory both webp and avif could have lossless photos, but i do not think they are designed for that (think in terms of their backrounds, they are kinda like a single frame videos. and usually you only have lossy video).
jpeg xl in theory aims to take job of both jpeg and png (it can handle lossy as well as lossless). In theory, we (as in all of computing and media people) decide to back on jpegxl, we could potentially just have 1 format, and accordingly 1 library which provides support. but that is just a dream i do not see happening. google essentially paralysed jpeg xl by removing it from chromium , and that is the largest userbase.
almost all other big companies want to use jpeg xl. meta, adobe, intel and others. the main benefit to them is reduced bandwidth cost (for exactly same data, jpeg xl can be ~20% smaller than jpeg), and jpeg can be losslessly translated to jxl, and even for backwards compatibility, reverse can be done on client end. but without chrome, no web developer will adopt. if web people do not, the demand for format would be extremely small, no hardware manufacturer will include hardware support (your gpus have “special” stuff for almot all codecs and formats, but that is not the case for jxl for now), so jxl operations currently are slow, so end user might not even be motivated to use (other than space savings).
okay. it is a lot simplified, but mostly correct. ideally image format for drawn out stuff and other flat animated stuff is svg (vector graphics - ie - infinitely scalable yet crisp), but png is usually used because it is defacto lossless standrad. lossless here roughly translates to - sensor produced a matrix of colors - lossless photo preserves all data. lossy discards some data. For irl stuff, usually lossless is overkill for end user, hence you see jpegs (defacto lossy standrad)
jxl can so both. others can do that as well. jpegs can be lossless, but that is usually not the standard we use. you can store lossy data in pngs, but the loss is not created by png. jxl behaves by default like lossless (like png), but due to newer algorithms, size when lossless is closer to jpeg. if you prepare loss jxl - it can be close to half size of jpegs.
there are other benifits to jxl (extreme future proofing (extremely high bit depth, and pixel size limit, large amount of channels), progressive decoding, etc.), but our reality has to suck because of google.
I locally use jxl to store family photos, but this means i can not send them, because they are using stuff which does not support jxl, so have to convert and share.
I like how you say that it’s supported by grand total of 2 programs, yet I never had any problems opening it in any media viewing software. Even Windows Paint opens it as far as I am aware.
I do expect it to be a matter of time. Typically, you pull some image rendering library into your program, which pulls in a whole bunch of libraries that support the different image formats.
As such, it’s the job of that intermediary library to support as many formats as possible. If you keep that intermediary library up-to-date, you may get support for new image formats without really doing anything.
But well, it may take more time for this to happen, for various reasons. One reason is obviously that we already have other image formats that may not be amazing, but they work everywhere, so most people continue to use those.
Another aspect that may slow adoption down, is that .webp was spear-headed by Google alone. Normally, you get other industry leaders into the boat, to make sure you cover everyone’s use-cases and have somewhat of a commitment for them to integrate it. I assume that Photoshop supports .webp by now, but it probably took relatively long for that to happen, for example.
and with very few exceptions i’ve run across, it’s also (intentionally or not) configured to produce shit-tier quality output by pretty much everyone implementing it at any sort of scale.
Webp is the worst format ever.
Never mind that:
it sucks because the one image viewer I’ve ever had installed by the ubiquitous (= monopolistic) operating system everyone has by default doesn’t support it.
I just converted all the images on my website to webp for faster load time. Very happy with it.
avif is better than it in almost all ways, and jpex xl is even better than that (but not about gifs i think)
webp is essentially a webm file (which is mkv with codec restrictions(vp8/9 and ogg vorbis or opus))
avif is av1 encoded files in a webp like container (but not webm afaik)
jpeg xl is a format made specifically for images
jpeg xl has even less default support tho unless you use a mac
that is indeed the sad truth
AV1 is only supported by new devices, most support VP9. For example, the iPad Air 2024 does not support AV1.
yes, but that is a bit apple specific, and on intel side, they support hwdec since 2021. and since these are just images, even software decoding works (although a bit slower)
I’d say 2021 is still pretty damn recent, most of my computing devices are still pre 2020. It’s also not just Apple, for example the latest Fairphone 6 doesn’t support it either. Images can still be pretty damn big when taken from a high resolution camera, and software decoding defeats the benefit from a format that’s supposed to be efficient. I’d say that it will probably take another decade for avif to become mainstream.
No SVG?
svg is great, but at vector graphics. we are mostly discussing raster formats.
Do the traditional JPG vs PNG usage “rules” apply to AVIF and JPEG XL?
IMO AVIF works really well at making convincing looking results at really high compression ratios, it’s worse at pretty much everything else.
And occasionally the ‘convincing looking’ results aren’t actually very accurate to the original image…
But those results really do look very convincing.
And IMO one of the most compelling features of JPEG-XL is its’ great lossless compression, although it is generally good all-around. AVIF is pretty terrible at lossless compression, usually well-behind WebP and only a bit better than PNG.
Anyways, for photos, if you want to compress them a ton then maybe AVIF is best, but if you want high quality JXL is probably best.
I think https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front is a good comparison
what would they be?
do you mean in sense of lossy or lossless? if so, in theory both webp and avif could have lossless photos, but i do not think they are designed for that (think in terms of their backrounds, they are kinda like a single frame videos. and usually you only have lossy video).
jpeg xl in theory aims to take job of both jpeg and png (it can handle lossy as well as lossless). In theory, we (as in all of computing and media people) decide to back on jpegxl, we could potentially just have 1 format, and accordingly 1 library which provides support. but that is just a dream i do not see happening. google essentially paralysed jpeg xl by removing it from chromium , and that is the largest userbase.
almost all other big companies want to use jpeg xl. meta, adobe, intel and others. the main benefit to them is reduced bandwidth cost (for exactly same data, jpeg xl can be ~20% smaller than jpeg), and jpeg can be losslessly translated to jxl, and even for backwards compatibility, reverse can be done on client end. but without chrome, no web developer will adopt. if web people do not, the demand for format would be extremely small, no hardware manufacturer will include hardware support (your gpus have “special” stuff for almot all codecs and formats, but that is not the case for jxl for now), so jxl operations currently are slow, so end user might not even be motivated to use (other than space savings).
https://jpegxl.info/
This is more or less everything I know about how image formats work.
okay. it is a lot simplified, but mostly correct. ideally image format for drawn out stuff and other flat animated stuff is svg (vector graphics - ie - infinitely scalable yet crisp), but png is usually used because it is defacto lossless standrad. lossless here roughly translates to - sensor produced a matrix of colors - lossless photo preserves all data. lossy discards some data. For irl stuff, usually lossless is overkill for end user, hence you see jpegs (defacto lossy standrad)
jxl can so both. others can do that as well. jpegs can be lossless, but that is usually not the standard we use. you can store lossy data in pngs, but the loss is not created by png. jxl behaves by default like lossless (like png), but due to newer algorithms, size when lossless is closer to jpeg. if you prepare loss jxl - it can be close to half size of jpegs.
there are other benifits to jxl (extreme future proofing (extremely high bit depth, and pixel size limit, large amount of channels), progressive decoding, etc.), but our reality has to suck because of google.
I locally use jxl to store family photos, but this means i can not send them, because they are using stuff which does not support jxl, so have to convert and share.
I think gif is also better than jpg for the low-complexity images and is lossy so the file size gets even smaller. Or so I’ve heard.
this is true, but gifs had some other license related issues early on so did it was behind jpeg. now jpeg has momentum far superior to anythinng else
I just hate webp because it’s supported in a grand total of 2 programs so it’s just annoying to deal with
I like how you say that it’s supported by grand total of 2 programs, yet I never had any problems opening it in any media viewing software. Even Windows Paint opens it as far as I am aware.
Is this a matter of time, or do most programs never plan to add support?
I do expect it to be a matter of time. Typically, you pull some image rendering library into your program, which pulls in a whole bunch of libraries that support the different image formats.
As such, it’s the job of that intermediary library to support as many formats as possible. If you keep that intermediary library up-to-date, you may get support for new image formats without really doing anything.
But well, it may take more time for this to happen, for various reasons. One reason is obviously that we already have other image formats that may not be amazing, but they work everywhere, so most people continue to use those.
Another aspect that may slow adoption down, is that .webp was spear-headed by Google alone. Normally, you get other industry leaders into the boat, to make sure you cover everyone’s use-cases and have somewhat of a commitment for them to integrate it. I assume that Photoshop supports .webp by now, but it probably took relatively long for that to happen, for example.
Superb explanation. Many thanks for the insight Ephera!
and with very few exceptions i’ve run across, it’s also (intentionally or not) configured to produce shit-tier quality output by pretty much everyone implementing it at any sort of scale.
Is this the only drawback though? Genuinely curious
Probably not, some here say there are better formats, but it’s still much better at (almost?) everything than GIF