> While we can't link to Google's issue tracker directly because of another freedom issue -- its use of nonfree JavaScript -- we're told ...
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.
New account whose first comment is flamewar-style insult-no point engaging with them, they clearly aren’t here for constructive discussion, just flag and move on. With enough flags it will go dead
(Can everyone flag comments? Or is there some minimum karma for it? I forget.)
If Google's website is designed in the fashion where none of the content is available statically and the only way to access it is via running a blob of intrusive code, I can understand their sentiment.
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".
If non-intrusive browsers existed, which could run Javascript, is that considered acceptable to go to JS sites? eg what about Firefox or its derivatives?
No. The objection to linking to sites with JS is that they contain nonfree JS blobs that spy on you, run unknown obfuscated code, and are not open to modification, because they’re almost always obfuscated.
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.
At worst, postscript can crash your printer or take up a lot of cpu. There are no networking libraries or access to system stuff for postscript. So it should be safe for all practical purposes assuming you don’t care about the possible inconveniences that any Turing complete language can provide. This is a very different concern than executing random JavaScript.
I can't imagine why you would not be able to run site JavaScript in sandboxed manner (it already is) - just throw in some additional limitations and you are done.
This will break JS on some sites but not all of them, but that is apparently not sufficient for Stallman & co.
The reason you can’t do it is because JavaScript is Turing complete (like postscript, but unlike HTML) and JS needs to load from the network. This does not happen with postscript. There is no comparison to postscript that is meaningful in my mind.
It is not the determinism that’s a concern. JavaScript can test the capabilities of your machine and then create a new connection to transmit its results back to another computer. Even in the hypothetical scenario when you are only allowed to download messages and not upload messages, things are hard: because you have a fully programmable language at your disposal, you can create a system to transmit information by a sequence of reads with JavaScript. So the only safe way is to pre-download everything, then turn off the network and only then evaluate JavaScript in an environment without network or storage. FSF is not against such a mode of operation, but it becomes cumbersome for most people. And as the development of browsers consolidates, the fraction of the web that can be used in that way (for those who want to be super careful) becomes smaller.
I don't think there's any doubt that Postscript would have the same copyright and software freedom issues as Javascript. I myself have written a GUI Postscript program for NeWS.
So yes, of course Stallman would have objections to some Postscript files.
I wouldn’t be surprised if RMS said “I don’t file tax returns, because I would have to either (a) use nonfree online filing software, (b) use nonfree PDF technologies (since the US Form 1040 features XFA forms, and Wikipedia says the are nonfree [0]), or (c) hire an accountant, but they would also be using nonfree software, and the IRS is using proprietary software to process the tax returns anyway, so therefore I am not filing them”.
The link I gave described that exact topic. Stallman wrote:
"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.
When you open the form linked, SumatraPDF will warn that “The document uses unsupported features (XFA) and might not render properly”, and it cannot fill out the form. Perhaps it’s not XFA specifically, but some other strange technology.
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.
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."
> If non-intrusive browsers existed, which could run Javascript, is that considered acceptable to go to JS sites?
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.
I agree with the FSF principles. But they could add a picture, or a link to an archive site that strips most JS. To avoid users having to go and open the real thing to see it
Unfortunately, I think this is a phenomenon with the FSF...
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.
FSF is the uncompromising idealist for better and for worse. It takes some serious balls to live life the way RMS does, fetching HTML by sending email and all that. No one else wants to be that extreme, so even though they value computing freedom in the abstract they compromise and tolerate little injustices in the name of getting things done.
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 Javascript issue never made sense to me. You are reading a non-free document to begin with, what difference does it make if it is running Javascript or not? If they wanna spy on you they can do that with HTML and CSS just as well. Even releasing the spying software under GPL wouldn't stop it from spying on you.
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.
> The Javascript issue never made sense to me. [...] Even releasing the spying software under GPL wouldn't stop it from spying on you.
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.
> because you can't use your freedoms in practice anyway
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.
> Yes, you could. You can adapt the code and use an extension to use your "fork" instead of the provided one.
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.
>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
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.
None of that is accessible in the normal user interface, nor is there an easy way to disable any of that stuff from happening in the first place. As said, we used to have buttons to disable Javascript, CSS, image loading and cookies straight in the main menu, no addons or developer tools needed.
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.
You can turn off JavaScript execution in all browsers by going to about:config and setting javascript.enabled=false. It's not a button, but I think it's okay.
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).
Except they compromised on the very issue of media formats. They are making an unnecessary fight between two royalty-free formats, yet compromised and are hosting videos in royalty-bearing formats in their website. https://www.fsf.org/blogs/community/the-fsfs-approach-to-usi...
I've been saying this for years and years. [1] The FSF / GNU folks are only preaching to the choir and don't really have any positive solutions.
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.
> If you're a budding free software fan but happen to have a macOS machine or Windows machine your parents supplied, too bad.
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.
And that exact mindset made them totally irrelevant in the real world.
The FSFE and other organizations like the EFF and the EDRI are much more relevant and have a bigger impact than an org which still insists on using devices from 2007
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?).
I must be failing to understand your comment. The people complaining are FSF, and no matter how hard I squint, I cannot see how fair competition could require Google to be the first one to support a standard that literally nobody else supports.
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).
There's also the more widespread phenomenon of profitable-enough local businesses blaming Walmart for putting them out of business. How do we evaluate which analogy is appropriate?
So they're now forced to maintain every single format someone invents, keep it compatible and security patched forever? Even though even FOSS champion Mozilla wouldn't touch it?
>So they're now forced to maintain every single format someone invents,
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 could. They could also choose to not to. They could also have done it and their set of reasons doesn’t align with yours.
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.
They dont have to. But they could also not lie about it. Or lie about do no evil ( I know that is no longer their motto ). Or they could also not lie about WebP, AOM or AMP or everything else about being Good.
I mean they could do all those things, but, once again, they don’t have to. They don’t have a responsibility to anyone but their shareholders and therefore bottom line.
Then it's internal politics at play. Or perhaps image codecs are not as important to Google.
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]
this depends a lot on how you count. edge and Samsung Internet are both just reskinned chrome. Safari, Firefox and Opera Hot sound 20%, but that's almost all Safari, and Apple still wants to pretend that their special image format is relevant.
>instead of the entire industry that didn't adopt it?
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.
> Nobody is going to adopt something without being natively supported by browsers without ugly js hacks
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.
Why should Google be the ones solely responsible for pushing forward file formats? Either you criticize everyone for their parts in not adopting it, or not at all. It seems silly to single out Google and Google alone when nobody else batted an eyelash to try and support the format.
Being supported by some browsers is useless. It needs to be supported by all the major browsers, as shown by webp.
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!
JPEG XL is not Google created. The problem here is that there's a conflict of interest, Google has its own image formats and they're being petty about competition.
Of the people listed as the main authors of the JPEG XL spec on Wikipedia, I believe 2 out of 3 worked at Google.
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!)
> 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 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.
It was based on Google's submission, the majority of the authors are Google employees, and the majority of the commits to the reference implementation were written by Google employees. You mean other than that?
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.
Is your argument that more folks should have pushed back against JPEG XL? Webp was initially released in 2010 when it was the best alternative. JPEG XL came along almost a decade later. The state of image formats is very different.
No, instead Google should made WebP a proof-of-concept that there are technological advancements that can improve and made a successor of WebP like they've done with QUIC (to HTTP 3), not force-slinging it to everyone. Also, WebP violates the "two independent implementations" standard - at least AVIF can be argued to have two different implementations (due to dav1d).
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.
That seems fine then? Browsers are consumer consumption devices. And you have different formats good for other things. That's Apple's philosophy for HEIC.
Although I'm not personally a fan of web apps or Electron, the reality is that browsers are not just consumer consumption devices. And my reading of http://crbug.com/1178058 is that the existence of WebP and AVIF is being used as a justification for removing JPEG XL support.
The problem is that old PNG and JPEG are good enough for most purposes. They are certainly not as efficient but with todays technology and bandwidth, there is little downside to using JPEG and you know it will be supported everywhere.
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.
A 200MP smartphone is a nonsensical idea, their lenses are not big enough to utilize that many pixels. Even if it was actually possible, that 200MP is getting auto compressed the moment you message or upload it anywhere. I'm asking about legitimate uses.
It's not just that. There are purposes that require JPEG and so if I get a WEBP or AVIF or JXL I am actively angry.
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.
We shouldn't use a new format because some website sent you the wrong mime type and you don't know how to use an image converter? By that logic we should still be using .bmp files for all images.
I believe the main point is that Windows doesn't support AVIF desktop backgrounds, which is annoying. PNG and JPG (and possibly GIF) are common denominators for a vast majority of systems and applications.
The main point is that nothing supports AVIF other than browsers, and one or two image manipulation programs. If I have to open up GIMP every time I want to insert an image into a document, we have lost.
... so different formats exist because people want different things out of images, for instance for print, or for web, or for editing, and because all compression algorithms have their own tradeoffs. That's not a web engineer thing.
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.
I don't know that much about the subject but I had an image for a website I was optimising and the avif version was 10x smaller than the png version, even after I'd run through the normal techniques to squeeze it down, and 3x smaller than the jpeg while still looking much better. That's a really significant saving.
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
You see it's chicken and egg, but then ask why people are upset that the giant chicken with the ability to put out 10,000 eggs a week dropped a feature that was already in their product.
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.
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.
> How are you supposed to get feedback for a feature people can't actually use?
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.
Sure you can - you just do it. You just make the necessary fix.
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.
> Sure you can - you just do it. You just make the necessary fix.
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).
So, if it's behind a flag then people know not to use it, and therefor no one actually uses it. So you can change it if you want, but you never will because you'll never get feedback.
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.
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?
Yeah, because it is a new format. You don't immediately publicly release support for an experimental format.
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!
> 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.
Does anybody know why the earlier JPEG-XR also never got useful browser support? Are we just going to see this repeating over and over with nice general purpose image formats being relegated to individual vendor-centric ecosystems and never providing widespread interop?
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?
> why is Google the scapegoat instead of the entire industry that didn't adopt it?
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.
Anecdotally but sort of related - we've been using google lighthouse and tools like it to try and optimize our site performance and it was always suggested to use "next gen image formats" but we had the same problem where at the time none of the suggested formats really seemed to have good support.
Ehhh not quite. Google has some technology in JPEG-XL, but theirs isn’t the only in the project, there’s other code too, plus the JPEG group’s development, and it’s an ISO standard.
WebP is just flat out a Google thing, no standards body other than Google.
The article is about avif not webp. Note the editors (past and present) for the AOM avif specification don't even include Google https://aomediacodec.github.io/av1-avif/ Google was involved in each format but not responsible for on in control of either.
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.
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.
But surely JPEG is patent free by now (having been invented in the very early 90s)? To be honest I'm confused about what FSF's argument is here, as JPEG seems just fine to me.
I don't know what the FSF's argument is. I personally don't feel very strongly yet about this, but I am not comfortable with the "JPEG is sufficient" line of reasoning.
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.
So a few dozen comments, but so far it doesn't look like any mention the immediate thing that jumped out at me which was the claims vs AVIF:
>"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.
> 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.
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).
> 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.
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.
The profiles only matter if you want to be decodable by hardware decoders. If you only care about software decoders, which must be true if JPEG-XL is your comparison, then you don't have to use the HEIF grid for large dimensions, and the better question is how much memory your application will allow to be allocated. Because chances are JPEG's maximum 65535x65535 exceeds it that too.
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)
It is that simple, you're just noving the goal posts.
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.
The format supports that technically (the resolution is stored in two uint32_t variables), but libavif however currently seems to have pretty small limits in this area based off attempts a few months ago to try using it for high res photos: I couldn't get it to save images of size 8192 x 5464 (native Canon R5 res). avifEncoderAddImage() just returns a generic error when the size is too big. If I reduced the size of the image a bit, it then worked.
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" :(.
> And 12-bits per channel is considered a lot for end user final display formats?
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.
> and the maximum dimensions of a coded image is 65536x65536
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.
No, it's AV1 that uses (up to) 16-bit fields for image dimensions. HEIF grids, which is the AVIF feature that combines multiple AV1 images into one, have 32-bit fields for dimensions so are limited only by what the decoder is willing to allocate.
Claiming someone to 'spread misinformation' is not helpful. All the people related to compression that I know are trying their best to find the technically best solution by ethically best means. No dirty fighting observed.
"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.
>> 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.
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."
To be fair to MPEG, they don't actually run the patent pools, they just make everyone promise to join one.
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.
Google removes a standard nobody uses, I don't see the problem. AVIF is a decent alternative that can actually be used in modern browsers, with WebP as a fallback.
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.
The same reasoning could have applied to AVIF and WebP a few years ago. Nobody used these formats back then, so what's the problem if Google discontinues them?
There was a long period between the jpg/png/gif era and free alternatives that were significantly better but could replace all three format use cases (really 4, if you count that they were just a special format of the video codec they introduced). Even between webp and avif there was about a decade gap.
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.
“Slammed” is a word journalists love to use for when one entity criticizes another, regardless of impact or severity. It’s a trope that seems to have been around for a long time.
All of the people here who are so passionate about JPEG-XL will be happy to learn that there's nothing preventing them from using it on their sites right now:
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.
A bundling approach works great for web apps (e.g. an online image editor) but for serving images you have to be willing to not only lose any of the size and speed benefits but to completely demolish your website's performance all in hopes one day enough sites agree to do the same.
If the advantages of JPEG-XL are not worth websites downloading ~300KB (the size of 1 or 2 "hero" images) to users, one could argue that browser makers shouldn't add it to every download of their browser in perpetuity.
To be clear I'm not a fan of adding JPEG-XL to browsers rather I think you're presenting a strawman for why. Even if the size overhead were 0 bytes you're still completely ignoring the project page says it takes ~0.8 seconds (~0.5 multithreaded) to load 0.2 kilobyte image files with nothing else going on. An infinitely better format wouldn't make sense to a lot of sites.
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.
> To be clear I'm not a fan of adding JPEG-XL to browsers rather I think you're presenting a strawman for why.
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 indeed nothing in JPEG-XL worth breaking the entire image ecosystem for, where the image can used in a normal <img> tag, where you can direct link to the image URL, where you can save the image, where you can upload the image to any site you want, where you can see the thumbnail in your file browser, where you can open it in any image editor, etc.
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.
The jxl.js approach actually allows for some of that. Particularly putting <img src="https://jpegxl.info/logo.jxl"> works like normal (no <canvas>) as jxl.js functions using a mutation observer for such tags which then transcodes the image to a supported format (such as png) and caches it. Similarly you can then save the image in a way you'll have thumbnail support, image editor support, etc - all of course with the downside it'll be e.g. png at that point not the original.
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.
Passionate fans of an image format loading small numbers of images via shim isn't what makes browser makers change their minds. And clearly such fans do already exist or the github project wouldn't.
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.
Mozilla had the same issue - it was one engineer who stubbornly kept webp support out of the browser for years. Then he quit or got laid off and Mozilla finally got support. Mozilla also refused to support Yubikey for years, which we are still paying for now. It seems to me like Mozilla forgot really quickly what life was like when Internet Explorer was the dominant browser. Half the reason Chrome can ignore community outrage is because Mozilla decided existing options were "good enough" and stopped being competition.
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?
Maybe you misread or misunderstood (although maybe it makes no difference to you), but the specific issue is: the FSF won't link to the bug tracker (not can't) because of proprietary Javascript. The FSF has no absolute rejection of JS, they just are purist about the JS being free software.
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.
And yet HN automatically amputates title patterns that the mods consider clickbait, even if most of the time it just makes the title unintelligible or misleading.
200 comments
[ 3.2 ms ] story [ 223 ms ] threadWhile 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.
(Also, the insult is baseless, since the previous poster may have strong principles, even if they aren’t the same as yours.)
(Can everyone flag comments? Or is there some minimum karma for it? I forget.)
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.
[0] https://en.wikipedia.org/wiki/XFA
"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.
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=...
* https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...
* https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
https://caniuse.com/jpegxl
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...
[2] https://www.protocol.com/youtube-tv-roku-issues
https://developers.google.com/cast/docs/media
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.
WebP is just flat out a Google thing, no standards body other than Google.
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.
>"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.
----
0: https://github.com/AOMediaCodec/libavif
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... :
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.
https://avif.io/blog/comparisons/avif-vs-heif/
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
1: https://github.com/AOMediaCodec/av1-avif/issues/128
2: https://github.com/AOMediaCodec/av1-avif/pull/130
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.
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...
Look how FSF slammed Apple in the past for their iPod ecosystem with “defective by design”. Apple never recovered from that
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.
- 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://news.ycombinator.com/item?id=33442281
- https://news.ycombinator.com/item?id=35018672
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.
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.