Hacker News Reader

Comment by YetAnotherNick | Hacker News Reader

What's up with this JPEG XL cult in hacker news? I think the Chrome team pretty much handled this in the best way possible. They put everything in public and allowed anyone to comment on their main thread. They responded to lot of the comments. They seems to have their best intention in having JPEG XL implementation in chrome but the team decided it's not worth it, which is a valid decision for someone doing ROI analysis, after all engineers specialising in this are not cheap. It's like everyone is hinting at some conspiracy by Google here that is not there as they spent time in the spec and wanted to promote this.

Even I think the incremental 20% gain of JPEG XL is probably not worth the security risk and increased maintenance. JPEG decoders had been targeted so many times in the past even though it had been audited by best security folks.

View on HN

There is an interesting cult I only realized after this affair, namely a group of WebP haters. Apparently there are a lot of them but weren't visible until JPEG XL is seen as a "solution" to WebP, and many of them became a vocal supporter for JPEG XL at any cost. So that's a big part of the cult.

Another part is probably a growing opposition to Google and Chrome. I had to explain again and again that JPEG XL was also jointly developed by Google (Research Zurich) and Cloudinary, but you can still reasonably argue that Chrome aligns better with Google's own interest than Google Research. And if you apply the same stringent criteria to AVIF, AVIF doesn't stand well either---it would have made zero positive difference if AVIF was deployed this year and not 2 years ago, and libavif is not that small. As AVIF and JPEG XL have their pros and cons when compared to each other, this alone can be seen suspicious enough from outsiders. Keep in mind that Chrome is now the Web Browser so there are a lot more to expect from them, like or not.

I'm probably part of the group you'd call "WebP haters", especially if you look at my comment history[1]. I would rather describe myself as extremely disappointed in WebP.

It's a clear win over PNG in the lossless use case. I have encountered a few outliers where a PNG results in a smaller file size than lossless WebP, but they are sufficiently rare to not worry about it. It also excludes the image sizes too large for WebP to handle (my system has a mix of WebP-lossless and PNG files for that reason). For lossy use cases, however, WebP is not a win over JPEG if you are concerned about anything other than file size. MozJPEG closes the encoding size gap rather significantly and WebP-lossy's origins in VP8 intraframes and limiting itself to 4:2:0 subsampling is just... awful. I never use WebP-lossy. It gains nothing from JPEG and comes out as inferior in basically all scenarios.

I don't view JPEG XL as a "solution" to WebP, but rather as a solution to JPEG. WebP was never competitive in the first place.

[1] In particular: https://news.ycombinator.com/item?id=33448714

You have a right to be disappointed, I was the same and that alone doesn't make you a part of the cult. ;-)

I agree that WebP was initially oversold and better JPEG encoders have made lossy WebP increasingly less appealing; a lossless WebP is still worth today though.

I dont even believe it was oversold. There were lots of independent reviews and analysis, even by Mozilla themselves that WebP wasn't even good. And yet people still uses it because they somehow hate JPEG.

It there was ever a "cult", it is "Anti JPEG cult" and "WebP Cult". Not JPEG XL.

I'm the author of lossless WebP. From my personal point of view I agree, the benefits of WebP lossy were too marginal to balance off its weaknesses (I have observed somewhat unpredictable quality, tendency to blurring, occasional reduction of saturation, and limitation to 420).

I like MozJPEG in the lower quality range, but I'm disappointed with it in the medium-to-high quality range (q85-100) -- there guetzli or jpegli does quite a bit better. Often MozJPEG appears worse than libjpeg-turbo in the highest quality whereas both guetzli and jpegli are substantially (~35 %) better.

HN loves, in the aggregate, to hate on Google. So Chrome removing support for an image format is a good opportunity come up with inane conspiracy theories. Repeatedly.

The good thing about a conspiracy theory is that facts don't matter. JPEG XL being a primarily Google-created format in the first place? The format being dead in the water on the web without support from Apple/Safari, which was never forthcoming? Nobody wanting a repeat of web? Irrelevant, you can just pretend that this is actually a format that every other browser supports.

> The format being dead in the water on the web without support from Apple/Safari, which was never forthcoming?

Never stopped Google from pushing its own codecs. Often without even a stable version of the spec for years. And often threatening third party ecosystem with "implement this or else".

