Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The case for JPEG XL

cloudinary.com

Post reply on HN
Print view View original

51–60 of 210 posts

Re: The case for JPEG XL

#51

Post by lifthrasiir »

sfink wrote: post #36

I'm not really familiar with the space, but the article kind of suggests another reason I could imagine not supporting JPEG XL: if it has the long list of advantages described, then how much of a single thing is it? Do you have to implement every feature in order to be considered supporting JPEG XL? Or would a browser implementing from scratch run the risk of splitting what the format means? I don't think having an e…

> if it has the long list of advantages described, then how much of a single thing is it? Do you have to implement every feature in order to be considered supporting JPEG XL? Or would a browser implementing from scratch run the risk of splitting what the format means?

You have a very good point. In fact I think this is the first time I ever seen such a question, which was also something I wanted to answer by making J40. Of course in the practical standpoint you should just use existing libraries, but I wanted to answer that from the library author's perspective.

I'm happy to report that JPEG XL's design is better than I hoped and it successfully tried to do many things out of a reasonable number of components. This means that library authors can mostly implement those components and they will combine reasonably well. There are still some imperfect edges though. For example JPEG XL splits a full image into multiple tiles to faciliate parallel decoding, and the Table of Contents is used to locate individual tile data. But TOC requires a full entropy coding to decode, so you can't easily determine how many bytes are needed for decoding, say, 1/2 of the full image. Those kind of imperfections are harmless for JPEG XL's main use cases but still something I would definitely fix if I'm even given a chance (not to say that I'm a good person to do so).

Re: The case for JPEG XL

#52

Post by jokabrink »

I think the solely reason why JPEG XL did not go off is simple: It had no lobby. No large tech company actively promotes it and so, many people hadn't heard of it. Ironically, the deprecation of it in chrome made me aware of it in the first place.

Technically, JPEG XL may be a superior contestant. But from a 'social' point of view? Disastrous, especially considering it already has "JPEG" in it. (To be fair, its also quite young...)

I really hope JPEG XL gets more traction because it seems like a really good successor to the old namesake.

Re: The case for JPEG XL

#53

Post by Heikete »

The thing that I don't understand is why the world has switched over to Chrome leaving Firefox behind. Here in Poland most of the tech people use Firefox as that was the alternative when IE was a bad guy and Firefox continues to be a good browser. What was the advantage of Chrome which made people exchange one monopoly for another? PNG had also hard times in IE at first, as far as I remember. So instead of fighting for good chrome, shouldn't we just fight for more diversity in browserland?

Re: The case for JPEG XL

#54

Post by lifthrasiir »

nigeltao wrote: post #47

From the "Lossless Compression Performance" section of the article: > JPEG XL can do lossless image compression in a way that beats existing formats (in particular PNG) in all ways: it can be faster to encode, produces smaller files, and more... Does "in all ways" include any decode (not encode) speed numbers? Such numbers are dependent on the test suite, and I might be holding it wrong, but on my measurements, JPEG…

Your benchmark seems to lack options used. JPEG XL has two main knobs for quality and speed, as I've previously mentioned in [1], and the default effort 7 (which is, assuming that you didn't set any other options, presumably used in your benchmark) would definitely prefer compression ratio over compression speed. You will need multiple entries for JPEG XL with varying efforts for a fair compraison.

[1] https://news.ycombinator.com/item?id=33401540

Re: The case for JPEG XL

#55

Post by jbverschoor »

Heikete wrote: post #53

The thing that I don't understand is why the world has switched over to Chrome leaving Firefox behind. Here in Poland most of the tech people use Firefox as that was the alternative when IE was a bad guy and Firefox continues to be a good browser. What was the advantage of Chrome which made people exchange one monopoly for another? PNG had also hard times in IE at first, as far as I remember. So instead of fighting f…

Firefox was slow as hell and resource hungry

Also, the ui doesn’t feel naive at all

