Live data from Hacker News

macOS 14 will support JPEG XL

twitter.com

71–80 of 123 posts

Re: macOS 14 will support JPEG XL

#71

I hope it shows up in Safari and that this sign of interest from others gets it a second shot in Chrome. Just the JPEG recompression is arguably worth the price of entry; it's less savings than AVIF, of course, but it's easier to adopt now , where re-encoding everything as AVIF is a much larger hump to get over. Its other modes provide some real benefits for users for very-high-quality and lossless images as well as…

> I hope it shows up in Safari and that this sign of interest from others gets it a second shot in Chrome.

I'm pretty sure the Chrome team knew at the time they dropped JPEG XL that there was a decent chance Apple would implement it--there's certainly enough of a backchannel between the browser teams at Google, Apple, Mozilla and Microsoft.

Re: macOS 14 will support JPEG XL

#72

I'm trying to understand the motivation here. There's a few new image formats as potential candidates: jpeg xl, webp v2, avif, heic. Apple already had heic in the os, but still not Safari AFAIK. Avif has the benefit of hardware encoders/decoders (with limited chroma options though). I see the HDR mentioned in other comments which is interesting. Are there any (potential conspiracy) reasons they would choose not to go…

I'm confused where you got "it was available for years and ignored in popular software" from? Most of the ISO standard was only published last year, with the last bit being published in October 2022. IIRC AVIF is almost ~4 years old by the same standards and WebP is over a decade old.

Adobe has partial support (in Camera RAW) with presumably further support coming considering their website recommends JXL alongside AVIF for HDR images. It's also supported by Affinity Photo 2, Krita, Darkroom, GIMP, ffmpeg, ImageMagick, Paint.net, anything Qt/KDE-based via plugin, Pale Moon, libvips, and almost every third-party image viewer that I've ever used or heard of (nomacs, Irfanview, ImageGlass, xnView, etc.). It also has had vocal support from senior engineers at a variety of companies like Facebook, Shopify, Cloudinary, Intel, Flickr, etc.

My first thought when I heard about JXL several months ago was "oh, a new JPEG-2000?" but I've quickly become a JXL evangelist after reading more about it and then playing around with libjxl myself.

https://jpegxl.info/why-jxl.html

https://jpegxl.io/articles/faq/

https://cloudinary.com/blog/the-case-for-jpeg-xl

Re: macOS 14 will support JPEG XL

#73
post #68

Earlier quoted context omitted.

Their justification was more that adding it would be committing a lot of hardware and software vendors to support it which would be very expensive for not enough gain.

