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

171–180 of 210 posts

Re: The case for JPEG XL

#171

Post by ZeroGravitas »

lifthrasiir wrote: post #13
Nathanba wrote: post #7

As simplistic as it may sound but Google probably removed it mostly because it's a chunk of c++ that they don't want around. I'm the last person to usually endorse a rewrite but in this case maybe they should consider a Rust port so browsers feel more comfortable including this. The point of an image format is to be adopted by everyone.. it's kind of beneficial if you make that usecase as attractive as possible. Pers…

Chromium is an extremely large C++ code base and I don't think they would reject libjxl only for that reason. That said, as an author of the first significant reimplementation of JPEG XL format (J40), I think a Rust decoder would be a good addition to the format and has a long-term plan to make one [1]. [1] https://github.com/lifthrasiir/j40/issues/10

Some on the Mozilla side did raise this as a specific issue.

One interesting project would be a combined JPEG and JPEG XL decoder, written in rust which might even lead to a reduction in code size and better security since they have some overlap.

Re: The case for JPEG XL

#172

Post by pornel »

JyrkiAlakuijala wrote: post #154
pornel wrote: post #150

JXL developers are understandably upset about being a victim of Worse is Better. The Web platform is hardly cutting edge here. It took 10 years to add WebP across browsers, and it wouldn't have been added at all if it didn't cause web-compat issues for non-Chrome(ium) browsers. From browsers' perspective the question isn't "is the new codec better", but "are existing codecs so terrible that they need urgent replaceme…

With your logic we should quickly remove WebP and AVIF, and have an active discussion if JPEG XL is good enough to make it. Also port as much as possible from JPEG XL tech into traditional JPEG.

That's not what I was trying to say. You know that it's impossible to remove WebP from the web platform any more. I do think it'd be nice to have a plan for removal of AVIF from the platform, but I don't know if AV1 video will become unremovable. Porting of new features to the old JPEG has been attempted in JPEG XT, but it didn't take off.

It sucks that the codec with the best quality/filesize ratio doesn't just win. There are many other factors beyond this, e.g.

• There's a lot of inertia keeping old codecs alive, which is from "just works" that has been from merely being old and popular. There's a whole graveyard of JPEG-killers that have beaten it on features and compression. GIF isn't even "good enough" technically, and it still refuses to die, because it's just so old to be universally supported. JPEG XL hasn't done the legwork yet to be everywhere, and isn't old enough yet to be everywhere including old software.

• Browser vendors' default resistance to ever-growing complexity of the platform, code size, and attack surface. I think JPEG XL's ability to be both non-Web editing format and Web format is actually working against it here, because the Web platform doesn't want non-Web features. Browsers haven't even implemented AVIF as specced, only a bare minimum subset. JPEG XL doesn't have a minimal subset.

Re: The case for JPEG XL

#173

Post by pornel »

Attrecomet wrote: post #152
delroth wrote: post #67

Earlier quoted context omitted.

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.

It's relevant because there is no doubt that Firefox would not have axed a promising open format despite users asking for it. It is possible that FF won't continue the work of implementing it if they see no future without the oligarch in the field, but we'll see

Mozilla did not want to ship WebP at all, despite users asking for it, and only added it after too many Chrome-only sites forced them to.

All browser vendors are pretty reluctant to add new codecs, because there's always going to be yet another promising codec to add, but they're left maintaining all of them forever, even after they're not cool and new any more.

Re: The case for JPEG XL

#174

Post by pbowyer »

worldofmatthew wrote: post #125
jl6 wrote: post #68

Earlier quoted context omitted.

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 m…

Besides that jokes you can make at that tweet in how it claims a image codec can be racist. If you know how to limit the image quality range in AVIF (and how to reduce smoothing which can be done), you can get images that have dark areas that are near to that of JPEG-XL. I have been able to (by both reducing the quality range and turning smoothing off) to get much better results on a high contrast image with most of…

Can you share the settings that have worked well for high contrast, darker images? I agree the default settings are not great.

Re: The case for JPEG XL

#175

Post by pizza »

nigeltao wrote: post #62
lifthrasiir wrote: post #54

Earlier quoted context omitted.

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 what…

Just want to mention that modular mode (the encoding technique for lossless mode) does have flags that let you have a bit of loss (by changing a quality flag), though by default what you said is correct, it is fully lossless.

Re: The case for JPEG XL

#176

Post by pizza »

JyrkiAlakuijala wrote: post #76
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?

Some of it relates to the modeling of spontaneous excitation bias of opsin molecule releasing their energy in the retina. These are modeled in the compression curve in JPEG XL by a bias before the compression non-linearity, whereas other codecs don't have that bias unless they use sRGB -- sRGB has modeled the bias as a short linear slope, but compresses in wrong directions (RGB) in the color space, not LMS. In JPEG X…

Hi Jyrki, this is all very interesting. A couple questions for you, while you’re in this thread:

- where is the best documentation for the Butteraugli metric? I’ve found it quite difficult to find a high-level rationale/design notes for the metric.

