Reading the FSF’s original statement on this is a perfect illustration of the tragedy that the FSF has negative credibility on important issues like this, and why this is the case.
Firefox, through ethical distributions like GNU IceCat and Abrowser, can weaken that stranglehold.
We’re only two sentences in and already we’re being told to use software nobody has ever heard of because it’s ‘ethical’. Why is vanilla Firefox from Mozilla not ‘ethical’? I think I can guess, but it’s only a guess. In any case, mentioning this issue at all here is derailing one issue (JPEG XL being excluded from Chrome for questionable reasons, showing Google’s bullying dominance of the web platform) into another (that vanilla Firefox doesn’t meet the FSF’s exacting standards for entirely free software). Mentioning any other browser at all by name is derailing, in fact: it’s not clear why this has to be a duopoly Chrome vs. Firefox situation, since Apple-made WebKit still exists and is actually being used by free software projects like GNOME Web.
Putting aside the problematic aspects of the term “ecosystem”
Again, even mentioning this is classic FSF language policing, once more derailing the actual issue at hand into criticizing something irrelevant because it’s a particular bugbear of Richard Stallman. (The linked essay is implicitly credited to him.) The FSF thinks it has to mention everything it hates at every available opportunity. This is not effective campaigning.
If we take their contribution in turning the web into the “WWWorst App Store” seriously […]
And the icing on the language policing cake, inserting random in-group propaganda terms of the FSF which nobody outside its clique has heard of. Admittedly, though, the linked essay is of some relevance to the actual issue.
While we can’t link to Google’s issue tracker directly because of another freedom issue – its use of nonfree JavaScript
It’s really not a good look not to link to a primary source when one is available, especially since the source they do link also uses ‘non-free JavaScript’. It’s probably not the intention in this case, but it gives the impression of wanting to cover up actual facts and point only to sources supporting a particular spin, especially when it comes from a campaign group.
we’re told that the issue regarding JPEG-XL’s removal is the second-most “starred” issue in the history of the Chromium project
Why is ‘starred’ in quotes? It makes it seem like this was written by someone who has no idea how the modern Internet works.
An organization of the FSF’s age, pedigree, and achievement ought to be able to command considerable respect when making a statement like this. Instead, anything they say is actually counterproductive, because the FSF has reputation for being obsessively idealistic weirdos — a reputation they take every opportunity to bolster with tactics like the ones shown in this and every single statement on issues of importance. The achievements of the FSF are almost all in creating software, but none in actually getting people to use it or listen to them.
This is a classic issue you see with all radical orgs. And the same thing happens any time those orgs experiment with softening their stances, they just tend toward the same space already ineffectively occupied by many other vaguely anti-establishment (but cool about it!) groups. All social movements need a radical flank. Who is going to fulfill that for FLOSS other than the FSF?
That is certainly a bummer. That article is a lot of circlejerky for the already drank-the-Kool-Aid in-group that reads more like the post in a topic’d chat room by a frustrated user than a statement of any official capacity. I like the concept the FSF stands for but there’s a lot of weird approaches (like GNU IceCat existing because they trademarked the logo of their otherwise FOSS application). But even still, I do like that there’s some “extremism” out there to maybe shift the window on these topics by dragging moderates–but even the FSF community blog seems a bit too official for a rant post like this. At least Ars Technica took the sentiment and ran in a more reasonable direction and helped focus on the Google interests going against the greater web interest for the image format.
Why is being a “starred” issue even relevant. The FSF has been around long enough to know that voting on hot issues always attracts copious zealots to swarm the vote in ways that don’t reflect reality. As another - non fsf related - example, take the libc++ post about making containers bounds checked: a huge swarm of essentially silent or outright new accounts came into existence to complain on the proposal despite none having any actual project involvement, while at the same time people who do agree don’t feel the need to involve themselves. It’s the same behaviour, and it is a behaviour the FSF is familiar with, has experienced directly, and frequently encourages on non-FSF projects they want to influence (they and EFF both largely contributed to the star bombing of this bug). Given that they clearly understand what they are doing, and what is actually being demonstrated, the fact that they try to represent the starring as being reflective of the general community is unethical and dishonest, and I feel deliberately so.
attracts copious zealots to swarm the vote in ways that don’t reflect reality
The funny thing about anti-JPEG XL posters is that they complain about swarms of zealots who don’t reflect reality, posting multiple comments per thread to remind us of their arguments.
Note to self: if you ever comment on a topic, you only have one opportunity, even if 5 months has passed, otherwise you are a zealot. It doesn’t matter if it’s a different article, or a different comment with different points, you only get one comment per topic. /s
Seriously, you just searched through history to find 3 (sorry, “multiple”) comments in 5 months, none of which said “we should go start/vote bomb support for our favorite format”, nor “format A is superior to format B no matter what anyone says”.
I literally do not care what format won (as demonstrated by my ongoing confusion as to wtf HEIC is given I thought it was just an AVIF wrapper?). If JPEG-XL was first to market+saturation I would be “an anti-AVIF” poster by your definition.
I work on platform security. My rationale is purely security. Supporting functionally dead file formats is a persistent source of major security holes. If a format is not under widespread use, and does not look like widespread use is likely, then it should be culled as it is otherwise just a landmine waiting to go off in the distant future. As I said to u/david_chisnall, there have been numerous exploits for safari over the years due to support for formats that were “big” but died. I get that there might be reasons that JPEG-XL is superior to AVIF or whatever, but that doesn’t matter. The dominant cameras today are phones, and as far as I can tell the overwhelmingly vast majority produce AVIF or JPEG (or Apple’s HEIC thing, but iOS and macOS seems to convert things to jpeg whenever going cross platform, so???), so the only thing having a JPEG-XL decoder does is provide attack surface.
So don’t try to equate a single digit number of comments that you found only by going through months of history and even then on stories about the same general topic, to the behaviour of a bunch of zealots for whom technical rationale are secondary to philosophical, or who organize pile on voting among their in group and represent that as being some kind of representative example of public opinion (especially on a forum where there is no counter to the upvote/star).
When you make that equivalence, what you are doing is saying “you can only ever comment on a given topic once, or you are a zealot”, and I don’t think that is your intent as that obviously means that the likelihood you can comment on any given lobste.rs post is inversely proportional to how long you’ve been on lobster.rs.
My point wasn’t that you said the same thing in this thread as the previous one, but rather that you commented three times in this thread saying essentially the same thing each time, and twice in the previous thread. (Note I’m not talking about replies within the same discussion, but completely independent comments making the same points.)
And if your concern were purely security, why try to make the point that ‘there’s no demand for it’ at all? It’s evidently untrue by any measure. Adobe and Affinity, the two biggest players in professional photo editing software, have added support. (Note that professional photographers do not shoot JPEG files directly; they shoot RAW files and export their edited versions to a format like JPEG or TIFF.) Every company with significant investment in image hosting is begging for it. For a format which was finalized less than a year ago, which still lacks a stable reference implementation, this was unusually good momentum until Google came along and cancelled support.
I’m sympathetic to arguments about the size of the Web Platform and the inability to shrink it once features ship – but given the tremendous amounts of bloat (with obvious security implications) Google is otherwise happy to add, it seems a little disingenuous.
Making untrue points – or more charitably, points you made up without knowing they whether were true – repeatedly on the same page looks like a sad attempt at the kind of astroturfing you’re accusing others of.
My point wasn’t that you said the same thing in this thread as the previous one, but rather that you commented three times in this thread saying essentially the same thing each time, and twice in the previous thread.
I disagree - the points in each thread were different enough to me, and to different people/comments as well (otherwise you get back to “you cannot answer or correct comments by people if you’ve answered the same topics in the past” - when I first answered these threads there were maybe 3 comments in total on the thread). I accept there’s some overlap those thread replies, but if you’re trawling months of comments to produce a single digit count I don’t think portraying me as some rabid zealot is reasonable.
And if your concern were purely security, why try to make the point that ‘there’s no demand for it’ at all? It’s evidently untrue by any measure. Adobe and Affinity, the two biggest players in professional photo editing software, have added support.
Because photo editors are not browsers. I didn’t say there was no demand. I said that it had lost on the web. ImageIO (the Darwin image loading library) supports untold myriad image formats, and it was a hard learned lesson to just allow-list the formats webkit rather than slowly blocking specific formats.
That some people want a format doesn’t mean it’s appropriate to expose it to the web.
I’m sympathetic to arguments about the size of the Web Platform and the inability to shrink it once features ship – but given the tremendous amounts of bloat (with obvious security implications) Google is otherwise happy to add, it seems a little disingenuous.
That’s not the problem. The problem is adding single features that add significant complexity, but also aren’t used means that you’re just adding surface area.
Making untrue points – or more charitably, points you made up without knowing they whether were true – repeatedly on the same page looks like a sad attempt at the kind of astroturfing you’re accusing others of.
“Cool”
Again, you wanting a feature, or there being some group of people wanting a feature, does not magically make it popular enough to warrant the attack surface it exposes.
That all said, given your last point I suggest we ignore each other, you’ve clearly decided to dismiss anything I do say, and out right accuse me of making things up or lying. I’m uninterested in talking to someone who is only going to make up false claims and attack me personally.
In English, the distinction between single and double quotes is syntactic, not semantic; broadly speaking, U.S. usage is to use double quotes for the outermost level of quoting, while UK usage is to use single quotes. You would switch to the other form only when you need to nest quotes. There’s no situation in which you would say, “this is less important, so I’m going to put it in single quotes instead of double,” or anything like that. (At least not in standard usage.)
A lot of the internet commentary suggests Google is/was opposed to JPEG XL, but if anything they seem to have been the only browser vendor interested in it. It’s derived from Google tech (PIK and Brunsli), was implemented in Chrome early (behind a flag, per current standard practice), and doesn’t seem to have been implemented by any of the other major browsers (Safari, Firefox, Edge).
We are hoping to use JPEG XL in both image encoding and content encoding. For content encoding we can deliver traditional JPEGs with the -22 % savings in transferred bytes. We can help in the exploration work, documentation and other aspects of the possible integration.
JPEG XL is building on our previous work in FLIF, FUIF, pik, guetzli, zopfli, butteraugli, knusperli, brunsli, WebP lossless, and brotli. I believe it is the technically strongest, easiest to use, and most backward compatible and full-featured contender of the next-gen image formats.
What was the Chrome team supposed to do here? If they’d pushed JPEG XL despite lack of interest from anyone else, then that would have been “browser hegemony”.
Is Google now evil for not trying to force-feed adoption of a Chrome-specific technology?
As so often, I think this was a management intervention at Google. The engineers are probably still for it, but Google wants to push their own formats, too.
This has never been a technical debate, even though some are trying to turn it into one. AVIF is a video codec shoehorned into an image format, which brings a lot of disadvantages (no progressive decoding, lack of error tolerance, performance). Just the simple fact that JPEG XL allows JPEG transcoding with 20-30% savings is reason enough to support it exclusively.
Ok, then why single out Google? Why isn’t the FSF also going after Mozilla and Apple? It’s not like JPEG XL as a technology is inherently more aligned with copyleft than AVIF or WebP, and the primary stakeholders are all sites that nobody belonging to the FSF would use regularly (due to e.g. requiring JavaScript).
If Chrome shipped JPEG XL and it started getting adopted on sites like Facebook, I guarantee you there would be angry articles about depending on Chrome-specific capabilities. There was a lot of that for WebP[0], and it took years before Mozilla gave in and implemented support for it.
This reads like the FSF jumping into a debate they don’t understand, for obscure reasons.
This is a good point. As a counterargument, other than AVIF or WebP, JPEG XL is actually an ISO standard. I think we should all shame Mozilla for wimping out on this great format only because big brother Google decided so. Google might have even used their influence over Mozilla here, given they fund it heavily.
Did you see like every major graphics-related or social-media-related vendor have a spokesperson comment on the Chromium issue tracker about this? Like you have team Krita and GIMP agreeing with Facebook and Adobe over interest.
This is what really frustrates me. Seeing people buy into Google’s suggestion that there’s a ‘lack of interest’ and then claim that supporters are just jumping on the anti-Google bandwagon as if I haven’t read the whole issue thread (and followed the format’s history for years) because JPEG-XL really is something I care about. Forget about the FSF, this is much bigger than that. We have a chance here to make the right decision, which we will benefit from for many years to come. It’s being killed off by some Google internal politics. I can’t believe anyone would jump to their defence here.
Disregarding the FSF, JPEG-XL has clear benefits, and has had wide industry support, essentially waiting on Chrome to add it to make it usable on the web. And despite how the FSF statement is written, the overall theme of the browser hegemony is correct. If Chrome doesn’t play ball, you’re screwed. Chrome is the new IE of web standards.
JPEG-XL came at the wrong time: It now competes with AVIF, and AVIF makes sense given that AV1 is a must.
It’s not only about the gains right now: Since you can’t remove support for a format once it has become widespread, you have to balance it against the generational improvement that adding support would give.
I’m rather thinking now is a good time to combine the best of AV1, EVC and JPEG-XL into a next generation combined video/image codec.
This is the thing that FSF is refusing to acknowledge. There isn’t really room for multiple formats for exactly the same purpose, and supporting unused formats creates a significant security risk, especially as formats get more complex. It doesn’t matter if JPEG-XL is better by some metrics that AVIF, once AVIF became dominant JPEG-XL was dead.
That’s how format wars work.
But rather than accepting this, and starting to work on ensuring the next/future formats meet their ideological ideals FSF is just shitting on everyone else, and producing weird propaganda documents that further reduce their credibility.
I think it’s true for video, because decoding video is so expensive that doing it without hardware offload is bad for battery life. You want a small set of standards to implement in hardware because verification costs are high and hardware timelines are long. I might buy the argument for audio, since often people put mobile devices in low-power states playing audio. I am far less convinced for still images, where the decoding costs are now fairly small compared to the rest of the browser and the only cost is maintaining the decoder.
The decoding cost is not the issue, it’s the maintenance overhead and security risk which has to be justified.
If you want the proposed format to be included on purely technical grounds, then it needs to be so much better that not including it is essentially unthinkable, and that’s a very high bar to clear e.g. zstd content-encoding is currently nowhere, despite being way superior to gzip for on-the-fly compression (and competitive though marginally worse than lz4 and br at the lower and upper extremes of compression ratio, if with much better decompression throughput than brotli), because while it’s way superior it’s not overwhelming enough for any of the major actors to be convinced.
The best ways to get the format in are largely political:
force it in (à la Google) and everybody else has to follow
have everybody agree that it’ll go in beforehand (AV1?)
have the format be so popular elsewhere that it’s unthinkable not to have it
and finally have it come for free with something that’s getting in via one of the previous (AVIF)
Sorry for the delayed reply, lobster’s exciting approach to saying you have replies strikes once more! :D
I’m not concerned about the performance cost of including additional decoders. It’s purely security: I don’t believe a single image decoder that has been exposed to the web has not eventually seen exploitation, and the generally unused ones are particularly egregious as those formats don’t get the same level of scrutiny or testing. If an image format is not extremely widely used, the cost:reward balance tends very quickly to removal. This isn’t a hypothetical: numerous full RCE exploits against safari have been via rare formats being exposed to the web. Similarly, modal image formats where some modes are significantly rarer or share little logic with primary paths have the same problems.
Re: hardware decoding - I believe apple uses the gpu to decode JPEGs, but I do recall there being some talk about there being actual JPEG specific hardware in early generation iPhones, but that memory is very murky, very old, and may just be me merging in the incessant AVIF/HEIC zealots rambling about hardware decoding for those formats so that’s something that gets a grain of salt. Also obviously if JPEG-XL had won, then any hardware decode support would be for JPEG-XL rather than AVIF/HEIC (though as I understand it AVIF/HEIC can ostensibly make use of a bunch of the video decode logic directly which obviously would help).
Don’t know about the FSF, but I have the hots for JPEG-XL because $WORK has over 1tb/day egress of user-supplied images in jpeg format. Being able to shrink that by 30% with no loss of quality would be a huge win!
That might be the case, but while the company @danielrheath works for deals with image data, I have to imagine that for a generic cloud provider video bandwidth dwarfs image bandwidth (if we’re talking media). The big wins are in making video encoding more effective.
I’m a semi-avid photographer and I don’t know how to produce a JPEG XL image.
This is because the format is still brand new, and also because the lack of adoption by the most popular application for consuming the largest distribution network for images. This is why JPEG XL’s removal from Chrome seems suspiciously premature: the bitstream and file format for JPEG XL was finalized last year, but the reference implementation isn’t stable yet.
As for why people are excited about it, there are a lot of reasons which point to companies with big investments in image delivery being able to save significantly on bandwidth costs without losing quality, as @danielrheath pointed out. I’m one of the few small-time users with a legitimate interest in JPEG XL that goes beyond the comparatively marginal benefit of saving some of my personal disk space, because it offers uniquely good set of characteristics for my use-cases as a photographer. In increasing order of esotericism:
I usually edit and save my photos these days assuming they’ll be viewed on a wide gamut display with at least Display P3 capability. Regular old JPEG can do this, but the colour space information is stuffed into EXIF data rather than being intrinsic to the file format, and zealous EXIF stripping programs on various websites sometimes delete it, so the colours in the picture look wrong. Also, regular old JPEG is limited to 8 bits per channel, which starts to get quite thin as the gamut increases. Admittedly, AVIF and WebP are ‘good enough’ at this.
I work with scans of medium format and large format film, in the range of tens of thousands of pixels per image dimension. Regular old JPEG is limited to 65k pixels per side, and newer formats – especially AVIF, based on a format designed for video with much smaller dimensions – are actually worse than old-school JPEG at this, and can only ‘cheat’ very large images by gluing them together side by side, so you lose the advantages of being able to share compression information between ‘panels’ of an image, an effect that gets worse as pictures get larger. There may also be visible artefacts between panels because the transition can’t be smoothed over by the compression algorithm effectively. JPEG XL natively supports up to a thousand million pixels per image side.
I also sometimes work with photos with transparency. Among older formats, JPEG can’t do this at all, and PNG only offers lossless compression which isn’t intended for photographic data and thus makes absolutely huge files when used for it. Again, AVIF and WebP are probably ‘good enough’ at this, but for some applications they suck because afaict you can’t have transparency in a CMYK image for them, so if I’m preparing an image with transparency for press, there’s no format for that.
Thank you for sharing. If I’m understanding correctly, the removal of JPEG XL from Chrome wouldn’t really affect most of your personal use-cases then, right? For instance, I can’t imagine you’d be inlining any billion-by-billion pixel images on a web page.
Your points are all valid yet entirely pointless on the web (CMYK? billion pixels in each direction?).
JPEG-XL could make inroads in print, design, arts etc without thinking about Chrome even once. Yet it seems that there isn’t much enthusiasm in supporting it and its unique features in that space. How is that Chrome’s fault?
That seems more of a self-imposed hegemony: “We only look at the format for any use case once Chrome supports it. Bad Google!” In my opinion that’s a weird notion of “free as in freedom”.
The question was why people are interested in JPEG XL, especially from the perspective of a ‘semi-avid photographer’. I acknowledged explicitly that I benefit unusually extensively from JPEG XL compared to other individual photographers, and pointed to another answer in this thread that makes a more compelling case that’s very relevant to the web. I would also say that each of my points contains something less unusual that actually is relevant for the web (e.g. it’s not that uncommon for images larger than 4K, the maximum size for one panel of AVIF data, to be posted on the web).
Also, JPEG XL is actually beginning to see adoption outside of web browsers for these use cases. But that wasn’t the question I was answering here.
Yet it seems that there isn’t much enthusiasm in supporting it and its unique features in that space. How is that Chrome’s fault?
Because that’s Google’s line, not reality. Read the issue thread and note how many voices there are (from major companies) speaking against the decision to remove it.
“to remove it” - an experimental feature behind a flag. Nobody seriously used that capability, ever. How many of those opposing the removal in the issue thread are even aware of that instead of just joining the choir?
So where’s JPEG-XL support in Edge, Firefox, Safari? Where’s the “10% of the web already use a JPEG-XL decoder polyfill until Chrome finally gets its act together and offers native support” article?
This entire debate is in a weird spot between “Google (Chrome) force developments down our throats” (when something new does appear, such as WebUSB, WebMIDI, WebGPU, …) and “We have to wait until Chrome does it before everybody else can follow”.
That’s kind of the point. It wasn’t even given a chance to prove itself. This was very premature and came out of nowhere just as JPEG-XL was starting to gain attention. Why is it so hard to understand why people are frustrated by this? I guess I just don’t understand why you’re against it, or feel the need to suggest that people against the removal are just ‘joining the choir’. Maybe people do really care?
I don’t know what this has to do with any other web technology. I would take JPEG-XL over any of those (not that’s that’s really relevant).
Right, JPEG-XL hasn’t got a chance to “prove itself” by becoming part of the standard feature set of Chrome because it was never put in front of ordinary users (it’s always been behind a flag).
Every other time that Chrome unilaterally decides to put something in front of ordinary users, people claim that this is just an example of Chrome’s web hegemony. That would have happened with JPEG-XL, too.
What should happen for healthy web standard evolution:
Polyfills implement a strongly sought-after feature in a portable way for browsers, so it’s not up to browser vendors to decide what ends up a part of the web platform and what doesn’t.
These polyfills become successful so much that they’re impossible to ignore and that browser vendors are incentivized to implement the feature natively for efficiency.
Multiple browser vendors implement the feature.
Browser vendors who don’t follow are called out for blocking progress.
For some odd reason, JPEG-XL advocacy starts at step 4, simultaneously arguing that Chrome shouldn’t be the arbiter of what becomes a web standard and what doesn’t, and not doing any of the other work. (edit to add: meanwhile it ignores all the other actors on the web who don’t support JPEG-XL, either.)
To me that looks like JPEG-XL advocates were expecting Chrome to implement the format, take the heat for “forcing more stuff on people” (as always happens when Chrome unilaterally adds stuff), then have everybody else follow. That’s a comfortable strategy if it works, but I don’t see why JPEG-XL should have a right to this kind of short cut. And I don’t see how “Chrome didn’t employ its hegemony to serve our purpose” is a sign of “how the web works under browser hegemony.”
So: where are the Polyfills? Where are the Adobes, Flickrs and everybody using them, with blog posts documenting their traffic savings and newly enabled huge image features, and that “x% of the web runs on JPEG-XL”?
And, to keep that line of thought a bit separate, as its own post:
I don’t so much mind JPEG XL folks doing that. That means that they’re working in a world view that presumes such a web hegemony by Chrome. I disagree but given that it’s xPEG, they probably can’t think any other way.
The FSF, however, should be well aware how stuff like this ought to work…
Okay, so it’s more about web standards being fast tracked without proper procedure? I can definitely appreciate that.
The way Google has gone about this though is not just removing an existing experimental flag for a feature that actually has (or had) a good chance of getting in had it just been given time, but did so in such a way that made it sound like the decision was final and there would be no way back from it, while providing such a weak/misleading explanation that it seemed pretty obvious there must be an ulterior motive. Especially when they didn’t even acknowledge the flood of companies showing an interest and clearly proving them wrong. If even they can’t convince Google to think twice, then clearly they aren’t interested in having an honest discussion.
Personally I don’t mind how long it takes for the web to adopt JPEG-XL. I would have been all too happy for it to have gone through the process you describe (although I’m not sure how realistic it is that the major players would use a polyfill for something like this). What’s frustrating is that the way they did handle it may have effectively killed any chance it had prematurely rather than allowing it to gain traction slowly and naturally.
Edit: And I really want to be wrong about that. I hope that there is a way back from this.
so it’s more about web standards being fast tracked without proper procedure?
To some degree, but not only. The other aspect is that all those organizations chiming in on the issue tracker talk the talk but don’t walk the walk. There are numerous options to demonstrate that they care about a JPEG-XL deployment and that kickstart JPEG-XL on the web. I haven’t seen much in that space (see above for ideas what they could do, that nobody working on Chrome could block).
What I’ve seen are complaints that “Mighty Chrome is taking our chance at becoming part of the web platform!” and that seems more like a pressure campaign that Somebody Else (namely: the Chrome folks) should invest in JPEG-XL and bear any risks (whatever they might be, e.g. patent encumbrance issues) without doing anything themselves.
And that’s a pretty clear sign to me that nobody actually cares - it’s not just “Google’s line”.
Adobe (back then, owner of Flash, the scourge of the web) and Serif Labs (who also chimed in on the tracker) could provide a maintained, freely licensed polyfill for its customers to use to benefit from JXL on the web, driving adoption.
Facebook/Instagram don’t need to wait to ship JXL data to give “The benefit of smaller file size and/or higher quality can be a great benefit to our users.” - again: ship a polyfill (with a long cache duration it’s worth it sending it over, to then benefit from the space savings)
Again: Talk is cheap. Chrome’s JXL support was barely beyond “let’s see if it compiles”, given that it was behind a flag. If all these parties who “care so much” truly care and make JXL-on-the-web a thing, I’m quite sure that Chrome will change course and reintroduce that code.
And unlike with IE6, it won’t take 15 years between Chrome finally introducing native support and everybody being able to take out their polyfills because Chrome has an actual planned update process. My guess is that Safari would be the last hold-out, as is usual.
What is the problem with AVIF exactly? Is it that it has some patent on it that could potentially make it harder to write or distribute GPL code that handle the format?
I don’t see any issues with AVIF from Free Software perspective. It already has multiple open-source GPL-compatible implementations, and AV1 is royalty-free licensed. The HEIF and MP4 specs that AVIF depends on are behind ISO’s paywall, but so is JPEG XL.
With codecs there’s always some stink around software patents, but Google and Apple have shipped AVIF. I see it as an assurance, because they know that if a patent troll wins litigation against even a small victim, they’ll be on hook too for even bigger money, so they’re strongly motivated to defend AVIF for everyone.
The real issues I’m aware of are on technical merits. JPEG-XL is significantly faster to encode, compresses a bit better in high-quality range, and has some neat features like ability to losslessly convert from a classic JPEG.
But AVIF is still way better than the old JPEG and WebP. People on the web aren’t even using AVIF yet, so the JPEG XL vs AVIF battle is like Lamborghini vs Ferrari while everyone still drives a Toyota.
That’s the summary: Concerns over licensing, royalties, and patents. These things are unlikely to impact Apple, Facebook, Microsoft, or Google, but will have potential impact on “the little guys”.
Not on the legal side but AV1 requires a lot more performance to encode and decode that content creators have begged for hardware encoding of AV1 to save time. Transparent compression on JPEG and progressive decoding can make a much better experience. Folks aren’t saving images from their cameras in AVIF or WebP.
The FSF is increasingly delusional, and is assuming that there is no cost to including support for arbitrary formats regardless of actual use.
The reality is that JPEG-XL lost the “next gen” image format war, so is essentially unused. The FSF believes that supporting JPEG-XL when it is not being used doesn’t cause any harm, which is false. The history of browsers is littered with “random unused file parser had exploitable bug leading to the browser being owned”.
Then in this report itself there’s just copious dogmatic nonsense: “can’t read the bug database because of non-free js”. You absolutely can, you just don’t get to force your own licensing view on others. Recall the the FSF is relatively opposed to license freedom, preferring GPL over the much “freer” BSD or MIT style licenses.
It’s then filled with propaganda scare quotes which delegitimizes everything they’re saying by making this come across a zealot driven piece of marketing and propaganda, making any technical argument that they might have had irrelevant tot he reader. Also it has a bunch of nonsense “I don’t get the internet” stuff like quoting ‘“starred”’, which further just makes them come across as idiots at best - coupled with the standard “lots of votes on an issue the triggers zealot swarming of a bug means lots of real world support”. That last point on vote swarming is something that the FSF is familiar with, so it just reinforces that the FSF is being deliberately obtuse/misleading and unethical in how it is presenting its argument.
The FSF has an important mission, and twenty years ago it was super effective, but I think its absolutely blank and white stance, coupled with its dismissal of any issue other than “does this match our personal definition of free” is causing (has caused?) irreparable harm to itself, and by proxy the actual mission.
Recall the the FSF is relatively opposed to license freedom, preferring GPL over the much “freer” BSD or MIT style licenses.
Not to spout the dogma, but they do support the permissive Apache 2.0. They oppose BSD and MIT over unclear language and lack of a clause to address patent retaliation. (Source
Reading the FSF’s original statement on this is a perfect illustration of the tragedy that the FSF has negative credibility on important issues like this, and why this is the case.
We’re only two sentences in and already we’re being told to use software nobody has ever heard of because it’s ‘ethical’. Why is vanilla Firefox from Mozilla not ‘ethical’? I think I can guess, but it’s only a guess. In any case, mentioning this issue at all here is derailing one issue (JPEG XL being excluded from Chrome for questionable reasons, showing Google’s bullying dominance of the web platform) into another (that vanilla Firefox doesn’t meet the FSF’s exacting standards for entirely free software). Mentioning any other browser at all by name is derailing, in fact: it’s not clear why this has to be a duopoly Chrome vs. Firefox situation, since Apple-made WebKit still exists and is actually being used by free software projects like GNOME Web.
Again, even mentioning this is classic FSF language policing, once more derailing the actual issue at hand into criticizing something irrelevant because it’s a particular bugbear of Richard Stallman. (The linked essay is implicitly credited to him.) The FSF thinks it has to mention everything it hates at every available opportunity. This is not effective campaigning.
And the icing on the language policing cake, inserting random in-group propaganda terms of the FSF which nobody outside its clique has heard of. Admittedly, though, the linked essay is of some relevance to the actual issue.
It’s really not a good look not to link to a primary source when one is available, especially since the source they do link also uses ‘non-free JavaScript’. It’s probably not the intention in this case, but it gives the impression of wanting to cover up actual facts and point only to sources supporting a particular spin, especially when it comes from a campaign group.
Why is ‘starred’ in quotes? It makes it seem like this was written by someone who has no idea how the modern Internet works.
An organization of the FSF’s age, pedigree, and achievement ought to be able to command considerable respect when making a statement like this. Instead, anything they say is actually counterproductive, because the FSF has reputation for being obsessively idealistic weirdos — a reputation they take every opportunity to bolster with tactics like the ones shown in this and every single statement on issues of importance. The achievements of the FSF are almost all in creating software, but none in actually getting people to use it or listen to them.
The free software movement deserves better.
The EFF does a lot better, from what I can tell.
yes, agreed
This is a classic issue you see with all radical orgs. And the same thing happens any time those orgs experiment with softening their stances, they just tend toward the same space already ineffectively occupied by many other vaguely anti-establishment (but cool about it!) groups. All social movements need a radical flank. Who is going to fulfill that for FLOSS other than the FSF?
That is certainly a bummer. That article is a lot of circlejerky for the already drank-the-Kool-Aid in-group that reads more like the post in a topic’d chat room by a frustrated user than a statement of any official capacity. I like the concept the FSF stands for but there’s a lot of weird approaches (like GNU IceCat existing because they trademarked the logo of their otherwise FOSS application). But even still, I do like that there’s some “extremism” out there to maybe shift the window on these topics by dragging moderates–but even the FSF community blog seems a bit too official for a rant post like this. At least Ars Technica took the sentiment and ran in a more reasonable direction and helped focus on the Google interests going against the greater web interest for the image format.
IceCat mostly exists because of the add-ons search in Firefox, auto-drm download offer, etc
I’m not saying it’s not silly, but it’s not “trademarked the logo”
Good info to know because if it was just that, it would be quite silly
Why is being a “starred” issue even relevant. The FSF has been around long enough to know that voting on hot issues always attracts copious zealots to swarm the vote in ways that don’t reflect reality. As another - non fsf related - example, take the libc++ post about making containers bounds checked: a huge swarm of essentially silent or outright new accounts came into existence to complain on the proposal despite none having any actual project involvement, while at the same time people who do agree don’t feel the need to involve themselves. It’s the same behaviour, and it is a behaviour the FSF is familiar with, has experienced directly, and frequently encourages on non-FSF projects they want to influence (they and EFF both largely contributed to the star bombing of this bug). Given that they clearly understand what they are doing, and what is actually being demonstrated, the fact that they try to represent the starring as being reflective of the general community is unethical and dishonest, and I feel deliberately so.
The funny thing about anti-JPEG XL posters is that they complain about swarms of zealots who don’t reflect reality, posting multiple comments per thread to remind us of their arguments.
Note to self: if you ever comment on a topic, you only have one opportunity, even if 5 months has passed, otherwise you are a zealot. It doesn’t matter if it’s a different article, or a different comment with different points, you only get one comment per topic. /s
Seriously, you just searched through history to find 3 (sorry, “multiple”) comments in 5 months, none of which said “we should go start/vote bomb support for our favorite format”, nor “format A is superior to format B no matter what anyone says”.
I literally do not care what format won (as demonstrated by my ongoing confusion as to wtf HEIC is given I thought it was just an AVIF wrapper?). If JPEG-XL was first to market+saturation I would be “an anti-AVIF” poster by your definition.
I work on platform security. My rationale is purely security. Supporting functionally dead file formats is a persistent source of major security holes. If a format is not under widespread use, and does not look like widespread use is likely, then it should be culled as it is otherwise just a landmine waiting to go off in the distant future. As I said to u/david_chisnall, there have been numerous exploits for safari over the years due to support for formats that were “big” but died. I get that there might be reasons that JPEG-XL is superior to AVIF or whatever, but that doesn’t matter. The dominant cameras today are phones, and as far as I can tell the overwhelmingly vast majority produce AVIF or JPEG (or Apple’s HEIC thing, but iOS and macOS seems to convert things to jpeg whenever going cross platform, so???), so the only thing having a JPEG-XL decoder does is provide attack surface.
So don’t try to equate a single digit number of comments that you found only by going through months of history and even then on stories about the same general topic, to the behaviour of a bunch of zealots for whom technical rationale are secondary to philosophical, or who organize pile on voting among their in group and represent that as being some kind of representative example of public opinion (especially on a forum where there is no counter to the upvote/star).
When you make that equivalence, what you are doing is saying “you can only ever comment on a given topic once, or you are a zealot”, and I don’t think that is your intent as that obviously means that the likelihood you can comment on any given lobste.rs post is inversely proportional to how long you’ve been on lobster.rs.
My point wasn’t that you said the same thing in this thread as the previous one, but rather that you commented three times in this thread saying essentially the same thing each time, and twice in the previous thread. (Note I’m not talking about replies within the same discussion, but completely independent comments making the same points.)
And if your concern were purely security, why try to make the point that ‘there’s no demand for it’ at all? It’s evidently untrue by any measure. Adobe and Affinity, the two biggest players in professional photo editing software, have added support. (Note that professional photographers do not shoot JPEG files directly; they shoot RAW files and export their edited versions to a format like JPEG or TIFF.) Every company with significant investment in image hosting is begging for it. For a format which was finalized less than a year ago, which still lacks a stable reference implementation, this was unusually good momentum until Google came along and cancelled support.
I’m sympathetic to arguments about the size of the Web Platform and the inability to shrink it once features ship – but given the tremendous amounts of bloat (with obvious security implications) Google is otherwise happy to add, it seems a little disingenuous.
Making untrue points – or more charitably, points you made up without knowing they whether were true – repeatedly on the same page looks like a sad attempt at the kind of astroturfing you’re accusing others of.
I disagree - the points in each thread were different enough to me, and to different people/comments as well (otherwise you get back to “you cannot answer or correct comments by people if you’ve answered the same topics in the past” - when I first answered these threads there were maybe 3 comments in total on the thread). I accept there’s some overlap those thread replies, but if you’re trawling months of comments to produce a single digit count I don’t think portraying me as some rabid zealot is reasonable.
Because photo editors are not browsers. I didn’t say there was no demand. I said that it had lost on the web. ImageIO (the Darwin image loading library) supports untold myriad image formats, and it was a hard learned lesson to just allow-list the formats webkit rather than slowly blocking specific formats.
That some people want a format doesn’t mean it’s appropriate to expose it to the web.
That’s not the problem. The problem is adding single features that add significant complexity, but also aren’t used means that you’re just adding surface area.
“Cool”
Again, you wanting a feature, or there being some group of people wanting a feature, does not magically make it popular enough to warrant the attack surface it exposes.
That all said, given your last point I suggest we ignore each other, you’ve clearly decided to dismiss anything I do say, and out right accuse me of making things up or lying. I’m uninterested in talking to someone who is only going to make up false claims and attack me personally.
This particular friendly fire incident comes to mind.
I think it’s fine to put ‘starred’ in quotes, or at least single quotes.
In English, the distinction between single and double quotes is syntactic, not semantic; broadly speaking, U.S. usage is to use double quotes for the outermost level of quoting, while UK usage is to use single quotes. You would switch to the other form only when you need to nest quotes. There’s no situation in which you would say, “this is less important, so I’m going to put it in single quotes instead of double,” or anything like that. (At least not in standard usage.)
A lot of the internet commentary suggests Google is/was opposed to JPEG XL, but if anything they seem to have been the only browser vendor interested in it. It’s derived from Google tech (PIK and Brunsli), was implemented in Chrome early (behind a flag, per current standard practice), and doesn’t seem to have been implemented by any of the other major browsers (Safari, Firefox, Edge).
The Firefox tracking bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1539075) has quotes from someone who appears to have been a Google employee at the time they posted:
What was the Chrome team supposed to do here? If they’d pushed JPEG XL despite lack of interest from anyone else, then that would have been “browser hegemony”.
Is Google now evil for not trying to force-feed adoption of a Chrome-specific technology?
As so often, I think this was a management intervention at Google. The engineers are probably still for it, but Google wants to push their own formats, too.
This has never been a technical debate, even though some are trying to turn it into one. AVIF is a video codec shoehorned into an image format, which brings a lot of disadvantages (no progressive decoding, lack of error tolerance, performance). Just the simple fact that JPEG XL allows JPEG transcoding with 20-30% savings is reason enough to support it exclusively.
Ok, then why single out Google? Why isn’t the FSF also going after Mozilla and Apple? It’s not like JPEG XL as a technology is inherently more aligned with copyleft than AVIF or WebP, and the primary stakeholders are all sites that nobody belonging to the FSF would use regularly (due to e.g. requiring JavaScript).
If Chrome shipped JPEG XL and it started getting adopted on sites like Facebook, I guarantee you there would be angry articles about depending on Chrome-specific capabilities. There was a lot of that for WebP[0], and it took years before Mozilla gave in and implemented support for it.
This reads like the FSF jumping into a debate they don’t understand, for obscure reasons.
[0] Websearch surfaces https://news.ycombinator.com/item?id=18974637 and https://news.ycombinator.com/item?id=27508300 as examples, which match my general memories of online consensus at that time.
This is a good point. As a counterargument, other than AVIF or WebP, JPEG XL is actually an ISO standard. I think we should all shame Mozilla for wimping out on this great format only because big brother Google decided so. Google might have even used their influence over Mozilla here, given they fund it heavily.
Did you see like every major graphics-related or social-media-related vendor have a spokesperson comment on the Chromium issue tracker about this? Like you have team Krita and GIMP agreeing with Facebook and Adobe over interest.
This is what really frustrates me. Seeing people buy into Google’s suggestion that there’s a ‘lack of interest’ and then claim that supporters are just jumping on the anti-Google bandwagon as if I haven’t read the whole issue thread (and followed the format’s history for years) because JPEG-XL really is something I care about. Forget about the FSF, this is much bigger than that. We have a chance here to make the right decision, which we will benefit from for many years to come. It’s being killed off by some Google internal politics. I can’t believe anyone would jump to their defence here.
Disregarding the FSF, JPEG-XL has clear benefits, and has had wide industry support, essentially waiting on Chrome to add it to make it usable on the web. And despite how the FSF statement is written, the overall theme of the browser hegemony is correct. If Chrome doesn’t play ball, you’re screwed. Chrome is the new IE of web standards.
JPEG-XL came at the wrong time: It now competes with AVIF, and AVIF makes sense given that AV1 is a must.
It’s not only about the gains right now: Since you can’t remove support for a format once it has become widespread, you have to balance it against the generational improvement that adding support would give.
I’m rather thinking now is a good time to combine the best of AV1, EVC and JPEG-XL into a next generation combined video/image codec.
This is the thing that FSF is refusing to acknowledge. There isn’t really room for multiple formats for exactly the same purpose, and supporting unused formats creates a significant security risk, especially as formats get more complex. It doesn’t matter if JPEG-XL is better by some metrics that AVIF, once AVIF became dominant JPEG-XL was dead.
That’s how format wars work.
But rather than accepting this, and starting to work on ensuring the next/future formats meet their ideological ideals FSF is just shitting on everyone else, and producing weird propaganda documents that further reduce their credibility.
I think it’s true for video, because decoding video is so expensive that doing it without hardware offload is bad for battery life. You want a small set of standards to implement in hardware because verification costs are high and hardware timelines are long. I might buy the argument for audio, since often people put mobile devices in low-power states playing audio. I am far less convinced for still images, where the decoding costs are now fairly small compared to the rest of the browser and the only cost is maintaining the decoder.
The decoding cost is not the issue, it’s the maintenance overhead and security risk which has to be justified.
If you want the proposed format to be included on purely technical grounds, then it needs to be so much better that not including it is essentially unthinkable, and that’s a very high bar to clear e.g. zstd content-encoding is currently nowhere, despite being way superior to gzip for on-the-fly compression (and competitive though marginally worse than lz4 and br at the lower and upper extremes of compression ratio, if with much better decompression throughput than brotli), because while it’s way superior it’s not overwhelming enough for any of the major actors to be convinced.
The best ways to get the format in are largely political:
Sorry for the delayed reply, lobster’s exciting approach to saying you have replies strikes once more! :D
I’m not concerned about the performance cost of including additional decoders. It’s purely security: I don’t believe a single image decoder that has been exposed to the web has not eventually seen exploitation, and the generally unused ones are particularly egregious as those formats don’t get the same level of scrutiny or testing. If an image format is not extremely widely used, the cost:reward balance tends very quickly to removal. This isn’t a hypothetical: numerous full RCE exploits against safari have been via rare formats being exposed to the web. Similarly, modal image formats where some modes are significantly rarer or share little logic with primary paths have the same problems.
Re: hardware decoding - I believe apple uses the gpu to decode JPEGs, but I do recall there being some talk about there being actual JPEG specific hardware in early generation iPhones, but that memory is very murky, very old, and may just be me merging in the incessant AVIF/HEIC zealots rambling about hardware decoding for those formats so that’s something that gets a grain of salt. Also obviously if JPEG-XL had won, then any hardware decode support would be for JPEG-XL rather than AVIF/HEIC (though as I understand it AVIF/HEIC can ostensibly make use of a bunch of the video decode logic directly which obviously would help).
I have no idea why the FSF has the hots for JPEG XL and at this point, I’m afraid to ask.
I’m a semi-avid photographer and I don’t know how to produce a JPEG XL image. I think there’s both a demand and a supply problem for the format.
Don’t know about the FSF, but I have the hots for JPEG-XL because $WORK has over 1tb/day egress of user-supplied images in jpeg format. Being able to shrink that by 30% with no loss of quality would be a huge win!
It suddenly occurs to me that a cloud provider who charges people for egress would have no incentive to fix
problemsrevenue sources like that.That might be the case, but while the company @danielrheath works for deals with image data, I have to imagine that for a generic cloud provider video bandwidth dwarfs image bandwidth (if we’re talking media). The big wins are in making video encoding more effective.
if you control the receiver in any form, Lepton might be of interest
This is because the format is still brand new, and also because the lack of adoption by the most popular application for consuming the largest distribution network for images. This is why JPEG XL’s removal from Chrome seems suspiciously premature: the bitstream and file format for JPEG XL was finalized last year, but the reference implementation isn’t stable yet.
As for why people are excited about it, there are a lot of reasons which point to companies with big investments in image delivery being able to save significantly on bandwidth costs without losing quality, as @danielrheath pointed out. I’m one of the few small-time users with a legitimate interest in JPEG XL that goes beyond the comparatively marginal benefit of saving some of my personal disk space, because it offers uniquely good set of characteristics for my use-cases as a photographer. In increasing order of esotericism:
I usually edit and save my photos these days assuming they’ll be viewed on a wide gamut display with at least Display P3 capability. Regular old JPEG can do this, but the colour space information is stuffed into EXIF data rather than being intrinsic to the file format, and zealous EXIF stripping programs on various websites sometimes delete it, so the colours in the picture look wrong. Also, regular old JPEG is limited to 8 bits per channel, which starts to get quite thin as the gamut increases. Admittedly, AVIF and WebP are ‘good enough’ at this.
I work with scans of medium format and large format film, in the range of tens of thousands of pixels per image dimension. Regular old JPEG is limited to 65k pixels per side, and newer formats – especially AVIF, based on a format designed for video with much smaller dimensions – are actually worse than old-school JPEG at this, and can only ‘cheat’ very large images by gluing them together side by side, so you lose the advantages of being able to share compression information between ‘panels’ of an image, an effect that gets worse as pictures get larger. There may also be visible artefacts between panels because the transition can’t be smoothed over by the compression algorithm effectively. JPEG XL natively supports up to a thousand million pixels per image side.
I also sometimes work with photos with transparency. Among older formats, JPEG can’t do this at all, and PNG only offers lossless compression which isn’t intended for photographic data and thus makes absolutely huge files when used for it. Again, AVIF and WebP are probably ‘good enough’ at this, but for some applications they suck because afaict you can’t have transparency in a CMYK image for them, so if I’m preparing an image with transparency for press, there’s no format for that.
Thanks a lot for taking the time to listing these pros for JPEG XL!
It’s interesting that according to the wiki page for the format, both Adobe and Flickr (after the SmugMug purchase?) were on the JPEG XL train.
Thank you for sharing. If I’m understanding correctly, the removal of JPEG XL from Chrome wouldn’t really affect most of your personal use-cases then, right? For instance, I can’t imagine you’d be inlining any billion-by-billion pixel images on a web page.
Your points are all valid yet entirely pointless on the web (CMYK? billion pixels in each direction?). JPEG-XL could make inroads in print, design, arts etc without thinking about Chrome even once. Yet it seems that there isn’t much enthusiasm in supporting it and its unique features in that space. How is that Chrome’s fault?
That seems more of a self-imposed hegemony: “We only look at the format for any use case once Chrome supports it. Bad Google!” In my opinion that’s a weird notion of “free as in freedom”.
The question was why people are interested in JPEG XL, especially from the perspective of a ‘semi-avid photographer’. I acknowledged explicitly that I benefit unusually extensively from JPEG XL compared to other individual photographers, and pointed to another answer in this thread that makes a more compelling case that’s very relevant to the web. I would also say that each of my points contains something less unusual that actually is relevant for the web (e.g. it’s not that uncommon for images larger than 4K, the maximum size for one panel of AVIF data, to be posted on the web).
Also, JPEG XL is actually beginning to see adoption outside of web browsers for these use cases. But that wasn’t the question I was answering here.
Because that’s Google’s line, not reality. Read the issue thread and note how many voices there are (from major companies) speaking against the decision to remove it.
“to remove it” - an experimental feature behind a flag. Nobody seriously used that capability, ever. How many of those opposing the removal in the issue thread are even aware of that instead of just joining the choir?
So where’s JPEG-XL support in Edge, Firefox, Safari? Where’s the “10% of the web already use a JPEG-XL decoder polyfill until Chrome finally gets its act together and offers native support” article?
This entire debate is in a weird spot between “Google (Chrome) force developments down our throats” (when something new does appear, such as WebUSB, WebMIDI, WebGPU, …) and “We have to wait until Chrome does it before everybody else can follow”.
That’s kind of the point. It wasn’t even given a chance to prove itself. This was very premature and came out of nowhere just as JPEG-XL was starting to gain attention. Why is it so hard to understand why people are frustrated by this? I guess I just don’t understand why you’re against it, or feel the need to suggest that people against the removal are just ‘joining the choir’. Maybe people do really care?
I don’t know what this has to do with any other web technology. I would take JPEG-XL over any of those (not that’s that’s really relevant).
Right, JPEG-XL hasn’t got a chance to “prove itself” by becoming part of the standard feature set of Chrome because it was never put in front of ordinary users (it’s always been behind a flag).
Every other time that Chrome unilaterally decides to put something in front of ordinary users, people claim that this is just an example of Chrome’s web hegemony. That would have happened with JPEG-XL, too.
What should happen for healthy web standard evolution:
For some odd reason, JPEG-XL advocacy starts at step 4, simultaneously arguing that Chrome shouldn’t be the arbiter of what becomes a web standard and what doesn’t, and not doing any of the other work. (edit to add: meanwhile it ignores all the other actors on the web who don’t support JPEG-XL, either.)
To me that looks like JPEG-XL advocates were expecting Chrome to implement the format, take the heat for “forcing more stuff on people” (as always happens when Chrome unilaterally adds stuff), then have everybody else follow. That’s a comfortable strategy if it works, but I don’t see why JPEG-XL should have a right to this kind of short cut. And I don’t see how “Chrome didn’t employ its hegemony to serve our purpose” is a sign of “how the web works under browser hegemony.”
So: where are the Polyfills? Where are the Adobes, Flickrs and everybody using them, with blog posts documenting their traffic savings and newly enabled huge image features, and that “x% of the web runs on JPEG-XL”?
And, to keep that line of thought a bit separate, as its own post:
I don’t so much mind JPEG XL folks doing that. That means that they’re working in a world view that presumes such a web hegemony by Chrome. I disagree but given that it’s xPEG, they probably can’t think any other way.
The FSF, however, should be well aware how stuff like this ought to work…
Okay, so it’s more about web standards being fast tracked without proper procedure? I can definitely appreciate that.
The way Google has gone about this though is not just removing an existing experimental flag for a feature that actually has (or had) a good chance of getting in had it just been given time, but did so in such a way that made it sound like the decision was final and there would be no way back from it, while providing such a weak/misleading explanation that it seemed pretty obvious there must be an ulterior motive. Especially when they didn’t even acknowledge the flood of companies showing an interest and clearly proving them wrong. If even they can’t convince Google to think twice, then clearly they aren’t interested in having an honest discussion.
Personally I don’t mind how long it takes for the web to adopt JPEG-XL. I would have been all too happy for it to have gone through the process you describe (although I’m not sure how realistic it is that the major players would use a polyfill for something like this). What’s frustrating is that the way they did handle it may have effectively killed any chance it had prematurely rather than allowing it to gain traction slowly and naturally.
Edit: And I really want to be wrong about that. I hope that there is a way back from this.
To some degree, but not only. The other aspect is that all those organizations chiming in on the issue tracker talk the talk but don’t walk the walk. There are numerous options to demonstrate that they care about a JPEG-XL deployment and that kickstart JPEG-XL on the web. I haven’t seen much in that space (see above for ideas what they could do, that nobody working on Chrome could block).
What I’ve seen are complaints that “Mighty Chrome is taking our chance at becoming part of the web platform!” and that seems more like a pressure campaign that Somebody Else (namely: the Chrome folks) should invest in JPEG-XL and bear any risks (whatever they might be, e.g. patent encumbrance issues) without doing anything themselves.
And that’s a pretty clear sign to me that nobody actually cares - it’s not just “Google’s line”.
Again: Talk is cheap. Chrome’s JXL support was barely beyond “let’s see if it compiles”, given that it was behind a flag. If all these parties who “care so much” truly care and make JXL-on-the-web a thing, I’m quite sure that Chrome will change course and reintroduce that code.
And unlike with IE6, it won’t take 15 years between Chrome finally introducing native support and everybody being able to take out their polyfills because Chrome has an actual planned update process. My guess is that Safari would be the last hold-out, as is usual.
If you work with RAWs and darktable (free software and multi platform), you can export your pics into JXL files (and choose parameters) ;)
It’s a bit slow though (compared to JPEG), but still faster than exporting AVIF, which is also supported.
As for me, the standard image viewer included with Fedora supports JXL too.
I work with RAWs but I don’t use darktable. I used to use Lightroom but am trying out alternatives.
Anyway I publish to Flickr and AFAIK they don’t support to format. This goes back to the original point I guess, browsers not supporting it.
What is the problem with AVIF exactly? Is it that it has some patent on it that could potentially make it harder to write or distribute GPL code that handle the format?
I don’t see any issues with AVIF from Free Software perspective. It already has multiple open-source GPL-compatible implementations, and AV1 is royalty-free licensed. The HEIF and MP4 specs that AVIF depends on are behind ISO’s paywall, but so is JPEG XL.
With codecs there’s always some stink around software patents, but Google and Apple have shipped AVIF. I see it as an assurance, because they know that if a patent troll wins litigation against even a small victim, they’ll be on hook too for even bigger money, so they’re strongly motivated to defend AVIF for everyone.
The real issues I’m aware of are on technical merits. JPEG-XL is significantly faster to encode, compresses a bit better in high-quality range, and has some neat features like ability to losslessly convert from a classic JPEG.
But AVIF is still way better than the old JPEG and WebP. People on the web aren’t even using AVIF yet, so the JPEG XL vs AVIF battle is like Lamborghini vs Ferrari while everyone still drives a Toyota.
That’s the summary: Concerns over licensing, royalties, and patents. These things are unlikely to impact Apple, Facebook, Microsoft, or Google, but will have potential impact on “the little guys”.
Not on the legal side but AV1 requires a lot more performance to encode and decode that content creators have begged for hardware encoding of AV1 to save time. Transparent compression on JPEG and progressive decoding can make a much better experience. Folks aren’t saving images from their cameras in AVIF or WebP.
The FSF is increasingly delusional, and is assuming that there is no cost to including support for arbitrary formats regardless of actual use.
The reality is that JPEG-XL lost the “next gen” image format war, so is essentially unused. The FSF believes that supporting JPEG-XL when it is not being used doesn’t cause any harm, which is false. The history of browsers is littered with “random unused file parser had exploitable bug leading to the browser being owned”.
Then in this report itself there’s just copious dogmatic nonsense: “can’t read the bug database because of non-free js”. You absolutely can, you just don’t get to force your own licensing view on others. Recall the the FSF is relatively opposed to license freedom, preferring GPL over the much “freer” BSD or MIT style licenses.
It’s then filled with propaganda scare quotes which delegitimizes everything they’re saying by making this come across a zealot driven piece of marketing and propaganda, making any technical argument that they might have had irrelevant tot he reader. Also it has a bunch of nonsense “I don’t get the internet” stuff like quoting ‘“starred”’, which further just makes them come across as idiots at best - coupled with the standard “lots of votes on an issue the triggers zealot swarming of a bug means lots of real world support”. That last point on vote swarming is something that the FSF is familiar with, so it just reinforces that the FSF is being deliberately obtuse/misleading and unethical in how it is presenting its argument.
The FSF has an important mission, and twenty years ago it was super effective, but I think its absolutely blank and white stance, coupled with its dismissal of any issue other than “does this match our personal definition of free” is causing (has caused?) irreparable harm to itself, and by proxy the actual mission.
Not to spout the dogma, but they do support the permissive Apache 2.0. They oppose BSD and MIT over unclear language and lack of a clause to address patent retaliation. (Source
Good to know!
The FSF is free and democratic, just like the Soviet Union was. I really don’t know why people criticize the FSF.
/s