Re: The case for JPEG XL

#56

Post by jonsneyers »

nigeltao wrote: post #47

From the "Lossless Compression Performance" section of the article: > JPEG XL can do lossless image compression in a way that beats existing formats (in particular PNG) in all ways: it can be faster to encode, produces smaller files, and more... Does "in all ways" include any decode (not encode) speed numbers? Such numbers are dependent on the test suite, and I might be holding it wrong, but on my measurements, JPEG…

Lossless encoding can be done with various trade-offs between speed and compression density.

At one extreme we have fjxl, see e.g. https://twitter.com/LucaVersari3/status/1485971553892323333?.... This is an extremely fast lossless jxl encoder, which is about 100 times faster than PNG encoding (libpng) and compresses about 10% better.

At the other extreme, there are the slowest settings of the reference encoder libjxl, which are 1000 times slower than libpng but compresses a lot better.

As for decode speed: this depends on whether you consider single-threaded or multi-threaded performance. In single-threaded decode performance, it is hard to beat PNG since it is basically just gunzip. PNG is inherently sequential though (unless you apply trickery at encode time to make parallel decode possible), while JXL is by design decodable in parallel. We are anticipating that in the future, the number of cores available on typical hardware will only grow, so this difference will naturally lead to JXL becoming faster to decode in practice.

The current reference software libjxl is quite optimized for the lossy case, but still has some room for improvement for the lossless case — in particular it does not have fast paths yet for the common case where the full precision of 32-bit per sample is not required.

So in conclusion, I think it is safe to say that JPEG XL beats PNG in all ways.

Re: The case for JPEG XL

#57

Post by est31 »

lifthrasiir wrote: post #30
hypothesis wrote: post #14

Earlier quoted context omitted.

This is a valid argument, but which of the contenders are using Rust or similar security minded languages? WebP appears to be written in C++, perhaps because underlying video codec is also written in C++…

There is a Rust WebP decoder in image-rs [1], presumably independently written from the specification. [1] https://github.com/image-rs/image/tree/master/src/codecs/web...

FTR that decoder does not support colors, so for most uses it is not ready yet: https://github.com/image-rs/image/pull/952

Re: The case for JPEG XL

#58

Post by nine_k »

tgv wrote: post #46
nine_k wrote: post #17

The scoop: a JPEG XL developer explains how JPEG XL is uniquely better than AVIF, webP, and PNG, and laments the Chrome team's decision to drop the experimental support for it. AFAICT, JPEG XL does not seem to have the licensing complications of JPEG2000.

You're seriously underselling the article.

I'm trying to entice reading it! :)

Re: The case for JPEG XL

#59

Post by atemerev »

Heikete wrote: post #53

The thing that I don't understand is why the world has switched over to Chrome leaving Firefox behind. Here in Poland most of the tech people use Firefox as that was the alternative when IE was a bad guy and Firefox continues to be a good browser. What was the advantage of Chrome which made people exchange one monopoly for another? PNG had also hard times in IE at first, as far as I remember. So instead of fighting f…

Advertising and branding. Google is a search monopoly, and has (or used to have) the reputation of "we are making high-quality software". We have a web search monopoly, because our search engine is the best, so why not trust us for making the best browser too?

Firefox has no search engine monopoly to advertise and build its brand upon.

Re: The case for JPEG XL

#60

Post by atemerev »

jbverschoor wrote: post #55
Heikete wrote: post #53

The thing that I don't understand is why the world has switched over to Chrome leaving Firefox behind. Here in Poland most of the tech people use Firefox as that was the alternative when IE was a bad guy and Firefox continues to be a good browser. What was the advantage of Chrome which made people exchange one monopoly for another? PNG had also hard times in IE at first, as far as I remember. So instead of fighting f…

Firefox was slow as hell and resource hungry Also, the ui doesn’t feel naive at all

No UIs feel native these days, everybody invents their own UI kits.
Post reply on HN