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

macOS 14 will support JPEG XL

twitter.com

Post reply on HN
Print view View original

111–120 of 123 posts

Re: macOS 14 will support JPEG XL

#111

Post by cjawdb »

Dalewyn wrote: post #87
cjawdb wrote: post #82

Earlier quoted context omitted.

Firefox has next to zero marketshare (unfortunately and despite my best efforts to get people to use FF). There was never any chance that Mozilla was going to waste their very limited resources attempting to be the early adopters of an image codec when nobody is going to use it on the web until the browser engine with de facto control over the market starts supporting it.

>never any chance that Mozilla was going to waste their very limited resources Mozilla is many things, but "limited resources" Mozilla is not. That is if they would stop paying their CEO their entire coffer, anyway. >be the early adopters of an image codec when nobody is going to use it on the web until the browser engine with de facto control over the market starts supporting it. The exact opposite mentality was how…

I don't disagree but unfortunately that's the state of Mozilla at the moment.

Re: macOS 14 will support JPEG XL

#112

Post by cjawdb »

viraptor wrote: post #95
cjawdb wrote: post #72

Earlier quoted context omitted.

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

(Facepalm) I was totally thinking of jpeg2000 not jpeg xl. That makes so much more sense!

LOL well that makes much more sense. Hopefully JXL doesn't go the way of JPEG2000 (based on how things have gone thus far and its impressive featureset, I think it might be safe).

Re: macOS 14 will support JPEG XL

#113

Post by twotwotwo »

schrmh wrote: post #77
twotwotwo wrote: post #44

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.

Those words were about the JPEG recompressor (Brunsli) specifically, which saves about 22% but has a smoother transition from today's .jpg world than any of the new lossy formats; you can bit-for-bit reconstruct the original JPEG from the Brunsli-compressed one, and it's certainly much faster than AVIF to encode with CPUs. You can even insert Brunsli as a Content-Encoding that's transparent to the user (so right click still saves .jpg), and Chrome had an issue open to consider doing that before they backed out JXL support.

Re: macOS 14 will support JPEG XL

#114

Post by alwillis »

alwillis wrote: post #67
slig wrote: post #22

Earlier quoted context omitted.

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.

> Is there a specific reason why this has to be a OS update thing? The way Apple does it, it's cleaner to implement the APIs for this sort of thing in a new operating system version, especially if it requires features not present in the current versions of the operating system. They could make an exception for Safari by including the required code to support JPEG XL in Safari Technology Preview on Ventura to allow de…

JPEG XL support is coming Safari 17 on Sonoma, Ventura and Monterey: https://front-end.social/@jensimmons/110497266298128289

Re: macOS 14 will support JPEG XL

#115

Post by majora2007 »

woah wrote: post #12
PaulHoule wrote: post #5

Earlier quoted context omitted.

As a mirrorless photographer who wants to publish photos on the web that look like they came out of a mirrorless camera I want JPEG XL. In trials I've done, AVIF works well for a throwaway splash image for a blog but compression results are not so impressive compared to JPEG or WEBP if you want the image to hold up under close inspection. On the other hand there is something that seems almost infantile about image su…

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?

Canvas has hard caps on the size it can be as well and when resizing an image to a fixed size, there is a lot of hard edges as you need to implement your own smoothing. Image tag is more flexible and versatile.

Re: macOS 14 will support JPEG XL

#116

Post by jonsneyers »

ajconway wrote: post #17
zamadatix wrote: post #13

Earlier quoted context omitted.

Assuming you meant "de"coding: it does, albeit I like JPEG XL's more. To me, that point seems an argument for things being the other way around anyways (i.e. general-purpose but not a good delivery format).

I stand (partially) corrected: https://github.com/AOMediaCodec/libavif/pull/640

I am not sure how exactly the "progressive avif" works, but it looks like basically something optional that comes at a cost in the final file size, whereas in jxl some basic progressive encoding is always available (at least for lossy images) and doesn't come at a cost in file size.

Re: macOS 14 will support JPEG XL

#117

Post by JyrkiAlakuijala »

woah wrote: post #12
PaulHoule wrote: post #5

Earlier quoted context omitted.

As a mirrorless photographer who wants to publish photos on the web that look like they came out of a mirrorless camera I want JPEG XL. In trials I've done, AVIF works well for a throwaway splash image for a blog but compression results are not so impressive compared to JPEG or WEBP if you want the image to hold up under close inspection. On the other hand there is something that seems almost infantile about image su…

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?

HDR and progression are difficult to do right now. Possible interplay with CPU/GPU in rendering is difficult. JS is executed later than html is parsed.

Re: macOS 14 will support JPEG XL

#118

Post by ksec »

jez wrote: post #31
amoerie wrote: 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?

>If the decision was intentional: did they state a reason why?

Yes It was intentional.

They stated AVIF is as good if not better than JPEG XL.

Re: macOS 14 will support JPEG XL

#119

Post by ksec »

account42 wrote: post #103
cjawdb wrote: post #65

Earlier quoted context omitted.

This is the terrible explanation they gave for dropping support: https://bugs.chromium.org/p/chromium/issues/detail?id=117805... "Thank you everyone for your comments and feedback regarding JPEG XL. We will be removing the JPEG XL code and flag from Chromium for the following reasons: - Experimental flags and code should not remain indefinitely - There is not enough interest from the entire ecosystem to continue expe…

WebP and libwebp/cwebp is such a clusterfuck. Lossless mode isn't even visually lossless because cwebp doesn't understand how PNGs encode color space information. Default lossy settings are extremely garbage for darker (parts of images) images - a problem that has plagued video codecs (which is what webp is based on) for a long time. Animated webp is ridiculously inefficient compared to webm and really shouldn't be a…

>At this point it should really just be deprecated in favor of JPEG XL. And let's skip AVIF completely please.

You say that now, try doing that between 2020 all the way to 2022 you get attacked by AOM Strike Force.

Re: macOS 14 will support JPEG XL

#120

Post by ksec »

DannyBee wrote: post #74
derefr wrote: post #34

Earlier quoted context omitted.

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

I am sorry but Google's rationale and comparison [1] between JpegXL and WebP is even more impressive.

And much like Microsoft, I will put any research arm of a company as a separate company.

[1] http://storage.googleapis.com/avif-comparison/index.html

Post reply on HN