13 ms·

macOS 14 will support JPEG XL

318 points by biggestfan 3y ago

amoerie 3y ago
As a radiology software developer: please please let JPEG XL become a thing. I sincerely hope this might make Chrome change its mind. JPEG XL is a game changer for 16 bit lossless images. The technical landscape for these kinds of images today is barren.
- jeffbee 3y ago
  Can you explain to the rest of us what about JPEG XL applies to that use case? If you asked me to store lossless, 16-bit (per channel, or monochrome, I am assuming) images I would suggest TIFF.
  - lonjil 3y ago
    I think they want better compression. JXL has excellent lossless compression.
    - deleted 3y ago
      [deleted]
  - vetinari 3y ago
    TIFF is a container, it can have payload with different compression schemes, lossy or lossless. Including JXL.
    - account42 3y ago
      TIFF can be used as a container. It also comes with its own (relatively shitty) compression methods which is probably what you'd end up using if you wanted 16-bit TIFFs today. And TIFF as a container for JXL would no less require JXL adoption than plain JXL.
- PaulHoule 3y ago
  As a mirrorless photographer who wants to publish photos on the web that look like they came out of a mirrorless camera I want JPEG XL. In trials I've done, AVIF works well for a throwaway splash image for a blog but compression results are not so impressive compared to JPEG or WEBP if you want the image to hold up under close inspection. On the other hand there is something that seems almost infantile about image support in the "operating system" being pivotal. If you read a review of a new MacOS in ArsTechnica you might get the idea that 99% of an OS is about what the buttons look like but in terms of the computer science definition, image codecs are definitely a userspace thing and as a Windows or Linux user I never wait for my OS to support an image format, I just install the codec and code away.
  - kps 3y ago
    As an ‘operating system’ OS X includes user space tools like the Finder and Quick Look in particular where vendor support is helpful.
    - asddubs 3y ago
      also crucially, safari
  - woah 3y ago
    Dumb question, but why is OS or browser support necessary? Couldn't an HTML canvas element and some JS that can parse the file format display any kind of image that you might want?
    - ianlevesque 3y ago
      A canvas element is not as performant as an image element.
      - PaulHoule 3y ago
        When I am serious about images it is all about high performance: upgrading to better data compression (1) speeds up the network and server and reduces (2) network and (3) storage costs. (4) Decompression of the image is another bottleneck and a soft decoder is itself something to download and compile locally. If you use a high-powered device you might not appreciate that performance of a low-end Android device hasn't really improved since 2017. I test with an Android Go device that does pretty well if you feed it scaled images but would struggle with the soft decoder. The native implementation of the decompressor can be much better than one in WebAssembly in that it can use SIMD units on the CPU and many other tricks, including special purpose hardware. That's why Apple is so keen to say that an image format is now supported in the OS, because they codesign the hardware, the OS and the file formats to take advantage of all that.
- bick_nyers 3y ago
  Ex-radiology software developer here, and seconded! J2K is good, but here are some advantages of JXL in the context of medical imaging: - Better compression ratios - Ability to modify effort of lossless compression (good for real time transcoding) - Multi-threaded encode and decode - Far superior progressive decoding (great for low bandwidth scenarios, just stream in the lossless quality over time)
- vbezhenar 3y ago
  Does it really matter? These days decoding image with JS or Wasm should be fine. It's not video.
  - bick_nyers 3y ago
    Video is not lossless, a second of high quality video might be a total of 5 megabytes. A mammogram on the other hand, might be 300 images of lossless 4k resolution, which could clock in at about 2 gigabytes. That could be per breast in a given study, and a study could have prior mammograms attached as well. You will hit memory limits, so you need to be able to unload and load data intelligently and quickly.
    - simondotau 3y ago
      Image compression for mammograms seems like a thing ideally suited to a straightforward ML task — a model trained to classify sections of an image which are outside of the area of relevance (i.e. not the breast) and classify details of high importance so that detail can be retained where it's needed. Especially handy that it wouldn't require a new file format. It only requires the encoder to support variable compression. (I know Photoshop supported this for JPEG many decades ago.)
      - bick_nyers 3y ago
        I might be missing the details here, but everything outside the breast should be pretty much black and will get compressed very efficiently (high signal, low noise, easy to predict). Foveated compression sounds like a super cool idea I've never thought about before. Before that, you would need to get radiologists onboard with the idea of something being "diagnostically lossless" (think visually lossless), which is currently a hard sell (some promising research does exist on this)!
  - crazygringo 3y ago
    Images are opened and used in a lot of places that aren't browsers.
  - 3y ago