Some people don't like Google or Chrome in general, for various reasons (valid or not), and they'll use any opportunity to criticize them.

JPEG XL was made in the JPEG committee and the two main proponents were Google and Cloudinary. So it's insane to say that Google in general would be opposed to JPEG XL. This was not a Google team that was part of the Chrome team though.

The way the Chrome team has handled this was not "the best way possible" in my opinion. They first made a decision, and then a month later they showed the data that lead to it (that was one week ago). This data was created by the AVIF team. They did invite anyone to provide feedback on this data, but they did not wait for this feedback to execute on the decision. I don't think this is the best way possible to handle this. A better way would be to first provide data, then wait for feedback, allow all sides to provide their input, have an open and honest discussion involving all stakeholders and experts, and then make a decision. That would be a better ordering of steps.

I agree though that this is not some conspiracy by Google. It is just a difficult technical decision to make, and they're currently making the wrong decision in my opinion, but this is something that has to be motivated technically, not emotionally or politically.

I am probably the first few if not the first to put JPEG XL on HN's radar. I am definitely not in an JPEG XL Cult. Although I do dislike Google.

I am simply a supporter of Better Tech. (And I am already omitting WebP hate here. ) And I suspect a lot of us are. And IMO neither WebP nor AVIF are better than JPEG XL.

Had Google actually posted a thorough analysis, as they stated that JPEG XL is not better or even inferior to AVIF, and suggest they decide not to go with it. It would have been fine. ( I may disagree with their take, but at least you can see it from their POV ). Not only did they not do that, they provided the Data with out of date version of JPEG XL [1] and a set of test that does not represent the actual internet usage. Compared to [2], where JPEG XL is surprisingly better when they wont expected.

So if, a) everything JPEG XL released and tested were true, and truly better than AVIF, then b) Why isn't Google supporting the better Image codec?

I am also perfectly fine with Google saying, I dont like it. I hate it because It is not AOM even if JPEG XL is better. Fine. Chrome is Google's browser. Do what ever you want with it.

Just dont ever come out again and say everything you do is better for the Web.

[1] https://storage.googleapis.com/avif-comparison/index.html

[2] https://twitter.com/jonsneyers/status/1563442356493230080

I know essentially zero about this space, but I would almost argue categorically that 20% is not "incremental".

Then why haven't everyone switched to webp from png/jpeg which gave >25% gain over jpeg and supported by chrome from 12 years? For better or worse, no one wants to sacrifice compatibility for 20% gain.

Because WebP does not offer a >25% improvement. As far as I know, it is only better than JPEG in some cases, and then seldom by that much. [1] And of course, this is only when you compress an image lossily. If you try to recompress an already-lossy JPEG as a WebP, it will suffer even more quality loss in the process. (And if you try to recompress it losslessly, the resulting WebP will be bigger.)

JPEG XL lets you recompress an existing lossy JPEG losslessly, saving you 20% in the process. This is something that other formats like WebP or AVIF do not and can not offer.

[1]: https://siipo.la/blog/is-webp-really-better-than-jpeg

Even the site you pointed to show average 18% decrease in size compared to best but slow jpeg encoder.

"JPEG XL lets you recompress an existing lossy JPEG losslessly” This is such a niche usecase. Who cares about bit more lossy compression for an already lossy compressed file.

I guess you have a misunderstanding here, it's a lossless compression of an already lossily compressed file (which had used suboptimal coding methods). You will get a bit-perfect original JPEG file when you decompress a recompressed JPEG XL file. No additional compression artifact there.

> Who cares about bit more lossy compression for an already lossy compressed file.

Perhaps for those unaware: "without quality loss". I guess the people who care are those who store a lot of images in jpeg format (at least relative to the storage space they have). In my example, I have >1TiB of photos in JPG format (yes, I know), and it would be nice to get 200GiB back for free without losing quality. For a company offering an image storage product, this would be great cost reductions.

I don't think it's a niche use case. The amount of existing JPEG files is huge. Having a way to compress them better without having to worry about introducing additional loss, is a "nobrainer" type of improvement.

Are we looking at the same graphs? In the linked comparison, WebP has at best maybe 10% of an improvement over JPEG for a 500px image, and actually performs worse as the images get bigger. (The 18% you’ve likely read are in comparison to the cjpeg, not mozjpeg, which compresses better.)

