lonjil

I don't think you can use Chrome to view any raw image files...

> Animated AVIF is widely supported, and can represent GIFs losslessly.

Doesn't lossless AVIF have terrible compression ratios?

They aren't switching from HEIC to JXL. Apple uses HEIC for regular photos, but they use DNG with Lossless JPEG for "ProRAW". They are switching the latter to use JXL inside DNG instead of L-JPEG.

> So Google killed XL a while ago already and I feel like either Microsoft or Mozilla at least considered following suit.

There's been JXL stuff visible in Windows 11 preview builds for months now. They might roll out support next year.

Apple's ProRAW format is Linear DNG, that is to say, already debayered, not what most people would call "raw". Previously they've used Lossless JPEG for compression inside these DNG files, but now they use JXL.

The DNG spec also allows for using JXL to compress proper raws, but I don't know if anyone is doing this yet. I know Samsung uses JXL compression in DNGs produced by their phones, but I haven't checked if those are proper raws or debayered.

There's literally no way Apple developed a hardware accelerator for JXL encoding. So they're definitely using some kind of a CPU or generic DSP.

> In lossy mode I think there is no difference between AVIF, HEIC or JXL. AVIF is even a little bit ahead.

AVIF is definitely not ahead for the high quality levels you'd use in photography. AVIF is ahead at lower quality levels.

> For lossless mode, JXL's fast modes (-e1 and -e2) are fast. But their compression ratio is terrible.

JXL lossless e1 is still a lot better than the lossless compression people tend to use for photos these days. Like Apple has been using Lossless JPEG, which sucks.

They aren't doing JXL encoding in hardware though. Zero chance that the new iPhone chip has hardware acceleration for JXL. Definitely just plain old CPU encoding.

And we're not talking about video anyway, this is about ProRAW, a still image format.

Adobe added JXL as a compression option for the DNG format last year. Previous options were JPEG, Lossless JPEG, Deflate, and nothing. Apple used Lossless JPEG. Apple engineers have decided to take advantage of the option Adobe added last year to make their DNG files smaller.

AVIF is worse than JXL both for high fidelity compression and for lossless compression, which is what Apple is using JXL for here.

One aspect may change (file size) while another remains the same (the actual data you get when you read the file).

> Why make the distinction if there is no difference?

There is a difference, which is that the compressed lossless version is smaller and requires some amount of processing time to actually be compressed or uncompressed. But there is zero difference in the raw camera data. After decompression, it is identical.

> If a computer compresses and expands the image using an algorithm you are not getting back the same image. Period. I do not care if you perceive it to be the same, it is not the same.

It is the same. You can check each and every bit one by one, and they will all be identical.

ZFS can help you with backups and data integrity beyond what RAID provides, though. For example, I back up to another machine using zfs's snapshot sending feature. Fast and convenient. I scrub my machine and the backup machine every week, so if any data has become damaged beyond repair on my machine, I know pretty quickly. Same with the backup machine. And because of the regular integrity checking on my machine, it's very unlikely that I accidentally back up damaged data. And finally, frequent snapshots are a great way to recover from software and some user errors.

Of course, there are still dangers, but ZFS without backup is a big improvement over RAID, and ZFS with backups is a big improvement over most backup strategies.

> If Apple is giving you JPEG-XL they are compressing the file, so it is not RAW.JPEG-XL is lossless compression.

Are you unaware that most DNG files are compressed using Lossless JPEG? Including ones that are storing raw sensor data rather than debayered data like ProRaw?

That number includes all the different extra tools in the repo, and all tests. And as mentioned, the encoder.

You've got it backwards. Before M1, most Macs that regular consumers owned were incredibly bad GPU-wise. M1 was an enormous upgrade and finally made Mac usable for gaming for the average Mac owner. But years of most Macs being useless for gaming drove the game devs away.

> Firstly, several games engines and rendering libraries support it.

So? If no one is using that support to ship PC games using Vulkan, who cares? Those same engines all support Metal, so clearly this is irrelevant to the question of Mac gaming.

Did you paste the wrong link? That is about M1 Max, which is a very different, much bigger, chip.