- jez 3y ago
  > I sincerely hope this might make Chrome change its mind. I take this to suggest that Chrome actively decided against implementing JPEG XL? Did they consider supporting it and reject support for it, or has it simply not been prioritized, but still might be prioritized one day? If the decision was intentional: did they state a reason why?
  - csnover 3y ago
    From April: https://arstechnica.com/gadgets/2023/04/free-software-group-decries-google-dropping-space-saving-jpeg-xl-format/ https://arstechnica.com/gadgets/2023/04/free-software-group-... Discussed several times previously on HN: https://news.ycombinator.com/item?id=35589179 https://news.ycombinator.com/item?id=35589179 https://news.ycombinator.com/item?id=33399940 https://news.ycombinator.com/item?id=33399940 https://news.ycombinator.com/item?id=33563378 https://news.ycombinator.com/item?id=33563378
  - derefr 3y ago
    They did all the work required to implement it, sat around for a few months, and then removed it, before anyone else even noticed it was there / had a chance to start integrating it. My personal conspiracy theory is that some Google engineer who works on Chrome, came up with "JPEG XL support" as a feature they could work on, pushed it through to prod, patted themselves on the back, and forgot about it; but this was all done without first getting sign-off from whoever at Google is trying to push for WebP to be a thing. When that person or group noticed "Chrome now supports JPEG XL", they got that support ripped out.
    - asddubs 3y ago
      it was also only ever hidden behind a flag
    - lonjil 3y ago
      The work wasn't done by anyone on the Chrome team. Someone at Google Research Zurich (I don't recall who) wrote the patches and submitted them. Actually, I think that they've even kept the patches up to date with newer Chrome releases so in theory it would be easy to re-introduce JXL into Chrome if there is a will to do it...
- kstrauser 3y ago
  I am suuuper ignorant on the subject, but is this something that could replace DICOM?
  - concise_unicorn 3y ago
    No, DICOM is a container format that can contain JPEG XL image data
    - kstrauser 3y ago
      Ah, I see. What does the contain provide other than image data?
      - neandrake 3y ago
        Lots of metadata about the image scan. Patient name/id, etc. and often physics related to the image scan such as the voxel size, units, properties of the imaging equipment, etc. DICOM is also used for other data that isn’t directly related to the visual image such as segmentation of the image, radiotherapy planning info, and so on. There are hundreds of dicom tags (the metadata entries) that can be in the dataset.
  - mk_stjames 3y ago
    Not an expert either by far, but DICOM isn't just images, it's a much larger data structure and following protocol, which deals with the transmission of the data between devices as well. The files are just one part of it. It also supports more dimensions to the data frames other than 2D. The pixel data in DICOM itself uses JPEG however (among other potential pixel compression methods), and it is possible that JPEG XL rolled into DICOM could allow for benefits.
- alwillis 3y ago
  > As a radiology software developer: please please let JPEG XL become a thing. If things with Apple go well and JPEG XL is supported natively on macOS, iOS and iPadOS this fall, it would be on its way to becoming a thing. After all, 2 billion devices isn't nothin’.
