lonjil

But we do know where it is, to quite good precision. We know how much or how little dark matter is present in different galaxies, which matches quite well with the amount of dark matter that must've been present in the early universe to explain some of the anisotropy of the cosmic microwave background.

Just the opposite. Sure, DM was proposed when some observations didn't match predictions, but do you think scientists liked that? Do you think they just accepted it? They did not. No one liked DM, and many people tried to disprove it. How does one disprove DM? You simply assume that it exists, and then make a prediction using that assumption. If the prediction is wrong, that's evidence against DM. What happened is that every time someone made a DM prediction, it turned out to be correct.

Two early cases of this were that if invisible matter exists, there should be gravitational lensing around seemingly empty space, which was then found, and that if if something like dark matter existed before recombination, then a certain pattern should be found in the cosmic microwave background, and a few years after the prediction, sensitive enough equipment was deployed that could see enough detail in the CMB, and the prediction turned out correct.

Today there's something like a dozen such predictions that have come true, ranging in scale from kiloparsecs to gigaparsecs, from things happening today to things that happened in the early universe. When a theory makes accurate predictions across many problems and areas, that is good evidence for the theory.

I guess I should say, take up lots of space unless you're OK with lower quality. In any case, gainmaps are entirely unrelated to the 8 bit vs 10 bit question. The more range you have (gamut or brightness) the worse 8 bit is, regardless of whether you're using a gainmap or not. And you can use gainmaps with 10 bit images.

> but it's absolutely ass for UI.

uhh, no it isn't?

And gainmaps suck, take lots of space, don't reduce banding. Even SDR needs 10-bit in a lot of situations to not have banding.

> "We've never had to wear helmets before, why start now?"

> We live in the future. We have memory-safe languages now. We're allowed to use them. You won't get in trouble from anyone, I promise.

That's why I specifically said that it's unfortunate that C++ is still wide spread, and pointed to a fully conformant JXL decoder written in Rust :p

> There are only a handful of image codecs that are widely accepted. Essentially just GIF, PNG, and JPG. There's a smattering of support for more modern formats, but those three dominate.

Every browser ships libwebp and an AVIF decoder. Every reasonably recent Android phone does as well. And every iPhone. Every (regular) install of Windows has libwebp. Every Mac has libwebp and dav1d. That's all C++. AVIF in particular is only a couple of years older than JXL, and yet I've never seen opposition to it on the grounds of memory safety. That is what I meant about JXL being singled out.

> JPEG XL is a complex codec, with a lot of code. This increases the chance of bugs and increases the attack surface.

> A (surprisingly!) good metric for complexity is the size of the zip file of the code. Libjpeg is something like 360 kB, libpng is 350 kB, and giflib is 90 kB.

> The JXL source is 1.4 MB zipped, making it nearly twice the size than all of the above combined.

Which code exactly are you including in that? The libjxl repo has a lot of stuff in it, including an entire brand new JPEG encoder! Though jxl certainly is more complex than those three combined, since JXL is essentially a superset of all their functionality, plus new stuff.

Pretty much every codec in every browser is written in an unsafe language, unfortunately. I don't see why JXL should be singled out. On the other hand, there is a JXL decoder in Rust called jxl-oxide [1] which works quite well, and has been confirmed by JPEG as conformant. Hopefully it will be adopted for decode-only usecases.

[1] https://github.com/tirr-c/jxl-oxide/pull/267

> It’s absolute insanity that we write codecs — pure functions — in an unsafe language that has a compiler that defaults to “anything goes” as an optimisation technique.

Rust and C++ are exactly the same in how they optimize, compilers for both assume that your code has zero UB. The difference is that Rust makes it much harder to accidentally have UB.

But the server doesn't necessarily have unlimited time to encode those images. Each of those 1 million images needs to be encoded before it can be sent to a client.

Actually, if you already have loss, you should try as hard as possible to avoid further loss.

Actually, they did try QOI for the photographic images:

