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

61–70 of 210 posts

Re: The case for JPEG XL

#61

Post by jonsneyers »

lifthrasiir wrote: post #23
hypothesis wrote: post #19

On one hand numbers do not mean much, but I think that releasing a 1.0 version of official library would at least help with morale and signal some completeness. I’m sure there are reasons making fresh 0.x releases even after creating a standard format, but it was a bit disappointing after years of waiting, even before this blow by certain browser maker.

libavif is still not at 1.0 (in fact, 0.11.1 at the time of this writing). Having a 1.0 release is good, but not relevant to this matter.

Also libwebp reached 1.0 only about 8 years after it was added to Chrome. So I don't think this is a major criterion.

That said, we are aiming to reach the libjxl 1.0 milestone within a reasonable timeframe, i.e. somewhere in 2023, preferably first half.

Re: The case for JPEG XL

#62

Post by nigeltao »

lifthrasiir wrote: post #54
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.y…

IIUC, the quality knob (not the effort knob) isn't relevant for lossless encoding.

Knobs are also less relevant for lossless decoding, where there's only one correct output for any given input.

In any case, my code (https://github.com/nigeltao/qoir/blob/main/adapter/jxl_adapt...) copy/pastes examples/encode_oneshot.cc from the libjxl repository, plus an additional JxlEncoderSetFrameLossless call.

So I'm using whatever knob values that the libjxl example uses, i.e. the default knob values. If there are better knob values for lossless, let me know.

Re: The case for JPEG XL

#64

Post by jonsneyers »

izacus wrote: post #31
nine_k wrote: post #18

Earlier quoted context omitted.

I wonder what is the Mozilla's position on JPEG XL.

Mozilla is one of the founding members of AoM backing AVIF/AV1. They're shipping AVIF support enlabled. The JPEG-XL bug hasn't received any news or updates for at least a year now and the support is disabled on all stable builds (meaning: you can't even enable it with a flag since it's not compiled in). You can enable a flag on nightlies.

It hasn't received news or updates because it has been locked. Basically Mozilla's position seems to be that they're not going to do anything on this front until Chrome does it first. I can only assume the decision makers at Mozilla feel the need to "prove their loyalty to the AOM", just like the Chrome codec devs, by blocking non-AOM codecs, in particular JXL.

Re: The case for JPEG XL

#65

Post by nigeltao »

jonsneyers wrote: post #56
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 libjx…

fjxl is the "JXL_Lossless/f" lines in my full_benchmarks.txt link. It's about mid-table in terms of encode speed. I clocked it at about 10x faster than libpng, not 100x faster.

If you look solely at encode speed, fjxl loses to fpnge (also listed in full_benchmarks.txt) so I'm not convinced yet that JPEG XL beats PNG in all ways.

I believe that Apple have an unofficial PNG extension that facilitates multi-threaded decoding: https://github.com/w3c/PNG-spec/issues/45

Re: The case for JPEG XL

#66

Post by sangnoir »

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…

> The thing that I don't understand is why the world has switched over to Chrome leaving Firefox behind

Reasons why I, a former Firefox promoter switched to Chrome:

1. Speed. Chrome was blazing fast compared to other browser

2. Stability: Chrome could have a tab crash without bringing down your entire browser.

3. Really good developer tools that were superior to Firebug. As a matter of fact, Chrome Dev tools were my gateway drug as I'd use Chrome for work and Firefox for personal browsing, and the gradually shifted entirely to Chrome.

Re: The case for JPEG XL

#67

Post by delroth »

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…

How is this relevant to this article given that Firefox has never shipped JPEG XL support in a public build? Not even behind an experimental flag like Chrome did.

Re: The case for JPEG XL

#68

Post by jl6 »

DaiPlusPlus wrote: post #49
est wrote: post #39

Earlier quoted context omitted.

> people-of-color skin is better represented in JPEG XL wait what? What is this woodoo and why it itsn't the case for other image formats in which encodings color in RGB?

Preface: It's difficult to write about stuff like this and I know reading it back to myself after will leave me wanting to redraft it 5 times over but it's 1am already. But, if this post is wrong/incorrect or is missing other factors that are too important to leave out then please let me know and I'll amend or even delete it. My focus is on the technical side of things. So anyway: > why it itsn't the case for other i…

There’s a Twitter thread by a JPEG XL dev who tries to explain some of this in terms of the XYB color space giving more bits to dark tones:

https://mobile.twitter.com/jonsneyers/status/155021585930558...

But I’m not clear if this was a design goal of JPEG XL, or a theoretical side-benefit, or something you would need an HDR screen to appreciate (I couldn’t tell the difference in any of the example images, but those may have been processed by Twitter).

Re: The case for JPEG XL

#69

Post by zokier »

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.

> AFAICT, JPEG XL does not seem to have the licensing complications of JPEG2000.

Well, there is this thing https://jpegxl.io/articles/rans/

Re: The case for JPEG XL

#70

Post by lonjil »

gman83 wrote: post #40

Was there any momentum getting JPEG XL approved in browsers (not behind a flag) before Google decided not to support it? I barely heard about it at all. Perhaps if Google wants to create developer enthusiasm for some new feature they want to implement, they should first announce they're NOT going to be implementing said feature, then when the inevitable backlash happens, very publicly backtrack.

> Was there any momentum getting JPEG XL approved in browsers (not behind a flag) before Google decided not to support it?

Not sure if it counts as momentum, but engineers representing Facebook, Intel/VESA, Shopify, Adobe, and more have been asking for JXL to be enabled in Chrome without a flag for quite a while now.

Post reply on HN