qingcharles 3y ago
And Google just (sadly) pulled support from Chrome. Your move, Google.
- chungy 3y ago
  With the only justification being "nobody wanted it", a plainly false statement. WebP isn't good enough. AVIF isn't good enough. JPEG XL is good enough.
  - jbverschoor 3y ago
    Google is using the wrong tricks to keep marketshare.. I'm not even sure if they know it
  - Gigachad 3y ago
    Their justification was more that adding it would be committing a lot of hardware and software vendors to support it which would be very expensive for not enough gain.
    - lonjil 3y ago
      > Their justification was more that adding it would be committing a lot of hardware Which is completely nonsensical. Hardware support is meaningless for web images.
      - pgeorgi 3y ago
        Hardware accelerated handling was one of the arguments used to oppose a WASM based implementation that sites could use at will to prove that there's demand for JPEG-XL support (and that the Chrome team provides, by the way).
        lonjil 3y ago
        No it wasn't. WASM implementations are simply slower than native support. No browser uses HW accelerated decode for AVIF images or JXL. I think Safari might use HW for JPEG, but that's it across all browsers.
kps 3y ago
Excellent. JPEG XL is a usable general-purpose image format, not just a passive delivery format like WebP and AVIF.
- zamadatix 3y ago
  Could you explain how so? JPEG XL seems cool enough but what about e.g. AVIF makes it "just a passive delivery format" instead of a general-purpose image format? It handles color spaces, lossless, lossy, up to 12 bit, up to 4:4:4/RGB, transparency, and animation at a good quality/size ratio so what's so drastically different about JPEG XL to move them to separate categories?
  - ajconway 3y ago
    AVIF does not support progressive encoding.
    - zamadatix 3y ago
      Assuming you meant "de"coding: it does, albeit I like JPEG XL's more. To me, that point seems an argument for things being the other way around anyways (i.e. general-purpose but not a good delivery format).
      - ajconway 3y ago
        I stand (partially) corrected: https://github.com/AOMediaCodec/libavif/pull/640 https://github.com/AOMediaCodec/libavif/pull/640
        jonsneyers 3y ago
        I am not sure how exactly the "progressive avif" works, but it looks like basically something optional that comes at a cost in the final file size, whereas in jxl some basic progressive encoding is always available (at least for lossy images) and doesn't come at a cost in file size.
      - 3y ago
masswerk 3y ago
Finally, a good reason to upgrade (again).
- slig 3y ago
  Is there a specific reason why this has to be a OS update thing? I know that it's likely that they don't update the emoji font outside major OS updates so people have an extra reason to update.
  - eyelidlessness 3y ago
    It doesn’t have to be, but Apple has generally deferred new functionality to major versions, especially since they moved to an annual release cadence. There have also been a few exceptions since then, but they’re usually headline features which were supposed to bolster the major release but fell behind schedule.
  - alwillis 3y ago
    > Is there a specific reason why this has to be a OS update thing? The way Apple does it, it's cleaner to implement the APIs for this sort of thing in a new operating system version, especially if it requires features not present in the current versions of the operating system. They could make an exception for Safari by including the required code to support JPEG XL in Safari Technology Preview on Ventura to allow developers to test their sites and web apps until macOS, iOS, etc. ship in the fall. I suspect we'll learn what the plan is as the Safari/WebKit team make more announcements during WWDC: https://www.webkit.org/blog/14203/web-technology-sessions-at-wwdc23/ https://www.webkit.org/blog/14203/web-technology-sessions-at...
    - alwillis 3y ago
      JPEG XL support is coming Safari 17 on Sonoma, Ventura and Monterey: https://front-end.social/@jensimmons/110497266298128289 https://front-end.social/@jensimmons/110497266298128289
  - ezfe 3y ago
    It doesn't have to be, but by making it an OS level thing, then when you download that photo, it still opens in Preview, etc.
