I mean, of course this is still valuable (JPEG-only consumers will probably be around for decades, just like MP3-only players), and I realize Google is a large company, but man, the optics on this...
It's really hard to say this in public, because people are treating it like a divisive "us or them" issue that's obvious, but the JPEG-XL stuff is _weird_.
I've been in codecs for 15 years, and have never seen as unconstructive behavior like the JPEG-XL work. If I had infinite time and money and it came across my plate, we'd have a year or two of constructive work to do, so we didn't just rush something in with obvious issues and opportunities.
It turned into "just figure out how to merge it in, and if you don't like it, that's malfeasance!" Bread and circus for commentators, maybe, but, actively preventing even foundational elements of a successful effort.
In light of the recent security incident, I'd see that completely hypothetical situation as more admirable.
In that case, that would just be extremely bad messaging (which I also wouldn't put past Google). Why agitate half of the people on here and in other tech-affine parts of the Internet when they could have just publicly stated that they're working on it and to please have some patience?
Public support by Google, even if it's just in the form of a vague "intent to implement", would be so important for a nascent JPEG successor.
I use asking questions as a way to keep contentious discussions on track without being boorish. And you're right, it can easily be smarmy instead of Socratic without tone, a la the classic internet sarcasm problem.
Gentle note: I only asked one question, and only in the post you replied to.
Same thing with Firefox, which has had basic support merged into Nightly, and a couple more patches gathering dust due to lack of involvement from the side of Firefox. Mozilla has since decided to take a neutral stance on JPEG XL, seemingly without doing any kind of proper evaluation. Many other programs (like GIMP, Krita, Safari, Affinity, darktable) already support JPEG XL.
People are not getting upset because projects don’t invest their resources into supporting JPEG XL. People are getting upset because Google (most notably), which has a decisive say in format interoperability, is flat out refusing to give JPEG XL a fair consideration. If they came up with a list of fair conditions JPEG XL has to meet to earn their support, people could work towards that goal, and if JPEG XL failed to meet them, people would easily come to terms with it. Instead, Google has chosen to apply double standards, present vague requirements, and refuse to elaborate. If anyone is ‘preventing even foundational elements of a successful effort’, it’s Google, or more specifically, the part that’s responsible for Chromium.
I read the parent post as saying that this is the problem, i.e. that "complete" support is a mess, because AFAIK even the reference implementation is incomplete and buggy, and that then getting angry at the consumers of it is besides the point and won't lead anywhere (which is what we see in practice).
Browsers supporting a format "a little" is almost worse than not supporting it at all, because it makes the compatibility and interoperability problems worse.
It isn't not accepting it or hostile. That is completely not true.
They actively push against JPEG XL, despite all the data, prior to even 1.0 suggest it is or could be better than AVIF in many cases. To the point where they even make up false benchmarks to downplay JPEG XL.
Companies were even willing to paid ( wont name ) and put resources into getting JPEG XL because they see it to be so good. But they still refused.
It is at this point people thought something doggy is going on. And then not only did Google not explain themselves. They were even more hostile.
So why the extra hate? Well partly because this is a company who gave us an over promised WebP and underdelivered.
It’s so prominent running into files you can’t open in your tools that I have a right click convert to PNG context menu
Because Chromium doesn’t support it, Electron doesn’t.
Because Electron doesn’t, Teams and other modern web apps and web sites don’t either, etc…
If Google just added JPEG XL support instead then it would be… a supported alternative to JPEG.
You’re saying working in that is a waste of time because… it’s not supported.
These formats are in Chromium because of Google politics, not because of their technical merit.
And a graphics format better be damn good (i.e. much, not just a little bit, better than what it's hoping to replace) if it aspires to become widely supported across applications, operating systems, libraries etc.
The article has 35% compression improvements over JPEG mentioned and that's at least as much as usually thrown around when discussing WebP.
If I had just used the internet quality images, WebP lossless would have improved size by -42 %.
Yet another 'marketing textbook' way to overstate -42 % is to turn it into 'loading speed': 1/(1-0.42) = 72 % faster.
None of this was made for the lossless and the most conservative estimate was shown. I didn't do any hacking or cherry picking to produce the number and I had several internal verification approaches to be correct.
Before making that kind of claim, I would spend some time looking at the names of the folks who contributed heavily to the development of JPEG XL and the names of the folks who wrote jpegli.
Here: https://www.mail-archive.com/blink-dev@chromium.org/msg04351...
"can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format"
It's a yes!
Of course full JPEG XL is quite a bit better still, but this helps old compatible JPEG to support HDR without 8-bit banding artefacts or gainmaps, gives a higher bit depth for other uses where more precision is valuable, and quite a bit better compression, too.
Only within pretty narrow limits.
Classic JPEG will never be as efficient given its age, in the same way that LAME is doing incredible things for MP3 quality, but any mediocre AAC encoder still blows it out of the water.
This is in addition to the things you've already mentioned (HDR) and other new features (support for lossless coding).
And I'd find their sentiment much easier to believe if Google/Chrome weren't hell-bent on making WebP (or more recently AVIF) a thing themselves! That's two formats essentially nobody outside of Google has ever asked for, yet they're part of Chrome and Android.
Reminds me of "You Scientists Were So Preoccupied With Whether Or Not You Could, You Didn't Stop To Think If You Should."
The arithmetic coding feature was already painful enough. I'm simply not in need of yet another thing that makes jpeg files more complicated to deal with.
> After weighing the data, we’ve decided to stop Chrome’s
> JPEG XL experiment and remove the code associated with
> the experiment.
> We'll work to publish data in the next couple of weeks.
Did that ever happen?
If they don't, literally nothing happens.
I fail to see a major downside. Perhaps open up your thinking on this?
Yes, Chrome published data.
People said the same thing last time and it took more than 10 years until decoding worked reliably. I'm simply not interested in dealing with another JPEG++.
> Perhaps open up your thinking on this?
Nah, I'm fine. I went JXL-only for anything new I'm publishing, and if people need to switch browsers to see it – so be it.
(Of course JXL is better still.)
This makes your website only viewable on Safari (and by extension Apple devices) only, right?