"We don't like to implement JPEG XL because this takes code, although barely so since we import a library. Also, we saw little usage in our own browser in which it is actually disabled by default."
The case for JPEG XL
161–170 of 210 posts
Re: The case for JPEG XL
#162The scoop: a JPEG XL developer explains how JPEG XL is uniquely better than AVIF, webP, and PNG, and laments the Chrome team's decision to drop the experimental support for it. AFAICT, JPEG XL does not seem to have the licensing complications of JPEG2000.
I might be wrong, but doesn't AVIF benefit enormously because all the new phones, CPUs, GPUs, etc. support AV1 codec out of the box?
it was often argued, but HW codecs are not used in practice -- they have other compromises (quality, size limitations, setup times, single central resource when there are often 100 images on a web page) that make them difficult to be used for images
simd based software coding if more than fast enough, at least for JPEG and JPEG XL
Re: The case for JPEG XL
#163Earlier quoted context omitted.
Personally, even if Chrome goes ahead with removing support I hope JPEG XL will "win" in the long run by being an attractive "universal" format for all other use-cases for image compression. So in other words: that it finds an ecosystem elsewhere, slowly takes over outside of the browsers, and then the browsers will adopt it after all. For example, I remember reading somewhere that there are people looking at whether…
What if Google demand every Android devices to support AVIF and not JPEG XL? This isn't a fight about whether something is technically superior, it is about marketing, cult and ideology. It wont be long before major force of AOM supporters arrives with new PR points to fight back.
> What if Google demand every Android devices to support AVIF and not JPEG XL?
Has there ever been a case when a company has demanded a device not support a codec that wasn't a patent dispute? And what does it mean for a device not to support an image format? Almost all image decoding is done in software.
This seems like an unfounded concern.
Re: The case for JPEG XL
#164Earlier quoted context omitted.
Personally, even if Chrome goes ahead with removing support I hope JPEG XL will "win" in the long run by being an attractive "universal" format for all other use-cases for image compression. So in other words: that it finds an ecosystem elsewhere, slowly takes over outside of the browsers, and then the browsers will adopt it after all. For example, I remember reading somewhere that there are people looking at whether…
> Personally, even if Chrome goes ahead with removing support I hope JPEG XL will "win" in the long run by being an attractive "universal" format for all other use-cases for image compression. So in other words: that it finds an ecosystem elsewhere, slowly takes over outside of the browsers, and then the browsers will adopt it after all. Ah, like how Chrome delayed APNG so much that there was a dedicated extension fo…
>> Personally, even if Chrome goes ahead with removing support I hope JPEG XL will "win" in the long run by being an attractive "universal" format for all other use-cases for image compression. So in other words: that it finds an ecosystem elsewhere, slowly takes over outside of the browsers, and then the browsers will adopt it after all.
> Ah, like how Chrome delayed APNG so much that there was a dedicated extension for it?
No? APNG never caught on like described in the GP.
Re: The case for JPEG XL
#165Earlier quoted context omitted.
Disclaimer: I co-chaired the JPEG XL working group; opinions are my own. The JPEG XL format is most certainly not a nightmare internally. Compare the spec lengths: 681 pages for https://aomediacodec.github.io/av1-spec/av1-spec.pdf , 101 for https://www.iso.org/standard/77977.html . Or code sizes: 6.6 MB uncompressed for libjxl (encoder+decoder), 9.5 MB for dav1d (decoder only) plus 34.2 MB for SVT-AV1 (encoder). Feat…
> Compare the spec lengths: 681 pages for https://aomediacodec.github.io/av1-spec/av1-spec.pdf , 101 for https://www.iso.org/standard/77977.html . And here we immediately see one important difference between them: the first link is to a 681-page PDF, which opens immediately in my browser. The second link is to a place where one can buy access to what it says is a 101-page PDF, after paying more money than it would co…
That's a difference between AOM and ISO: ISO puts specs behind a paywall but anyone interested can participate in the actual standardization process through their national standardization body, AOM makes specs publicly available but participating in the standardization process costs about as much as a nice car. I don't really like either model, but I don't think I particularly prefer AOM's model.
Re: The case for JPEG XL
#166Earlier quoted context omitted.
Recent drafts do tend to get circulated amongst the image compression community. For wide audiences I don't think this type of document is very readable nor relevant; the number of people who are going to make their own independent implementation is relatively small. In this sense the spec audience is not quite the same as that of a spec for a programming language, which is important not just for compiler implementer…
Any chance of publishing the spec with ECMA in addition to ISO? The C# spec is both an ECMA and an ISO standard, but it started with ECMA.
As one of the authors of the spec, I would be open to also publishing it with another standardization organization that makes specs publicly available, if the legal issues can somehow be sorted out. I think the other spec authors would also be open to that. We certainly have no desire to have a spec that is behind a paywall; that is just the way ISO operates, unfortunately.
Re: The case for JPEG XL
#167Earlier quoted context omitted.
What if Google demand every Android devices to support AVIF and not JPEG XL? This isn't a fight about whether something is technically superior, it is about marketing, cult and ideology. It wont be long before major force of AOM supporters arrives with new PR points to fight back.
> What if Google demand every Android devices to support AVIF and not JPEG XL? Has there ever been a case when a company has demanded a device not support a codec that wasn't a patent dispute? And what does it mean for a device not to support an image format? Almost all image decoding is done in software. This seems like an unfounded concern.
I wouldn't be surprised if a WASM-based polyfill emerges soon enough
Re: The case for JPEG XL
#168I think the solely reason why JPEG XL did not go off is simple: It had no lobby. No large tech company actively promotes it and so, many people hadn't heard of it. Ironically, the deprecation of it in chrome made me aware of it in the first place. Technically, JPEG XL may be a superior contestant. But from a 'social' point of view? Disastrous, especially considering it already has "JPEG" in it. (To be fair, its also…
Personally, the name always turned me off. I saw the option in photoshop when saving files, but my thinking went "jpg bad, jpg XL is a weird name, must be a minor incremental improvement over jpg".
Why would you think "XL" would be minor improvement?
Re: The case for JPEG XL
#169Earlier quoted context omitted.
Also libwebp reached 1.0 only about 8 years after it was added to Chrome. So I don't think this is a major criterion. That said, we are aiming to reach the libjxl 1.0 milestone within a reasonable timeframe, i.e. somewhere in 2023, preferably first half.
And Mozilla waited for libwebp to reach 1.0 before making the plunge to support it in Firefox. One of the main issues was that libwebp was willing and frequently made backwards-incompatible changes to the codec in the 0.x days; Google simply didn't care about breaking images, but Mozilla cared.
Yes, that's a problem when a format is not standardized but controlled by a single entity. JPEG XL is standardized though, and backwards-incompatible changes are essentially impossible.
Re: The case for JPEG XL
#170If I was king of the web, AVIF wouldn't have been added and JPEG XL would.
Having said that, AVIF did get added and I don't think having some kind of process for adding new image formats beyond "it exists and is better" is a bad thing.
Ideally all the big players would come together and settle on one.
This kind of happened for AV1 video, so it's a shame that as a side effect of that AVIF got added before JPEG XL and split the potential momentum for a next generation image codec in two.
That feels like a mistake that it's not too late to revert though.