twotwotwo 3y ago
I hope it shows up in Safari and that this sign of interest from others gets it a second shot in Chrome. Just the JPEG recompression is arguably worth the price of entry; it's less savings than AVIF, of course, but it's easier to adopt now, where re-encoding everything as AVIF is a much larger hump to get over. Its other modes provide some real benefits for users for very-high-quality and lossless images as well as any situation where progressive display helps. For folks producing images, is much easier to fit in than AVIF for anyone who needs to encode a lot on the CPU.
- alwillis 3y ago
  > I hope it shows up in Safari and that this sign of interest from others gets it a second shot in Chrome. I'm pretty sure the Chrome team knew at the time they dropped JPEG XL that there was a decent chance Apple would implement it--there's certainly enough of a backchannel between the browser teams at Google, Apple, Mozilla and Microsoft.
  - saagarjha 3y ago
    Apple typically does not announce intent to implement things; they just implement them.
  - twotwotwo 3y ago
    Yeah, that is all odd to me; Google cited lack of "interest from the entire ecosystem" (https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...). Mozilla also had an experimental JXL implemenation out there. I'd hope, like you said, that the browser vendors had enough of a backchannel to keep a good thing from fizzling because each is uncertain if the others will implement it. But if the Chrome folks did know they had all three major browser engines were ready to go, along with the positive noises from Facebook, Adobe, other parts of Google, and a few other notable folks, that seems like a solid base of support, unless you're really expecting the world to go all-in on a format before a browser supports it without a flag. So I guess I wonder if it's that the Chrome team had set the bar high, that they hadn't expected Apple to support JXL at the time they made the call, or something else.
captainmarble 3y ago
Google always need a push from another tech giants to do something right like chatgpt did.
viraptor 3y ago
I'm trying to understand the motivation here. There's a few new image formats as potential candidates: jpeg xl, webp v2, avif, heic. Apple already had heic in the os, but still not Safari AFAIK. Avif has the benefit of hardware encoders/decoders (with limited chroma options though). I see the HDR mentioned in other comments which is interesting. Are there any (potential conspiracy) reasons they would choose not to go for another format? I'm trying to understand how they arrived at this answer given it was available for years and ignored in popular software.
- Macha 3y ago
  The big feature JPEG XL offers that HEIC and AVIF do not is lossless filesize reduction for JPEG images (such as those produced by basically every non-iphone camera). Also AVIF and HEIC as specified don't support >8k images.
- cjawdb 3y ago
  I'm confused where you got "it was available for years and ignored in popular software" from? Most of the ISO standard was only published last year, with the last bit being published in October 2022. IIRC AVIF is almost ~4 years old by the same standards and WebP is over a decade old. Adobe has partial support (in Camera RAW) with presumably further support coming considering their website recommends JXL alongside AVIF for HDR images. It's also supported by Affinity Photo 2, Krita, Darkroom, GIMP, ffmpeg, ImageMagick, Paint.net, anything Qt/KDE-based via plugin, Pale Moon, libvips, and almost every third-party image viewer that I've ever used or heard of (nomacs, Irfanview, ImageGlass, xnView, etc.). It also has had vocal support from senior engineers at a variety of companies like Facebook, Shopify, Cloudinary, Intel, Flickr, etc. My first thought when I heard about JXL several months ago was "oh, a new JPEG-2000?" but I've quickly become a JXL evangelist after reading more about it and then playing around with libjxl myself. https://jpegxl.info/why-jxl.html https://jpegxl.info/why-jxl.html https://jpegxl.io/articles/faq/ https://jpegxl.io/articles/faq/ https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl
  - viraptor 3y ago
    (Facepalm) I was totally thinking of jpeg2000 not jpeg xl. That makes so much more sense!
Taywee 3y ago
Good. I can't believe the Google argument for removal, being in effect "it's only slightly better in every single way than all the other formats we support, and not enough people jumped though the hoops to manually opt into it, so we're removing it entirely."
alwillis 3y ago
Here's the text of the WWDC session description that will cover JPEG XL [1]: Learn about the latest image formats and video technologies supported in Safari 17. Discover how you can use JPEG XL, AVIF, and HEIC in your websites and experiences and learn how they differ from previous formats. We’ll also show you how the Managed Media Source API draws less power than Media Source Extensions (MSE) and explore how you can use it to more efficiently manage streaming video over 5G. The link isn't live yet as the session is scheduled for Thursday, June 8th. [1]: https://developer.apple.com/videos/play/wwdc2023/10122/ https://developer.apple.com/videos/play/wwdc2023/10122/
aidenn0 3y ago
JPEG XL is the first image format in over a decade that has shown real quality improvements for high-frequency images (i.e. sharp edges). JPEG 2000 is competitive with all of the video codec I-frame formats I've tried, and you can embed them in PDFs unmodified, so I've not troubled with anything new.
eviks 3y ago
Nice, maybe Chrome will reconsider and add this new great format