There’s also no reason one should tolerate further loss just because the image is already lossy. Whether the original is lossy or not, you either want to keep it exactly the same, or you're okay losing quality to save some space. Archiving and preservation come to mind as the first reason someone would want to go with the former.

JPEG and JPEG XL are compatible.

> What's up with this JPEG XL cult in hacker news?

I'm not sure it's on HN specifically. There seems to be a JXL cult, and like butters they flock to any mention. And in the same vein, they seem to inject large amounts of copium when reality doesn't go their way.

I don't like them too, but you do sound like naysayers to Rust back when it was less mature, don't you? Having cults doesn't mean anything, just stick to verifiable facts and logical reasoning regardless of them.

What’s the issue with being naysayer to rust? As long as somoneone is not actively harming rust community or spamming the community, it is fine and Rust is free to do what they want. On the other hand, look at the JPEG XL google group and see all kind of demanding and spammy messages asking the same questions literally dozens of times.

> Having cults doesn't mean anything

It does mean that they are the worst person to talk to.

> What’s the issue with being naysayer to rust?

There is no issue per se, but I'm referring to a certain group of people who didn't like Rust because they thought many if not most Rust users are in a cult. This observation was partly true and partly false; I've previously described what went possibly wrong [1].

Even at that time some people, no matter they like or don't like Rust, tried to continue a constructive discussion and I'm asking the same here. Your claim should not vary by the presence or lack of the quote-unquote cult.

[1] https://news.ycombinator.com/item?id=32802291

Which google group are you referring to? The bugtracker? Some of the comments there are useful imo, e.g. when image experts from various companies bring their views. Others are basically just "+1", which is better done by just starring the issue. But it does look like most people who did not have anything useful to add did indeed do exactly that, comparing the number of comments to the number of stars.

Yes, the bugtracker. It’s subjective and I could point to multiple examples, but those would be (rightly) dismissed as cherry picking. To me the entire thread really felt like a mob attack, and is filled with comments like:

> "We do not bloody care!"

> "We are the kings of the universe, we dictate which image formats you can use".

[0]: https://bugs.chromium.org/p/chromium/issues/detail?id=117805...

I agree that such comments are not useful. I can understand the frustration people may feel (very well actually), but it is not productive to express it in such ways. I don't encourage such reactions, but I do think they are understandable when the first argument for removal is "There is not enough interest". That can be perceived as someone telling you they're removing the thing you want to have because _you_ are not interested in it, and I can see how that can be infuriating and provoke emotional responses.

Proposal: some of the criticism may be motivated primarily by the meta-level issue rather than the object-level issue, viz. what this kerfuffle says about HTML5 and web technology in general.

The web has many positive aspects but modularity isn't one of them. HTML5 has turned into an unfocused attempt to specify a whole computer from bottom to top - everything from a [virtual] CPU, to programming languages, graphics stacks, text rendering, UI toolkits, MIDI, sockets, storage, Bluetooth, USB and more. Unlike other operating systems, the resulting Chrome pseudo-OS has nearly no extensibility. Attempts to use WebAssembly to hack around this yield mixed results at best given the problems of needing to constantly re-download the modules (cache segmentation), needing to re-JITC the modules and inability to share code (process isolation).

Images are a core part of the web's functionality, they were literally one of the first features ever added to HTML. The fact that new image formats can't be added for code maintenance reasons, even when having clearly unique features and interest from major companies, worryingly suggests that the web platform may be heading towards a form of technical bankruptcy. HTML has support for obscure features virtually no web sites will ever use like MIDI or USB support, whilst an upgrade to a core feature that every website uses (except HN of course!) apparently cannot be done any longer. It means implementing a complete yet non-extensible OS stack from top to bottom is a task too large for even the world's largest and richest corporations.

In the beginning, the web's architects realized and understood that it wasn't feasible for browsers to implement everything you might want to embed in a web page. The plugins API was an early addition to the platform as a consequence. When it was deprecated, the stated reasoning was as follows:

https://blog.chromium.org/2014/11/the-final-countdown-for-np...

"Last September we announced our plan to remove NPAPI support from Chrome, a change that will improve Chrome’s security, speed, and stability as well as reduce complexity in the code base"

