[heliographe]

It’s supported, but unfortunately no 3rd party APIs yet. It’s a bit surprising they wouldn’t ship them on launch to encourage adoption.

I make photography/camera apps and would like to support JPEG XL natively (without having to rely on 3rd party code) so I hope it’s something they add soon!

[troupo]

> It’s a bit surprising they wouldn’t ship them on launch to encourage adoption.

Because Apple is all in in HEIC/HEIV. The "high efficiency" codecs that require up to a second on an M1 Pro to render an image. A comparable image in PNG renders instantly

[illiac786]

They might have been all in on HEIC, yes, but they definitely are not any more if they are introducing JPEG XL.

I rather think they are doing a cautious test run, and decided that API was for a later phase. (decision which I do not agree with btw)

[troupo]

Oh great. Another image format no one really supports, that requires hardware decoders, and will probably take 2 seconds to decode on a modern supercomputer

[illiac786]

I’m a big fan of XKDC #927 [0] but if we followed your position, we would never introduce any new standard, ever.

https://xkcd.com/927/

[troupo]

I'm bot a big fan of codecs that seem to only benefit a few megacorps

[illiac786]

please provide some details on why you think JPEG XL only benefit megacorps – if you say it like this, it just sounds like trolling.

couple of counter arguments on my side:

* JPEG XL heavily reduces storage requirements both for lossless and lossy compression * JPEG XL allows to reversibly compress old JPEG to further reduce storage requirements * JPEG XL is patent unencumbered * JPEG XL support very high definition pictures (jpeg does not), native HDR support, higher number of bit per pixel, etc. etc. * Google wants JPEG with gain map to support some form of HDR, as well as now introducing XYB color coding, etc. etc. They clearly are against JPEG XL