318 points by biggestfan 3y ago

As a radiology software developer: please please let JPEG XL become a thing. I sincerely hope this might make Chrome change its mind. JPEG XL is a game changer for 16 bit lossless images. The technical landscape for these kinds of images today is barren.

jeffbee 3y ago
Can you explain to the rest of us what about JPEG XL applies to that use case? If you asked me to store lossless, 16-bit (per channel, or monochrome, I am assuming) images I would suggest TIFF.
- lonjil 3y ago
  I think they want better compression. JXL has excellent lossless compression.
  - deleted 3y ago
    [deleted]
- vetinari 3y ago
  TIFF is a container, it can have payload with different compression schemes, lossy or lossless. Including JXL.
  - account42 3y ago
    TIFF can be used as a container. It also comes with its own (relatively shitty) compression methods which is probably what you'd end up using if you wanted 16-bit TIFFs today. And TIFF as a container for JXL would no less require JXL adoption than plain JXL.
PaulHoule 3y ago
As a mirrorless photographer who wants to publish photos on the web that look like they came out of a mirrorless camera I want JPEG XL. In trials I've done, AVIF works well for a throwaway splash image for a blog but compression results are not so impressive compared to JPEG or WEBP if you want the image to hold up under close inspection. On the other hand there is something that seems almost infantile about image support in the "operating system" being pivotal. If you read a review of a new MacOS in ArsTechnica you might get the idea that 99% of an OS is about what the buttons look like but in terms of the computer science definition, image codecs are definitely a userspace thing and as a Windows or Linux user I never wait for my OS to support an image format, I just install the codec and code away.
- kps 3y ago
  As an ‘operating system’ OS X includes user space tools like the Finder and Quick Look in particular where vendor support is helpful.
  - asddubs 3y ago
    also crucially, safari
- woah 3y ago
  Dumb question, but why is OS or browser support necessary? Couldn't an HTML canvas element and some JS that can parse the file format display any kind of image that you might want?
  - ianlevesque 3y ago
    A canvas element is not as performant as an image element.
    - PaulHoule 3y ago
      When I am serious about images it is all about high performance: upgrading to better data compression (1) speeds up the network and server and reduces (2) network and (3) storage costs. (4) Decompression of the image is another bottleneck and a soft decoder is itself something to download and compile locally. If you use a high-powered device you might not appreciate that performance of a low-end Android device hasn't really improved since 2017. I test with an Android Go device that does pretty well if you feed it scaled images but would struggle with the soft decoder. The native implementation of the decompressor can be much better than one in WebAssembly in that it can use SIMD units on the CPU and many other tricks, including special purpose hardware. That's why Apple is so keen to say that an image format is now supported in the OS, because they codesign the hardware, the OS and the file formats to take advantage of all that.
bick_nyers 3y ago
Ex-radiology software developer here, and seconded! J2K is good, but here are some advantages of JXL in the context of medical imaging: - Better compression ratios - Ability to modify effort of lossless compression (good for real time transcoding) - Multi-threaded encode and decode - Far superior progressive decoding (great for low bandwidth scenarios, just stream in the lossless quality over time)
vbezhenar 3y ago
Does it really matter? These days decoding image with JS or Wasm should be fine. It's not video.
- bick_nyers 3y ago
  Video is not lossless, a second of high quality video might be a total of 5 megabytes. A mammogram on the other hand, might be 300 images of lossless 4k resolution, which could clock in at about 2 gigabytes. That could be per breast in a given study, and a study could have prior mammograms attached as well. You will hit memory limits, so you need to be able to unload and load data intelligently and quickly.
  - simondotau 3y ago
    Image compression for mammograms seems like a thing ideally suited to a straightforward ML task — a model trained to classify sections of an image which are outside of the area of relevance (i.e. not the breast) and classify details of high importance so that detail can be retained where it's needed. Especially handy that it wouldn't require a new file format. It only requires the encoder to support variable compression. (I know Photoshop supported this for JPEG many decades ago.)
    - bick_nyers 3y ago
      I might be missing the details here, but everything outside the breast should be pretty much black and will get compressed very efficiently (high signal, low noise, easy to predict). Foveated compression sounds like a super cool idea I've never thought about before. Before that, you would need to get radiologists onboard with the idea of something being "diagnostically lossless" (think visually lossless), which is currently a hard sell (some promising research does exist on this)!
