Hacker News Reader

Comment by JyrkiAlakuijala | Hacker News Reader

Chrome advised and inspired this work in their position about JPEG XL.

Here: https://www.mail-archive.com/blink-dev@chromium.org/msg04351...

"can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format"

It's a yes!

Of course full JPEG XL is quite a bit better still, but this helps old compatible JPEG to support HDR without 8-bit banding artefacts or gainmaps, gives a higher bit depth for other uses where more precision is valuable, and quite a bit better compression, too.

View on HN

> "can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format"

Only within pretty narrow limits.

Classic JPEG will never be as efficient given its age, in the same way that LAME is doing incredible things for MP3 quality, but any mediocre AAC encoder still blows it out of the water.

This is in addition to the things you've already mentioned (HDR) and other new features (support for lossless coding).

And I'd find their sentiment much easier to believe if Google/Chrome weren't hell-bent on making WebP (or more recently AVIF) a thing themselves! That's two formats essentially nobody outside of Google has ever asked for, yet they're part of Chrome and Android.

Despite the answer being yes, IMO it's pretty clear that the question is disingenuous, otherwise why did they add support for WebP and AVIF? The question applies equally to them.

> It's a yes!

Reminds me of "You Scientists Were So Preoccupied With Whether Or Not You Could, You Didn't Stop To Think If You Should."

The arithmetic coding feature was already painful enough. I'm simply not in need of yet another thing that makes jpeg files more complicated to deal with.

> After weighing the data, we’ve decided to stop Chrome’s

> JPEG XL experiment and remove the code associated with

> the experiment.

> We'll work to publish data in the next couple of weeks.

Did that ever happen?

I don't see any downsides with Jpegli. Your Linux distro admin exchanges the lib for you, you never need to think about it, only get smaller and more beautiful files. If you use commercial software (Apple, Adobe, mobile phone cameras, Microsoft, ...) hopefully they migrate by themselves.

If they don't, literally nothing happens.

I fail to see a major downside. Perhaps open up your thinking on this?

Yes, Chrome published data.

> you never need to think about it, only get smaller and more beautiful files

People said the same thing last time and it took more than 10 years until decoding worked reliably. I'm simply not interested in dealing with another JPEG++.

> Perhaps open up your thinking on this?

Nah, I'm fine. I went JXL-only for anything new I'm publishing, and if people need to switch browsers to see it – so be it.

It's not a new JPEG++. It creates old JPEGs, fully 100% compatible.

(Of course JXL is better still.)

> I went JXL-only for anything new I'm publishing, and if people need to switch browsers to see it – so be it.

This makes your website only viewable on Safari (and by extension Apple devices) only, right?

Reply on news.ycombinator.com