At the time this sounded wise. But since then tens of millions of lines of code have been added to Chrome (almost all C++) so "reducing complexity in the codebase" seems like a hard argument to make with hindsight. Browsers were capable of running plugins inside their process sandboxes and exploits in Blink are found regularly, so it's not really clear that it made much security difference either.

So maybe that's one reason it's getting such a reaction. This JXL incident isn't just about JXL. It's about what it implies for the future. Who will even bother researching new image codecs now, if even Google itself can't get a better codec into the web?

It may be time to start thinking about what alternative designs to the web might look like, with a strong focus on modularity and extensibility whilst still taking into account everything that was learned over the past 30 years. I have some ideas already but haven't written them up yet.

> The fact that new image formats can't be added for code maintenance reasons

Your entire premise is wrong here. A new image format is being added across all major browsers (AVIF).

So what's the distinction between JPEG XL and AVIF? On a tecnical level, it's hard to find a way that AVIF is preferrable. It's just gross. But the reality is that Apple will support AVIF and will never support JPEG XL, and an image format that doesn't work on iOS-based browsers is useless. Basically nobody will deploy it, even if it works on Chrome, they'll just continue using other formats. We know this from nobody deploying webp in a similar situation. The blood is on Apple's hands here.

Why is adding e.g. USB support useful, then? Because that's entirely new functionality, unlocking new capabilities, with no obvious fallback to a slightly less efficient older version unlike with images.

> So what's the distinction between JPEG XL and AVIF? On a tecnical level, it's hard to find a way that AVIF is preferrable.

AVIF support comes nearly for free with AV1 already supported for video.

Life span of image formats is 5x the life span of video formats. With AVIF we will be stuck with loads of unnecessary complexity.

Look at WebP. VP8 are already being phased out and WebP is only emerging now.

Perhaps that should have been worded more precisely: "The fact that some new image formats can't be added"? Code maintenance costs are the stated justification for not adding JXL. We can assume any other new image format that isn't AVIF would hit the same barrier. What if tomorrow someone comes out with e.g. a new binary vector format? Same thing. Apple may well be the real issue, but that just moves the question around (why doesn't Apple add JXL, well, probably code maintenance costs too).

It's good that they're adding AVIF, but it will presumably be the last image codec added for a very long time, especially as we face the question of who will bother researching new such codecs now. And IIUC the primary reason they like AVIF is that it's basically a video codec in image form, so again - the choice is being dominated by code maintenance costs.

So I think the wider point stands. There is already a big issue with Chrome adding features that Safari and Firefox never match. Now this. It suggests the architecture is not scalable. Why shouldn't we have as many image formats as people want to create? It's due to the desire by browser makers for everything to be in HTML5 rather than bringing back a plugin architecture.

Where did you get the information that Apple will never support JPEG XL?

I haven't heard or seen anything from Apple, neither in favor nor against JPEG XL.

I would assume though that when Adobe and Serif (and their open source alternatives like Gimp, Krita, and darktable) are adding JPEG XL support in their products, there will be some incentive for Apple to add it in their products as well. After all, they do have nice HDR-capable screens now, so it would not really make sense for them to not support the best codecs currently available for HDR, which are AV1 for video and JPEG XL for still images. Apple does have a long-standing reputation for being excellent in high-fidelity image workflows, and I don't see how they would be able to keep that reputation without adding support for JPEG XL.

So I don't see why Apple can't just support both AVIF and JPEG XL. AVIF is 2-3 years older so of course they'll land support for that one first, but I don't think that should be seen as an indication that they'll not support JPEG XL.

I believe Apple will be the second major OS to add JPEG XL after Linux distros. They understand user value in the creative space. Creative work occasionally needs more than 12 bits, no surprises approach to quality, and performant lossless coding.

> The blood is on Apple's hands here.

Come on. This is bullshit, and you know it. The only reason industry at large is even supporting Google's codecs is because Google literally threatens hardware manufacturers to support their codecs in hardware, or else: https://www.protocol.com/bulletins/av1-android-14-requiremen... and https://www.protocol.com/youtube-tv-roku-issues

Google can't really strongarm Apple into supporting anything. And Apple either sets the trends or follows the industry. Stop pretending Apple has anything to do with JPEG XL's imagined or real failures.

In this particular case blood is squarely on Google's hands. And it's all for the same reasons that you accuse Apple of: https://news.ycombinator.com/item?id=33937745

Reply on news.ycombinator.com