3 ms·

> Apple is clearly not interested They have made no such statement AFAIK. The fact that they adopted AVIF relatively swiftly, and generally improved their cade

> Apple is clearly not interested They have made no such statement AFAIK. The fact that they adopted AVIF relatively swiftly, and generally improved their cadence a bit, makes me ready to not be surprised if they ship JPEG XL in a year or two.

JyrkiAlakuijala 4y ago
Apple is a company that cares deeply about usability. Once JPEG XL reaches critical mass in photography or creative work (video mastering, image processing, graphics and similar), Apple will very likely be the first to add support. Their users much rather have a thumbnail than a stock icon for photographs and graphics. I wouldn't be surprised if JPEG XL support would be announced by mid 2023.
pigsty 4y ago
Apple dragged their feet on introducing webms to Safari and they still often require fiddling with to get working on iOS. If Apple isn’t jumping at supporting a format, it’s generally safe to assume they’ll do all they can to not support it unless the pressure is overwhelming. Which doesn’t seem to be the case with this format.
masklinn 4y ago
> The fact that they adopted AVIF relatively swiftly Can be linked to Apple being a governing member of AOM. > and generally improved their cadence a bit, makes me ready to not be surprised if they ship JPEG XL in a year or two. Feel free to hold your breath, but I don't think that'll be good for your health. The webkit bug for AVIF was opened in February 2020, an "initial support" patch was proposed in May, support was merged in March 2021. Apple separately shipped the decoder[0] in iOS and macOS in September/Octoboer 2022, and enabled the feature for Safari. The webkit bug for JXL was opened in February 2020. That's about all that's happened to it. Reaction has been: - Webkit is not super interested in adding a bunch of third-party unsafe code[1] - Safari support requires OS support, which is non-existent for JXL[2] [0] Webkit on non-apple platforms can use Webkit's decoders, on Apple platforms it uses CoreGraphics, though as seen with HEIF having CG support doesn't mean Apple enables the format in Safari. [1] https://lists.webkit.org/pipermail/webkit-dev/2021-May/031846.html https://lists.webkit.org/pipermail/webkit-dev/2021-May/03184... [2] https://lists.webkit.org/pipermail/webkit-dev/2021-May/031851.html https://lists.webkit.org/pipermail/webkit-dev/2021-May/03185...
- dieulot 4y ago
  They’re working on ending the OS-parity nonsense with AVIF. https://webkit.org/blog/13584/release-notes-for-safari-technology-preview-158/#:~:text=Enabled%20AVIF%20image%20decoding%20for%20macOS%20Monterey%20and%20macOS%20Big%20Sur%20(255984%40main) https://webkit.org/blog/13584/release-notes-for-safari-techn... To be clear I didn’t say I’m holding my breath. Just that it’s not “obviously” impossible.
  - masklinn 4y ago
    They’re not working on anything, this just means the WebKit previews or the odd product which embeds WebKit rather than use webviews can run regardless of OS support. Apple ain’t going to enable features they don’t support on safari.
    - dieulot 4y ago
      That’s Safari’s preview.
      - masklinn 4y ago
        No, it is not. It's webkit. Safari is based on webkit, but the webkit project at large does not decide what does and does not go in Safari. That's why there are regular "Webkit features in Safari X": that something is added to webkit does not guarantee it'll land in Safari, ever. Hell, it took 18 months and 2 iOS/macOS releases for the AVIF support to go from landing in Webkit to landing in Safari. And that was something Apple wanted.
  - smoldesu 4y ago
    > Just that it’s not “obviously” impossible. Neither was webm support, but that didn't stop them from taking several years to implement it (and even then it was half-finished). Apple clearly wants to play the superiority game with their own codecs. They have zero incentive to support any codecs they didn't build, and have been known to abandon standards that they help develop. Nothing is technically impossible for Apple, but codec support is stuck between an ideological/financial rock and a hard place.

JyrkiAlakuijala 4y ago

Apple is a company that cares deeply about usability. Once JPEG XL reaches critical mass in photography or creative work (video mastering, image processing, graphics and similar), Apple will very likely be the first to add support. Their users much rather have a thumbnail than a stock icon for photographs and graphics. I wouldn't be surprised if JPEG XL support would be announced by mid 2023.

pigsty 4y ago

Apple dragged their feet on introducing webms to Safari and they still often require fiddling with to get working on iOS. If Apple isn’t jumping at supporting a format, it’s generally safe to assume they’ll do all they can to not support it unless the pressure is overwhelming. Which doesn’t seem to be the case with this format.

masklinn 4y ago

> The fact that they adopted AVIF relatively swiftly Can be linked to Apple being a governing member of AOM. > and generally improved their cadence a bit, makes me ready to not be surprised if they ship JPEG XL in a year or two. Feel free to hold your breath, but I don't think that'll be good for your health. The webkit bug for AVIF was opened in February 2020, an "initial support" patch was proposed in May, support was merged in March 2021. Apple separately shipped the decoder[0] in iOS and macOS in September/Octoboer 2022, and enabled the feature for Safari. The webkit bug for JXL was opened in February 2020. That's about all that's happened to it. Reaction has been: - Webkit is not super interested in adding a bunch of third-party unsafe code[1] - Safari support requires OS support, which is non-existent for JXL[2] [0] Webkit on non-apple platforms can use Webkit's decoders, on Apple platforms it uses CoreGraphics, though as seen with HEIF having CG support doesn't mean Apple enables the format in Safari. [1] https://lists.webkit.org/pipermail/webkit-dev/2021-May/031846.html https://lists.webkit.org/pipermail/webkit-dev/2021-May/03184... [2] https://lists.webkit.org/pipermail/webkit-dev/2021-May/031851.html https://lists.webkit.org/pipermail/webkit-dev/2021-May/03185...

dieulot 4y ago
They’re working on ending the OS-parity nonsense with AVIF. https://webkit.org/blog/13584/release-notes-for-safari-technology-preview-158/#:~:text=Enabled%20AVIF%20image%20decoding%20for%20macOS%20Monterey%20and%20macOS%20Big%20Sur%20(255984%40main) https://webkit.org/blog/13584/release-notes-for-safari-techn... To be clear I didn’t say I’m holding my breath. Just that it’s not “obviously” impossible.
- masklinn 4y ago
  They’re not working on anything, this just means the WebKit previews or the odd product which embeds WebKit rather than use webviews can run regardless of OS support. Apple ain’t going to enable features they don’t support on safari.
  - dieulot 4y ago
    That’s Safari’s preview.
    - masklinn 4y ago
      No, it is not. It's webkit. Safari is based on webkit, but the webkit project at large does not decide what does and does not go in Safari. That's why there are regular "Webkit features in Safari X": that something is added to webkit does not guarantee it'll land in Safari, ever. Hell, it took 18 months and 2 iOS/macOS releases for the AVIF support to go from landing in Webkit to landing in Safari. And that was something Apple wanted.
- smoldesu 4y ago
  > Just that it’s not “obviously” impossible. Neither was webm support, but that didn't stop them from taking several years to implement it (and even then it was half-finished). Apple clearly wants to play the superiority game with their own codecs. They have zero incentive to support any codecs they didn't build, and have been known to abandon standards that they help develop. Nothing is technically impossible for Apple, but codec support is stuck between an ideological/financial rock and a hard place.