Hacker News Reader

Comment by delroth | Hacker News Reader

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.

View on HN

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.

I don't think there was ever a good case for WebP, but JPEG XL sounds promising. The problem of course, is the monopoly browser developer made WebP, and the monopoly browser developer sees JPEG XL as a competitor to their in-house format.

That's a bizarre and unfounded accusation. Author of WebP worked on JPEG XL, and Google has shipped AVIF which includes tech from Mozilla, Nokia, and many others.

I consider that WebP lossy was fixed to usable quality level around 2015, five years after the launch. For the first five years it had a tendency to make 4x4 pixel lego-block representations of smooth gradients and lose highly saturated colors.

8-bits per channel and YUV420 only were caused by hurrying it.

With JPEG XL we have the opposing mistake. We had a great format already in 2017, and spent 5 years more for improving it further.

They did. image.jxl.enabled in about:flags

Warning: this only works in nightly builds of firefox. In stable and beta they have the flag but they're not compiling the code, so it just doesn't work.

Reply on news.ycombinator.com