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

Google's decision to deprecate JPEG-XL emphasizes the need for browser choice

fsf.org

Post reply on HN
Print view View original

11–18 of 18 posts

Re: Google's decision to deprecate JPEG-XL emphasizes the need for browser choice

#11

Post by Kab1r »

Jasper_ wrote: post #10
bick_nyers wrote: post #7

I really wanted (and still want) JPEG-XL to succeed. Not sure how feasible this is, but one thing that could of helped with .jxl is allowing it to be read by a jpeg decoder. Let me explain. JPEG-XL has a feature that allows you to pull out a fully compliant jpeg, if you could somehow send the entire .jxl payload, and the browser's jpeg decoder just decoded the jpeg part, I feel adoption would be significantly easier,…

What value does this provide over serving a .jpg file?

Presumably, JPEG-XL decoders would produce higher quality decodes out of the same file while being backwards compatible with browsers that only have support for standard JPEGs

Re: Google's decision to deprecate JPEG-XL emphasizes the need for browser choice

#12

Post by Jasper_ »

Kab1r wrote: post #11
Jasper_ wrote: post #10

Earlier quoted context omitted.

What value does this provide over serving a .jpg file?

Presumably, JPEG-XL decoders would produce higher quality decodes out of the same file while being backwards compatible with browsers that only have support for standard JPEGs

If it's backwards-compatible with standard JPEG decompressors, then you've just made a better JPEG encoder. And that's great, and people are still doing that all the time, but we don't need a whole new ISO spec to do it. All of the JPEG-XL enhancements are new additions to the format that aren't backwards-compatible.

Re: Google's decision to deprecate JPEG-XL emphasizes the need for browser choice

#13

Post by zorgmonkey »

Jasper_ wrote: post #9
netol wrote: post #6

"Google's deprecation of the JPEG-XL image format in February in favor of its own patented AVIF format might not end the web in the grand scheme of things, but it does highlight, once again, the disturbing amount of control it has over the platform generally." I thought AVIF was royalty-free.

The specification of AVIF is also publicly available, while you would have to pay a little under $500 to purchase all five of the ISO/IEC 18181 specifications for JPEG-XL. Not a monumental cost, but something prohibitive for a hobbyist: https://www.iso.org/standard/77977.html?browse=tc https://www.iso.org/standard/81554.html?browse=tc https://www.iso.org/standard/80617.html?browse=tc https://www.iso.org/standard/8061…

The C++ committee makes draft versions of the standard available for free[0], I've heard that often the last draft before a new standard version is published is almost identical to the published version. It would be awesome if someone involved with JPEG-XL could arrange for the same. Edit: I found https://arxiv.org/abs/1908.03565 but it hasn't been updated since 2019.

[0] https://eel.is/c++draft/

Re: Google's decision to deprecate JPEG-XL emphasizes the need for browser choice

#14

Post by fyzix »

overstay8930 wrote: post #8

I like how this article conveniently left out the fact that Google also created JPEG-XL, and implies AVIF is a Google proprietary format. Can't believe how far FSF has fallen if they have to resort to straight up lying to people to get their message across.

That's my issue with fanatics, they think the ends justify the means...

Re: Google's decision to deprecate JPEG-XL emphasizes the need for browser choice

#15

Post by ZeroGravitas »

netol wrote: post #6

"Google's deprecation of the JPEG-XL image format in February in favor of its own patented AVIF format might not end the web in the grand scheme of things, but it does highlight, once again, the disturbing amount of control it has over the platform generally." I thought AVIF was royalty-free.

Patented and royalty-free are not distict, it depends on whether the owners of the patent have agreed to others using it royalty-free, which is the case here (for both AVIF and JPEG-XL, and both have Google owned patents I think) .

So they are technically correct but a little misleading.

Re: Google's decision to deprecate JPEG-XL emphasizes the need for browser choice

#16

Post by SideQuark »

overstay8930 wrote: post #8

I like how this article conveniently left out the fact that Google also created JPEG-XL, and implies AVIF is a Google proprietary format. Can't believe how far FSF has fallen if they have to resort to straight up lying to people to get their message across.

Google did not create JPEG-XL. They answered a call by the independent JPEG standards org, as did others. The majority of the spec and ideas came from elsewhere, as did the reference code.

Next you'll tell us Microsoft made C++ because they have an employee on the standards board...

Re: Google's decision to deprecate JPEG-XL emphasizes the need for browser choice

#17

Post by olliej »

jerryX wrote: post #2

Chromium 934 stars, 397 comments: https://bugs.chromium.org/p/chromium/issues/detail?id=117805... Firefox: 434 upvotes, 61 comments: https://connect.mozilla.org/t5/ideas/idb-p/ideas/status-key/... Official support software list: https://en.wikipedia.org/wiki/JPEG_XL#Official_support Comparison/benchmarks: https://cloudinary.com/blog/contemplating-codec-comparisons Feature comparison: https://jpegxl.info/comparison.pn…

Votes and comments aren’t a measure of popularity or importance. They’re super easily skewed by specific communities deciding to hammer the reports or similar - often about things they don’t have technical understanding of.

Other examples would be when Libc++ announced adding bounds checking by default and a huge number of people (from HN and similar) came in to provide votes/+1s or comments with little actual technical feedback

Re: Google's decision to deprecate JPEG-XL emphasizes the need for browser choice

#18

Post by habitue »

This is kind of an awkward issue for FSF, since the relevant parts of chrome are free software. You can fork chrome and keep the jpeg-xl implementation in and surf the web.

But that doesn't matter, because the source being free isn't the issue, it's the default in a complex ecosystem of websites responding to browsers supporting standards, which they judge by uptake of the pre-standardized versions, etc etc etc.

Post reply on HN