Comment by mips_r4300i
3 years ago
This is really impressive even compared to WebP. And unlike WebP, it's backwards compatible.
I have forever associated Webp with macroblocky, poor colors, and a general ungraceful degradation that doesn't really happen the same way even with old JPEG.
I am gonna go look at the complexity of the JXL decoder vs WebP. Curious if it's even practical to decode on embedded. JPEG is easily decodable, and you can do it in small pieces at a time to work within memory constraints.
Everyone hates WebP because when you save it, nothing can open it.
That's improved somewhat, but the formats that will have an easy time winning are the ones that people can use, even if that means a browser should "save JPGXL as JPEG" for awhile or something.
Everyone hates webp for a different reason. I hate it because it can only do 4:2:0 chroma, except in lossless mode. Lossless WebP is better than PNG, but I will take the peace of mind of knowing PNG is always lossless over having a WebP and not knowing what was done to it.
> peace of mind of knowing PNG is always lossless
There is pngquant:
> a command-line utility and a library for lossy compression of PNG images.
4 replies →
I've noticed in chrome-based browsers, you can right click on a webp file and "edit image". When you save it, it defaults to png download, which makes a simple conversion.
Mobile browsers seem to default to downloading in png as well.
I think JXL has been seeing adoption by apps faster than Webp or AVIF.
Unfortunately its the other way around for web browsers :|
> And unlike WebP, it's backwards compatible.
No, JPEG XL files can't be viewed/decoded by software or devices that don't have a JPEG XL decoder.
JPEG XL can be converted to/from JPEG without any loss of quality. See another commenter where shows a example where doing JPEG -> JPEG XL -> JPEG generates a binary exact copy of the original JPEG.
Yeah, this not means what usually we call backwards compatibility, but allows usage like storing the images as JPEG XL and, on the fly, send a JPEG to clients that can't use it, without any loss of information. WebP can't do that.
But that only works when the JXL has been losslessly converted from a JPEG in the first place, right? So this wouldn’t work for all JXL in practice. (Unless I’ve missed something and this is not the case.)
1 reply →