FSF Says Google's Decision to Deprecate JPEG-XL Emphasizes Need for Browser Choice (fsf.org) 130
"The fact remains that Google Chrome is the arbiter of web standards," argues FSF campaigns manager Greg Farough (while adding that Firefox, "through ethical distributions like GNU IceCat and Abrowser, can weaken that stranglehold.")
"Google's deprecation of the JPEG-XL image format in February in favor of its own patented AVIF format might not end the web in the grand scheme of things, but it does highlight, once again, the disturbing amount of control it has over the platform generally." Part of Google's official rationale for the deprecation is the following line: "There is not enough interest from the entire ecosystem to continue experimenting with JPEG-XL." Putting aside the problematic aspects of the term "ecosystem," let us remark that it's easy to gauge the response of the "entire ecosystem" when you yourself are by far the largest and most dangerous predator in said "ecosystem." In relation to Google's overwhelming power, the average web user might as well be a microbe. In supposedly gauging what the "ecosystem" wants, all Google is really doing is asking itself what Google wants...
While we can't link to Google's issue tracker directly because of another freedom issue — its use of nonfree JavaScript — we're told that the issue regarding JPEG-XL's removal is the second-most "starred" issue in the history of the Chromium project, the nominally free basis for the Google Chrome browser. Chromium users came out of the woodwork to plead with Google not to make this decision. It made it anyway, not bothering to respond to users' concerns. We're not sure what metric it's using to gauge the interest of the "entire ecosystem," but it seems users have given JPEG-XL a strong show of support. In turn, what users will be given is yet another facet of the web that Google itself controls: the AVIF format.
As the response to JPEG-XL's deprecation has shown, our rallying together and telling Google we want something isn't liable to get it to change its mind. It will keep on wanting what it wants: control; we'll keep on wanting what we want: freedom.
Only, the situation isn't hopeless. At the present moment, not even Google can stop us from creating the web communities that we want to see: pages that don't run huge chunks of malicious, nonfree code on our computers. We have the power to choose what we run or do not run in our browsers. Browsers like GNU IceCat (and extensions like LibreJS and JShelter> ) help with that. Google also can't prevent us from exploring networks beyond the web like Gemini. What our community can do is rally support behind those free browsers that choose to support JPEG-XL and similar formats, letting the big G know that even if we're smaller than it, we won't be bossed around.
"Google's deprecation of the JPEG-XL image format in February in favor of its own patented AVIF format might not end the web in the grand scheme of things, but it does highlight, once again, the disturbing amount of control it has over the platform generally." Part of Google's official rationale for the deprecation is the following line: "There is not enough interest from the entire ecosystem to continue experimenting with JPEG-XL." Putting aside the problematic aspects of the term "ecosystem," let us remark that it's easy to gauge the response of the "entire ecosystem" when you yourself are by far the largest and most dangerous predator in said "ecosystem." In relation to Google's overwhelming power, the average web user might as well be a microbe. In supposedly gauging what the "ecosystem" wants, all Google is really doing is asking itself what Google wants...
While we can't link to Google's issue tracker directly because of another freedom issue — its use of nonfree JavaScript — we're told that the issue regarding JPEG-XL's removal is the second-most "starred" issue in the history of the Chromium project, the nominally free basis for the Google Chrome browser. Chromium users came out of the woodwork to plead with Google not to make this decision. It made it anyway, not bothering to respond to users' concerns. We're not sure what metric it's using to gauge the interest of the "entire ecosystem," but it seems users have given JPEG-XL a strong show of support. In turn, what users will be given is yet another facet of the web that Google itself controls: the AVIF format.
As the response to JPEG-XL's deprecation has shown, our rallying together and telling Google we want something isn't liable to get it to change its mind. It will keep on wanting what it wants: control; we'll keep on wanting what we want: freedom.
Only, the situation isn't hopeless. At the present moment, not even Google can stop us from creating the web communities that we want to see: pages that don't run huge chunks of malicious, nonfree code on our computers. We have the power to choose what we run or do not run in our browsers. Browsers like GNU IceCat (and extensions like LibreJS and JShelter> ) help with that. Google also can't prevent us from exploring networks beyond the web like Gemini. What our community can do is rally support behind those free browsers that choose to support JPEG-XL and similar formats, letting the big G know that even if we're smaller than it, we won't be bossed around.
Some perspective... (Score:3)
Maybe I've heard once or twice about JPG-XL, never ever have come across an image in such format. And when I heard of it, I never even tried to work with it after the fiasco with JPEG 2000 working times and their draconian licenses.
I've heard more than twice of QOI, and I've come across some images in such format. In fact, I've installed support for it in various programs and works (limited to what it is) like charm.
Will Chrome support QOI? Why not work on a QOI format (frozen forever) based instead?
Re: (Score:3, Insightful)
Maybe I've heard once or twice about JPG-XL, never ever have come across an image in such format.
Yep. This is a non-issue, nobody uses it.
Will Chrome support QOI? Why not work on a QOI format (frozen forever) based instead?
Let's hope not. The fewer "standards", the better. We're having enough trouble getting people to use webp.
ObXKCD: https://xkcd.com/927/ [xkcd.com]
Re:Some perspective... (Score:4, Informative)
JPEG-XL is great for archival storage of JPEGs, as it can losslessly and surprisingly quickly transcode them and gain ~25% extra compression. Honestly, it's just a great format in general, much better than AVIF IMHO, which is slow and under some license threats.
If browsers were to maintain JPEG-XL support, it could have led to a scenario where servers with caching proxies could store images in JPEG-XL format, and when requesting browsers support JPEG-XL, deliver the images directly, and if not, deliver a quickly JPEG-converted version from the caching proxy. This could in turn have had a snowballing effect toward increasing support and usage of the (excellent) JPEG-XL format. But with Google dropping support, this kills the likelihood of this happening.
Re: Some perspective... (Score:3)
Re: (Score:2, Informative)
I don't think that is true anymore. JPEG lists various patents that apply and they all expired a few years back. Unless there is another more recent patent that applies to JPG, I think it is as unencumbered, at this point, as GIF is.
Re: (Score:2)
But JPEG-XL isn't license free. It's based on JPEG which also isn't license free.
Why would JPEG require any sort of license? The standard was released in 1992. Any patents on that standard expired more than a decade ago.
Specific *implementations* are licensed, but the standard itself can be freely reimplemented at this point.
Re: (Score:3)
and gain ~25% extra compression
25% of fuck all is still fuck all. The problem is ... there's no real problem to be solved. JPEG itself is fine. It very much does the job, and situations where it doesn't are complete edge cases. JPEG itself was fine even back when our modems made noises when we connected to the internet, so with my connection now being literally 10000x faster, what's the use case to save 25% bandwidth on a JPEG?
I think an entire weeks worth of web browsing is easily blown away by watching a single Youtube video. Hell Java
Re: Some perspective... (Score:2, Informative)
Re: (Score:2)
It's pretty bad that jpegs are only 8bit.
JPEG XL is way more flexible that the old JPEG standard. Channels can have up to 24-bit integers or 32-bit floats per pixel. Then you can have from a single monochrome channel up to thousands of channels per image, supporting RGB, CMYK, etc., and many colour spaces including HDR support.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Web sites could include the images and have some code to inform the user "Your web browser is broken due to missing JPEG-XL support. Try using Firefox instead." - If Facebook or Twitter did this, then it might even cause Chrome to lose users.
Re: (Score:2)
Web sites could include the images and have some code to inform the user "Your web browser is broken due to missing JPEG-XL support. Try using Firefox instead."
When people see these kinds of messages, they don't chose a different browser, they choose a different website.
Cross-Origin Resource Sharing (Score:2)
Images decoded by a polyfill in the browser must be from either the same origin or an origin that specifically allows the page's origin. Only the web browser itself has privilege to decode and display images that do not satisfy CORS, and this lets a website operator set restrictive policies on image transclusion (aka "hotlinking") by operators of other websites.
Re: (Score:2)
I don't want fucking webp. If a URL ends in ".jpeg" I should get a fucking jpeg.
That's not an issue with webp, that's an issue with websites being too lazy to use the picture HTML element.
Re: (Score:3, Informative)
QOI doesn't seem interesting enough to me. It is advertising "faster" encoding and decoding speed than old PNG, with size similar to PNG. The bottleneck of current web is not client nor server CPU time in handling static lossless images. It is too small a niche for mainstream browsers to care.
JXL isn't just a "better" JPG like what JP2 promoted. The most important feature of JXL is it offers a transcoding from existing JPG into JXL reversibly. If JXL gains mainstream software support, any images that are
Re:Some perspective... (Score:4, Interesting)
I like the QOI story quite a bit. Seeing how complicated popular image formats are, one guy sets out to make something much simpler. Easy to understand, easy to implement, and fast. Despite the incredible simplicity, it turns out that his format is ... quite okay. Other formats, it turns out, don't really gain all that much in exchange for the added overhead and complexity. I see it as huge victory for simplicity in this age of needless complexity.
Snappy compression seems to be in a similar spirit. Simple and high-speed.
Re: (Score:2)
It's a compression system, not a format, and it works exclusively with 24-bit color. Think of it as the imaging equivalent to Javascript. The author explicitly ignored any feedback and released the spec quickly, because he didn't give a damn about the criticism.
Among those of use who understand and work with imaging systems, QOI is awful.
Re: (Score:2)
If "ecosystem" is the excuse that Google uses to drop support for JPEG-XL, then there's no way they'll support QOI with even less ecosystem around it.
They already have AV1F. If they're going to ignore the wishes of some developers for JPEG-XL, then they're going to ignore your wishes for QOI too.
Here's the thing - if you don't support other developers when they want their formats to be included, don't expect other developers to support your wants either.
Re: (Score:2)
"Here's the thing - if you don't support other developers when they want their formats to be included, don't expect other developers to support your wants either."
Sounds good. Meritocracy please.
Re:Some perspective... (Score:5, Interesting)
Re: (Score:2, Troll)
I'm not. Formats with nicer features and better compression than JPEG are dime a dozen. They all share one thing in common: No one cares. They aren't solving a core problem people have. AV1 is solving one (multiple in fact), not the least of which is the bandwidth used by video is actually relevant.
Re: (Score:2)
Maybe I've heard once or twice about JPG-XL, never ever have come across an image in such format.
How would you know? Is your web browser set to alert you whenever it displays one?
What Google wants, Google gets (Score:4, Insightful)
all Google is really doing is asking itself what Google wants...
Seen that in IETF standards meetings, you go into a meeting and there's Google posters on the walls, everyone is wearing Google t-shirts, the food and drinks have a "Sponsored by Google" sign over them... gee, I wonder what 90% of the standard we're about to vote on will be pandering to?
The weird thing is that this sort of behaviour is what saw Microsoft hit with years of antitrust action. Why isn't it happening with Google, who are far more egregious than MS ever were?
Re: (Score:2)
Microsoft got let off with a handslap.
Gates, who ran the company while it did all those things, got to keep all his money.
Nobody "hit" Microsoft.
Re: (Score:3)
The weird thing is that this sort of behaviour is what saw Microsoft hit with years of antitrust action.
No it wasn't.
Why isn't it happening with Google, who are far more egregious than MS ever were?
Because it never happened to Microsoft either. At no point were did MS ever lose (I'm not sure they ever even fought) an antitrust suit over not including 3rd party support for standards, or for pushing their own standards. They fought and lost an antitrust suit for a completely different reason, but the "Designed for Internet Explorer" didn't even remotely factor into the case.
Re: (Score:2)
The weird thing is that this sort of behaviour is what saw Microsoft hit with years of antitrust action. Why isn't it happening with Google, who are far more egregious than MS ever were?
While Microsoft owned your desktop and your office productivity, Google owns your search&browsing history. They can cut anyone's career short if they so choose, that's why no politician would even think of putting up a fight against them, campaign donations or not.
Jpeg-XL vs WebP vs AVIF (Score:2)
Personally, I never used nor remember having saw a JPEG-XL picture.
I see WebP happily replacing Jpeg AND PNG AND GIF thought.
I wonder how an open, royalty-free image file format should not be desirable (see https://en.wikipedia.org/wiki/AVIF )
Re: (Score:2)
I see WebP happily replacing Jpeg AND PNG AND GIF thought.
I can't say that, when I've looked, I've seen WebP used for much of anything save on Google properties. JPEG, PNG, GIF, and (more recently) SVG pretty much rule the roost.
Re: (Score:2)
It's now reached nearly 8% of internet image traffic, and continues growing quickly.
It took many years of browser support to reach the point where WebP support was widespread enough, however. And the complaint in this article is that with Google dropping JPEG-XL support, this will never happen with the far-superior JPEG-XL.
Re: (Score:2)
FWIW I'm betting that "8%" (assuming it's real) is due to AMP pages - which basically amounts to a Google property.
Re: (Score:2)
Re: (Score:2)
WebP is older and thus has much wider browser support, hence its progressive takeover.
It's also heavily inferior to JPEG-XL in almost every respect.
If you drop browser support, you prevent a format from ever getting to the "takeover" stage that WebP is entering.
Re: (Score:2)
There is no browser choice (Score:2)
Bad summary (Score:4, Insightful)
Re:Bad summary (Score:5, Informative)
Source [tonisagrista.com]
Re: (Score:2)
I'm pretty sure the human eye cannot distinguish between adjacent shades of color on a 32-bit channel. IIRC the eye is capable of distinguishing adjacent shades at somewhere between 8-12 bits on a channel.
Re: Bad summary (Score:2)
32-bit per channel graphics is a bit of a misnomer. It uses a 32-bit float for each channel instead of the usual 8/10 bit unsigned integer. Furthermore, the value must be between 0 and 1 in order to display as anything other than 0% or 100% of that color. Its real utility is in high dynamic range situations, where overshooting the mark actually means something. In ordinary situations you just get the equivalent of an unsigned integer with the same bits as the mantissa, which for single-precision (32-bit) fl
Re: (Score:2)
The extra bits are useful when the image might be manipulated later (think gamma correction, color shifting, colorspace translation, image layering,...). If the precision of the color doesn't have an exact one-to-one match with the result, you get a rounding error. If that kind of conversion happens a lot, that error compounds and can become noticeable. The extra precision allow that rounding error to remain below the perception threshold, even when (reasonably) compounded.
This is the same reason that profe
Re: (Score:2)
Having more bits will allow storing high dynamic range images. For example, the light outside might be 100 times brighter than the lighting inside your apartment, yet we can perceive the interior and the view at the same time. If you took an 8-bit photo with decent exposure for the view, the interior would be rendered in 1-bit definition (i.e. black with some noise...) To store everything your eye can see requires either multiple exposures, or for more convenience, more bits.
Re: Bad summary (Score:2)
Re: (Score:2)
Wikipedia's page on it has some notes on adoption:
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:3)
Boy, if you think JPEG XL performance is slow, try AVIF for the same compression level...
Re: (Score:2)
I wonder if GPU decoding might help, but the overhead to set it up is probably too high. In any case older devices won't support that.
Re: (Score:2)
Google is actively hostile to older devices, so that's a benefit in their book
Re:Bad summary (Score:5, Informative)
I'm seeing significantly better performance than that.
My test set is 21 images, which total 83.0 MB when converted to JPG at q=85. Losslessly transcoding them to JPEG-XL brings their size down to 69.7 MB; 16% smaller. The .jxls are about 1.6x slower to decode (4.3s vs 7.0s of CPU time).
But... that's CPU time. Unlike the JPEG decoder, the JPEG-XL decoder is multi-threaded -- and quite good at it too. It'll happily use all 2400% CPU of my widest machine without breaking a sweat. The wall clock time for those measurements was 4.5s and 2.5s respectively, on a quad core machine. So it's actually faster in terms of waiting time.
Encoding the images directly from the source to .jxl at q=85 (which is supposed to be roughly equal in quality to JPEG at the same q) gives a total size of 39.3 MB, and the images take 9.5s CPU and 3.3s wall time to decode. The extra native JPEG-XL features slow it down a bit, but give significant space saving and it still takes less wall time to decode them.
I did notice that imagemagick's decoder is both slow and single-threaded: 14.5s to decode the transcoded set, about 3.5x slower than .jpg. That's a problem, given how prevalent it is in image processing pipelines, but at least browsers don't use imagemagick.
Re: (Score:2)
I have a few test images, losslessly transcoded I see about 15% improvement on size as well.
Decoding though... My CPU is an old i7 2700k, so it's possible that newer ones are able to use a more efficient code path with better vector instructions. However, decoding the same image as JXL is around 8x more real time than JPEG on average. It's worse on small images because libjxl uses fewer threads. Larger images where it can hit all cores end up using less real time (but obviously much more CPU time).
I haven't
Re: (Score:2)
Ah, that would do it: "JPEG XL decoder v0.9.0 [AVX2,SSE4,SSSE3,Unknown]", on an i5-6600k. I didn't compare decoding, but for encoding AVX2 is a significant speedup over SSE4. Your CPU only has AVX (which I'm not sure is even supported by libjxl?).
It can do much better on some images, particularly in lossless mode: a random screenshot of my desktop goes from 827 kB (crushed PNG) to 445 kB, 46% smaller. In fact it goes all the way to 389 kB at -e9 instead of the default -e7, but the encode time explodes (3s t
Re: (Score:2)
Thing is many devices don't have those vector instructions. Mobile devices in particular. The decoding overhead is going to be a big issue on mobile browsers.
Re: (Score:2)
It does support NEON, which I think is common in mobile devices. With the amount of cores modern mobile CPUs have, JXL can probably keep up.
But... what about the energy cost? Spending energy for speed is great on a desktop, but on mobile? Then again, it might actually require less power to multithread on a wide CPU running at an efficient clock speed than to design a CPU that burns tons of power to get high single-thread performance. And if battery life is good enough anyway, people might prefer better perf
Re: (Score:2)
Most mobile chips have a few cores with NEON support, or at least one. The low power cores usually omit it. I don't think it's all that useful for decoding JPEG and PNG anyway.
Maybe that's the issue, that current CPUs are tuned more towards decoding older formats. That makes it very hard for new formats to gain a footing.
Re: (Score:2)
You can losslessly transcode normal JPEG to a file about 20% smaller, but it takes around 8x longer to decode.
Given how fast JPEGs are to decode now on even slow hardware, that seems pretty reasonable. I just made a 25600x2560 sized JPEG. ffmpeg can decode them in about 0.8 seconds each, giving about 85 megapixels per second. 8x is still pretty fast not going to be much of a bottleneck.
Re: (Score:2)
I've been working with JPEG XL for a while and I can see why Google ditched it. Performance is very poor. You can losslessly transcode normal JPEG to a file about 20% smaller, but it takes around 8x longer to decode.
JPEG XL decodes faster than JPEG.
Websites would love the bandwidth saving, but the poor performance and affect on battery life won't be appreciated by users.
More than a little over the top.
Re: (Score:2)
Do you have any benchmarks showing JPEG XL decoding faster than JPEG?
Also are we talking about newer CPUs with things like AVX2, or is this for all x86/ARM CPUs?
Mozilla has also been guilty of this (Score:4, Interesting)
When it comes to making decisions which affect people - and ignoring objections by their user base - the people behind Firefox have multiple "prior"s. There is a reason why Palemoon forked off Firefox, there is a reason why people abandoned Firefox for Chrome and it is not just down to performance.
This dropping support for a little used format is not a big issue for me, far more annoying is all the Javascript extensions which are then adopted by website creation software and mean that browsers like Palemoon have to run faster and faster to stay in place.
+1 for Pale Moon (Score:2)
I have to use Firefox for two or three websites which have parts not implemented in Pale Moon (yet?), but otherwise I don't use it.
I'm glad Pale Moon didn't go the multi-process route like the others with good reason, as it is the only browser that doesn't gobble up the 4GB RAM in my laptop all by itself.
Re: (Score:2)
The reason why it's little-used is because it was just ratified. Google added support and killed it off in such a quick fashion specifically to prevent people from using it. My only hope is that their little stunt will cause the Streisand Effect will kick in.
Actual comparison and options (Score:5, Interesting)
Based on this: https://tonisagrista.com/blog/2023/jpegxl-vs-avif/
It seems that JPEG-XL is usually superior to AVIF mostly for lossless compression. Having it as an option, especially without the patents, would be a big boon.
The claim about ecosystem is a red herring. With CDNs you only need two pieces to get widespread use: CDN support and browser support. If Chrome and FF don't support it then a CDN won't pick it up. A CDN has the luxury of picking up the right format for every image to reduce bandwidth costs. Giving them another option is a win for everyone. I don't see any reason for dropping JPEG-XL other than getting Google owned properties deeper in.
Re: (Score:2)
And it's faster, and it can (quickly) losslessly transcode JPEGs for greater compression, and it has no patent threats, and basically unlimited resolution, and higher max bit depth, and progressive encoding (including a neat variant where detail that draws the eye loads before detail you notice later), and on and on. It's an excellent format, which is what makes this so annoying.
It's argued that AVIF outperforms JPEG-XL in compression at very low bitrates (we're talking quality factor = 0.4), but that does
Re: Actual comparison and options (Score:2)
Re: (Score:2)
Citation needed. You're right that PNG is free, but I've never heard of patents on JPEG. And JPEG has been around for quite some time, so any patents that might have been on it when it was created have to have expired by now. Or they are invalid by the prior art of JPEG itself.
Maybe you are thinking of JPEG2000? I'm not sure if there are any active patents on it, but IIRC parts of the J2K spec are not free (though the base spec is free).
So we're back at IE6 (Score:4, Insightful)
Some dufus company makes some ridiculous choices and doesn't give a fuck about standards, and everyone has to bend over backwards to cater to their whims because they corner the browser market.
Really, people? We have to do that again?
Re: (Score:2)
Yes, we do. And they're going to get away with it.
AVIF is annoyingly slow, and it looks like we're not going to get anything better until we switch straight from algorithmic compression formats to neural network-based ones.
Re: (Score:2)
I made a post about this in another Slashdot article [slashdot.org] which basically said that what caused IE to lose it's market-share was it's stagnation (IE6). Not only did it have many security bugs, but it's implementation of certain web-standards was poor. FireFox came at just the right time, filled in the gap in the market, more web-developers felt confident using things that were broken on IE6, and FireFox chewed away at IE's share of the browser market.
Nowadays, Chr*me's lack of support for JPEG-XL might seem simi
Re: (Score:2)
Nowadays, Chr*me's lack of support for JPEG-XL might seem similar, but it's just one issue, compared to IE6's notorious buggyness. This might be a chance to break the hegemony of Chr*me, but for that to happen, there would have to be a lot of websites that serve content in JPEG-XL.
There would also have to be at least one browser that supports content in JPEG-XL format without having to figure out how to turn on experimental features. Right now, AFAIK, there are zero. As long as that is the case, no website will ever even try to support it.
Had either Firefox or Chrome turned it on by default (and regularly tested it to make sure that it didn't break), the story might be different, but....
Re: (Score:2)
Re: (Score:2)
You can say Chrome. It's not like god, it won't smite you for using its name in vain.
Re: So we're back at IE6 (Score:2)
This is the kind of stuff that made me go Linux (Score:2)
And since the web has become a larger part of my daily computer use this all sounds so familiar.
Re: This is the kind of stuff that made me go Linu (Score:2)
Re: (Score:2)
Re: (Score:2)
That's why I run Microsoft Edge on Linux, along with MSSQL on Linux. It's just so unexpectedly bizaare that I can't resist.
Community Versus Money (Score:2)
The problem is so deep yet so simple. Nevertheless, lets make it about something else so we can continue to make money number one.
Scrod (Score:2)
I was listening until the middle of the first quoted paragraph. Then it became an obvious, motivated screed against Google.
Chromium Ends JPEG XL (Score:2)
I never heard of JPEG XL before, but came across this video [youtube.com] a few months ago.
It's very well explained why no JPEG XL would be a big loss for everyone.
Chrome still supports plugins (Score:2)
The PPAPI architectural underpinnings are still there. If there is enough support for JPEG-XL, a plug-in can be written for it.
Re: (Score:2)
Is there a Web Assembly decoder?
Re: (Score:2)
There is JXL.js [github.com]. It shares the same disadvantage as other image decoder polyfills that Cross-Origin Resource Sharing is required for cross-origin image display.
Microsoft patents rANS (Score:3)
https://jpegxl.io/articles/ran... [jpegxl.io]
Eek.
"Microsoft obtained the patent for ANS-Coding after a failed attempt by Google."
"Microsoft did not create ANS, but Jaroslaw (Jarek) Duda, a researcher at the University of Krakau. Due to Duda's own desire to never patent or otherwise protect ANS, his work is available on the Arxiv repository. Several years ago, the information scientist criticized Google's attempts to register a patent on ANS. Google's application for the patent was rejected as well.
A patent has been granted to software giant Microsoft after years of trying to obtain one from the US Patent Office. Several variants of the coding procedure Asymmetric Numerical Systems (ANS) may be found in most modern codecs, such as AV1, Z-Standard compression, or even rANS in JPEG XL."
"Furthermore, Duda emphasizes that rANS is being used in JPEG XL, delivering significantly better compression and quality than the 30-year-old JPEG. The JPEG XL work has mainly been completed and standardized. The format will gain widespread adoption as a license-free file format, including web browsers and operating systems. Duda fears that Microsoft's patent will significantly hinder this development."
Re: (Score:2)
Here is a link to the patent [freepatentsonline.com], which is surprisingly not provided in the article you linked to, but only further down in the referenced Reddit thread. The patent does not cover Prof. Duda's invention itself, but only some improvements or hardware based optimizations. Yes, it's a pain, that anyone implementing JPEG-XL must now walk through that minefield of patents, but that comes with any popular technology.
Chrom* (Score:3)
>"The fact remains that Google Chrome is the arbiter of web standards, [...] deprecation of the JPEG-XL image format in February in favor of its own patented AVIF format"
I have been screaming about this for years. We are in a VERY dangerous situation now. The new era of Internet Explorer, where one company controls the "standards" and breaks compatibility with everything else, is happening. Essentially, all multi-platform browsers that are NOT Firefox are based on Chromium, and are therefore, in many ways, just a single browser, which I call "Chrom*". And its market share is shocking.
Chromium, itself, might be open-source, but:
1) Nobody controls this source but Google.
2) It is not really an open development or contribution model.
3) There is no community or standards-based adherence or governance.
4) Unlike when using Firefox, when using Chrom*, most people are using a proprietary, hidden-source, different binary.
This latest JPEG-XL issue is obscure, but that is not the point. This isn't the first time, and it won't be the last that Google has passed dogma on the web. And it isn't just about "standards", it is extremely dangerous from privacy, security, innovation, and freedom standpoints to have a single browser base.
You can fight back before it is too late:
1) Use Firefox as your browser.
2) Complain LOUDLY to any site management that doesn't work perfectly in Firefox or "recommends Chrom*." It doesn't take much effort to write an Email once and a while.
3) Your money (and eyes/usage) speaks volumes- don't partake in services that restrict your browser choice.
4) If you are a web developer, ALWAYS also test against Firefox and open/real standards. And don't ever use any "feature" that is Chrom*-only.
5) Disspell false information about Firefox being slower, "uses more resources", or is "less reliable" because those are simply not true, and hasn't been for many years.
6) Spread the word about the above, and also that using Edge, Opera, whatever, is still essentially using Chrome.
Yes, your single decision makes an impact. I have seen companies and organizations change their stances on these issues in a positive way due to feedback. Although we desperately need to retain two different, strong, mult-platform browsers, and Firefox does fill that role, three would be even better. Unfortunately, there is nothing on the horizon yet.
Electron (Score:2)
2) Complain LOUDLY to any site management that doesn't work perfectly in Firefox or "recommends Chrom*." It doesn't take much effort to write an Email once and a while.
Does "recommends our Electron-based desktop application" count as "recommends Chrom*"? I ask because I've noticed that a small number of features are missing from the Discord.com chat service under Firefox.
Re: (Score:2)
>"Does "recommends our Electron-based desktop application" count as "recommends Chrom*"? I ask because I've noticed that a small number of features are missing from the Discord.com chat service under Firefox."
That is a more ambiguous example. Not exactly browser. Still somewhat annoying. I am not really a fan of embedding browser technology to make pretend "applications." But Mozilla does have Brick (seemingly with not a lot of movement behind it):
https://github.com/mozbrick [github.com]
https://www.hongkiat.com/b [hongkiat.com]
Re: (Score:2)
2) Complain LOUDLY to any site management that doesn't work perfectly in Firefox or "recommends Chrom*." It doesn't take much effort to write an Email once and a while.
I'm already seeing the push back. I have Chrome on a tablet. I navigate to a site and get a message "Your browser is not supported" and a link to Firefox, Safari and Chrome installation sites. So, I humor them and install Chrome (from the Google Play site) and try again.
"Your browser is not supported".
Google might be the 800 pound gorilla, but the bonobos are hiding the bananas and Harambe hasn't figured out the keep-away game yet.
Extensions; Chrome on outdated Android (Score:2)
I have Chrome on a tablet. I navigate to a site and get a message "Your browser is not supported"
I have a couple guesses as to why that may be happening. Which is closer to your case?
A. You are viewing the official website of a browser extension using Chrome for Android, which does not support extensions.
B. You are viewing a website using a tablet running an Android version prior to Android 7 "Nougat", and the application on that website relies on one or more features introduced in newer versions of Chrome. The system requirements page [google.com] claims that Google no longer updates Chrome for Android versions pr
Re: (Score:2)
A. You are viewing the official website of a browser extension using Chrome for Android, which does not support extensions.
No. It's a financial services site.
B. You are viewing a website using a tablet running an Android version prior to Android 7 "Nougat"
No. The tablet is running Android v 11, Chrome v 111 ...
I suspect that the company's developers have given up on chasing an ever-changing platform. I can access the site with my desktop, running an ancient (and much patched) Debian 7.6 version, running a creaky old Firefox v 76. Granted, I get the popup stating that my browser is old. But I dismiss that and carry on just fine. I also have less problems with various sites running lynx v 2.8.9. Probably because it's so far
Re: (Score:2)
Radical idea (Score:2)
Re: (Score:2)
When I read the headline I first thought that JPEG-XL would be for BBW pron
Can't link to a bug report? (Score:3)
"While we can't link to Google's issue tracker directly because of another freedom issue â" its use of nonfree JavaScript"
Okay, I appreciate the goals of the FSF, but that? Pull your head out of your elitist, purist ass for just a few seconds.
Re: (Score:3)
https://bugs.chromium.org/p/ch... [chromium.org]
Ok ... (Score:2)
So, you want JPEG-XL huh? (Score:2)
Re: (Score:2)
Then find a goddamn browser other than Chrome. [...] Get off your high horse and look at the picture from business perspective. Nobody is giving you something for free. Every free horse comes with a lot of hidden expectations. You are free to reject the free browser and go with something else. [...]
Well, many people in a "news for nerds" site have another option besides changing browser:
Writting a PPAPI plugin for chrome that can render JPEG-XL
Curent web devs don't know browser wars. (Score:3)
Support browsers like Pale Moon, the first one to release JPEG-XL support: https://tech.slashdot.org/stor... [slashdot.org]
What ever happened to... (Score:2)
"Don't be evil."
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
They formally got rid of that motto around a decade ago. I guess keeping up pretenses was too much of a hassle.
But... (Score:2)
"problematic aspects"? (Score:2)
I just read the paper OP linked to. I also recently read a paper by PETA explaining how people could not ethically play games with animal characters. I could swear I was reading the same document with different buzzwords. Protip; If you want to promote a worthy cause like Free/Libre, do yourself a favor and don't link to papers whose author was high from sniffing their own farts.