More accurately, their justification was based on discredited benchmarks (which used a fairly old-even-at-the-time version of libjxl and IIRC created by the AVIF team)... and the commit to remove support was created by a co-author of WebP who gives talks on WebP and is the primary contributor to libwebp. The Chromium issue where they made this decision is full of "hardware and software vendors" (Adobe, Serif/Affinity…

You certainly have an opinion, but you do also keep leaving out facts that don't particularly support it, both here, and elsewhere.

"and the commit to remove support was created by a co-author of WebP who gives talks on WebP and is the primary contributor to libwebp."

Google also employs two of the co-authors of JPEG XL, who give talks on JPEG XL, and was were two of the primary contributors to libjxl.

The main authors of the JPEG XL specification are Jyrki Alakuijala, Jon Sneyers, and Luca Versari. Jyrki is a Googler. Jon is at Cloudinary. Luca is also at Google.

If you are going to try to come up with a silly conspiracy about this being WebP related, it probably would help if this wasn't the case.

Maybe consider that they do in fact have the expertise necessary to decide whether JPEG-XL is something they want to do?

I mean, seriously. You can disagree with the decision, but your argument that they have no idea what they are doing WRT to JPEG-XL seems pretty silly - the only company who arguably has any better idea would be cloudinary.

Re: macOS 14 will support JPEG XL

#74
post #34
post #31

Earlier quoted context omitted.

> I sincerely hope this might make Chrome change its mind. I take this to suggest that Chrome actively decided against implementing JPEG XL? Did they consider supporting it and reject support for it, or has it simply not been prioritized, but still might be prioritized one day? If the decision was intentional: did they state a reason why?

They did all the work required to implement it, sat around for a few months, and then removed it , before anyone else even noticed it was there / had a chance to start integrating it. My personal conspiracy theory is that some Google engineer who works on Chrome, came up with "JPEG XL support" as a feature they could work on, pushed it through to prod, patted themselves on the back, and forgot about it; but this was…

The number of people in this thread pretending they have more expertise about this, and spreading random conspiracy theories about WebP, is impressive.

Actually, Google employs 2 of the 3 main authors of the JPEG XL spec, and the main contributors to libjxl.

Also, it wasn't a few months, and others had explicitly said no.

You can argue it was a dumb decision, but like, can we at least get facts straight instead of making up random stories?

There people in this thread arguing they have no idea what they are doing and have no expertise, while they simultaneously employ the spec authors to work on it and are one of the two primary contributors to the reference library.

A bit silly and incongruous.

Just because someone does something you don't like doesn't make them stupid or wrong. You'd be much better off if you would gather facts first, listen to the perspectives of others, and then respond.

Re: macOS 14 will support JPEG XL

#75
post #12

Earlier quoted context omitted.

Dumb question, but why is OS or browser support necessary? Couldn't an HTML canvas element and some JS that can parse the file format display any kind of image that you might want?

There's a JS/WASM polyfill for JXL, but it involves some fragile hacks like MutationObserver and canvas writes, has worse performance than native code, and tends to crash Chrome.

Why would MutationObserver be necessary to display a static image in a ?

Re: macOS 14 will support JPEG XL

#76
post #31
post #2

As a radiology software developer: please please let JPEG XL become a thing. I sincerely hope this might make Chrome change its mind. JPEG XL is a game changer for 16 bit lossless images. The technical landscape for these kinds of images today is barren.

> I sincerely hope this might make Chrome change its mind. I take this to suggest that Chrome actively decided against implementing JPEG XL? Did they consider supporting it and reject support for it, or has it simply not been prioritized, but still might be prioritized one day? If the decision was intentional: did they state a reason why?

The Googlers behind webp have more clout than the Googlers behind Jpeg XL.

JPEG XL has gained broader industry interest than any of the previous attempts to replace JPEG.

I think someone is very hurt that their web p pet project has earned more hate than love

Re: macOS 14 will support JPEG XL

#77

I hope it shows up in Safari and that this sign of interest from others gets it a second shot in Chrome. Just the JPEG recompression is arguably worth the price of entry; it's less savings than AVIF, of course, but it's easier to adopt now , where re-encoding everything as AVIF is a much larger hump to get over. Its other modes provide some real benefits for users for very-high-quality and lossless images as well as…

»it's less savings than AVIF, of course,« In most cases JPEG XL will save you more than AVIF.

Re: macOS 14 will support JPEG XL

#78
post #68

Earlier quoted context omitted.

More accurately, their justification was based on discredited benchmarks (which used a fairly old-even-at-the-time version of libjxl and IIRC created by the AVIF team)... and the commit to remove support was created by a co-author of WebP who gives talks on WebP and is the primary contributor to libwebp. The Chromium issue where they made this decision is full of "hardware and software vendors" (Adobe, Serif/Affinity…

You certainly have an opinion, but you do also keep leaving out facts that don't particularly support it, both here, and elsewhere. "and the commit to remove support was created by a co-author of WebP who gives talks on WebP and is the primary contributor to libwebp." Google also employs two of the co-authors of JPEG XL, who give talks on JPEG XL, and was were two of the primary contributors to libjxl. The main autho…

»they do in fact have the expertise necessary to decide whether JPEG-XL is something they want to do?« The problem is that they do have the people with expertise but those were not asked. For example, the AVIF team at Google does not have the expertise — they have proven that publicly (there was a AVIF vs JXL comparison thing that got put out) and later on an response they gave to Sneyers (the response got shared on Discord).

Re: macOS 14 will support JPEG XL

#79
post #22
post #9

Finally, a good reason to upgrade (again).

Is there a specific reason why this has to be a OS update thing? I know that it's likely that they don't update the emoji font outside major OS updates so people have an extra reason to update.

It doesn't have to be, but by making it an OS level thing, then when you download that photo, it still opens in Preview, etc.

Re: macOS 14 will support JPEG XL

#80
post #68

Earlier quoted context omitted.

More accurately, their justification was based on discredited benchmarks (which used a fairly old-even-at-the-time version of libjxl and IIRC created by the AVIF team)... and the commit to remove support was created by a co-author of WebP who gives talks on WebP and is the primary contributor to libwebp. The Chromium issue where they made this decision is full of "hardware and software vendors" (Adobe, Serif/Affinity…

You certainly have an opinion, but you do also keep leaving out facts that don't particularly support it, both here, and elsewhere. "and the commit to remove support was created by a co-author of WebP who gives talks on WebP and is the primary contributor to libwebp." Google also employs two of the co-authors of JPEG XL, who give talks on JPEG XL, and was were two of the primary contributors to libjxl. The main autho…

Phrasing this like "well Google must know best because they employ some subset of the people that worked on JXL" when the entire rest of the industry has been very overwhelmingly pro-JXL isn't very convincing. Also my point wasn't "Google doesn't know what they're doing", it's that internal politics at Google are probably a factor in them basically being the only opposition to a standard that has been gaining support significantly faster than WebP or AVIF (both much older formats at this point) ever did.
Post reply on HN