Why Apple Uses JPEG XL in the iPhone 16 and What It Means for Your Photos(petapixel.com)
petapixel.com
Why Apple Uses JPEG XL in the iPhone 16 and What It Means for Your Photos
https://petapixel.com/2024/09/18/why-apple-uses-jpeg-xl-in-the-iphone-16-and-what-it-means-for-your-photos/
158 comments
That’s good news. I’ve watched a really good video in the last weeks about JPEG XL advantages, if you want to learn a bit more: https://youtube.com/watch?v=FlWjf8asI4Y
This may be a naive question but can't we have the features of JPEG XL combined with the compression algorithm of AVIF? Why does it have to be one or the other? Size clearly matters, especially for the majority of the world's population who do not have access to super fast internet and TBs of storage. It's definitely a luxury not having to care about file sizes.
Buying Apple is a luxury in itself: don't expect them thinking about the non rich.
AVIF is worse than JXL both for high fidelity compression and for lossless compression, which is what Apple is using JXL for here.
"Worse" in what sense? There are of course always trade-offs when compressing. In terms of size though even the reviewer from the above video - who says he much prefers JPEG XL - claims his AVIF compression lead to a very significant reduction in file size when testing his family photos. At a loss of detail that's negligible, or basically invisible for practical every-day purposes.
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?
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" in what sense?
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.
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.
You don't need to store two whole independent images. The high quality image can predict from the low quality image, and the low quality image can be a lower resolution, too. It is less efficient than storing one image, but more efficient than storing two independent images.
Was just about to see if someone mentioned this video. Really good explanation comparing JPEG XL vs AVIF.
To increase adoption they should not have limited this to the latest iPhone models. Why on earth can a one year old iPhone 15’s CPU not handle encoding JXL? It can encode 4K video in real time, so this should be no problem at all, right?
This is how they sell new phones. The grand majority of new features don't require the latest hardware, but artificially restricting it increases sales of new phones. None technical people can't usually tell the difference between hardware and software clearly enough to understand this nasty trick.
To be fair it’s less bad than what some other vendors are doing, which is stopping to provide updates. Not saying apple is an angel, they intentionally generate ewaste by withholding such features…
I spend a lot of time using my phone, and can afford the latest & greatest - but I use a 6 year old apple phone, because it's _perfectly fine_. A 10 year old apple phone is "just barely usable".
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"
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"
I don't think anyone is deciding to buy a new phone or not based on JPEG XL support.
From the article:
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.
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.
One of the tricks for achieving the target battery life is that photo and video formats are offloaded to dedicated and very power-efficient hardware in all mobile devices. The iPhone 16 is the first to get hardware offload for AV1 and JXL, which is why it'll support these formats.
It's not just software, unlike in the PC world where going from 5W hardware decode to 50W software decode basically doesn't matter.
It's not just software, unlike in the PC world where going from 5W hardware decode to 50W software decode basically doesn't matter.
Is that documented somewhere?
The "CPU" (that is, the generic compute part) cannot encode 4K video in real time, that part is handle by codec-specific HW.
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.
And we're not talking about video anyway, this is about ProRAW, a still image format.
> Zero chance that the new iPhone chip has hardware acceleration for JXL. Definitely just plain old CPU encoding.
Given apple design their own camera controllers and have their own chip design teams, I wouldn't be nearly so quick to conclude that.
Given apple design their own camera controllers and have their own chip design teams, I wouldn't be nearly so quick to conclude that.
I’d guess hardware acceleration could have something to do with it
I don't know, but my guesswork is that the DNG/ProRAW/JXL support comes with compatibility challenges. Limiting the size of the launch to well-informed photography prosumers and professionals will help to iron out the compatibility challenges — rather than make all confused consumers face these challenges at once.
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.
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.
In lossy mode I think there is no difference between AVIF, HEIC or JXL. AVIF is even a little bit ahead.
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.
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.
Last time I tested, libjxl e1 had a better compression ratio than default libpng, while being two orders of magnitude faster. See https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#the...
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.
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.
> 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.
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.
Agreed. At camera quality jpeg xl is far ahead in quality. Apple's last announcement is about camera quality, close to lossless kind of lossy. In this domain jpeg xl does not have real competition. AVIF and HEIC don't even support more than 12 bits of dynamics, and become slow when quality is increased.
>AVIF is definitely not ahead for the high quality levels you'd use in photography.
I read the parent's point of comparison in terms of speed, not quality.
I read the parent's point of comparison in terms of speed, not quality.
It does seem odd to restrict new features to the latest models, especially when older ones still have powerful capabilities.
Apple announced support for JPEG XL last year at WWDC; Apple's 1st party apps supported JPEG XL when iOS 17 shipped: https://developer.apple.com/wwdc23/10122
Regarding older hardware, I addressed that: https://news.ycombinator.com/item?id=41611709
Regarding older hardware, I addressed that: https://news.ycombinator.com/item?id=41611709
It’s good in a corporate setting, you don’t want to suddenly have to deal with a new file format for which you won’t have an app installed on your company PCs to view them.
This, I just don't understand why it seems only latest iPhones got this.
I also don't know, but I suspect the fact that Apple not only develops the OS, but also sells the devices, might have something to do with it...
Crystal clear case of faked obsolescence, a major cause for environmental damage.
Costing the planet our future sustainability in the name of greed.
And all you have to say about it is a snark?
Costing the planet our future sustainability in the name of greed.
And all you have to say about it is a snark?
Words mean things. Please use the right words.
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.
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.
> Words mean things. Please use the right words.
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?
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?
> 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.
"Nobody" - is that you speaking for everyone?
Stop it.
"Nobody" - is that you speaking for everyone?
Stop it.
I literally read someone on Twitter saying they wanted to upgrade from a 13 pro max to be able to have access to JPEG XL.
adityaathalyo, welcome to the club of people who cannot bring up ecological concerns about tech on HN.
adityaathalyo, welcome to the club of people who cannot bring up ecological concerns about tech on HN.
I will buy an iphone if it supports jpeg xl, and exactly because of that reason. ProRAW or DNG on top of jpeg xl, I wouldn't buy yet...
I actually commented exactly the same thing. [1] In full support of JPEG-XL.
[1] https://news.ycombinator.com/item?id=41538352
[1] https://news.ycombinator.com/item?id=41538352
This is not “fake obsolence”. Your old devices works exactly how they did before.
I will give you another unrelated example to demonstrate fake obsolescence on an iPhone. For example, on the iPhone 13 Pro Max, You cannot set the battery to stop charging at 80%. You can do this with the new iPhone. I don't remember either 14 or 15, but you can't do this with the 13 Pro Max. So can you say that the iPhone 13 Promax is actually supported for so many years with the latest and greatest iOS When apple doesn't actually bring these new features. Back to the older version of iPhone?
FYI, you can get most of the same effect on your 13 Pro Max by plugging your charger into a smart plug, and using Shortcuts to make an automation that turns off the smart plug whenever the phone battery goes about 80%.
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.
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.
By default all iPhones stop charging at 80%
The "stop at 80%" option is 15 and later.
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 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%.
This makes me think: If JPEG-XL needs more computing power to decompress, does that out weigh the ecological benefit benefit of the smaller file size?
JPEG XL is pretty cheap to decompress.
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.
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.
But how does the ecological benefit of space savings compare with the extra power consumption from compressing and decompressing?
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.
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.
You have an invalid assumption that extra power is spent on better compression or decompression. It generally takes less energy to decompress a better-compressed file, because the decompression work is mostly proportional to the file size. Energy for compression varies greatly depending on codec and settings, but JPEG XL is among the fastest (cheapest) ones to compress.
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.
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.
He also has an invalid assumption about RAW as well .
No, I did not. You did not understand the question I was asking.
The CPU isn’t used for encoding video
Encoding a single image with the CPU takes nothing compared to modern video codecs.
Burst mode captures 10 images per second, for encode demands of 120 MP/s. That’s half the throughput of 4k30.
Is there a cool down between bursts or can you do 10 a second for as many consecutive seconds as you like? You only have to get the images encoded and stored before the next burst starts, or at least before the user runs out of memory.
I’ve done bursts that lasted for 2 minutes.
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.
They might have some things like DCTs and colorspace transforms accelerated.
Reading the whole piece a few days ago, it's a pretty good overview of the promises of JPEG XL.
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.
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.
Attaching any significance to being “first” on open standards is a game Apple rarely plays, but which others impose upon them because Apple’s adoption is (rightly or wrongly) seen as the most consequential and/or most newsworthy inflection point.
In the specific case of JPEG XL I think Google support will be the real inflection point: no chrome and default android support is a deal breaker for wide audience content publishers.
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.
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.
>The ironic part being of course that Chrome used to support it way too early
Chrome never officially supported it and it was behind a flag for experimental role.
Chrome never officially supported it and it was behind a flag for experimental role.
… especially as petapixel already spotted Samsung adopting JPEG XL months before Apple.
JPEG XL was added to iOS 17 and macOS 14 last year [1].
[1]: https://developer.apple.com/wwdc23/10122
JPEG XL was added to iOS 17 and macOS 14 last year [1].
[1]: https://developer.apple.com/wwdc23/10122
In terms of JPEG XL Lossless, Camera makers are already or has plan to adopt the format as RAW. In that space I think the adoption roadmap is quite good.
Thank god they went with a standard this time. When they launched HEIC, there wasn’t a single workable open source decoder. Hell, there wasn’t even a single non-Apple decoder.
XL color depth looks amazing.
XL color depth looks amazing.
An annoying oversight is that while my Fujifilm camera is modern enough to shoot HEIF+RAW, Apple Photos only knows to group JPEG+RAW as a single photo. Because Apple did not spend a day of engineering time bringing feature parity for the file format they themselves promoted, it has turned into a bigger feature to match and merge the HEIF and RAW assets after the fact. After several years, I'm growing doubtful they'll ever accomplish it.
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.
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.
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.
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.
Thank god they went with a standard because when they went with a standard it wasn’t widespread?
What?
What?
HEIC is a standard too - it wasn’t a secret internal Apple project…
It might be a standard, but for a long time the licensing costs were exorbitant, and that likely stifled adoption. While licensing costs have come down, the pushback against HEIC’s pricing led to the development of better, royalty-free alternatives—including JPEG XL. Thank god they went with an unencumbered standard this time.
Windows showing you a popup saying you need to buy a £0.79 windows add on to just open photos taken with an iPhone was always unbelievable. Like some kind of malware or something.
Haha, that's rich. I have never seen this popup (haven't had the use case), was it this one?
https://helpdeskgeek.com/wp-content/pictures/2020/10/02-HEVC...
https://helpdeskgeek.com/wp-content/pictures/2020/10/02-HEVC...
Yep, that's the one.
In what context was thisnprompt appearing. I can not think of a time I have ever struggled to be able to open a photo from my iPhone in any of the apps I commonly use. Is this a Windows application issue or an OS issue, and how were the photos coming to your machine?
Just to clarify, this is an honest question not sarcasm.
Just to clarify, this is an honest question not sarcasm.
If you directly download the HEIC photos to your windows PC.
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.
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.
Not really. It was a 2 company colab with a pseudo spec. But their implementation had quirks that weren’t in the spec, and weren’t documented anywhere.
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.
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.
Yes, OP worded this a bit incorrectly. Open source, royalty-free standard would be better.
> these .jxl files are wrapped in a DNG container, so you can’t just fire off .jxl files from the iPhone 16 Pro.
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.
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.
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.
You wouldn't want 24MB files with GPS and face detection metadata served raw on the Web anyway.
I wouldn't want them on my phone either, but maybe that's just me.
Serving images from CDNs is not the only use case for browser JXL support. Browsers can perform client side processing of images before upload. They even host fully featured image editors like https://photopea.com. And sometimes you do want to see an original image from your camera in your browser, like say on the web version of Google Photos.
Of course it’s .dng; .jxl doesn’t carry the metadata needed to process a RAW image because it’s not intended for that.
Which metadata exactly? Is the actual concern that someone unaware might accidentally stumble on the unprocessed image?
To start with, without a linearization table, white and black levels, how exactly do you expect sensor data to be usefully interpreted?
Well, I assumed Exif and embedded color profile would have been expressive enough for this. I do agree I'm a bit out of my depth when it comes to raw photo data but Exif seemed to have properties for everything, even counting the kitchen sinks in the image.
Where did that come from? It feels like you’re working backwards from some bad feelings felt about Apple.
Hmmm, is the jpeg xl data inside the dng not demosaicized?
Some more recent developments around browser support: https://www.phoronix.com/news/Mozilla-Interest-JPEG-XL-Rust
Weirdly enough, JPEG-XL support is actually fairly decent in Firefox already and there were patches developed by the community that work well for things such as color profiles, animation support etc. I’ve had them in Waterfox for a few years now - it was a purely “political” decision, if you want to call it that, to stop any more progress until recently.
Man this back and forth is really frustrating.
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.
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.
> 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.
There's been JXL stuff visible in Windows 11 preview builds for months now. They might roll out support next year.
Use Jpegli for now. You can get half the benefits of JPEG XL with it.
Firefox Nightly is listed as supported on the jpegxl.info web site. My understanding is that it does not fully support the specification yet which is why it is not released to production.
https://jpegxl.info/resources/supported-software.html
https://jpegxl.info/resources/supported-software.html
> Compared to a standard JPEG, a JPEG XL file is up to 55% smaller
I still find JPEG "XL" to be such a bizarre name. I would intuitively think it would result in larger file sizes.
I still find JPEG "XL" to be such a bizarre name. I would intuitively think it would result in larger file sizes.
JPEG XL is a great name from a marketing perspective. The Apple roadmap has several successor compressors with AI elements in the planning sheet - JPEG XL PLUS, JPEG XL MAX. These formats will have small nominal yearly licensing fees to use. Finally, the most advanced format will be JPEG XXXL which they are developing in collaboration with pornhub.
What exactly has Apple to do with the name of JPEG XL?
The XL probably relates to the fact that the relative savings increase with higher res pictures. Whereas original jpeg's file size might have scaled linearly, jxl could do better than that.
Lets just call it JPEG 40 to avoid any confusion.
Even weirder, L stands for legacy.
Although it might seem confusing at first glance, having your selling point as "our file sizes are larger!" is so counterintuitive, that I think it's obviously not that!
Sometimes it can be like "our file sizes are larger, but look at this big list of cool features".
Bigger is better, it is known.
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.
This is why I consider JPEG XL to be the standardized successor to Dropbox's Lepton https://github.com/dropbox/lepton
It’s actually even better, it’s supposed to be reversible. You want you jpeg file back? There you go.
It would be safe to assume that Apple will eventually add a way to recompress your photo library to JXL… if they weren’t in the business of selling storage and cloud storage. They have in the past released tools to optimize storage so it wouldn’t be completely out of the ordinary, but… I wouldn’t hold my breath.
Sigh. I’ll happily hold my breath. Apple has done plenty to reduce use of storage. They even give you free iCloud storage to back your phone up when transferring to a new device. A very clear attractive source of penny pinching that they’ve put effort into to leaving on the table. This is tiring.
Not just the original file quality, it's exactly the same image but (losslessly) compressed better.
> but so far I haven’t seen any tooling (in macOS) to re-encode my existing photo library
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)
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)
I don’t have iphone 16, and this article puzzles me.
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?
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?
ProRAW files are large, so there's more potential to save space, making ProRAW a more attractive feature to use for a wider audience.
DNG spec added JPEG-XL as their modern codec. Both lossy and lossless modes are significantly better than the other 3 allowed codecs (JPEG, lossless JPEG, and zip.)
How does JPEG XL compare to Apple’s current default HEIC? Is HEIC eventually going away in favor of JPEG XL?
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.
Ok wow, that was not clear from the article. It also seems kind of confusing and unfortunate that Apple is using so many different image formats.
> Compared to JPEG XL, HEIC — an implementation of HEIF — is just not good.
I would've loved an explanation with this statement.
I would've loved an explanation with this statement.
For one you can't use Chrome to view those photos.
note: the format was co-developed by Google who also makes Chome.
note: the format was co-developed by Google who also makes Chome.
I don't think you can use Chrome to view any raw image files...
Indeed, but Chrome removed support for the format some time ago.
Isn't it a little early to write this article? They haven't tried the implementation yet.
Isn’t Samsung generally ahead of apple on most technical fronts though? Especially on mobile, I think people usually just assume apple just spends more effort on refining it, which is not a bad rule of thumb, but certainly not always the truth.
I can’t wait for animated JPEG XL to replace animated GIF.
Animated AVIF is widely supported, and can represent GIFs losslessly.
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.
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.
> Animated AVIF is widely supported, and can represent GIFs losslessly.
Doesn't lossless AVIF have terrible compression ratios?
Doesn't lossless AVIF have terrible compression ratios?
You'd use lossless blocks for really simple pixel art that the GIF was made for. For GIFs made from video clips, you can apply regular video compression and decimate their size.
Well, most "GIFs" already really aren't that. Most image hosters already convert to and serve a silent looping h264 in it's place.
You could already use apng and the file size isn't too bad.
You may be waiting a while. APNG and animated WebP are already widely rolled out, but haven't replaced GIF.
Neither of these are well supported at all. APNG has a whole history of non-support by major browsers and animated WebP doesn't even have its own mime type so you can't fall back to gif/apng if support is not there - and support for webp does not guarantee support for animated webp. Both are also decidedly mediocre improvements over gif (which is quite the accomplishment considering how shit gif compression is).
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.
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.
They're both probably decades ahead of JXL. APNG has 96% browser support on caniuse after a surprise come-from-behind on Apple.
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.
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.
please tell me this means chromium will un-drop jxl and we can just stick them on the web like png/jpg/gif
Cries in iPhone11Pro … also WTF!? Why not make QOK format and x266 available and exclusive to iPhone17
[deleted]
Yes, yes, but 48mP only, when will they finally have 240MP on a sensor that can be mounted on the ass of an ant. But double the protrusion 6 times I guess for the lens supporting the new tech and whatnot (tele-macro at night in a panoramic sport event!), it may even take picture for you without thinking taking a picture, you purchased a smartphone didn't you, let it be smart then, it will know better than you what you need, how you need it, and when you need it, all is necessary to fix it to your forehead so it can see what you see, tiny bitsy inconvenience beyond storing and managing the billboard sized but polaroid quality stream of pics vomited out by the device - never to see the most.
This good photo = phone deception marketers pushed on idiotic customers who actually pay the premium for the marketing material is pathetic.
This good photo = phone deception marketers pushed on idiotic customers who actually pay the premium for the marketing material is pathetic.
The article states that because the file sizes are smaller the format is more environmentally friendly because, they state, "All that stuff lives somewhere, and wherever it is, it requires energy to operate."
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.
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.
You encode the image once, but transmit it many, many times, in general. It it send from phone to iCloud, then from iCloud to your other apple device and so and so on. God forbid you share it with someone. Then iCloud has internal resiliencies and redundancies, etc. etc.
Short point: I do think it’s environmentally better (or less worse). it’s a drop in the ocean though.
Short point: I do think it’s environmentally better (or less worse). it’s a drop in the ocean though.
On the other hand, we have industry defined standards to compress TCP headers [1] - incurring a cost to compress/decompress but resulting in lower packet sizes.
[1] https://en.wikipedia.org/wiki/Robust_Header_Compression
[1] https://en.wikipedia.org/wiki/Robust_Header_Compression
Most iPhone users would be storing photos in iCloud.
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.
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.
What is environmentally (OK, mentally) unfriendly to me is the creation of new formats that various apps, and notably, websites where I post images, can't handle, so I swear a bit, convert the image to jpeg or png, and post.
People are part of the environment, too!
But lo! men have become the tools of their tools. ... Thoreau.
People are part of the environment, too!
But lo! men have become the tools of their tools. ... Thoreau.
You wouldn't like a website that accepted raw phone photos, because they're in HDR, and you'd get blinded by looking at them.
Instagram already does this to me when I look at it at night, because it accepts HDR video.
Instagram already does this to me when I look at it at night, because it accepts HDR video.
I'm still dealing daily with webp. I get a link to one and post the link, and the site does not render it.
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.
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.
> The hard drive on my shelf isn't using any energy.
When it filled up you put it on a shelf and bought a new one.
When it filled up you put it on a shelf and bought a new one.
That's essentially what I do with my RAW files. One hard drive per year. It's still less expensive than every cloud storage I looked at.
> Are they storing all of their images in RAM?
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.
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.
> Are they storing all of their images in RAM?
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.
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.
> 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.
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.
If people are going to take credit for crunching something down from 10 MB to 8 MB, I wish they'd also take the blame for massively bloating something into a modern monstrosity out of sheer laziness or betting that profit margins will be higher if they waste user time, storage, and cpu for the sake of releasing the project faster.
This whataboutism we are hearing now about "the energy needed to store your pictures" is just corporate whataboutism, trying to push blame onto consumers.
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.
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.
> The hard drive on my shelf isn't using any energy
But it is losing its data: <https://news.ycombinator.com/item?id=41244143>
But it is losing its data: <https://news.ycombinator.com/item?id=41244143>
[deleted]