FSF Slams Google over Dropping JPEG-XL in Chrome
phoronix.com
phoronix.com
Unless I'm misunderstanding that, no browser actually ever supported JPEG-XL without a flag (or at all on Safari's cases). No OS appears to have supported it natively either[0]. The reality is that formats have a chicken & egg problem. Normally Google deserves to get dunked on, but in this case, why is Google the scapegoat instead of the entire industry that didn't adopt it? Feels like there is a bigger issue with JPEG-XL's failure to launch, and they did more than some (Apple? Microsoft?).
[0] https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_a...
Nope, not just FSF. The Chromium team have prototyped JXL, but removed it initially for unknown reasons (https://bugs.chromium.org/p/chromium/issues/detail?id=117805...). Engineering teams including but not limited to Adobe, Facebook, Intel and Shopify have complained about its abrupt removal. Chromium developers have subsequently said that it was "due to low interest" (despite piles of messages from engineering teams both in leading companies and small groups saying otherwise).
> I cannot see how fair competition could require Google to be the first one to support a standard that literally nobody else supports.
First, Adobe products have just included JXL. Second, It's because Google is pushing for AVIF, which was extended from AV1. While it has some advantages (as essentially extended version from AV1), it also has a lot of disadvantages: https://news.ycombinator.com/item?id=35590516. No one said to remove AVIF in favor of JXL and in fact there are instances where AVIF is the better choice (animated images due to its interframe support) but instead to support JXL regardless of Google's support of AVIF, and some people have seen it as forcing Google-favored AVIF instead of considering all formats developed (like how WebP was rammed a decade ago).
Just an FYI, they gave their reasons in comment #84 of the thread you linked.
Or they could pick a better format and evaluate it? The question is why the better format here, even though it is the same royalty free ( or patents free in AOM's term ), wasn't picked.
They’re a private company. They can choose to do whatever they want or don’t want to.
If they don’t want to support JPEGXL, why should they be forced to do it? If it was such a necessary format, it would have been a competitive disadvantage to not have support and that would have forced their hand, but nobody else supports it either so why should Google be forced to if they (clearly) don’t want to.
E.g. Android TV now requires hardware support for AV1 [1] and Google threatened Roku that Rouku would lose Youtube support if it didn't support AV1 in hardware [2]
[1] https://www.protocol.com/bulletins/av1-android-14-requiremen...
Found this: https://stackoverflow.com/questions/75459594/why-doesnt-edge...
Not sure what you mean by OS. The link you provided shows that Linux with several GNOME and other tools support JPEG-XL (especially GIMP).
Is this a good argument? Nobody is going to adopt something without being natively supported by browsers without ugly js hacks, and when it comes to browser standards it seems to me Google has more leverage than anybody else. Cloudinary has made a lot of posts about JPEG-XL, so you might say they're quite biased towards it, but it also seems to me there is some interest in it by multiple companies [0, 1]. I personally very much doubt webp would be anywhere today without the massive (arguably deceptive) campaigning and double standards it had.
0. https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_a...
1. https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
That's fair, but it is worth pointing out that <picture> tags support multiple source formats. I serve some logos and other important images as both .png and .webp. Adding additional lines for avif for jxl seem reasonable - especially if browsers are testing new formats.
Apple did not support JPEG XL, based on past history was unlikely to do so, and despite what you say about Google having the most leverage they have none on Apple. If Apple doesn't want something supported, no iOS browser will support it. And if no iOS browser supports a format, it is not going to be useful in production.
I do find it hilarious that all the people who complained about Chrome supporting webp then went on to complain about Chrome not supporting JPEG XL. They're both Google-created formats not widely supported by the ecosystem!
What's the "conflict of interest" you're talking about? AVIF? How is that their own format when JPEG XL isn't?
If Apple, Mozilla and Microsoft wanted JPEG XL and committed to supporting it, I bet Chrome could be convinced to restore the support. But AFAIK those companies have made no such commitment, or even any kind of indication of intent. Why should we have another image format that gets only implemented in Chrome, not the wider web ecosystem? (Of course, they too are members of the foundation building AVIF. Oh my God, so many conflicts of interest!)
Google Research. Which is similar to Microsoft Research.
https://github.com/mozilla/standards-positions/issues/522#is...
graphics heavy sites often optimize for various platforms instead of serving to just one standard.
They are different formats with different attributes, so it's reasonable to distinguish between them. JPEG XL is a general purpose image format. It's reasonable to want browsers to display it. WebP and AVIF are special-purpose formats, designed to leverage their corresponding video decoders, for delivery of ephemeral images to end-user devices. It's reasonable to object to limited formats that are manifestly crowding out general ones.
How is it Google created?
That's not to say they're the only contributors or should have all the credit. But it does make the "Google is trying to kill an open standard to push their own format" narrative here completely moronic.
The same company that gave us WebP. At least Mozilla and Safari did the sane thing and push back against it.
JPEG XL is a general purpose image format, like JPEG and PNG, but improved. WebP is not a serious modern image format; it doesn't even support 16-bit channels. WebP has one specific purpose: web delivery of ephemeral images, leveraging VP8 hardware decoding driven by consumer consumption devices. That's what Google, and web-oriented companies in general, care about. They have no particular interest in general purpose image formats.
It is not the case for video. Video is still a huge bandwidth hog, and finding better codecs is worth it, that's why they get better support. Webp is a clever hack as it is essentially a single frame webm video, so if you have webm support, which is worth it, then you can have webp almost for free, JPEG-XL doesn't have that incentive.
JPEG = I want to see the content in the image but don't care too much about the quality
PNG = I want a lossless version of this image
Since bandwidth is cheap in most places, the only advantage that JPEG XL has is suddenly not that enticing.
I was trying to set the desktop background image on a project laptop last week. I found an image I liked, that would immediately remind me what machine this was when I look at it.
It was an AVIF. Windows 10 won't accept those as desktop backgrounds. It looked, for all intents and purposes, like the search image results were going to give me JPEGs -- the URL ended in .JPG and had "jpeg" as the media type! -- but that is not what I got. This did not work. Refusing to give up, I eventually determined that using curl to retrieve the image gave me a usable JPEG, and so I got my background and now I can tell this stupid project laptop apart.
For my use cases, which is as someone who does light work with images (backgrounds, occasional use in some kind of paint program, occasional insertion into documents or slides), anything that isn't a JPEG or PNG is actively harmful. Not everyone uses images the way I do, but developers need to remember that not everyone is a passive sheep who just stares at things or a power-developer who builds JPEG-XL from source in their sleep. There are people in between, and we don't take kindly to being forgotten.
Face it, these "modern" image formats are a massive annoyance for everyone except Web engineers.
I can't really imagine a world where you don't have to choose what format files should be in, and I can't really imagine a more easy way to do that conversion.
Making an image your wallpaper isn't something people do every day, going through an extra step is hardly onerous. And support will increase until it no longer matters.
1) Chrome is much bigger, so it's much more consequential, so it's valid is a bigger target for criticism
2) It's much easier to performantly support the format on some OS without it being "native", so again, lack of browser support is worse, and thus it's valid it's a bigger target for criticism
This is kinda how standards are supposed to work: at least two independednt implementations [1], released behind a flag to gather developer and user feedback. However it seems that in the end it went nowhere.
[1] See Implementation experience: https://www.w3.org/2021/Process-20211102/#implementation-exp... Among other considerations: "are there independent interoperable implementations of the current specification?"
How are you supposed to get feedback for a feature people can't actually use?
It's like when Debian removed a package I use that was not shipped under the rationale that "no one uses it". Obviously no one uses it - you never actually shipped it, you just had the source available if people wanted to compile it.
The moment it's out there (that is, not behind a flag), you cannot fix it, update it etc. because people will be relying on the observed behaviour.
The hard part is advertising the feature (at the very least to developers) because there are just too many featurs in modern browsers. Edit: for example, Chrome has Origin Trials https://developer.chrome.com/origintrials/#/trials/active for experimental features.
But you do it quickly, within a short time of launching it. Anyone who was able to make use of it within a couple months, will be able to adapt and fix things.
Once it's been there for a year, then sure, people rely on it. But there's no reason to take so long.
No, you can't. Not simply.
> But you do it quickly, within a short time of launching it. Anyone who was able to make use of it within a couple months, will be able to adapt and fix things.
That's not how the web works. "People who make use of it in a few months" could easily apps and sites serving millions of people. This is a process that applies not only to image codecs, but to, say hardware APIs and interfaces, network protocols etc.
> But there's no reason to take so long.
There are very many reasons from technical to political to anything in between (and sideways, too).
Or, if it's not behind a flag, then you can tell people not to use it, but they will anyway, which is exactly what you want, because then you get feedback. And when you change it, nothing really bad happens.
Sounds like the flag method is a failure, and just releasing it actually works.
In JPEG XL case it failed not because it was behind a flag, and the failure of one feature doesn't mean that the entire system isn't working.
> Sounds like the flag method is a failure, and just releasing it actually works.
No, "just releasing" doesn't work for the reasons I outlined above.
If a browser doesn't support a format as default nobody will use it unless big players like Apple or Google enforce it.
If Jpeg XL had been enabled some time without a flag they could claim > There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
but hidden behind a flag there is no way to know.
How many users enable experimental features in their browser?
Chrome added support for the in-progress version of JPEG XL in April 2021. The core coding specification was finished in March 2022, and the last part of the spec wasn't done until October 2022.
Chrome removed it in December 2022, citing a "lack of interest from the ecosystem", despite it having support in most major image editors already. It was a new format which was rapidly being adopted and a lot of major players were very excited about it, but Chrome's removal pretty much killed it due to their dominance in the browser space. At the time of removal, it had better support than HEIC!
I don't think I've ever encountered a single JPEG-XL image. Meanwhile I've encountered plenty of HEIC and never encountered a problem in dealing with them.
What annoys me more is that despite basically the entire modern tech industry being in support of- and pushing av1, 99% of the most-modern-compression content I encounter is encoded with h265. There's a good reason for it (h265's initial release was about 5 years earlier) but it still annoys me.
I was hoping at least av2 (or whatever it will be called) would be able to get ahead of h266, but I don't see that happening anymore either. Which means were gonna be stuck in the patents quagmire for a long while.
Even worse is that parties outside of AOmedia have created an av1 patent pool, despite the explicit reason for av1 being concocted is to not be patent encumbered. Most nastily, they don't go after AOmedia itself but instead sue small(er) parties using av1 to bully them into paying a license. One would expect AOmedia to bring to bear the full brunt of their collective legal departments to scare off the av1 patent leeches, but, so far, not a peep.
I find it frustrating how computers have gained so much compute and storage capacity but the web seems to be slipping away as ever more consumer-focused and neutered. Having been there since the beginning, I really expected the web tech and browsers to improve and facilitate scientific data sharing. Not being able to natively decode and display any "exotic" imagery without a bunch of server-side nonsense is frustrating.
Today's client machines have so much capability but become totally balkanized when you can't just serve an image tag and display a real scientific image. Instead you either have to hope the users install extra "workstation" tools to display an image after downloading, or deploy absurdly over-engineered "image servers" to do the basic image rendering and ship plain 8-bit JPEGs to the client.
Why can't a browser natively provide some basic range-mapping color transfer function tools for high bit-depth images in an image tag? Why can't it provide a pan-zoom viewing mode for high resolution images in an image tag?
Because on the web Google is 'the industry'. It's not a problem that it was behind a flag, it's a new format after all.
The problem is Google did implement it and then removed support without sufficient explanation. Given their market power and the fact they're behind competing standard, it raises a few questions.
While there may be genuinely good arguments for keeping JPEG-XL, I cannot take seriously the arguments of an organisation that cuts itself off from the rest of the world for such silly reasons.
Edit: Google's argument that there wasn't enough interest is equally impossible to take seriously when it was always behind an optional flag. No web devs are going to invest time in developing JPEG-XL functionality until their users can actually use it.
I would love people to stop linking, and posting links, to e.g. Facebook because the only thing it would show me is "you have to register to view this".
I both understand the FSF not wanting to link to something that's not readable without running non-free code, and the wish to have the link anyway, at least for reference.
https://www.gnu.org/software/librejs/free-your-javascript
Just like any other software.
The FSF - and Stallman! - publish PDF documents. At https://stallman.org/cgi-bin/showpage.cgi?path=/archives/202... you can see Stallman uses xournal to fill in a PDF form.
This will break JS on some sites but not all of them, but that is apparently not sufficient for Stallman & co.
So yes, of course Stallman would have objections to some Postscript files.
"I do not submit my tax returns on line because it requires nonfree software. I use xournal to write my data on the PDF form, and print that. As I have no printer, I will visit a copying store to do the printing."
Note that the copying store will be using a printer with nonfree software.
Thus, your (a) is correct, your (b) appears to be incorrect as Stallman was doing this 3 years ago, and your (c) is incorrect as Stallman doesn't have that objection.
We futher know (c) is incorrect because Stallman at https://stallman.org/rms-lifestyle.html write that he will use someone else's cell phone, even though it it not free.
Regarding (b), I can't tell if the 1040 at https://www.irs.gov/pub/irs-pdf/f1040.pdf uses XFA forms ("deprecated in PDF 2.0", in 2017), but it appears to work in Firefox, which I believe is using free software. Even if it does, you can order the forms at https://www.irs.gov/forms-pubs/forms-and-publications-by-us-... or visit a post office or library (see https://www.irs.com/en/articles/local-irs-tax-forms ).
These do not require using software, so I don't see why you conclude that Stallman would have a free software objection to filing taxes at all.
I did see that note about how Stallman does his taxes. But if Stallman has a sectarian objection to basic things like using a cell phone, or to even more basic non-tech things like personal hygiene, an objection to taxes wouldn’t seem far-fetched to me.
I have just learned the Firefox 93 added support XFA - https://techdows.com/2021/10/open-xfa-pdfs-in-firefox.html .
So it would appear there are free software solutions to XFA forms.
Just because something doesn't seem far-fetched to you, doesn't mean most people will regard it as far-fetched.
Many people all sorts of "sectarian objections" - far more than there are SovCits or other tax protesters. Stallman has never come across as a tax protester. Ergo, I think it's far-fetched that "sectarian objections" is strongly associated with tax protests.
Further, at https://stallman.org/archives/2017-may-aug.html we can read Stallman opinine that we need to "return to the "bad old days", when Americans in general could have a decent life, not penury; when the US could afford to build what the public needed instead of privatizing everything with a toll" by making taxation more progressive. At https://stallman.org/archives/2011-jan-apr.html we read he supports "The Fairness in Taxation Act [which] would raise taxes to 45% on incomes over a million dollars a year."
User agents need not be browsers. What if we had a scraper for every site? What if we had reverse engineered free software clients for every website's API endpoints? We'd be in full control.
People maintain humongous repositories of ad blocker filters and executable countermeasures against "clever" websites. Perhaps it would be feasible to maintain a collection of scrapers and custom clients too.
They want to raise a point X, which could in theory be communicated in a persuasive way.
But they can't resist also mentioning their zero-tolerance on unrelated point Y.
I think the Y makes people tend to go WTF, and then dismiss both X and Y.
Every time now, I'm thinking "You don't have to always mention Y!"
On at least a couple occasions, I actually abandoned an argument I was making on some X in a venue, because some FSF person jumped in with a Y. If I didn't know they were a true-believer in Y and at least sympathetic to X, I'd think they were trying to discredit both.
The FSF has some great principles, but a lot of the communications don't seem to be calibrated for me, nor for my understanding of anyone else.
At the end of the day RMS is still right though. Those little injustices add up, the corporations creep up on you slowly and next thing you know you're being surveilled by the javascript you used to see as harmless, and soon you learn how to tolerate that too. Dude saw ridiculously far into the future even decades ago but it doesn't matter because stuff like RYF certification is irrelevant and will only ever apply to machines that must 20 years old by now because manufacturers don't care and everyone is on mobile now anyway.
The party one should be angry about here is the browser, which provides little to no tools to show the user what is going on and provides no real means to stop it. This is quite a bit different from the early web days when every browser had a "Javascript off" and style sheet selector right in the main menu by default.
> Dude saw ridiculously far into the future even decades ago
Not far enough. Ever since the whole world moved to "software as a service" and your computer has become little more than a thin terminal to some Google/Facebook/whatever-service FSF started to feel quite out of touch. Sure, they tell you "don't do that", but while that isn't wrong, it's not exactly helpful either. Many service simply have to run on a computer that you don't own and we need rules to govern that. None of the Free Software licenses help here.
FSF never bothered to create any kind of licenses or best practices that deal with how those services should work. They are stuck in dealing with software freedom problems of the 90s, not the problems we face today. Luckily we do have the GDPR now, but the FSF had nothing to do with that and never provided anything similar.
Exactly. The licence is not the only problem with javascript on the web because you can't use your freedoms in practice anyway since the code is automatically downloaded and executed when you load the page in a common web browser.
What we need is something that allows people to choose what code to run, similarly to how software traditionally is downloaded and executed in two separate steps. We need to get away from the assumption that people will run all code you throw at them when they visit your site. Then maybe licences on javascript can start to make more sense.
Yes, you could. You can adapt the code and use an extension to use your "fork" instead of the provided one. A convenient extension to do this might not exist yet, but you could block the website's provided JavaScript with uBlock Origin / uMatrix and use your fork with ViolentMonkey or another *Monkey extension. And distribute your fork on some user scripts repository (for instance).
Free software is not (only) about avoiding spying. It's about running the code you want to run for any endeavor you can have, and be able to study and distribute your modifications.
I totally agree with your last paragraph and I agree something should be done to deal with how (web) software is distributed and run.
Ok, that's possible to do but it's not a solution to the problem because:
- You would not have much use of it because javascript is often very dependent on the web page and the server so if any of those changes, your script breaks. There is no expectation that people do this so the website owners have no reason to keep a stable API.
- Only the people who use that extension or browser benefit from having that freedom. Compare this to traditional software where forks can easily be created and maintained and get more popular than the original fork. Now people who don't even know about the forks will benefit from it because they will likely use the fork that gets popular which can be the better one. An example of this is software distributions (like Debian and so on) that may modify upstream software in a way that benefits all users, even the ones who are not aware. That would be extremely difficult to do with all websites on the web without things constantly breaking.
https://www.gnu.org/philosophy/javascript-trap.html
However this page is a little out of date :)
Wait, what? The browser is the single best platform in existence for showing people what is going on behind the scenes - hit F12 and enjoy. Very few other software projects give users these kinds of tools, available at runtime.
But if you refuse to use software because of religious reasons, you may not be aware of this.
We wouldn't have needed EU cookie banner laws if browser didn't stop making cookie storage obvious. Lynx is about the only browser left that still makes cookie storage an explicit action. A Stop button that actually stops a webpage from executing Javascript in the background would be welcome as well.
Browser have long given up trying to be document viewers that serve the user and just turned into advertisement displays.
Browser have long given up trying to be document viewers...
I know, and isn't it wonderful? Its very cool to have a truly cross-platform, graphical, debuggable environment! Plus the two best ones are open source (Firefox and Chromium).
They're happy to tell you what not to do, what software not to use (and what software they won't use) but that's it.
Their communications are calibrated for true believers only. They rely heavily on the reader/audience 1) agreeing with a fairly extreme position relative to the mainstream, and 2) the idea that the FSF/GNU has a position of authority/trust with the audience.
What's annoying is that I agree with them on the idea that deprecating JPEG-XL is counter to user interests and that Google has too much power. But they could've led with IceCat and made a more pragmatic case that might resonate with a larger audience. Hilariously, though, "building binary packages for Windows and MacOS currently requires nonfree software, so we no longer distribute binary packages for those platforms."
So... if you're already happy to be an Orthodox Free Software True Believer then you have an alternative. If you aren't, well, too damn bad. If you're a budding free software fan but happen to have a macOS machine or Windows machine your parents supplied, too bad. If you'd like to make a work computer slightly more free, too bad. Etc.
[1] https://web.archive.org/web/20100703110224/http://www.linux-... [2] https://www.gnu.org/software/gnuzilla/
There's much more to this. I have tried for well over a decade to run Linux as my daily driver on my laptop and gave up in 2018 January and just run Windows + WSL, especially since WSL2 this is quite good. There's always something that doesn't work. (And yes, if all you connect your laptop to is a normal wifi then your experience might differ. My problems were with Bluetooth, enterprise wifi and multifunctional printers.) It's entirely possible some people would prefer not running Linux because the manufacturers refuse to pay much attention to it.
I have been on Linux since 1993. Still running it on servers and router. It's still not the year of Linux on the desktop.
The deployment references google-analytics, but everyone already blocks that, right?
Why would they risk unsuspecting visitors running Google code on their computer? It is a spyware company.
There is nothing silly about not wanting to link to Google. Maybe futile given their market domination. But not silly.
>"In turn, what users will be given is yet another facet of the web that Google itself controls: the AVIF format."
Huh? I'll admit I haven't been following codecs as super ultra closely as I used to, but I thought AOM was a pretty broad coalition of varying interests and AV1 an open, royalty free codec that was plenty open source friendly? I've heard plenty of reasonable arguments that JPEG XL has some real technical advantages over AVIF and as well as superior performance is much more feature rich and scalable. So I could see people being bummed for that. But this is the first time I've heard the assertion that it's somehow a Google project? I mean, AOM's libavif reference is BSD too [0]? I'd love some more details on that from anyone who has been following this more closely. I can even understand if AOM isn't as community friendly and an accusation that it's dominated by big corps, but in that case why single out Google alone? From wiki:
>The governing members of the Alliance for Open Media are Amazon, Apple, ARM, Cisco, Facebook, Google, Huawei, Intel, Microsoft, Mozilla, Netflix, Nvidia, Samsung Electronics and Tencent.
Like, Google is certainly significant, but that's a lot of equally heavy hitters. And interesting that Mozilla is there too.
----
Mozilla is a dependent of Google's. The thing that stands out about that list is that aside from Google and Facebook (who completely control their markets), the New Microsoft and the aforementioned Mozilla, most of these companies are notoriously openly hostile to anything open.
Good summary from https://www.phoronix.com/forums/forum/phoronix/latest-phoron... :
Max image size is limited to 4K (3840x2160) in AVIF, which is a deal breaker to me. You can tile images, but seams are visible at the edges, which makes this unusable. JPEG XL supports image sizes of up to 1,073,741,823x1,073,741,824. You won’t run out of image space anytime soon.
JXL offers lossless recompression of JPEG images. This is important for compatibility, as you can re-encode JPEG images into JXL for a 30% reduction in file size for free. AVIF has no such feature.
JXL has a maximum of 32 bits per channel. AVIF supports up to 10.
JXL is more resilient to generation loss.5
JXL supports progressive decoding, which is essential in web delivery, IMO. AVIF has no such feature.
AVIF is notoriously based on the AV1 video encoder. That makes it far superior for animated image sequences, outperforming JXL in this department by a wide margin. However, JXL also supports this feature.
AVIF is supported in most major browsers. This includes Chrome (and derivatives) and Firefox (and forks). JXL is supported by almost nobody right now. Only Thorium, Pale Moon, LibreWolf, Waterfox, Basilisk and Firefox Nightly incorporate it. Most of these are community-maintained forks of Firefox. That is a big downside for adoption, as I already ranted about in this post.
Both formats support transparency and wide gamut (HDR).What?! That is terrible for a next-generation image format, and should be an immediate and obvious dealbreaker for introducing any type of support.
It would be one thing if AVIF was a legacy format already in widespread, but anything new should be several orders of magnitude more future-proof.
> AVIF has different limitations when it comes to the highest megapixel count / largest dimensions. Several decoders may not support larger images, so single-coded photos do not exceed 4k resolution. According to AV1, AVIF Baseline profile coded image items must not have more pixels than 8912896 or wider widths or higher heights than 8192 or 4352. The Baseline profile can still be used to create larger images using grid derivation. You might encounter discontinuities along the grid boundaries, depending on how the image is decomposed. For this particular case, however, the maximum size of a coded picture is 65536x65536.
https://avif.io/blog/faq/avif-megapixel/
So as I understand this, anything with more than ~9 MP would be encoded in some kind of tiled way, possibly introducing artifacts where tiles meet.
However, another blog post claims different limits
> The default limit of AVIF is 8K. Video professionals will recognize this as the size of an 8K video frame. It is possible to break this limit for both formats by independently encoded tiles of 8K frames. But this method introduces artifacts at the tile boundaries, affecting the overall appearance of images.
AV1 itself allows a maximum of 65536x65536 for a single picture, whereas the HEIF grid hypothetically allows even more than that regardless of how large each individual picture is (HEIF grid dimensions are 32-bits). As a practical example, libavif will not use the grid for large dimensions unless explicitly told to do so, by default producing files that aren't compliant to either baseline or advanced profiles.
(to further my pedantry against your source: AVIF is a subset of HEIF; what people usually mean by "HEIF" is the HEIC subset)
The concept of profiles is nothing new to ensure HW decoder compatibility and JPEG-XL offers nothing extra there either (except no support for the concept ensuring that HW decode isn't possible at all).
Pretty much all newer formats are tiled in some way too - even JPEG.
Given I was trying to store high res panoramas of even larger dimensions, I was pretty surprised at the apparent limits, wherever they exist in the callstack.
>Max image size is limited to 4K (3840x2160) in AVIF, which is a deal breaker to me. You can tile images, but seams are visible at the edges, which makes this unusable. JPEG XL supports image sizes of up to 1,073,741,823x1,073,741,824. You won’t run out of image space anytime soon.
>JXL has a maximum of 32 bits per channel. AVIF supports up to 10.
Max resolution and bit depth is certainly massively higher for for JPEG XL, but spec [0] says that:
>"NOTE: [AV1] supports 3 bit depths: 8, 10 and 12 bits, and the maximum dimensions of a coded image is 65536x65536, when seq_level_idx is set to 31 (maximum parameters level)."
And 12-bits per channel is considered a lot for end user final display formats? It also seems to be supported in browsers too so it's not just theoretical. It looks like back in 2021 there was discussion around this and clarifying that the profiles decided on in 2018/2019 were more about giving targets for hardware acceleration of the time, but software decoders by 2021 supported essentially the whole spec (and it appears to me that another 2 years later now final lingering stuff has been dealt with) [1,2]:
>Cyril has proposed a pull request (#130) to better clarify what is and is not supported in AVIF. In short, AVIF supports everything that AV1 supports, which includes 12-bit encoding. The current software decoder implementations also support more or less all of AV1, which can be seen if you try to decode a 12-bit AVIF file in a web browser.
And for still images, hardware acceleration isn't important, so as a practical matter unlike AV1 video pure software for max features is fine. So 65k x 65k and 36-bit color appear to be the limit, which definitely isn't as much as JPEG XL, but is pretty respectable for majority of end user usage?
Edit to add: the comments there also mention complaints that the JPEG XL author has a history of spreading misinformation about AVIF, "See the article and infographic recently posted by the JPEG-XL author that claims (among other things) that AVIF does not support 12-bit images". So apparently there has been some good old dev drama going on during the last few years which means one may need to be a little suspicious about any "Good summaries" :(.
----
0: https://aomediacodec.github.io/av1-avif/#profiles-overview
WebP and AVIF introduced a bifurcation between general purpose image formats and ‘end user final display formats’ (i.e. internet delivery to consumer entertainment devices). I don't think this is a good thing.
As pointed out in another comment, this is less of 65536 by 65536 and more of 65536* by 65536* if you followed some more complicated steps. Considering that the original JPEG supports that without relying internally on multiple images (the trick AVIF used to "support" the full 65536 by 65536), it seems not suitable for software which writes images in one pass.
Check the site out:
https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth...
"Meanwhile, it has been clarified that the AVIF limits listed above apply to the highest currently defined AVIF profile (the “Advanced” profile). It is also possible to use AVIF without a profile, and then the AV1 limits apply: a precision of up to 12-bit, and maximum dimensions of up to 65535x65535 (or more using grids). For HEIC, it is possible to use the container with a HEVC payload with a precision of up to 16-bit and with 4:4:4, although most hardware implementations do not support that."
No AVIF implementation supports all what the clarification there claims. Sometimes it has happened that the implementations led to the practical standardization, instead of what is written in the spec.
No one has yet seen the tile grid artefacts. One could expect that there will be barely visible stripes extending from one side of the image to the other, and from bottom to top. This would be because of 'loop filtering' and 'noise synthesis' states not shared between frames.
No one really knows how the coding performance is for 12-bit photographs. AV1 needs to double escape large values which can reduce entropy coding performance of large values. Lossless coding commonly codifies larger values than lossy (due to less quantization). One might be able to observe this in the performance of the lossless coding.
No one knows how much progressive AVIF will compress. The implementation doesn't exist yet. The progressive approach chosen is new, very different from JPEG1/JPEG XL approach. It will be interesting to learn about its performance.
> Like, Google is certainly significant, but that's a lot of equally heavy hitters. And interesting that Mozilla is there too.
The Alliance for Open Media basically arose from the fact that MPEG decided to use the success of H.264 to charge a king's ransom in licensing fees for H.265, whereupon most of the consumer industry took one look at those fees and said "we need a free alternative."
MPEG-LA is the patent pool that everyone was using and it was assumed that would be the case for H.265. HEVC Advance and Velos Media realized they could break this business structure by giving a few net-implementer companies (e.g. Samsung) a sweetheart deal on patent licensing if they moved their patents over to their pool. They paid for this by double-charging people who were already licensed through MPEG-LA for those patents.
Leonardo Chiariglione, co-founder of MPEG, tried to get ISO to change their patent policy to allow more scrutiny of patent ownership in standards. ISO responded by... denying Leonardo's petitions, cutting MPEG up into pieces, and pushing him out of the working group he built.
Funny thing is, MPEG actually knows royalty-free video encoding is a thing people want. They've tried building an ISO standard for that. Problem is, ISO's patent policy only allows removing patented technology from a standard if the technology is not licensable - not if the technology is too expensive. So their standardized royalty-free codecs[0] are not actually royalty-free and nobody uses them.
The underlying problem was pointed out by Leonardo on his blog: patent owners want to go back to the days of charging an arm and a leg for MPEG-2, and they are willing to suck the brains out of MPEG in order to do it, under the assumption that people were paying royalty fees for the ISO branding rather than for the technical superiority of the standard. MPEG is not the cause of this problem, they are a victim of it.
[0] Fun fact: Google outright just submitted VP8 to MPEG as a candidate for MPEG IVC, but they decided against using it in favor of building their own royalty-free standard.
https://en.wikipedia.org/wiki/JPEG_XL
Also, Google contributed quite a bit to it's development. As the patent grants show:
https://github.com/ImageMagick/jpeg-xl/blob/main/PATENTS
https://github.com/libjxl/libjxl/blob/main/PATENTS
Microsoft seemed to have gotten a patent on part of it's implementation (which Google also tried to get). Not sure if Google will pay to invalidate that patent, but I have a feeling they are more likely to defend AVIF.
https://www.theregister.com/2022/02/17/microsoft_ans_patent/
Google's control is a little concerning, but I do feel there are bigger fish to fry then choosing between two free formats. A bigger concern is the H.264 and H.265 patents domination of video.
I don't know what the world could look like if a much-improved image format was common, but I don't think I'll see that future as long as the browser with 90% market share doesn't support that new format.
https://chromium-review.googlesource.com/c/chromium/src/+/40...
Maybe they're sour about webp not obseleting all other formats by now?
And apparently JPEG XL, which was only added in 2021, will be supported again from Chrome 117 onward.
That appears to have been an April 1st joke:
https://twitter.com/jonsneyers/status/1642039947719745537?t=...
That said though, that FSF guy is nuts. He can't link to their bug tracker because it uses Javascript? I think that battle is lost. But he did obviously read the tracker, does this mean he has to remove his tinfoil hat and go bathe in the living waters of Richard Stallman's bathtub?
And it wasn't a personal post by an "FSF guy", it's the stance of the whole FSF organization.
Yes, the battle is lost. Fighting an effectively lost battle isn't necessarily nuts, but criticizing it is quite understandable.
- https://news.ycombinator.com/item?id=35554107
Similar discussions when Chrome/Mozilla were removing it:
- https://news.ycombinator.com/item?id=33563378 (dang's comment has a list of additional related at the time)
- https://news.ycombinator.com/item?id=33803941
Relevant discussions:
- https://news.ycombinator.com/item?id=35212522
* https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...
* https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
https://github.com/niutech/jxl.js
If you want Chrome to ship with JPEG-XL support, use it. At some point, browser makers will decide it's worth the incremental cost (to them and all users) to add it.
That is to say people excited about JPEG-XL being removed aren't simply just ignorant they could decode it via JavaScript/WASM. Mostly they seem to disagree on what "enough improvement" to outweigh the cost of a shipping a new format is. E.g. Cloudinary is a commonly referenced proponent not by chance but because they operate a media CDN and it makes sense for them to present lots of material about the advantages vs say a single site.
I'm trying to make a good faith argument that if even passionate fans of the format are not willing to bear the time and bandwidth equivalent of loading a small number of images to use the format, that's a strong signal that it's not worth it.
There is probably never going to be an image format that would be worth throwing all that away for a JS shim that dumps pixels into a <canvas>. But that doesn't mean it is never worth adopting a new format into the image ecosystem.
One thing that is straight broken is direct linking. Since the transcoding is local the generated cached link is only local relevant. Similarly, since it has to not only spin up a decoder but transcode the image it is impractically slow.
The problem in this measure is it is impossible to pass regardless the format. How can a test be a strong signal of anything if everything would fail it? If this were a few millisecond/few byte component like a JavaScript feature extension I would see the applicability but image formats are too large and too slow to reasonably expect meaningful adoption via shims.
We've got plenty of open image formats for the web already. I don't get why people get so hung up about JPEG XL, it's not as if they're trying to force HEIF onto you like some other tech companies do.
Despite this jpg/png/gif aren't really gone and at the same time jpegxl is a one off codec for images. Mozilla didn't see the rush to introduce another format either but the FSF article isn't going to talk about that. Jpegxl definitely has some cool stuff about it and from the technical side I love it but from the "god damn it why isn't this saved image working this time" perspective I'm not angry at all to the browsers for not supporting it. Hell I'm still waiting for Microsoft to feel ready to enable AVIF in Edge when they had an employee as an editor for the standard.
My backend had the code written and ready to go, just waiting...
I think that’s true for a lot of people. Maybe one of them is better, but webp definitely has a distribution advantage by a mile.
Look how FSF slammed Apple in the past for their iPod ecosystem with “defective by design”. Apple never recovered from that
WebP is just flat out a Google thing, no standards body other than Google.