| ▲ | Chromium Has Merged JpegXL(chromium-review.googlesource.com) |
| 114 points by thunderbong 4 hours ago | 21 comments |
| |
|
| ▲ | adzm 2 hours ago | parent | next [-] |
| https://github.com/libjxl/jxl-rs jxl-rs is the underlying implementation. It's relatively new but Rust certainly calms security fears. This library wasn't really an option last time this came around in chromium. |
| |
| ▲ | quikoa an hour ago | parent [-] | | Didn't Google refuse adding JpegXL because they claimed there wasn't enough interest? I don't think they refused out of security concerns but maybe I'm misremembering that. | | |
| ▲ | pixelesque an hour ago | parent [-] | | Google argued that duplicating largely (I know JpegXL does support a bit more, but from most users' perspectives, they're largely right) what AVIF provided while being written in an unsafe language was not what they wanted in terms in increasing the attack surface. | | |
| ▲ | adzm an hour ago | parent [-] | | And it really was the right move at the time, imo. JXL however now has better implementations and better momentum in the wider ecosystem and not just yet another image format that gets put into chrome and de facto becomes a standard. | | |
|
|
|
|
| ▲ | LtdJorge an hour ago | parent | prev | next [-] |
| I’ve recently compared WebP and AVIF with the reference encoders (and rav1e for lossy AVIF), and for similar quality, WebP is almost instant while AVIF takes more than 20 seconds (1MP image). JXL is not yet widely supported, so I cannot really use it (videogame maps), but I hope its performance is similar to WebP with better quality, for the future. |
| |
| ▲ | adzm 44 minutes ago | parent [-] | | You have to adjust the CPU used parameter, not just quality, for AVIF. Though it can indeed be slow it should not be that slow, especially for a 1mp image. The defaults usually use a higher CPU setting for some reason. I have modest infrastructure that generates 2MP AVIF in a hundred ms or so. |
|
|
| ▲ | viktorcode 2 hours ago | parent | prev | next [-] |
| Anyone knows if their implementation supports animations? This is a feature missing from Apple's |
|
| ▲ | jakkos 3 hours ago | parent | prev [-] |
| I've been hearing about fights over JpegXL and WebP (and AVIF?) for years, but don't know much about it. From a quick look at various "benchmarks" JpegXL seems just be flat out better than WebP in both compression speed and size, why has there been such reluctance from Chromium to adopt it? Are there WebP benefits I'm missing? My only experience with WebP has been downloading what is nominally a `.png` file but then being told "WebP is not supported" by some software when I try to open it. |
| |
| ▲ | jmillikin 2 hours ago | parent | next [-] | | Most of the code in WebP and AVIF is shared with VP8/AV1, which means if your browser supports contemporary video codecs then it also gets pretty good lossy image codecs for free. JPEG-XL is a separate codebase, so it's far more effort to implement and merely providing better compression might not be worth it absent other considerations. The continued widespread use of JPEG is evidence that many web publishers don't care that much about squeezing out a few bytes. Also from a security perspective the reference implementation of JPEG-XL isn't great. It's over a hundred kLoC of C++, and given the public support for memory safety by both Google and Mozilla it would be extremely embarrassing if a security vulnerability in libjxl lead to a zero-click zero-day in either Chrome or Firefox. The timing is probably a sign that Chrome considers the Rust implementation of JPEG-XL to be mature enough (or at least heading in that direction) to start kicking the tires. | | |
| ▲ | latexr an hour ago | parent [-] | | > The continued widespread use of JPEG is evidence that many web publishers don't care that much about squeezing out a few bytes. I agree with the second part (useless hero images at the top of every post demonstrate it), but not necessarily the first. JPEG is supported pretty much everywhere images are, and it’s the de facto default format for pictures. Most people won’t even know what format they’re using, let alone that they could compress it or use another one. In the words of Hank Hill: > Do I look like I know what a JPEG is? I just want a picture of a god dang hot dog. https://www.youtube.com/watch?v=EvKTOHVGNbg | | |
| ▲ | jmillikin 42 minutes ago | parent [-] | | I'm not (only) talking about the general population, but major sites. As a quick sanity check, the following sites are serving images with the `image/jpeg` content type: * CNN (cnn.com): News-related photos on their front page * Reddit (www.reddit.com): User-provided images uploaded to their internal image hosting * Amazon (amazon.com): Product categories on the front page (product images are in WebP) I wouldn't expect to see a lot of WebP on personal homepages or old-style forums, but if bandwidth costs were a meaningful budget line item then I would expect to see ~100% adoption of WebP or AVIF for any image that gets recompressed by a publishing pipeline. |
|
| |
| ▲ | jacobp100 2 hours ago | parent | prev | next [-] | | JpegXL and AVIF are comparable formats. Google argued you only needed one, and each additional format is a security vulnerability. | | |
| ▲ | londons_explore 9 minutes ago | parent [-] | | And more importantly, an additional format is a commitment to maintain support forever, not only for you, but for future people who implement a web browser. I can completely see why the default answer to "should we add x" should be no unless there is a really good reason. |
| |
| ▲ | coppsilgold 2 hours ago | parent | prev | next [-] | | JPEG XL has progressive decoding https://www.youtube.com/watch?v=UphN1_7nP8U | |
| ▲ | speps 3 hours ago | parent | prev | next [-] | | It was an issue with the main JPEGXL library being unmaintained and possibly open for security flaws. Some people got together and wrote a new one in Rust which then became an acceptable choice for a secure browser. | | |
| ▲ | a-french-anon 2 hours ago | parent [-] | | Unmaintained? You must be mistaken, libjxl was getting a healthy stream of commits. The issue was the use of C++ instead of Rust or WUFFS (that Chromium uses for a lot of formats). |
| |
| ▲ | out_of_protocol 2 hours ago | parent | prev | next [-] | | - avif is better at low bpp (low-quality images), terrible in lossless - jxl is better at high bpp, best in lossless mode | |
| ▲ | archerx 2 hours ago | parent | prev [-] | | Google created webp and that is why they are giving it unjustified preferential treatment and has been trying to unreasonably force it down the throat of the internet. | | |
| ▲ | breppp 12 minutes ago | parent [-] | | unjustified preferential treatment over jpegxl a format google also had created | | |
| ▲ | archerx 8 minutes ago | parent [-] | | They helped create jpegXL but they are not the sole owner like they are with webp. There is a difference. |
|
|
|
