lonjil

The Microsoft patent doesn't apply to JXL, and in any case, Microsoft has literally already affirmed that they will not use it to go after any open codec.

You mean 30 years of listening to non-experts instead of experts. 30 years of listening to scientifically illiterate journalists who exaggerate and make stuff up to sell more papers or get more clicks, while refusing to listen to what scientists actually say.

Pretty much everything in that link is just random headlines, with zero connection to what the scientific consensus was in the listed years.

The parent commenter is incorrect. Yes, the JXL authors do want to try to use JXL as a raw format, but they are focusing on other priorities right now, so the specification for how JXL could be used as a raw format doesn't exist yet. But the format is flexible enough to allow for it, without backwards-incompatible changes.

Actually, lots of people were talking about it, and lots of people at big companies like Facebook were excited when Google added it behind a flag. Shopify even rolled out JXL to their storefronts not long after JXL was added to Chrome.

> Note how noone is asking Mozilla why Firefox won't support it or actually building websites using it.

People do ask why Firefox isn't supporting it, but the answer is obvious: because Chrome dropped it, and Firefox has what, 5% market share?

And people do use it on websites, you just didn't notice because companies like Nike don't tend to write up blog articles about how they're using a cool new image format.

You'll have to ask the person who wanted that.

I think you mean AVIF.

Lossy WebP has some crappy limitations. For example, it's limited to 4:2:0 chroma subsampling, which makes it unsuitable for high quality images. Hell, even if you restrict yourself to 420 JPEG, JPEG still comes out as having a higher quality ceiling than WebP. And yes, it does beat MozJPEG and libjpeg-turbo in file size sometimes, but newer JPEG encoders like jpegli crush WebP in size completely across the entire quality spectrum.

Mate, Apple has been using HEIC for over 6 years, but they didn't add it to Safari until less than a year ago. And Apple doesn't even want you to use HEIC on the web! They added it to Safari so that app devs can use it in WebViews.

> Apple also has a node advantage, which also makes their CPUs more expensive.

M2 is on TSMC N5. AMD's Zen 4 mobile processors are made with TSMC N4. From die shots, I believe the P-cores in the M2 are about the same size as Zen 4 cores. And yet Apple's M2 laptops are a good deal more power efficient than Zen 4 laptops.

> They did, but to get it running as well as they did they had to deviate from generic ARM by adding support for the x86 memory model in hardware.

Note that this is actually very cheap in hardware. All ARM CPUs already support memory accesses that behave similarly to x86. It's just that they're special instructions meant for atomics. Most load and store instructions in Aarch64 don't have such variants, because it'd use a lot of instruction encoding space. The TSO bit in Apple's CPUs is really more of an encoding trick, to allow having a large number of "atomic" memory instructions without needing to actually add lots of new instructions.

Here's a secret: a lot of the featurefulness of AMD's current Linux drivers is not due to AMD putting in the work, but due to Valve paying people to work on GPU drivers and related stuff. Neither AMD nor Nvidia can be bothered to implement every random thing a customer who moves maybe a million low cost units per year wants. But with open source drivers, Valve can do it themselves.

> This is the only part that seems to need to be low-level, anything else could be done at a higher one, generally EQ type settings like 'loudness'.

But that already is the only part that is low level. The EQ stuff is done with PipeWire.

Opus hasn't caught on for music and podcasts, but is very popular in some other areas. YouTube uses Opus heavily, for example, and its the default audio codec for webm video files. It's also very popular for real time audio like in video conferencing.

I can't find anything about the RP1 online, do you have a source?

Anything that can't supply 5V/3A is not a modern charger, that combination is mandated by USB-PD for anything that can provide 15W.

In actual real benchmarking OPi5 is about the same as RPi5.

It's more energy efficient than the RPi4, so you should be fine if you're doing fine with any of their older products?

Presumably due to higher taxes on sold goods in the UK?

It may be that whatever is currently bottlenecking RPi4 production isn't relevant to RPi5.

> My working theory is that the language standardisation effort invented the latter. So when people say C was always like this, they mean since ansi c89, and there was no language before that. And when people say C used to be typed/convenient assembly language, they're referring to the language that was called C that existed in reality prior to that standards document.

But the committee has always had a lot of C compiler developers in it. The people who wrote the C89 standard were the same people who developed many of the C compilers in use before C89. The people who created the reality prior to C89 created the reality after C89. Any perception of "portable assembly" probably stemmed simply from the fact that optimizers were much less sophisticated.

Note that XYB JPEG isn't the only way to increase the effective bit depth of the image. Using a typical color space but using a different transfer function such as Perceptual Quantizer or Hybrid Log-Gamma has a similar effect, and this is exploited right now. Take an HDR JXL file and tell djxl to decode it to a jpeg or a png, and you'll get a PQ-encoded file with an ICC profile containing the appropriate information for HDR rendering and for tone-mapped SDR rendering :)

> GDPR only covers personally identifiable data

the concept of 'personal data' under GDPR is quite broad. the mere presence of a username relates those messages to a possibly identifiable person. and asking for something to be deleted is asking for it to be deleted.

JPEG XL is a collaboration between a team at Google Research Zurich and Cloudinary. AVIF is no small part developed by Chrome developers. Treating Google as a unified monolith doesn't make any sense. It's perfectly possible for Chrome to behave like 90s Microsoft and for the Googlers in Zurich to do completely different things.

My Sony Xperia 10 IV lets you set it to never charge above 90 or 80 %, as an alternative to it learning your habits. I have it set to 80%, and I've been unable to use it up in under 2 days. I've heard that iPhones have similarly good battery life as the 10 IV, so it seems, to me, that get quite far on 80%.

An interesting difference with the WebP situation is that any app that uses Apple's codec framework on iOS/iPadOS, which is almost all apps that deal with images, will support JXL automatically.

Actually, I just downloaded a JXL via Safari, and after confirming that it was still a JXL, I tried using it in a context where JXL isn't supported, and it automatically turned into a JPEG.

But you can already do that. AVIF animations are regular AV1 videos. There is zero end user visible difference between what the above user is proposing and what AVIF does. Allowing webm in img tags would be identical.

Alliance of Open Media, the multi-company consortium that develops and promotes AV1 and AVIF.

JXL and HEIC/HEIF support are in the changelog for Safari 17. If you download the iOS or iPadOS 17 beta, JXL will work in pretty much all apps.

I agree on giving the Chrome people some space, the title here is ridiculous.

The JXL team at Google Zurich offered to take on JXL-related maintenance work in Chrome, but they were rejected.

Zink requires a fairly advanced Vulkan driver, with many complex optional extensions. A basic Vulkan driver wouldn't cut it. So getting basic OpenGL working is much less work, especially since they can share a lot of work with Mesa's existing OpenGL drivers.