- I also understand that JXL doesn’t try to explicitly optimize against Butteraugli distance unless you invoke the higher effort levels, and then, it uses a slightly different function than the original Butteraugli distance - is that correct?

- One q about the distance parameter -d; if I pass -d 1 -E x for some x, I’m asking for “an image with at most Butteraugli distance 1”, and if I pick another effort level higher than x, am I asking it to introduce a little bit more loss, so that the Butteraugli distance is likely to increase? Ie is the distance parameter more of an “upper bound for acceptable loss”

- I’ve seen Butteraugli values quoted for different “norms/p-norms” - which one do I use?

- How do I learn more about these colorspace transfer functions?

Thanks again for your awesome work!

Re: The case for JPEG XL

#177

Post by derf_ »

jonsneyers wrote: post #165
cesarb wrote: post #119

Earlier quoted context omitted.

> Compare the spec lengths: 681 pages for https://aomediacodec.github.io/av1-spec/av1-spec.pdf , 101 for https://www.iso.org/standard/77977.html . And here we immediately see one important difference between them: the first link is to a 681-page PDF, which opens immediately in my browser. The second link is to a place where one can buy access to what it says is a 101-page PDF, after paying more money than it would co…

That's a difference between AOM and ISO: ISO puts specs behind a paywall but anyone interested can participate in the actual standardization process through their national standardization body, AOM makes specs publicly available but participating in the standardization process costs about as much as a nice car. I don't really like either model, but I don't think I particularly prefer AOM's model.

We created avenues for open source / community participation in AOM that did not require people to pay any money. Specifically, Mozilla sponsored the membership of VideoLAN, which in theory anyone could join, and a number of people did and do participate through that organization.

Re: The case for JPEG XL

#178

Post by derf_ »

vanderZwan wrote: post #100
zokier wrote: post #69

Earlier quoted context omitted.

> AFAICT, JPEG XL does not seem to have the licensing complications of JPEG2000. Well, there is this thing https://jpegxl.io/articles/rans/

You're technically correct, but: > Several variants of the coding procedure Asymmetric Numerical Systems (ANS) may be found in most modern codecs, such as AV1, Z-Standard compression, or even rANS in JPEG XL. ... this is hardly the fault of the JPEG XL developers though, that's the US patent system being ridiculous. Also, in the current discussion context that patent screws over any new compression format, not JPEG X…

AV1 does not use rANS in any form. The quoted sentence is simply incorrect. However, any necessary patent claims owned by Microsoft, an AOM member, would be freely licensed to everyone for use in AV1 implementations if it actually did use rANS. Which it doesn't.

Re: The case for JPEG XL

#179

Post by ghusbands »

squarefoot wrote: post #74
sangnoir wrote: post #66

Earlier quoted context omitted.

> 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…

Situation has changed dramatically wrt points 1 and 2 since years, however. As for 3, I'm no web developer so can't comment on this.

Chrome is still significantly faster for me on multiple computers. Even now, Firefox can't smoothly scroll though this very page [1] without obvious jitter; no browser should have trouble with that.

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

Re: The case for JPEG XL

#180

Post by M1ch431 »

ogogmad wrote: post #153
pdntspa wrote: post #151

Yay, more "fuck the long tail" from lazy-ass Google developers. Google has a gigantic pile of money. They can afford to keep JPEG XL support.

Take note: This sort of abusive comment is not persuasive. If somebody spoke that way to me, I would not listen to their suggestions, if only out of sheer spite. Why is this manner of speaking so common?

You're ignoring what the commenter is addressing: a corporation, and a particularly insidious one at that.

It's easy to feel powerless and frustrated in a world where corporations (in this case a blatant monopoly) make decisions that affect people's lives.

Without a second thought, because they arbitrarily deem it harmful to their profits or wasting their human resources. Good will... serving the public interest? Only if it's profitable or works towards the corporation's collective interests.

And it's not democratic: I can't propose or participate in a vote to overturn something that a corporation does or decides that affects my life. A Google employee couldn't even do that: Google is under no obligation to follow what their employees decide.

I can adapt, change my habits, even boycott Google; but ultimately my power as a citizen is limited because I lack the most important elements to affect change in this world: very big piles of money and influence.

It seems that Google's developers are merely cogs in the machine (see: the Stadia fiasco). So I'm sure the commenter was mainly directing their frustration to Google.

If Google's employees had a voice, surely Google would have a support department that handles Google's various services? How would you feel if countless people are despairing because the service you developed/worked on isn't serving them properly?

Locked out of your Gmail and recovery methods don't work? Google flagged your domain for so-called abuse? Take to Twitter if you're a celebrity or well-connected and beg for support, or if not: get fucked.

Google is not a good company, and desperately needs regulated.

This manner of speaking is common because not everybody is born with a silver spoon, or is able or willing to take on an enormous amount of debt to obtain a degree that may or may not pan out into a career that uplifts them out of poverty.

Post reply on HN