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.
"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?
> 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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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 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%.
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.
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.
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.
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.
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.
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.
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.
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.
Exactly, I'd upload a bunch of photos to Google Drive to download to my PC, Google Drive could open them fine, but the default windows photo viewer app would demand payment to open them.
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.
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!
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.
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.
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.
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.
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.
> 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)
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
Was just about to see if someone mentioned this video. Really good explanation comparing JPEG XL vs AVIF.
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.
Because there is no point, AVIF does not have inherently superior compression to JPEG XL.
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?
Buying Apple is a luxury in itself: don't expect them thinking about the non rich.
> 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.
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.
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?
Where did that come from? It feels like you’re working backwards from some bad feelings felt about Apple.
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.
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.
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.
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.
> 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.
It does seem odd to restrict new features to the latest models, especially when older ones still have powerful capabilities.
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.
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.
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.
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.
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?
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.
> 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.
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.
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.
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%.
The CPU isn’t used for encoding video
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
Exactly, I'd upload a bunch of photos to Google Drive to download to my PC, Google Drive could open them fine, but the default windows photo viewer app would demand payment to open them.
Well, Windows wouldn't display the HDR part of the image, so you're still not exactly seeing it.
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.
Yes, OP worded this a bit incorrectly. Open source, royalty-free standard would be better.
Thank god they went with a standard because when they went with a standard it wasn’t widespread?
What?
> 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.
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.
Some more recent developments around browser support: https://www.phoronix.com/news/Mozilla-Interest-JPEG-XL-Rust
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
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.
There's been JXL stuff visible in Windows 11 preview builds for months now. They might roll out support next year.
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.
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)
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?
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.)
ProRAW files are large, so there's more potential to save space, making ProRAW a more attractive feature to use for a wider audience.
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.
> Compared to JPEG XL, HEIC — an implementation of HEIF — is just not good.
I would've loved an explanation with this statement.
Isn't it a little early to write this article? They haven't tried the implementation yet.
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.
> Animated AVIF is widely supported, and can represent GIFs losslessly.
Doesn't lossless AVIF have terrible compression ratios?
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.
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.
For one you can't use Chrome to view those photos.
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.
Is part of the reason patents / licensing issues with HEVC that makes it harder to adopt?
They already adopted it 7 years ago so no.
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
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.
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.
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.
> 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.
> 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.
> The hard drive on my shelf isn't using any energy
But it is losing its data: <https://news.ycombinator.com/item?id=41244143>
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
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.
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.
> 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.
> 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.
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.
You guys do do read tests occasionally, and transfer the data old drives to newer drives right?
I hope you get two at least. Backups needed.
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.
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.