-
Jyrki Alakuijala
JPEG XL compresses significantly (~25 %) more in the Web quality range. Think libjpeg quality 75-95.
-
Jim
I would say 50+. Once you go below 50 it becomes a mixed bag. Sometimes AVIF looks better and sometimes JXL does - depends on the image content.
-
Jon Sneyers 🔻
Very roughly speaking, I'd say avif is better at q<30, jxl and avif are similar at q around 50, and jxl is better at q>60 (significantly better at q>80).
"Web quality" is typically q70-90, "Camera quality" is q92-98.
-
Nicolas Hoizey
How/where is q<30 useful?
(I really don’t like LQIP 😅)
-
Anton
I wrote that note. Which part of it do you disagree with?
-
Jon Sneyers 🔻
I don't think it is very useful at all. Maybe when filesize/bandwidth is really, really more important than image fidelity, or if you have manual inspection to check that the artifacts are not excessive. You're probably better off just sending a lower res image though.
-
Nicolas Hoizey
2 parts:
- compression quality:
- features
-
Jyrki Alakuijala
Mobile bandwidth 3x'ed in last 5 years. Screen resolutions didn't increase much, and image resolutions increased less.
Because of these trends I believe the future is for shinier pixels at higher quality.
-
Jyrki Alakuijala
Current Internet qualities I observe to be in 75-100 range with median/average somewhere around 85.
-
Nicolas Hoizey
I agree it’s almost never useful.
Maybe with save-data if you don’t want lower res, but I can’t find how it would be better.
-
Jyrki Alakuijala
What are your thoughts on higher quality progression -- is it more acceptable than LQIP?
For example the first video on this page:
opensource.googleblog.com/2021/09/using-…
-
Nicolas Hoizey
This is exactly what I would like to have indeed, I loved this article when I read it last month! 👍
-
Jim
I'm fine with either the progressive scan or the block-progressive loading Jon showed (not shown in the site you provided). LQIP is better than nothing when progressive is not available, but could add a bit more bandwidth.
-
Jim
As far as the site you linked, I agree 100%. People are will glance over the main subject so if it is loaded in first they may keep on scrolling before the rest of the image is loaded. Also why most CMS provide a way to crop thumbnail images to a specific area.
-
Jim
I am not the best fan of LQIP either but it's better than nothing when progressive is not available. Q < 30 can be useful doing a background - say where there is heavy blurring so that the image does not need a lot of kb or b to represent. Or very small thumbnails.
-
Jim
True, but there are still a number of developing countries that have very low mobile bandwidth. If you're targeting the world you also want to consider getting your page to load quickly in countries whose infrastructure has not kept up with demand.
-
Jim
That's why we need browsers to support JXL's progressive and responsive loading. So it can load the lower resolutions of the image (say rough equivalent to q 30) then stop until the user hovers over or clicks to see the larger image, then loads in the rest.
-
Nicolas Hoizey
I prefer a single background color over the false promise of a LQIP, because I encounter too much LQIPs that don’t get replaced by the actual image (often on Medium).
-
Jim
I hate background image or using those hash color libraries. Even medium has had times where those scripts don't work right. If the image fails to load your left waiting, wondering if something will appear in the space.
-
Nicolas Hoizey
Exactly why I don’t like LQIPs. Single color backgrounds are nice for the ambiance, without much promises.
-
Anton
1) As Jon notes, depending on the compression level, both are "the best". Caniuse notes have to be brief, and we expect people who really care about compression to dig deeper, but for most people, knowing that they are similar in quality (and better than WebP), is good enough IMO
-
Anton
2) JPEG-XL has features like lossless reencoding of older JPEGs and progressive decode, which is why we note that it has more features than AVIF.
-
Nicolas Hoizey
OMG, I’m sorry, I understood the opposite, that the note said JPEG-XL had fewer features! 🤦♂️
Sorry, sorry, sorry… 🙏
-
Nicolas Hoizey
Both are the best if we consider a full range of compression levels, but as Jon also said (and I agree), most use cases are for compression levels where JPEG-XL is best.
But I understand the note must be simple, nuance is difficult.
-
Jon Sneyers 🔻
Natural language could use some brackets for disambiguation. "JPEG XL competes with (AVIF which has similar compression quality but fewer features overall).", Not "JPEG XL competes with (AVIF which has similar compression quality) but [has] fewer features overall."
-
Jon Sneyers 🔻
Personally, I don't like to think of it as "competing", because competitions have winners and losers while here they are more complementary. I see AVIF as the new GIF, and JXL as the new JPEG and PNG. They each have their own strengths.
-
Nicolas Hoizey
Good idea! 👍
-
Nicolas Hoizey
That’s fair, indeed.
-
Jon Sneyers 🔻
I'd say AVIF focuses on consumer-grade fidelity (i.e. end-user delivery) and is great for animation. JXL focuses on still images and is suitable for both authoring workflows and web delivery.
-
Nicolas Hoizey
That’s what I see in
@addyosmani’s book (I know you were a contributor)
-
Anton
Oh that makes sense 😄 If I see more evidence that people are misunderstanding it, it might warrant rephrasing the note.
-
Jyrki Alakuijala
It's complicated.
Resolution is another way to save data, often with more predictable behaviour than ulta-low quality.
Developing countries can be more image centric in their internet use, and can have more text integrated into the images, requiring higher quality for reading.
-
Jyrki Alakuijala
Many developing countries (like Kenya) have a fast mobile net. Kenya is supposedly faster than USA.
India is on average roughly 2x slower than Germany. That is about 3 years behind in development.
-
Jyrki Alakuijala
Thank you! Consider expressing thumbs up in Mozilla's Request for position and/or starring the JPEG XL bug on Chromium:
github.com/mozilla/standa…bugs.chromium.org/p/chromium/iss…
-
Anton
I would probably also recommend JXL over AVIF, but they're both great, and we are already pushing people to use JXL by noting that it has more features. Saying that the compression is always better, is a dangerous path to go down, and I don't see how it would help anyone.
-
Jon Sneyers 🔻
Yes, I agree, and also things are still early in the sense that both avif and jxl encoders can still be improved. They're both ahead of older codecs, but by how much, nobody can really say definitively at this point.
-
Anton
I absolutely agree with your comments, but I also think the note accomplishes everything we wanted it to, which was basically just to say "if you don't care enough to research the topic even a little, then use JPEG-XL" :)
-
Anton
But thanks for the constructive feedback to both of you! Next time I revisit these tables, I'll keep it in mind :)
Barry Pollard
Johannes Odland
Jason Grigsby