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?

In my experience, hardware companies all believe that software is trivial nonsense they don't need to spend any effort on. Consequently, the software that drives their hardware really sucks.

> Often the update are just windows only..

That's a choice the vendor makes, and Tuxedo Computers is the vendor in this case. Since they control the product they're making, they should be able to provide nice firmware updates for Linux users. They just decided not to even try, I guess?

Not particularly difficult. The main Typst crate should have you covered. I've seen quite a lot of projects that do it already.

Google is not a monolith. The Chrome team doesn't want it in Chrome, but many other parts of Google likes it.

> We barely even have movement to webp &avif

If you look at CDNs, WebP and AVIF are very popular.

> From what i understand avif gives better compression (except for lossless) and has better decoding speed than jxl anyways.

AVIF is better at low to medium quality, and JXL is better at medium to high quality. JXL decoding speed is pretty much constant regardless of how you vary the quality parameter, but AVIF gets faster and faster to decode as you reduce the quality; it's only faster to decode than JXL for low quality images. And about half of all JPEG images on the web are high quality.

The Chrome team really dislikes the concept of high quality images on the web for some reason though, that's why they only push formats that are optimized for low quality. WebP beats JPEG at low quality, but is literally incapable of very high quality[1] and is worse than JPEG at high quality. AVIF is really good at low quality but fails to be much of an improvement at high quality. For high resolution in combination with high quality, AVIF even manages to be worse than JPEG.

[1] Except for the lossless mode which was developed by Jyrki at Google Zurich in response to Mozilla's demand that any new web image format should have good lossless support.

> (surprisingly, Firefox is not attributed this - they also do not support it yet, and they are not doing anything _other_ than awaiting Chrome's work for it!)

The fuck are you talking about? The jxl-rs library Firefox is waiting on is developed by mostly the exact same people who made libjxl which you say sucks so much.

In any case, JXL obviously has mindshare due to the features it has as a format, not the merits of the reference decoder.

Other than Jon at Cloudinary, everyone involved with JXL development, from creation of the standard to the libjxl library, works at Google Research in Zurich. The Chrome team in California has zero authority over them. They've also made a lot of stuff that's in Chrome, like Lossless WebP, Brotli, WOFF, the Highway SIMD library (actually created for libjxl and later spun off).

FreeBSD does as well, but old ABI versions aren't kept forever.

> stubborn devs, a loaned Milk-V box, and a middle finger to pragmatism.

That's not what's happening here though? With skepticism, they're willing to give it another try because someone loaned them the needed hardware. They're being pragmatic, and they're not stubborn about supporting RISC-V, as they indicate that if there are more problems they'll drop it again.

You mention only producing a limited quantity, but do you have any plans to do a second batch next year? I know that knowing the future is impossible and that you thus can't make any promises, but are you at least hoping to be able to make more batches in the future?

I can't spend $225 right now, and by next month I'm guessing the pre-orders will already have blown way past your production quantity ^^

> The maintainers of core subsystems are the people he trusts, at least trusts as much as you can in this space. He'll take their opinions before anyone else, since they know best about the subsystems they maintain

But there were no technical arguments against the Rust wrapper. And in any case, the Rust wrapper isn't in that subsystem, it just uses that subsystem. Hellwig's argument was nothing more than "there shouldn't be a second language in the kernel". He had nothing specific about the DMA wrapper. And Linus has already approved Rust in the Linux kernel, so what's the problem? Why can't Linus put his foot down on an issue that he has already decided on?

I find this reply interesting. Linus says that what matters is technical stuff, but even before the social media brigading, the whole thread was nothing but non-technical drama. So why is Linus focused only on that and not Hellwig's behavior?

But preventing memory leaks is actually impossible. Even with garbage collection, memory leaks are common.

Not for a long time. The WebP encoder has improved a lot since MozJPEG was released. But these days we have Jpegli [1] which beats WebP at higher quality levels.

[1] https://github.com/google/jpegli/

> "Worse" in what sense?

Worse as in not compressing as well. As I said, at high fidelity or lossless. At lower quality levels, AVIF files are smaller and JXL files are bigger. At higher quality levels, JXL files are smaller and AVIF files are bigger. At lossless, AVIF is worse than PNG, while JXL is much better.

> Like implied I'm not an expert, I'm just wondering why AVIF can't have faster loading with a preview function like JPEG has.

JPEG is fast to load regardless of its progressive loading feature. So there are really two things at play, speed of decoding, and whether partially loaded files can give you a preview. The slow decoding of AVIF is inherent to the design of the format, but different encoding choices can lead to different decoding speed. IIRC, the lower the encoding quality, the faster the decoding can be. And as for progressive display, that simply wasn't considered when AV1 was designed. You can do something funny and store two AVIF frames, one low quality and maybe lower resolution, followed by the full image, but then you're storing two images just to get a preview.