Auf YouTube findest du die angesagtesten Videos und Tracks. Außerdem kannst du eigene Inhalte hochladen und mit Freunden oder gleich der ganzen Welt teilen.
JPEG is getting old long in the tooth, which prompted the creation of JPEG XL, which is a fairly future-proof new compression standard that can compress images to the same file size or smaller than regular JPEG while having massively higher quality.
However, JPEG XL support was removed from Google Chrome based browsers in favor of AVIF, a standalone image compression derived from the AV1 video compression codec that is decidedly not future-proof, having some hard-coded limitations, as well as missing some very nice to have features that JPEG XL offers such as progressive image loading and lower hardware requirements. The result of this is that JPEG XL adoption will be severely hamstrung by Google’s decision, which is ultimately pretty lame.
Monopolies don’t require 100% of a market. Just enough to effectively manipulate a market.
One firm might only be 10% of a market. But if every other firm is only 1-2%, that 10% will have an outsized monopolistic ability to manipulate that market.
AV1 Image File Format is an open, royalty-free image file format
While I am by no means trying to defend Google, or their monopoly, I’m struggling to see how this time is a “clear example” of monopolistic behaviour?
Like, take for contrast the Moving Picture Experts Group (MPEG) image format HEIC, which Apple has adopted as it’s main high-res format on iOS. It’s proprietary, and that fact is indeed worrying. However, the only reason I can figure out for Google’s move here being a ‘bad’ thing, is if you’re nostalgic about the .jpg extension…
I didn’t mean the choice of image format is a monopolistic behavior, but that the monopoly puts google in a position that any choice they make, be it a good or bad one, becomes an industry standard, without others having any choice in it.
Why not just say Rust? There isn’t really anything else that would provide good enough performance for a browser engine with modern heavy webpages while also fixing some major pain point of C/C++
Zig didn’t come to my mind when I was writing my comment and I agree that it’s probably a decent option (the only issue I can think of is its somewhat small community, but that’s not a technical issue with the language).
My argument against Go and Java is garbage collection - even if Java’s infamous GC pause can apparently be worked around with a specialized JVM, I’m pretty sure it still comes at the cost of higher memory usage and wasted CPU cycles compared to some kind of reference counting or Rust’s ownership mechanism (not sure about the proper term for that). And higher memory usage is definitely not something I want to see in my browser, they’re hungry enough as is.
Other browser vendors like Microsoft and Brave and Opera could’ve added XL support if they wanted to. It’s not just Google, none of the browser makers want to deal with yet another image format. Only Safari supports the protocol, and even then they don’t support animated images.
IE and pre-Chromium Edge implemented JPEG XR and nobody followed. Safari implemented JPEG 2000 and nobody followed. Implementing an image codec is a lot of work and adds attack surface for hackers, nobody really wants to do that unless they have to.
We have JPEG, we have WebP if you need smaller images than JPEG, and we have AVIF if you want something smaller than PNG for photographs. Unless all of the competition implements JPEG XL again, I don’t think they have any reason to bother. Especially with the whole patent vagueness.
JPEG is getting
oldlong in the tooth, which prompted the creation of JPEG XL, which is a fairly future-proof new compression standard that can compress images to the same file size or smaller than regular JPEG while having massively higher quality.However, JPEG XL support was removed from Google Chrome based browsers in favor of AVIF, a standalone image compression derived from the AV1 video compression codec that is decidedly not future-proof, having some hard-coded limitations, as well as missing some very nice to have features that JPEG XL offers such as progressive image loading and lower hardware requirements. The result of this is that JPEG XL adoption will be severely hamstrung by Google’s decision, which is ultimately pretty lame.
And here we have a clear example of how Chrome’s almost monopoly is a bad thing for us.
Not almost monopoly.
- the US govt
Monopolies don’t require 100% of a market. Just enough to effectively manipulate a market.
One firm might only be 10% of a market. But if every other firm is only 1-2%, that 10% will have an outsized monopolistic ability to manipulate that market.
While I am by no means trying to defend Google, or their monopoly, I’m struggling to see how this time is a “clear example” of monopolistic behaviour?
Like, take for contrast the Moving Picture Experts Group (MPEG) image format HEIC, which Apple has adopted as it’s main high-res format on iOS. It’s proprietary, and that fact is indeed worrying. However, the only reason I can figure out for Google’s move here being a ‘bad’ thing, is if you’re nostalgic about the .jpg extension…
I didn’t mean the choice of image format is a monopolistic behavior, but that the monopoly puts google in a position that any choice they make, be it a good or bad one, becomes an industry standard, without others having any choice in it.
I hope an opensource, non-C/C++ browser will pop up that can claw back from Chrome/Chromium. It’s about time.
Anti Commercial-AI license
Why not just say Rust? There isn’t really anything else that would provide good enough performance for a browser engine with modern heavy webpages while also fixing some major pain point of C/C++
Go is not an option? Zig neither? Even Java would be better (it’s used in high-frequency trading) than C++.
Rust is not the only contender.
Anti Commercial-AI license
Zig didn’t come to my mind when I was writing my comment and I agree that it’s probably a decent option (the only issue I can think of is its somewhat small community, but that’s not a technical issue with the language).
My argument against Go and Java is garbage collection - even if Java’s infamous GC pause can apparently be worked around with a specialized JVM, I’m pretty sure it still comes at the cost of higher memory usage and wasted CPU cycles compared to some kind of reference counting or Rust’s ownership mechanism (not sure about the proper term for that). And higher memory usage is definitely not something I want to see in my browser, they’re hungry enough as is.
Other browser vendors like Microsoft and Brave and Opera could’ve added XL support if they wanted to. It’s not just Google, none of the browser makers want to deal with yet another image format. Only Safari supports the protocol, and even then they don’t support animated images.
IE and pre-Chromium Edge implemented JPEG XR and nobody followed. Safari implemented JPEG 2000 and nobody followed. Implementing an image codec is a lot of work and adds attack surface for hackers, nobody really wants to do that unless they have to.
We have JPEG, we have WebP if you need smaller images than JPEG, and we have AVIF if you want something smaller than PNG for photographs. Unless all of the competition implements JPEG XL again, I don’t think they have any reason to bother. Especially with the whole patent vagueness.
Once again I find myself thinking, “Dammit, Google!”
Thank you very much for the text summary, I really appreciate it :)
No worries! :D
I’d also highly recommend reading https://endsoftwarepatents.org/2023/04/googles-decision-to-deprecate-jpeg-xl-emphasizes-the-need-for-browser-choice-and-free-formats/ — more than features and future proofing, the big issue here is patents. Google controls the patents for AVIF.
Then again, I use HEIF, which is alternately patent encumbered, and default to PNG and SVG for web-facing graphics.
Also fluffykins broke the camera recording again
*long in the tooth
Ah! quite right, thanks for the correction :)
Meh, we all should just move to .PNG anyway
/S kinda