- crazygringo 3y ago
  Images are opened and used in a lot of places that aren't browsers.
- 3y ago
jez 3y ago
> I sincerely hope this might make Chrome change its mind. I take this to suggest that Chrome actively decided against implementing JPEG XL? Did they consider supporting it and reject support for it, or has it simply not been prioritized, but still might be prioritized one day? If the decision was intentional: did they state a reason why?
- csnover 3y ago
  From April: https://arstechnica.com/gadgets/2023/04/free-software-group-decries-google-dropping-space-saving-jpeg-xl-format/ https://arstechnica.com/gadgets/2023/04/free-software-group-... Discussed several times previously on HN: https://news.ycombinator.com/item?id=35589179 https://news.ycombinator.com/item?id=35589179 https://news.ycombinator.com/item?id=33399940 https://news.ycombinator.com/item?id=33399940 https://news.ycombinator.com/item?id=33563378 https://news.ycombinator.com/item?id=33563378
- derefr 3y ago
  They did all the work required to implement it, sat around for a few months, and then removed it, before anyone else even noticed it was there / had a chance to start integrating it. My personal conspiracy theory is that some Google engineer who works on Chrome, came up with "JPEG XL support" as a feature they could work on, pushed it through to prod, patted themselves on the back, and forgot about it; but this was all done without first getting sign-off from whoever at Google is trying to push for WebP to be a thing. When that person or group noticed "Chrome now supports JPEG XL", they got that support ripped out.
  - asddubs 3y ago
    it was also only ever hidden behind a flag
  - lonjil 3y ago
    The work wasn't done by anyone on the Chrome team. Someone at Google Research Zurich (I don't recall who) wrote the patches and submitted them. Actually, I think that they've even kept the patches up to date with newer Chrome releases so in theory it would be easy to re-introduce JXL into Chrome if there is a will to do it...
kstrauser 3y ago
I am suuuper ignorant on the subject, but is this something that could replace DICOM?
- concise_unicorn 3y ago
  No, DICOM is a container format that can contain JPEG XL image data
  - kstrauser 3y ago
    Ah, I see. What does the contain provide other than image data?
    - neandrake 3y ago
      Lots of metadata about the image scan. Patient name/id, etc. and often physics related to the image scan such as the voxel size, units, properties of the imaging equipment, etc. DICOM is also used for other data that isn’t directly related to the visual image such as segmentation of the image, radiotherapy planning info, and so on. There are hundreds of dicom tags (the metadata entries) that can be in the dataset.
- mk_stjames 3y ago
  Not an expert either by far, but DICOM isn't just images, it's a much larger data structure and following protocol, which deals with the transmission of the data between devices as well. The files are just one part of it. It also supports more dimensions to the data frames other than 2D. The pixel data in DICOM itself uses JPEG however (among other potential pixel compression methods), and it is possible that JPEG XL rolled into DICOM could allow for benefits.
alwillis 3y ago
> As a radiology software developer: please please let JPEG XL become a thing. If things with Apple go well and JPEG XL is supported natively on macOS, iOS and iPadOS this fall, it would be on its way to becoming a thing. After all, 2 billion devices isn't nothin’.

qingcharles 3y ago

And Google just (sadly) pulled support from Chrome. Your move, Google.

chungy 3y ago
With the only justification being "nobody wanted it", a plainly false statement. WebP isn't good enough. AVIF isn't good enough. JPEG XL is good enough.
- jbverschoor 3y ago
  Google is using the wrong tricks to keep marketshare.. I'm not even sure if they know it
