Hacker News Reader

Comment by masklinn | Hacker News Reader

> in hopes that Google will change their mind once the rest of the industry has switched to JXL.

What rest of the industry? Apple is clearly not interested, neither is Microsoft[0], and xl weirdoes have been busting mozilla's balls for years with little progress.

Even if you manage to bully Mozilla into shipping and default-enabling xl rather than just removing it, Firefox is currently sitting at an incredible 2.5% market share (and I'm saying that as a Firefox user).

[0] well they obtained a patent on rANS so they might be interested in other people using it I guess, that's money in the bank: https://www.theregister.com/2022/02/17/microsoft_ans_patent/

View on HN

> Apple is clearly not interested

They have made no such statement AFAIK. The fact that they adopted AVIF relatively swiftly, and generally improved their cadence a bit, makes me ready to not be surprised if they ship JPEG XL in a year or two.

Apple dragged their feet on introducing webms to Safari and they still often require fiddling with to get working on iOS. If Apple isn’t jumping at supporting a format, it’s generally safe to assume they’ll do all they can to not support it unless the pressure is overwhelming.

Which doesn’t seem to be the case with this format.

> The fact that they adopted AVIF relatively swiftly

Can be linked to Apple being a governing member of AOM.

> and generally improved their cadence a bit, makes me ready to not be surprised if they ship JPEG XL in a year or two.

Feel free to hold your breath, but I don't think that'll be good for your health.

The webkit bug for AVIF was opened in February 2020, an "initial support" patch was proposed in May, support was merged in March 2021. Apple separately shipped the decoder[0] in iOS and macOS in September/Octoboer 2022, and enabled the feature for Safari.

The webkit bug for JXL was opened in February 2020. That's about all that's happened to it. Reaction has been:

- Webkit is not super interested in adding a bunch of third-party unsafe code[1]

- Safari support requires OS support, which is non-existent for JXL[2]

[0] Webkit on non-apple platforms can use Webkit's decoders, on Apple platforms it uses CoreGraphics, though as seen with HEIF having CG support doesn't mean Apple enables the format in Safari.

[1] https://lists.webkit.org/pipermail/webkit-dev/2021-May/03184...

[2] https://lists.webkit.org/pipermail/webkit-dev/2021-May/03185...

They’re working on ending the OS-parity nonsense with AVIF. https://webkit.org/blog/13584/release-notes-for-safari-techn...

To be clear I didn’t say I’m holding my breath. Just that it’s not “obviously” impossible.

They’re not working on anything, this just means the WebKit previews or the odd product which embeds WebKit rather than use webviews can run regardless of OS support.

Apple ain’t going to enable features they don’t support on safari.

That’s Safari’s preview.

No, it is not. It's webkit. Safari is based on webkit, but the webkit project at large does not decide what does and does not go in Safari.

That's why there are regular "Webkit features in Safari X": that something is added to webkit does not guarantee it'll land in Safari, ever.

Hell, it took 18 months and 2 iOS/macOS releases for the AVIF support to go from landing in Webkit to landing in Safari. And that was something Apple wanted.

> Just that it’s not “obviously” impossible.

Neither was webm support, but that didn't stop them from taking several years to implement it (and even then it was half-finished). Apple clearly wants to play the superiority game with their own codecs. They have zero incentive to support any codecs they didn't build, and have been known to abandon standards that they help develop.

Nothing is technically impossible for Apple, but codec support is stuck between an ideological/financial rock and a hard place.

> Apple clearly wants to play the superiority game with their own codecs. They have zero incentive to support any codecs they didn't build, and have been known to abandon standards that they help develop.

And on the other end you have Google who threatens others if they don't bend over and implement Google's codecs in hardware [1]. The codecs space is, and has always been, a game of shitty players.

[1] e.g. https://www.protocol.com/bulletins/av1-android-14-requiremen... and https://www.protocol.com/youtube-tv-roku-issues

AV1 is a more open codec than MOV or AAC, so it's not really any shittier of a play than Apple demanding third-parties use AAC for every iPhone accessory.

Apple is a company that cares deeply about usability. Once JPEG XL reaches critical mass in photography or creative work (video mastering, image processing, graphics and similar), Apple will very likely be the first to add support. Their users much rather have a thumbnail than a stock icon for photographs and graphics. I wouldn't be surprised if JPEG XL support would be announced by mid 2023.

That patent is completely irrelevant to JXL. JXL doesn't do anything described in the patent.

And in any case, I think the person you responded to is referring to non-web actors like Abode, who seem to like JXL.

> That patent is completely irrelevant to JXL. JXL doesn't do anything described in the patent.

In the article I linked, the creator of ANS asserts that Microsoft's patent covers the variant used in JXL.

A Cloudinary lead says it doesn't but they're not a lawyer, and it's not exactly in their interest to say it does.

> And in any case, I think the person you responded to is referring to non-web actors like Abode, who seem to like JXL.

That is completely irrelevant to Chrome, why would Google change their mind on that basis?

> In the article I linked, the creator of ANS asserts that Microsoft's patent covers the variant used in JXL.

Microsoft is a member of ISO. They're obligated to notify ISO if they have any relevant patents to new standards. The subcommittee that JPEG is part of is even chaired by a Microsoft employee, so it's not like they'd be unaware.

Duda seems to think that Microsoft's patent simply covers rANS in general, but this seems dubious. Not only would it cover a lot more than JXL, it would have shitloads of prior art. The patent seems to describe an improvement of rANS, which isn't used in JXL.

Further still, Microsoft has straight up said that the patent is free to use for any open codec.

> That is completely irrelevant to Chrome, why would Google change their mind on that basis?

WebP adoption was slowed, and is to some extent widely hated, because it for many years had zero support outside the web. Not only is JXL seeing faster than adoption outside the web than WebP, it's seeing faster adoption than AVIF. That seems relevant to me. And of course, web companies literally can't adopt it until at least one browser starts supporting it. Shopify already serves JXL when you enable the flag. Facebook wants to use it. Yet Chrome's devs claim that there is basically no ecosystem interest. It's pretty ridiculous.

There was some discussion about this rANS patent among data compression experts, but it looked like they don't know what improvement it is supposed to bring:

https://encode.su/threads/3863-RANS-Microsoft-wins-data-enco...

> In the article I linked, the creator of ANS asserts that Microsoft's patent covers the variant used in JXL.

This doesn't necessarily mean JPEG XL is patent-encumbered (the patent is still annoying, but not necessarily this way). It is recommended for ISO standards that relevant patents should be disclosed and available on a non-discriminatory basis [1], and while patent holders can ignore this recommendation they generally have no reason to do so. In the case of JPEG XL only Google [2] and Cloudinary [3] filed patent declarations, so Microsoft is reasonably thought to have no patents relevant to JPEG XL.

[1] https://www.iso.org/iso-standards-and-patents.html

[2] https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770...

[3] https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770...

Besides the fact that only some image viewing programs and image editors support JXL... it is worth remembering that AVIF is just the image format used within the AV1 video codec. So, when AV1 becomes more popular and starts really showing up in silicon (which Google is putting huge pressure on silicon vendors for), almost everyone will have a hardware AVIF decoder for free, should they choose to use it. If that happens, any decoding speed advantages that JXL has could be blown apart very quickly. This makes AVIF, in my view, a much stronger long-term play, as how many people are going to implement hardware JXL decoders? AVIF will be much faster, perhaps slightly less efficient, and plenty good enough.

> So, when AV1 becomes more popular and starts really showing up in silicon (which Google is putting huge pressure on silicon vendors for), almost everyone will have a hardware AVIF decoder for free, should they choose to use it. If that happens, any decoding speed advantages that JXL has could be blown apart very quickly.

No one has any plans to decode AVIF still images in hardware. There are two problems. The subset of AV1 supported by hardware is much narrower than what is in practice used in AVIF images. Such images cannot be decoded by hardware. Second is that it actually doesn't get you any speed. Each image would need to be shuffled to the GPU, decoded, then sent back because browsers aren't really set up right for doing everything on the GPU. And any non-stateless HW decoder would be problematic, since every single image would need to reconfigure the decoder state, which is slow.

> Each image would need to be shuffled to the GPU, decoded, then sent back because browsers aren't really set up right for doing everything on the GPU.

This isn’t a problem on any mobile SoC because “sent to the GPU” doesn’t mean anything on a unified memory system. (And Safari does use hardware image decoding.)

>The subset of AV1 supported by hardware is much narrower than what is in practice used in AVIF images

The majority of AVIF images are hardware decodeable, even if most viewers don't bother with it. The biggest limitation is that profile 0 decoders are 4:2:0 only, but that describes the majority of Web images.

> Besides the fact that only some image viewing programs and image editors support JXL.

Krita, GIMP, DarkTable, Affinity, and freaking Adobe are just "some" image viewing programs to you?

+ ImageMagick, imlib2, Firefox with a flag…

The ones most people actually use do not support JXL. Namely, for better or worse, Windows Photo Viewer and MacOS Preview. Nor does any web browser (except experiment flags that nobody knows about).

Adobe supports it... for importing, but you can't export to JXL. You can count plenty of obscure photo formats like JPEG 2000, IFF, PCX, OpenEXR, etc. in that category.

OpenEXR isn’t obscure for folks who work in animation / VFX :) but yeah I agree that JXL doesn’t seem to be getting wide support any time soon.

It works fine in feh (image preview) and all of the open source tools I use for photography mentioned before. I have the browser flags enabled.

I guess I’m not an actual user.

Wikimedia has 10% on Non-Input-crippled (or handicapped) devices for Firefox.

>>Firefox is currently sitting at an incredible 2.5% market share

Starting to think Firefox users can be put on the "non team players list" and "people that have something to hide list".

Why? I don’t understand the angle.

Reply on news.ycombinator.com