Archive for October 22, 2024

Tuesday, October 22, 2024

iPhone 16 Adds JPEG XL

Jeremy Gray (Hacker News, Reddit):

Apple and its various software iterations have supported JPEG XL for at least a year, including in Finder, Preview, Final Cut Pro, Pages, Photos, Mail, Safari, and more. Adobe has also supported the format for a while, including in Adobe Camera Raw and Lightroom Classic.

Despite JPEG XL supporting reversible JPEG transcoding and being superior to JPEG in terms of quality and efficiency, the format has yet to be widely adopted. Neither Chrome nor Firefox, two very popular web browsers, support the format natively, for example. Extensions are available to support JPEG XL files, but they’re not installed by default.

The JPEG XL community website cites the format’s ability to reduce file size while delivering “unmatched quality-per-byte.” Compared to a standard JPEG, a JPEG XL file is up to 55% smaller while providing a cleaner image that is visually lossless. Gone are typical JPEG artifacts.

[…]

As Apple explains on the new iPhone models, JPEG XL files are supported on iOS 17 and later and macOS 14 and later. However, as mentioned, these .jxl files are wrapped in a DNG container, so you can’t just fire off .jxl files from the iPhone 16 Pro.

Juli Clover (Reddit):

Compared to the HEIC format that Apple introduced several years ago, JPEG-XL supports both lossy and lossless compression. HEIC is a lossy format, and while it retains better quality than JPG images, pros will likely prefer JPEG-XL for zero image degradation. HEIC has never gained wide support, which has hindered its usefulness.

It sounds like Apple has only enabled Camera support for JPEG XL with the iPhone 16 family, not with iOS 18 generally. Is this because it depends on hardware acceleration that’s only available with the A18? However, iOS 17 and macOS 14 can read the files.

Also, although JPEG XL seems to be superior to HEIC, Apple is not offering it as a general choice alongside JPEG and HEIC. It’s only available when using ProRAW. This is all rather confusing.

Ryan Jones:

Photo settings have gone too far. WTF is happening.

Collin Donnell:

So JPEG XL seems flat out better than HEIC for images? I’m going to start saving all my film scans as 16 bit JPEG XL.

praseodym:

JPEG XL also supports re-encoding existing JPEG files to decrease file size while keeping the original file quality. That really seems like useful feature but so far I haven’t seen any tooling (in macOS) to re-encode my existing photo library.

Previously:

Update (2024-10-23): Florian Pircher:

A lot of confusion, as you mentioned, since the new iPhones don’t use JXL for storing regular images, just for raw images. It used to be that regular images are either JPEG or HEIF and raw images are DNG with the pixel data stored as lossless JPEG. Now, regular images are the same as before, but for raw images you can choose how the pixel data inside the DNG should be stored: lossless JPEG (as before), lossless JXL, or lossy JXL.

Most people who have heard of JPEG XL have only seen it used for regular (non-raw) images. And few people know about the lossless JPEG format that was used before for DNG pixel data.

Update (2024-10-28): Jon Sneyers (2020, via Hacker News):

This section highlights the important features that distinguish JPEG XL from other state-of-the-art image codecs like HEIC and AVIF.

morpheuskafka:

I found this interesting note in the article:

HEIC and AVIF can handle larger [than 35MP, 8MP respectively] images but not directly in a single code stream. You must decompose the image into a grid of independently encoded tiles, which could cause discontinuities at the grid boundaries. [demo image follows].

[…]

The newest Fujifilm X cameras have HEIC support but also added 40MP sensors--does this mean they are having to split their HEIC outputs into two encoding grids?

It seems like the iPhone avoided this, as 48MP output is only available as a “ProRAW” i.e. RAW+JPEG, which previously used regular JPEG and now JPEG-XL, but never HEIC.

Lightroom Classic 14

Agen Schmitz (release notes):

Adobe has issued Lightroom Classic 14.0, a big update with several new features. The release enhances the Generative Remove feature with improved selection and object detection for easier removal of unwanted objects and distractions; introduces Content Credentials to help secure digital assets by attaching credentials like digital signature, editing information, and more; adds denoise support for Linear Raw Digital Negatives (DNGs) to help reduce noise in high-resolution raw files, provides optimized tethering support with Nikon cameras (without Rosetta emulation); helps you to save disk space by setting the preview cache size limit; improves navigation and responsiveness in the Develop module[…]

