Live data from Hacker News

macOS 14 will support JPEG XL

twitter.com

21–30 of 123 posts

Re: macOS 14 will support JPEG XL

#21
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.

Does it really matter? These days decoding image with JS or Wasm should be fine. It's not video.

Video is not lossless, a second of high quality video might be a total of 5 megabytes.

A mammogram on the other hand, might be 300 images of lossless 4k resolution, which could clock in at about 2 gigabytes. That could be per breast in a given study, and a study could have prior mammograms attached as well.

You will hit memory limits, so you need to be able to unload and load data intelligently and quickly.

Re: macOS 14 will support JPEG XL

#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.

Re: macOS 14 will support JPEG XL

#23
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.

Can you explain to the rest of us what about JPEG XL applies to that use case? If you asked me to store lossless, 16-bit (per channel, or monochrome, I am assuming) images I would suggest TIFF.

Re: macOS 14 will support JPEG XL

#24
post #12

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?

A canvas element is not as performant as an image element.

Re: macOS 14 will support JPEG XL

#25
post #6

Earlier quoted context omitted.

With the only justification being "nobody wanted it", a plainly false statement. WebP isn't good enough. AVIF isn't good enough. JPEG XL is good enough.

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.

> Their justification was more that adding it would be committing a lot of hardware

Which is completely nonsensical. Hardware support is meaningless for web images.

Re: macOS 14 will support JPEG XL

#26
post #23
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.

Can you explain to the rest of us what about JPEG XL applies to that use case? If you asked me to store lossless, 16-bit (per channel, or monochrome, I am assuming) images I would suggest TIFF.

I think they want better compression. JXL has excellent lossless compression.

Re: macOS 14 will support JPEG XL

#27
post #26
post #23

Earlier quoted context omitted.

Can you explain to the rest of us what about JPEG XL applies to that use case? If you asked me to store lossless, 16-bit (per channel, or monochrome, I am assuming) images I would suggest TIFF.

I think they want better compression. JXL has excellent lossless compression.

[deleted]

Re: macOS 14 will support JPEG XL

#28
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?

A canvas element is not as performant as an image element.

When I am serious about images it is all about high performance: upgrading to better data compression (1) speeds up the network and server and reduces (2) network and (3) storage costs. (4) Decompression of the image is another bottleneck and a soft decoder is itself something to download and compile locally.

If you use a high-powered device you might not appreciate that performance of a low-end Android device hasn't really improved since 2017. I test with an Android Go device that does pretty well if you feed it scaled images but would struggle with the soft decoder.

The native implementation of the decompressor can be much better than one in WebAssembly in that it can use SIMD units on the CPU and many other tricks, including special purpose hardware. That's why Apple is so keen to say that an image format is now supported in the OS, because they codesign the hardware, the OS and the file formats to take advantage of all that.

Re: macOS 14 will support JPEG XL

#29
post #25

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.

> Their justification was more that adding it would be committing a lot of hardware Which is completely nonsensical. Hardware support is meaningless for web images.

Hardware accelerated handling was one of the arguments used to oppose a WASM based implementation that sites could use at will to prove that there's demand for JPEG-XL support (and that the Chrome team provides, by the way).

Re: macOS 14 will support JPEG XL

#30

And Google just (sadly) pulled support from Chrome. Your move, Google.

Can't it be enabled via an extension? Similar to how media players support third party codec.

Not really.

AFAIK (correct me if I’m wrong!) first-party and third-party codecs in media players are kinda equal: you load a file, and the media player picks which codec to delegate that file to. You can’t do that in with a Chrome extension – the extensions can manipulate HTML and run custom JS, but that’s more or less it (plus some basic browser-level stuff like work with tabs and intercept network requests).

This doesn’t mean an extension isn’t possible at all – eg there’s https://github.com/zamfofex/jxl-crx/ that detects JXL images and decodes them with JS – but that’s slower.

Plus the bigger issue is adoption. You want all users to get your JPEG XL images, not just the 0.1% of users that installed the extension.

Post reply on HN