Why Apple Uses JPEG XL in the iPhone 16 and What It Means for Your Photos
petapixel.com
petapixel.com
This seems to track with other comparisons I've read as well. Some claim even larger size reductions, depending on the source files. The main issue with AVIF seems to be slow loading, which granted is a real problem for web use in places with slow connections (as is file size!). 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. Is there a technical reason?
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.
I don't think that hardware support plays a role here. The fastest encoding modes of JPEG XL are ridiculously fast on software, and Apple's CPUs seem powerful enough.
For lossless mode, JXL's fast modes (-e1 and -e2) are fast. But their compression ratio is terrible. The higher levels are not usable in a camera in terms of speed. Of course, my favorite and many people's favorite in this regard is HALIC (High Availability Lossless Image Compression). It is a speed/compression monster. The problem is that for now it is closed source and there is no Google or similar company behind it.
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.
I read the parent's point of comparison in terms of speed, not quality.
The point of reference here is not PNG but lossless JPEG, which was the best available option in DNG before version 1.7 of the DNG spec. Lossless JPEG compresses worse (but faster) than PNG.
I don't know how HALIC works but if there is no FOSS implementation available that seems like a no-go.
Costing the planet our future sustainability in the name of greed.
And all you have to say about it is a snark?
I think you are thinking of the "optimized charging" option, which tries to guess how long you will be leaving the phone on the charger and then pauses when it reaches 80% until it gets near the time it thinks you are going to take the phone off the charger and then charges up to 100%.
I use that on my 10th generation iPad and used it on the iPhone X that I had up until about two months ago when it got replaced with a 15 which does support the "charge to 80%" option. It works great.
The only minor annoyance I ran into was that the phones where the OS supports the 80% limit it will occasionally go to 100%, which they say is necessary to keep the battery level indicator calibrated. With the smart plug method you'll have to handle occasionally disabling the shortcut (or charging with the charger plugged straight into the outlet).
Just make sure to pick a smart plug that can be turned off from Shortcuts.
1. As another commenter points out, your device works exactly as it did before.
2. Nobody on the face of the earth is making a decision about whether or not to buy a new phone based on JPEG-XL support. The fact that you’d even entertain that either means you’re in too much of a bubble or you’re so blinded by Apple hatred that you’re willing to believe any contrived thing that paints the company in a negative light.
Stop it.
"Nobody" - is that you speaking for everyone?
Stop it.
adityaathalyo, welcome to the club of people who cannot bring up ecological concerns about tech on HN.
What the ... You are ignoring what I wrote while not contributing anything. What did you fail to comprehend? You should be addressing what I wrote. Apparently many other commenters did understand me. What does that tell us? You are just being a jerk.
> Stop it.
Seriously. You are not discussing things, and you are not sharing an opinion here. You should be the one taking a break and consider your behavior.
How does it feel defending one of the richest companies in the world, and realizing they wouldn't care if you dropped dead?
Regarding older hardware, I addressed that: https://news.ycombinator.com/item?id=41611709
When I was in the android ecosystem, a 4 year old phone was "just barely" usable, and phones stopped being "fine" after about two years.
I'll give apple shit for a lot of things, and they could definitely do _more_ about e-waste... but this is as likely to be "we put the image encoder on the camera module, so it would have been slightly more work to backport to old phones"
It's not just software, unlike in the PC world where going from 5W hardware decode to 50W software decode basically doesn't matter.
And we're not talking about video anyway, this is about ProRAW, a still image format.
Given apple design their own camera controllers and have their own chip design teams, I wouldn't be nearly so quick to conclude that.
Advancements in compression algorithms also came with advancements in decompression speed. New algorithms like tANS are both compressing well, and have very fast implementations.
And generally smaller files decompress faster, because there's just less data to process.
And will people take more pictures because of the space savings leading to more power consumption from compressing and decompressing the photos?
Is this just greenwashing by Apple?
But I have now decided to take my photos off of Apple's servers as well as to take way way less photographs, if any. The climate of my near future is way more important than a photograph of my cat.
Secondly, you have an invalid assumption that the amounts of energy spent on compression have any real-world significance. Phones can take thousands of photos when working off a tiny battery, and most of it is spent on the screen. My rough calculation is that taking over a million photos takes less energy than there is in a gallon of gas.
Apart form that, compression cost is generally completely ignored, because files are created only once, but viewed (decompressed) many many times over.
Smaller files save storage space. Storage has costs in energy and hardware.
Smaller files are quicker to transfer, and transfer itself can be more energy intensive than compression. It's still small in absolute numbers.
As Apple explains on the new iPhone models, JPEG XL files are supported
on iOS 17 and later and macOS 14 and later.
The difference is JPEG XL is now part of the Apple's image pipeline for the camera in iPhone 16.
Any 3rd party photo app developer can support JPEG XL if they wish.
Apart from that, Apple's POV and PR bits being given such a central role felt a bit weird, especially as petapixel already spotted Samsung adopting JPEG XL months before Apple.
Aside from the petty "who was first" bickering, it's a completely different move to adopt a common standard already accepted by rival companies on the android side, and it means we can really expect a larger adoption of JPEG XL than the other standards Apple just pitched on its own.
That was the biggest beacon of hope IMHO, it would have benefited from more prominence.
The ironic part being of course that Chrome used to support it way too early, but support was dropped as nobody followed. So yes, Apple support is a big deal, but not more consequential than the other actors of the pretty vast ecosystems.
Chrome never officially supported it and it was behind a flag for experimental role.
JPEG XL was added to iOS 17 and macOS 14 last year [1].
XL color depth looks amazing.
I have yet to see whether they did it right with JXL+RAW (or is it DNG+RAW?) but hopefully they will before it becomes available in mainstream cameras.
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.
What?
Just to clarify, this is an honest question not sarcasm.
The iPhone tends to convert to jpeg whenever you email/whatsapp/etc a photo, so it's only direct file import that nets the original HEIC file.
https://helpdeskgeek.com/wp-content/pictures/2020/10/02-HEVC...
We spend a week building a decoder and kept finding new undocumented bits.
I wouldn’t call it a standard when zero folks outside Apple had access a reliable decoder at launch.
Any move toward JPEG XL support is good, but this is lame. Even if the Chrome team comes to its senses and restores jxl support you won't be able to view these files.
So Google killed XL a while ago already and I feel like either Microsoft or Mozilla at least considered following suit. After Apple has done heic for a while now I assumed it might go that way regarding a jpeg replacement, but now they did a 180 and switched to xl. I mean good, it's not as patent encumbered, but wtf am I supposed to expect for the future now? Will Google add XL back to chrome? I guess it will take another decade or five until we have a jpeg replacement that's being universally agreed upon, because come on, it would be too easy if we don't get another plot twist where a major player jumps onto something else again for a while.
There's been JXL stuff visible in Windows 11 preview builds for months now. They might roll out support next year.
I still find JPEG "XL" to be such a bizarre name. I would intuitively think it would result in larger file sizes.
On Linux you can re-encode every single .jpg to .jxl and they'll decode bit-for-bit, to the original .jpg.
On Debian and derivatives it's the libjxl-tools: the cjxl executable converts to .jxl and the djxl decompresses.
Works flawlessly.
P.S: as a sidenote there's zero reason anymore to serve a .jpg file to a browser when the browser supports .jxl files. That's just a waste of bandwith. (and if your stack cannot serve different files depending on the users' browsers' capacities, it's not much of a stack)
Is apple only using jxl for their “raw” camera capture, but not regular camera capture?? The non-raw use case seems to be the one that would have more impact to regular folks.
Why? Is jxl inferior to HEIC?
I would've loved an explanation with this statement.
note: the format was co-developed by Google who also makes Chome.
Really, animated WebP has little reason to exist. At least the lossy version should really just be a video file with no audio track and a convention for the loop metadata. Too bad that browsers decided to create yet another format (with intentionally crippled compression compared to webm) rather than allow silent videos in <img> tags.
The main reason for using GIF these days is you're on some platform where that's your only choice, so JXL is unlikely to change the status quo much.
BTW, Chrome vetoed the idea of supporting muted video files in `<img>` like Safari does, so we've got this silly animated AVIF that is a video format that has been turned into a still image format that has been turned back into a video format, which takes regular AV1 video data but packages it in a slightly different way, enough to break video tooling.
Doesn't lossless AVIF have terrible compression ratios?
This good photo = phone deception marketers pushed on idiotic customers who actually pay the premium for the marketing material is pathetic.
Cold storage exists, as well as different tiers of storage. The hard drive on my shelf isn't using any energy. Are they storing all of their images in RAM? Maybe you could say this would lead to less use of storage space so less use of raw materials for storage devices.
I would posit that it is possible this format is less environmentally friendly because it takes more compute cycles to produce the output from the compressed data, but I have no real insight into this just intuition.
And most professionals are storing their photos in Creative Cloud.
And in both cases the photo data would be replicated on multiple hard drives for redundancy. So it would definitely be more environmentally friendly to have smaller photos.
The more important reason is that cloud storage costs significantly more than local.
People are part of the environment, too!
But lo! men have become the tools of their tools. ... Thoreau.
Instagram already does this to me when I look at it at night, because it accepts HDR video.
I have to download, convert, and upload to an image hosting site.
The site has two admins dealing with twitter gyrations, "Threads" and possibly Mastodon, besides the daily chores and intruder nonsense.
My phone and cameras are kind enough to give me jpegs.
When it filled up you put it on a shelf and bought a new one.
That part would not matter regardless. RAM is powered at all times, kept being refreshed too. Unless, of course you mean, they'd have to keep buying new machines to store more pictures.
Consider the millions of iPhone users uploading new photos and scrolling their iCloud-hosted photo library. A substantial amount of photo data is in RAM at any given moment, spread across many network devices.
> I would posit that it is possible this format is less environmentally friendly because it takes more compute cycles
I'm curious how much energy it takes to send bits over cellular or wifi, my intuition is that this is orders of magnitude higher than compression or encoding.
Correct, but the computational cost of decoding a codec is generally correlated with the number of bits. So JXL is not necessarily more expensive to decode than older codecs, if it compresses better.
Let's say you have 2 TB of photos stored. If that's consuming more than 2 watts of electricity on average, the cloud providers have to be quite incompetent (they are mostly not).
2 watts is 1 kWh in 20 days, so 18 kWh in one year. The emissions from 18 kWh in the US is around 6 kg of CO2. This is the equivalent of driving a car for about 20 minutes on the highway, one time per year. Or spending 5 minutes longer in the shower 4 times per year.
But it is losing its data: <https://news.ycombinator.com/item?id=41244143>
Short point: I do think it’s environmentally better (or less worse). it’s a drop in the ocean though.