[X] My Assistant

As for why they swung hard for it as opposed to JXL? I'll admit I have no idea. Haven't read up enough on it to formulate a schizo theory. :^)

I admittedly had never heard of JXL until people started mentioning it in this topic, which means most of my info is just going to come from stuff like the JPEG XL Wikipedia article:

"The Chrome team cited a lack of interest from the ecosystem, insufficient improvements, and a wish to focus on improving existing formats as reasons for removing JPEG XL support."

Which, I mean... Yeah, if nobody adds support for it, the ecosystem won't really be that interested. Catch-22. Part of the reason getting buy-in from big players to start with is so important. Either way, the reasons given are at least somewhat reasonable - and not mutually exclusive with the various conspiracy theory stuff either, so not much to glean. It could really be anything, so whatever someone's personal theory is could be right.

I actually find this more interesting, honestly:

"Mozilla expressed security concerns, as they feel that the rather bulky reference decoder would add a substantial amount of attack surface to Firefox. They expressed willingness to ship a decoder that meets their criteria if someone provides and integrates a suitable implementation. The JPEG XL team offered to write one for them in the memory-safe Rust language."

That's a rather... realistic concern. One entirely unrelated to the feature set of the format itself (ie if it's N% faster, N% smaller, lossless, etc). And if the (relatively speaking) brand new JXL decoding code were found to have an exploitable bug in it, that would be kinda a big deal.

Sure, that's Mozilla, not Google. But I guess my point is, the reasoning and discussion behind these kinds of decisions can be a whole lot more nuanced. (And why I find the immediate jump to schizo theories so amusing.)

In their defense, 100,000 lines of C++ really is a massive attack surface that would almost certainly hide multiple exploitable RCEs that would show up to bite them in the ass for years to come. So I can't blame either party for refusing to include that.

Was it the Photos app or the legacy Windows 7 photo viewer? You should report to Microsoft so they can fix it if it's the former, but I don't think the latter is still supported.

Edit: Found [www.winhelponline.com] this.
It seems the Microsoft WebP Extension may cause images to be darker in the legacy photo viewer, the solution is to uninstall that and install Google's WebP Codec (instructions in that post).

Actually, I can confirm that the issue still persists in Windows 11 23H2, and replacing the Microsoft WebP Extension with the Google one did fix it.
I mean, I kinda get that the legacy photo viewer is discontinued, but shame on you, Microsoft.

In their defense, 100,000 lines of C++ really is a massive attack surface that would almost certainly hide multiple exploitable RCEs that would show up to bite them in the ass for years to come. So I can't blame either party for refusing to include that.

Its still a hugely complicated library, but 100k loc is a bs argument by Mozilla. It includes the encoder, jpegli, and everything else unrelated to the decoder itself in the reference library.
The google research team is working on a rust implementation now, which should make the people at Mozilla happy at least.

This post has been edited by -terry-: Nov 20 2024, 10:27

Its still a hugely complicated library, but 100k loc is a bs argument by Mozilla. It includes the encoder, jpegli, and everything else unrelated to the decoder itself in the reference library.
The google research team is working on a rust implementation now, which should make the people at Mozilla happy at least.

I mean, I didn't exactly download it and count lines. But that's literally what they said, [github.com] on the relevant Mozilla page - they said the "decoder" was "more than 100,000 lines". With the amount of numbers and formal dialog there, I would have to assume that if the figure was significantly wrong, someone would have corrected it.

Also another interesting thing (from [github.com] an earlier discussion in the same area):

"The difference is that the support cost (maintenance, attack surface, code size) for a video-derived codec is much lower, because browsers ship the associated codec already for video decoding. AVIF support in Firefox weighs in at about 1k lines of straightforward glue code. JPEG-XL is roughly 100k lines of multi-threaded C++."

So part of the reason the JXL decoder is so "heavy" is because it can't reuse someone else's homework like AVIF can.