> Though, I don't see true sideloading (like on Android) specified. If apps still need Apple's approval, we will get "freedom" who to pay, not what to run. I still don't see device liberation within the scope of the DMA.

But if Apple abuses its position as platform gatekeeper with the app approval process and rules, the EU will probably slap them down. The DMA doesn't care about device liberation, but it does care about fairness, so Apple will probably only be allowed to continue this if they act in very good faith towards 3rd parties, which doesn't seem like an Apple thing to do.

> The other CPU catch back after several months, the Apple Silicon is a good marketing prowess, the reality is that Apple CPUs wins because they are the first on to be produced on a new lithography node, because Apple can book a larger quantity than anyone else.

Uh, but M2 on TSMC's N5 node is faster and more efficient than AMD's products fabbed with TSMC's N4 node. Edit: more efficient in general, but I meant "faster" in comparison with AMD's latest laptop chips.

> Here Jim Keller explain why CPU architecture doesn't matter a lot in performance now: https://www.anandtech.com/show/16762/an-anandtech-interview-...

Let's see what he has to say:

> But instruction sets only matter a little bit - you can lose 10%, or 20%, [of performance] because you're missing instructions.

20% is quite a lot in the current competitive landscape. Jim Keller is stuck thinking like it's 10+ years ago.

That 50m+ figure is surely iPads in general, rather than iPads Pro? iPad Pro is specifically marketed to media production professionals as a viable replacement for a laptop, but media production professionals (like the aforementioned tech youtuber) again and again complain that it isn't good enough. It's certainly good for some professional tasks, like drawing, but it seems lacking for things like video editing.

I recently noticed that all the thumbnails on my computer are PNG, which I thought was funny.

> Their claims about Jpegli seem to make WebP obsolete regarding lossy encoding? Similar compression estimates as WebP versus JPEG are brought up.

I believe Jpegli beats WebP for medium to high quality compression. I would guess that more than half of all WebP images on the net would definitely be smaller as Jpegli-encoded JPEGs of similar quality. And note that Jpegli is actually worse than MozJPEG and libjpeg-turbo at medium-low qualities. Something like libjpeg-turbo q75 is the crossover point I believe.

> Hell, I question if AVIF is even worth it with Jpegli.

According to another test [1], for large (like 10+ Mpix) photographs compressed with high quality, Jpegli wins over AVIF. But AVIF seems to win for "web size" images. Though, as for point 2 in your next paragraph, Jpegli is indeed much faster than AVIF.

> JPEG XL would've still been worth it though because it's just covering so much more ground than JPEG/Jpegli and it has a streaming decoder like a sensible format geared for Internet use, as well as progressive decoding support for mobile networks.

Indeed. At a minimum, JXL gives you another 20% size reduction just from the better entropy coding.

[1] https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front

All the developers involved are part of the JXL team at Google Zürich, as far as I can tell.

Jpegli, of course, does this when you ask for 8 bit output.

> Not sure if you are part of the research team but a follow up question nevertheless.

I am not.

> what would it take to develop another widely supported image format? Would the research stage already need to be carried out as a multi-corporate effort?

I believe JXL will be very successful sooner or later, it already has a lot more support than many other attempts at new image formats.

But in general, the main way to get fast adoption on the web is to have Chromium's codec team be the main developers.

Jpegli encoded images decode just fine with any JPEG decoder, and will still be of great quality. All the tests were done with libjpeg-turbo as the decoder. Using Jpegli for decoding gives you a bit better quality and potentially higher bit depth.

8-bit JPEG actually uses 12-bit DCT coefficients, and traditional JPEG coders have lots of errors due to rounding to 8 bits quite often, while Jpegli always uses floating point internally.

It's regular old JPEG1. I don't know the details, but it turns out that "8 bit" JPEG actually has enough precision in the format to squeeze out another 2.5 bits, as long as both the encoder and the decoder use high precision math.

Not sure what the rate is, but Asahi Linux uncovered FS corruption on MacBooks. Before you can install Asahi, you have to do a fsck, and a bunch of people reported failures with that step.