Adobe:

Remove with Generative AI is now available with improved selection and object detection. Generative Remove lets you easily select and remove objects on complex backgrounds without any hassle.

Detect Objects lets you detect an object within the roughly brushed area to help you make a precise selection when you want to preserve as many details as possible from the scene.

I wish they would add better support for getting rid of Live Photos.

Previously:

Time Machine in Sequoia

Der Teilweise:

Backing up to a NAS currently says 3 days (!) left, after having backed up ~160GB. Was using WiFi with TX rate 133MBit.

Now I connected using Gigabit Ethernet, does not seem to be faster.

Plus: CPU usage is ridiculously high, fans spinning up to medium/max speed several times per hour.

[…]

I did not change all files on my disk …

Maybe they removed the alert that was shown when the backup got corrupted? Seems to be the case because I did not get that alert and all my old backups (on the NAS) seem to be gone.

[…]

So it seems like Apple indeed removed the confirmation dialog that they showed when they delete corrupted backups, taking away the chance to manually repair it.

I wonder whether this happened pre-Sequoia? Even on Sonoma, I would regularly have Time Machine backups where I would imagine that less than 50 GB changed, but it took all day to back up to a local hard drive. (Yet it wasn’t so slow that it seemed to be starting from scratch.) I wish Time Machine were better at showing which files are being copied and how the space is being used. (I guess some of this can be figured out using BackupLoupe.)

Miguel Arroz:

There’s some annoying bug in Sequoia that makes a Time Machine backup fail with an error “The backup failed because some files were not available”.

How on earth can files “not be available” on something running locally? And whatever it is, why isn’t Time Machine dealing with it properly? It’s all made by the same company. And it had all night to do whatever it has to.

I needed to have a current backup fresh in the morning, and now I’m sitting here waiting.

Der Teilweise:

I wouldn’t be surprised if the opendir bug described by @cdfinder is a race condition that also happens (more rarely) for local filesystems.

Previously:

Update (2024-10-23): Adam Chandler:

I recently had Time Machine issues on Developer beta where I wasn’t getting successful backups. I tried everything and finally disabling the MacOS Firewall fixed it for me.

MBP wired Ethernet to Synology using SMB on x.1 developer beta.

Kurt:

I don’t use my MacBook Pro (M1 Max running Sequoia) daily, but last night I went to use it and it was warm to the touch and the fans were at full blast. The process “diskimagesiod” was using 800% CPU. I also get the “files were not available” all the time with Time Machine. Super annoying.

Howard Oakley:

You can see files and progress in the log, easily accessible from T2M2’s Speed button during a backup.

Previously:

Update (2024-11-22): I and others have been having problems with Time Machine in Sequoia, where it’s copying files that don’t need to be copied, leading to unnecessary pruning of old backups. However, sometimes it gets wedged so that it can’t prune old snapshots and just reports that the backup failed. After restarting the Mac, it’s able to prune the snapshots again, though Disk Utility can’t show them.

Miguel Arroz:

Another thing that broke in 15.1 is ejecting disks now fails often because mds indexer holds a file open in them and just won’t let go. I keen to kill mds before ejecting the disks successfully. Fails on two Macs, both with Time Machine spinning disks and SSDs.

Update (2024-12-02): Jesse Squires:

Seems like Apple broke Time Machine in macOS 15 Sequoia because Time Machine doesn’t have Full Disk Access (or some other security theater permissions).

I am not seeing this particular problem.

Update (2024-12-19): Howard Oakley:

First full backups to SSD appear to run at higher priority to allow them to complete more quickly.

As a result, effective write speeds to SSDs during Time Machine backups are significantly faster than could be achieved to hard disks.

When the consequences of using APFS on hard disks are taken into account, storing Time Machine backups on SSD has considerable advantages in terms of both speed and longevity.

macOS 15.2 seems to introduce new problems, for both Time Machine and asr backups.

Previously:

Copyright © 2000–2024 Michael Tsai.