5 ms·

While being a big supporter of JPEG-XL on HN, I just want to note AV2 is coming out soon, which should further improve the image compression. ( Edit: Also worth

by ksec 11mo ago

While being a big supporter of JPEG-XL on HN, I just want to note AV2 is coming out soon, which should further improve the image compression. ( Edit: Also worth pointing out current JPEG-XL encoder is no where near its maximum potential in terms of quality / compression ratio ) But JPEG-XL is being quite widely used now, from PDF, medical images, camera lossless, as well as being evaluated in different stage of cinema / artist workflow production. Hopefully the rust decoder will be ready soon. And from the wording, it seems to imply Google Chrome will officially support anything from AOM.

snvzz 11mo ago
>medical images Isn't JPEG-XL a lossy codec?
- MagnumOpus 11mo ago
  It has both lossy and lossless modes.
  - snvzz 11mo ago
    Good to hear. I sure hope they came up with a good, clear system to distinguish them.
    - lxgr 11mo ago
      As in, a clear way to detect whether a given file is lossy or lossless? I was thinking that too, but on the other hand, even a lossless file can't guarantee that its contents aren't the result of going through a lossy intermediate format, such as a screenshot created from a JPEG.
      - snvzz 11mo ago
        I meant like a filename convention, and tags in the file itself.
        149765 11mo ago
        There is some sort of tag, jxlinfo can tell you if a file is "lossy" or "(possibly) lossless".
        stavros 11mo ago
        Presumably you can look at the file and tell which mode is used, though why would you care to know from the filename?
        crazygringo 11mo ago
        I find it incredibly helpful to know that .jpg is lossy and .png is lossless. There are so many reasons why it's almost hard to know where to begin. But it's basically the same reason why it's helpful for some documents to end in .docx and others to end in .xlsx. It tells you what kind of data is inside. And at least for me, for standard 24-bit RGB images, the distinction between lossy and lossless is much more important than between TIFF and PNG, or between JPG and HEIC. Knowing whether an image is degraded or not is the #1 important fact about an image for me, before anything else. It says so much about what the file is for and not for -- how I should or shouldn't edit it, what kind of format and compression level is suitable for saving after editing, etc. After that comes whether it's animated or not, which is why .apng is so helpful to distinguish it from .png. There's a good reason Microsoft Office documents aren't all just something like .msox, with an internal tag indicating whether they're a text document or a spreadsheet or a presentation. File extensions carry semantic meaning around the type of data they contain, and it's good practice to choose extensions that communicate the most important conceptual distinctions.
        stavros 11mo ago
        But JPEG has a lossless mode as well. How do you distinguish between the two now? This is an arbitrary distinction, for example then why do mp3 and ogg (vorbis) have different extensions? They're both lossy audio formats, so by that requirement, the extension should be the same. Otherwise, we should distinguish between bitrates with different extensions, eg mp3128, mp3192, etc.
- ksec 11mo ago
  JPEG-XL is both a lossy and lossless codec. It is already being used in Camera DNG format, making the RAW image smaller. While lossy codec is hard to compare and up for debate. JPEG-XL is actually better as a lossless codec in terms of compression ratio and compression complexity. There is only one other codec that beats it but it is not open source.
  - cipehr 11mo ago
    What is the non-open source codec?
    - ksec 11mo ago
      HALIC (High Availability Lossless Image Compression) https://news.ycombinator.com/item?id=38990568 https://news.ycombinator.com/item?id=38990568
      - cipehr 11mo ago
        Thank yoU! Totally missed this.
    - Nanopolygon 11mo ago
      HALIC is by far the best lossless codec in terms of speed/compression ratio. If lossy mode were similarly available, we might not be discussing all these issues. I think he stopped developing HALIC for a long time due to lack of interest. Its developer is also developing HALAC (High Availability Lossless Audio Compression). He recently released the source code for the first version of HALAC. And I don't think anyone cared.
      - cipehr 11mo ago
        Thank you for the information! Appreciate it. Will look into this more.
- andybak 11mo ago
  Surely something close to perceptually lossless is sufficient for most use cases?
  - AlotOfReading 11mo ago
    Think of all the use cases where the output is going to be ingested by another machine. You don't know that "perceptually lossless" as designed for normal human eyeballs on normal screens in normal lighting environments is going to contain all the information an ML system will use. You want to preserve data as long as possible, until you make an active choice to throw it away. Even the system designer may not know whether it's appropriate to throw that information away, for example if they're designing digital archival systems and having to consider future users who aren't available to provide requirements.
eviks 11mo ago
> AV2 .... further improve the image compression. ( Edit: Also worth pointing out current JPEG-XL encoder is no where near its maximum potential in terms of quality / compression ratio But at what cost? From this the en/decoding speed (links below) is much higher for those advanced video codecs, so for various lower powered devices they wouldn't be very suitable? Also, can we expect "near max potential" with AV2/near future or is it an ever-unachievable goal that shouldn't stop adding "non-max" codecs? https://res.cloudinary.com/cloudinary-marketing/image/upload/w_700,c_fill,f_auto,q_auto,dpr_2.0/Web_Assets/blog/Battle_of_the_Codecs_speed_v01.png https://res.cloudinary.com/cloudinary-marketing/image/upload... https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth...
- jaffathecake 11mo ago
  Fwiw, JPEG XL takes around 2.5x the time to decode as an equivalent AVIF, and has worse compression https://jakearchibald.com/2025/present-and-future-of-progressive-image-rendering/#jpeg-xl https://jakearchibald.com/2025/present-and-future-of-progres...
  - eviks 11mo ago
    Interesting, looks like another opportunity for Chrome to avoid the Safari mistake > slow. There's some suggestion that the Apple implementation is running on a single core, so maybe there's room for improvement. Though their own old attempt was even worse > of the old behind-a-flag Chromium JPEG XL decoder, and it's over 500% slower (6x) to decode than AVIF.
Nanopolygon 11mo ago
AVIF/AV1 is a codec that encodes both lossy and lossless files very slowly. JXL is significantly faster than AVIF. But AVIF provides better image quality than JXL even at lower settings. However, AV2 will require much more power and system resources for a small bandwidth gain.
- spartanatreyu 11mo ago
  > But AVIF provides better image quality than JXL even at lower settings. I don't think that's strictly true. The conventional reporting has been that JXL works better at regular web sizes, but AVIF starts to edge out at very low quality settings. However, the quality per size between the two is so close that there are comparisons showing JXL winning even where AVIF is supposed to out perform JXL. (e.g. https://tonisagrista.com/blog/2023/jpegxl-vs-avif/ https://tonisagrista.com/blog/2023/jpegxl-vs-avif/) Even at the point where AVIF should shine: when low bandwidth is important, JXL supports progressive decoding (AVIF is still trying to add this) so the user will see the images sooner with JXL rather than AVIF. --- There is one part where AVIF does beat JXL hands down, and that's animation (which makes sense considering AVIF comes from the modern AV1 video codec). However, any time you would want an animation in a file, you're better off just using a video codec anyway.
  - ksec 11mo ago
    To be fair, those comparison image size aren't small enough. Had it been 30 - 50% of those tested size AVIF should have the advantage. But then the question is should we even be presenting this level of quality. Or is it enough. I guess that is a different set of questions.

by ksec 11mo ago

snvzz 11mo ago

>medical images Isn't JPEG-XL a lossy codec?

MagnumOpus 11mo ago
It has both lossy and lossless modes.
- snvzz 11mo ago
  Good to hear. I sure hope they came up with a good, clear system to distinguish them.
  - lxgr 11mo ago
    As in, a clear way to detect whether a given file is lossy or lossless? I was thinking that too, but on the other hand, even a lossless file can't guarantee that its contents aren't the result of going through a lossy intermediate format, such as a screenshot created from a JPEG.
    - snvzz 11mo ago
      I meant like a filename convention, and tags in the file itself.
      - 149765 11mo ago
        There is some sort of tag, jxlinfo can tell you if a file is "lossy" or "(possibly) lossless".
      - stavros 11mo ago
        Presumably you can look at the file and tell which mode is used, though why would you care to know from the filename?
        crazygringo 11mo ago
        I find it incredibly helpful to know that .jpg is lossy and .png is lossless. There are so many reasons why it's almost hard to know where to begin. But it's basically the same reason why it's helpful for some documents to end in .docx and others to end in .xlsx. It tells you what kind of data is inside. And at least for me, for standard 24-bit RGB images, the distinction between lossy and lossless is much more important than between TIFF and PNG, or between JPG and HEIC. Knowing whether an image is degraded or not is the #1 important fact about an image for me, before anything else. It says so much about what the file is for and not for -- how I should or shouldn't edit it, what kind of format and compression level is suitable for saving after editing, etc. After that comes whether it's animated or not, which is why .apng is so helpful to distinguish it from .png. There's a good reason Microsoft Office documents aren't all just something like .msox, with an internal tag indicating whether they're a text document or a spreadsheet or a presentation. File extensions carry semantic meaning around the type of data they contain, and it's good practice to choose extensions that communicate the most important conceptual distinctions.
        stavros 11mo ago
        But JPEG has a lossless mode as well. How do you distinguish between the two now? This is an arbitrary distinction, for example then why do mp3 and ogg (vorbis) have different extensions? They're both lossy audio formats, so by that requirement, the extension should be the same. Otherwise, we should distinguish between bitrates with different extensions, eg mp3128, mp3192, etc.
ksec 11mo ago
JPEG-XL is both a lossy and lossless codec. It is already being used in Camera DNG format, making the RAW image smaller. While lossy codec is hard to compare and up for debate. JPEG-XL is actually better as a lossless codec in terms of compression ratio and compression complexity. There is only one other codec that beats it but it is not open source.
- cipehr 11mo ago
  What is the non-open source codec?
  - ksec 11mo ago
    HALIC (High Availability Lossless Image Compression) https://news.ycombinator.com/item?id=38990568 https://news.ycombinator.com/item?id=38990568
    - cipehr 11mo ago
      Thank yoU! Totally missed this.
  - Nanopolygon 11mo ago
    HALIC is by far the best lossless codec in terms of speed/compression ratio. If lossy mode were similarly available, we might not be discussing all these issues. I think he stopped developing HALIC for a long time due to lack of interest. Its developer is also developing HALAC (High Availability Lossless Audio Compression). He recently released the source code for the first version of HALAC. And I don't think anyone cared.
    - cipehr 11mo ago
      Thank you for the information! Appreciate it. Will look into this more.
andybak 11mo ago
Surely something close to perceptually lossless is sufficient for most use cases?
- AlotOfReading 11mo ago
  Think of all the use cases where the output is going to be ingested by another machine. You don't know that "perceptually lossless" as designed for normal human eyeballs on normal screens in normal lighting environments is going to contain all the information an ML system will use. You want to preserve data as long as possible, until you make an active choice to throw it away. Even the system designer may not know whether it's appropriate to throw that information away, for example if they're designing digital archival systems and having to consider future users who aren't available to provide requirements.

eviks 11mo ago

> AV2 .... further improve the image compression. ( Edit: Also worth pointing out current JPEG-XL encoder is no where near its maximum potential in terms of quality / compression ratio But at what cost? From this the en/decoding speed (links below) is much higher for those advanced video codecs, so for various lower powered devices they wouldn't be very suitable? Also, can we expect "near max potential" with AV2/near future or is it an ever-unachievable goal that shouldn't stop adding "non-max" codecs? https://res.cloudinary.com/cloudinary-marketing/image/upload/w_700,c_fill,f_auto,q_auto,dpr_2.0/Web_Assets/blog/Battle_of_the_Codecs_speed_v01.png https://res.cloudinary.com/cloudinary-marketing/image/upload... https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth...

jaffathecake 11mo ago
Fwiw, JPEG XL takes around 2.5x the time to decode as an equivalent AVIF, and has worse compression https://jakearchibald.com/2025/present-and-future-of-progressive-image-rendering/#jpeg-xl https://jakearchibald.com/2025/present-and-future-of-progres...
- eviks 11mo ago
  Interesting, looks like another opportunity for Chrome to avoid the Safari mistake > slow. There's some suggestion that the Apple implementation is running on a single core, so maybe there's room for improvement. Though their own old attempt was even worse > of the old behind-a-flag Chromium JPEG XL decoder, and it's over 500% slower (6x) to decode than AVIF.

Nanopolygon 11mo ago

AVIF/AV1 is a codec that encodes both lossy and lossless files very slowly. JXL is significantly faster than AVIF. But AVIF provides better image quality than JXL even at lower settings. However, AV2 will require much more power and system resources for a small bandwidth gain.

spartanatreyu 11mo ago
> But AVIF provides better image quality than JXL even at lower settings. I don't think that's strictly true. The conventional reporting has been that JXL works better at regular web sizes, but AVIF starts to edge out at very low quality settings. However, the quality per size between the two is so close that there are comparisons showing JXL winning even where AVIF is supposed to out perform JXL. (e.g. https://tonisagrista.com/blog/2023/jpegxl-vs-avif/ https://tonisagrista.com/blog/2023/jpegxl-vs-avif/) Even at the point where AVIF should shine: when low bandwidth is important, JXL supports progressive decoding (AVIF is still trying to add this) so the user will see the images sooner with JXL rather than AVIF. --- There is one part where AVIF does beat JXL hands down, and that's animation (which makes sense considering AVIF comes from the modern AV1 video codec). However, any time you would want an animation in a file, you're better off just using a video codec anyway.
- ksec 11mo ago
  To be fair, those comparison image size aren't small enough. Had it been 30 - 50% of those tested size AVIF should have the advantage. But then the question is should we even be presenting this level of quality. Or is it enough. I guess that is a different set of questions.