lonjil

The primary problem with that image is that is has over 60 channels, which means it'll take 20x more time to decode no matter what. Incidentally, the JXL spec suggests that web browsers shouldnt't decode images with so many layers. Jxl-rs will probably start enforcing such limits by default.

> Those methods include covert measures to ensure NSA control over setting of international encryption standards, the use of supercomputers to break encryption with "brute force",

Things that definitely don't happen. Those same encryption standards are used by the US military, and the international cryptography community can pretty readily rule out keyed backdoors.

The thought that supercomputers could break Internet encryption by brute force is laughable. One would have to be innumerate to think such a thing.

> I guess I wasn't aware that Wine pivoted from trying to be a general purpose, drop-in replacement for Windows to being a platform for games that only supports a subset of Windows functionality.

It didn't.

> I AM saying "people don't want ride trains that allow 5% of the riders to smoke cigarettes on enclosed train platforms and in enclosed train cars."

Just don't allow that then?

> Public transit advocates need to be honest with themselves that anti-social behavioral issues really matter to people. People are willing to pay more to have a more pleasant experience. When a transit system fails to meet that standard, then you'll suddenly find yourself with a transit system that people don't want to use.

"we can't have good transit because a few people who call themselves transit advocates have bad opinions" is very defeatist. Weak-spined politicians find it much easier to just set money on fire than actually solving problems, so even though most transit advocacy groups in the US emphasize quality and being less wasteful with budgets, your politicians usually prefer the worse options.

> That's not the reason, but the excuse. The reason firefox doesn't have jxl is that it is funded by Google, and someone at Google decided that it has to die.

So what, you think they were just lying when they said that they'll ship JXL when it has a Rust implementation? You think Mozilla devs were just bluffing when they were working directly with the JXL devs over the last year to make sure everything would work right?

what exactly do you mean by "trivially and stably mapped to a unique subnet"?

WUFFS only works for very simple codecs. Basically useless for anything complex enough that memory bugs would be common.

Some years ago, the Google Photos team asked the Chrome team to support JXL, so that they could use it for Photos. The request was ignored, of course.

> If they successfully contribute an implementation that satisfies these properties and meets our normal production requirements, we would ship it.

That's what they said a year ago. And a couple of Mozilla devs have been in regular contact with the JXL devs ever since then, helping with the integration. The patches to use jxl-rs with Firefox already exist, and will be merged as soon as a couple of prerequisite issues in Gecko are fixed.

long term support is actually being provided by google...

just a different team in a different country :D

most jxl devs are at google research in zurich, and already pledged to handle long tetm support

Since the person you replied to mentioned MozJPEG, I have to assume they meant that WebP's lossy capabilities were a marginal improvement.

The JXL spec already has gainmaps...

Also, just because there's a spec for using gainmaps with JPEG doesn't mean that it works well. With only 8 bits of precision, it really sucks for HDR, gainmap or no gainmap. You just get too much banding. JXL otoh is completely immune to banding, with or without gainmaps.

I don't understand what you're trying to say. Mozilla said over a year ago that they would support JXL as soon as there's a fast memory safe decoder that will be supported.

Google on the other hand never expressed any desire to support JXL at all, regardless of the implementation. Only just now after the PDF Association announced that PDF would be using JXL, did they decide to support JXL on the web.

> avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges).

AVIF is certainly better for the level of quality that Google wants you to use, but in reality, images on the web are much higher quality than that.

And JXL is pretty good if you want smoothing, in fact libjxl's defaults have gotten so overly smooth recently that it's considered a problem which they're in the process of fixing.

With incredibly bad compression ratios.

> Both Qualcomm and Mediatek have mobile SoC which are more performant than the M2 and the X2 Elite is in the ballpark of Apple top SoC.

At what power consumption? And is that both CPU and GPU, or just GPU?