- Gigachad 3y ago
  Their justification was more that adding it would be committing a lot of hardware and software vendors to support it which would be very expensive for not enough gain.
  - lonjil 3y ago
    > Their justification was more that adding it would be committing a lot of hardware Which is completely nonsensical. Hardware support is meaningless for web images.
    - pgeorgi 3y ago
      Hardware accelerated handling was one of the arguments used to oppose a WASM based implementation that sites could use at will to prove that there's demand for JPEG-XL support (and that the Chrome team provides, by the way).
      - lonjil 3y ago
        No it wasn't. WASM implementations are simply slower than native support. No browser uses HW accelerated decode for AVIF images or JXL. I think Safari might use HW for JPEG, but that's it across all browsers.

kps 3y ago

Excellent. JPEG XL is a usable general-purpose image format, not just a passive delivery format like WebP and AVIF.

zamadatix 3y ago
Could you explain how so? JPEG XL seems cool enough but what about e.g. AVIF makes it "just a passive delivery format" instead of a general-purpose image format? It handles color spaces, lossless, lossy, up to 12 bit, up to 4:4:4/RGB, transparency, and animation at a good quality/size ratio so what's so drastically different about JPEG XL to move them to separate categories?
- ajconway 3y ago
  AVIF does not support progressive encoding.
  - zamadatix 3y ago
    Assuming you meant "de"coding: it does, albeit I like JPEG XL's more. To me, that point seems an argument for things being the other way around anyways (i.e. general-purpose but not a good delivery format).
    - ajconway 3y ago
      I stand (partially) corrected: https://github.com/AOMediaCodec/libavif/pull/640 https://github.com/AOMediaCodec/libavif/pull/640
      - jonsneyers 3y ago
        I am not sure how exactly the "progressive avif" works, but it looks like basically something optional that comes at a cost in the final file size, whereas in jxl some basic progressive encoding is always available (at least for lossy images) and doesn't come at a cost in file size.
    - 3y ago

masswerk 3y ago

Finally, a good reason to upgrade (again).

slig 3y ago
Is there a specific reason why this has to be a OS update thing? I know that it's likely that they don't update the emoji font outside major OS updates so people have an extra reason to update.
- eyelidlessness 3y ago
  It doesn’t have to be, but Apple has generally deferred new functionality to major versions, especially since they moved to an annual release cadence. There have also been a few exceptions since then, but they’re usually headline features which were supposed to bolster the major release but fell behind schedule.
- alwillis 3y ago
  > Is there a specific reason why this has to be a OS update thing? The way Apple does it, it's cleaner to implement the APIs for this sort of thing in a new operating system version, especially if it requires features not present in the current versions of the operating system. They could make an exception for Safari by including the required code to support JPEG XL in Safari Technology Preview on Ventura to allow developers to test their sites and web apps until macOS, iOS, etc. ship in the fall. I suspect we'll learn what the plan is as the Safari/WebKit team make more announcements during WWDC: https://www.webkit.org/blog/14203/web-technology-sessions-at-wwdc23/ https://www.webkit.org/blog/14203/web-technology-sessions-at...
  - alwillis 3y ago
    JPEG XL support is coming Safari 17 on Sonoma, Ventura and Monterey: https://front-end.social/@jensimmons/110497266298128289 https://front-end.social/@jensimmons/110497266298128289
- ezfe 3y ago
  It doesn't have to be, but by making it an OS level thing, then when you download that photo, it still opens in Preview, etc.

twotwotwo 3y ago

I hope it shows up in Safari and that this sign of interest from others gets it a second shot in Chrome. Just the JPEG recompression is arguably worth the price of entry; it's less savings than AVIF, of course, but it's easier to adopt now, where re-encoding everything as AVIF is a much larger hump to get over. Its other modes provide some real benefits for users for very-high-quality and lossless images as well as any situation where progressive display helps. For folks producing images, is much easier to fit in than AVIF for anyone who needs to encode a lot on the CPU.

alwillis 3y ago
> I hope it shows up in Safari and that this sign of interest from others gets it a second shot in Chrome. I'm pretty sure the Chrome team knew at the time they dropped JPEG XL that there was a decent chance Apple would implement it--there's certainly enough of a backchannel between the browser teams at Google, Apple, Mozilla and Microsoft.
- saagarjha 3y ago
  Apple typically does not announce intent to implement things; they just implement them.