> Not shown on the chart is QOI, which clocked in at 154 Mpx/s to achieve 17 bpp, which may be “quite OK” but is quite far from Pareto-optimal, considering the lowest effort setting of libjxl compresses down to 11.5 bpp at 427 Mpx/s (so it is 2.7 times as fast and the result is 32.5% smaller).

17 bpp is way outside the area shown in the graph. All the other results would've gotten squished and been harder to read, had QOI been shown.

I misrecalled. While the Google patent is a lot more general than the Microsoft one, it doesn't apply to most uses of ANS.

I think JXL has been seeing adoption by apps faster than Webp or AVIF.

Whichever is more pessimistic. So for the axes in this article, the first one. If you have an option on the "bad" side of the Pareto curve, you can always find an option that is better in both axes. If a new option is discovered that falls on the good side of the curve, well, then the curve needs to be updated to pass thru that new option.

And the one you're replying to is also talking about battery life. The energy needed to display an image for a few seconds is probably higher than the energy needed to decode it.

8-bit can have banding even without "HDR". Definitely not enough. 10 bit HDR video is becoming more common, and popularity for images will follow. Adoption is hampered by the fact that Windows has bad HDR support, but it all works plenty well on macOS and mobile platforms.

I wonder if the text would be consistent enough for JXL's "patches" feature to work well.

I believe they were referring to that WebSocket issue, not JXL.

The Microsoft patent is for an "improvement" that I don't believe anyone is using, but Internet commentators seem to think it applies to ANS in general for some reason.

A few years earlier, Google was granted a patent for ANS in general, which made people very angry. Fortunately they never did anything with it.

Real-time encoding is pretty popular, for which encoding speed is pretty important.

Well, lots of things other than JXL use ANS. If someone starts trying to claim ANS, you'll have Apple, Disney, Facebook, and more, on your side :)

> And I suppose the Chrome folks have the telemetry to know how many people set that damn flag.

How is that relevant? Flags are to allow testing, not to gauge interest from regular users.

Daala's and Thor's features were supposed to be integrated into AV1, but in the end, they wanted to finish AV1 as fast as possible, so very little that wasn't in VP10 made it into AV1. I guess it will be in AV2, though.

> In most domains proprietary specifications form the backbone of everything. A lot of governments refer to ISO standards, which by default are not open access.

Standards documents being behind a paywall is not at all the same thing as something being proprietary or needing to be licensed. ISO charges for standards documents to pay their administrative costs, you can implement those standards without paying any extra money. And if you happen to have an alternative way of implementing the standard without reading its document, that is fine too. If you implement JPEG XL by studying its open source reference implementation, that is A-OK.

Hardware acceleration of image decoding is very uncommon in most consumer applications.

Prior art makes patents invalid anyway.

Lossless AVIF is just really quite bad. Notice that how for photographic content, it is barely better than PNG, and for non-photographic content, it is far worse than PNG.

If you don't have progressive decoding, those metrics are essentially the same.

I have heard that it will see a proper standalone release at some point this year, but I don't know more than that.

> Of course it didn't, it wasn't designed to be either the fastest nor the best. Just OK and simple. Yet in some cases it's not completely overtaken by competition, and I think that's cool.

Actually, there was a big push to add QOI to stuff a few years ago, specifically due to it being "fast". It was claimed that while it has worse compression, the speed can make it a worthy trade off.

> you want Chrome to re-add jxl behind a feature flag? Doesn't seem very useful.

Chrome has a neat feature where some flags can be enabled by websites, so that websites can choose to cooperate in testing. They never did this for JXL, but if they re-added JXL behind a flag, they could do so but with such testing enabled. Then they could get real data from websites actually using it, without committing to supporting it if it isn't useful.

> Also, all those Chrome offshoots (Edge, Brave, Opera, etc) could easily add and enable it to distinguish themselves from Chrome ("faster page load", "less network use") and don't. Makes me wonder what's going on...

Edge doesn't use Chrome's own codec support. It uses Windows's media framework. JXL is being added to it next year.

Mate, you're literally pulling something from your ass. Chrome engineers claim that they don't want JXL because it isn't good enough. Literally no one involved has said that it has anything to do with patents.