- twotwotwo 3y ago
  Yeah, that is all odd to me; Google cited lack of "interest from the entire ecosystem" (https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...). Mozilla also had an experimental JXL implemenation out there. I'd hope, like you said, that the browser vendors had enough of a backchannel to keep a good thing from fizzling because each is uncertain if the others will implement it. But if the Chrome folks did know they had all three major browser engines were ready to go, along with the positive noises from Facebook, Adobe, other parts of Google, and a few other notable folks, that seems like a solid base of support, unless you're really expecting the world to go all-in on a format before a browser supports it without a flag. So I guess I wonder if it's that the Chrome team had set the bar high, that they hadn't expected Apple to support JXL at the time they made the call, or something else.

captainmarble 3y ago

Google always need a push from another tech giants to do something right like chatgpt did.

viraptor 3y ago

I'm trying to understand the motivation here. There's a few new image formats as potential candidates: jpeg xl, webp v2, avif, heic. Apple already had heic in the os, but still not Safari AFAIK. Avif has the benefit of hardware encoders/decoders (with limited chroma options though). I see the HDR mentioned in other comments which is interesting. Are there any (potential conspiracy) reasons they would choose not to go for another format? I'm trying to understand how they arrived at this answer given it was available for years and ignored in popular software.

Macha 3y ago
The big feature JPEG XL offers that HEIC and AVIF do not is lossless filesize reduction for JPEG images (such as those produced by basically every non-iphone camera). Also AVIF and HEIC as specified don't support >8k images.
cjawdb 3y ago
I'm confused where you got "it was available for years and ignored in popular software" from? Most of the ISO standard was only published last year, with the last bit being published in October 2022. IIRC AVIF is almost ~4 years old by the same standards and WebP is over a decade old. Adobe has partial support (in Camera RAW) with presumably further support coming considering their website recommends JXL alongside AVIF for HDR images. It's also supported by Affinity Photo 2, Krita, Darkroom, GIMP, ffmpeg, ImageMagick, Paint.net, anything Qt/KDE-based via plugin, Pale Moon, libvips, and almost every third-party image viewer that I've ever used or heard of (nomacs, Irfanview, ImageGlass, xnView, etc.). It also has had vocal support from senior engineers at a variety of companies like Facebook, Shopify, Cloudinary, Intel, Flickr, etc. My first thought when I heard about JXL several months ago was "oh, a new JPEG-2000?" but I've quickly become a JXL evangelist after reading more about it and then playing around with libjxl myself. https://jpegxl.info/why-jxl.html https://jpegxl.info/why-jxl.html https://jpegxl.io/articles/faq/ https://jpegxl.io/articles/faq/ https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl
- viraptor 3y ago
  (Facepalm) I was totally thinking of jpeg2000 not jpeg xl. That makes so much more sense!

Taywee 3y ago

Good. I can't believe the Google argument for removal, being in effect "it's only slightly better in every single way than all the other formats we support, and not enough people jumped though the hoops to manually opt into it, so we're removing it entirely."

alwillis 3y ago

Here's the text of the WWDC session description that will cover JPEG XL [1]: Learn about the latest image formats and video technologies supported in Safari 17. Discover how you can use JPEG XL, AVIF, and HEIC in your websites and experiences and learn how they differ from previous formats. We’ll also show you how the Managed Media Source API draws less power than Media Source Extensions (MSE) and explore how you can use it to more efficiently manage streaming video over 5G. The link isn't live yet as the session is scheduled for Thursday, June 8th. [1]: https://developer.apple.com/videos/play/wwdc2023/10122/ https://developer.apple.com/videos/play/wwdc2023/10122/

aidenn0 3y ago

JPEG XL is the first image format in over a decade that has shown real quality improvements for high-frequency images (i.e. sharp edges). JPEG 2000 is competitive with all of the video codec I-frame formats I've tried, and you can embed them in PDFs unmodified, so I've not troubled with anything new.

eviks 3y ago

Nice, maybe Chrome will reconsider and add this new great format