9 ms·

Still no love for JPEG XL: Browser maker love-in snubs next-gen image format

99 points by DaveFlater 3y ago

anotherhue 3y ago
> The Firefox maker said it's neutral with regard to the technology, citing cost Since they pay their CEO $7MM per year, this is a profoundly infuriating argument.
- jokoon 3y ago
  why 2 M in $7MM? 2 millions millions dollars? that's 10^12 dollars.
  - anotherhue 3y ago
    It's the accepted financial notation, perhaps you're confusing it with 7M$ which would be an SI like encoding. https://corporatefinanceinstitute.com/resources/fixed-income/mm-millions/ https://corporatefinanceinstitute.com/resources/fixed-income...
    - themerone 3y ago
      That page says MM is antiquated, falling out of favor, and M is the more modern way to represent a million.
      - zamadatix 3y ago
        You have to be careful about separating your interpretation of what something is saying when referring to the claims of the content directly like that. Nowhere does the page say antiquated, that's just one particularly strong interpretation of "becoming less common". It'll probably eventually be antiquated but it certainly isn't yet - it's still very popular and accepted.
  - NelsonMinar 3y ago
    Roman numerals. 1000 1000
    - LinAGKar 3y ago
      Then it would be 2000
  - wongarsu 3y ago
    Because finance has weird conventions about numbers, and $7M could be misread as $7000 in the wrong context
- rwmj 3y ago
  With the CEO getting that much, they do have to be careful about other costs.
- dist-epoch 3y ago
  Technically Google is the one paying Mozilla CEO's $7m salary. Clearly a good investment, Firefox market share is lower and lower, and has been steadily declining since Google became Mozilla's main income source.
brucethemoose2 3y ago
When the Google JXL controversy first went down, I found that Google's commit rejecting JXL was authored by someone with AOMedia contributions, and that the manager who signed off and commented on it had some interview about the benefits of AV1. The links are buried somewhere on Phoronix, I am looking... But what I am saying is Google's rejection of JXL seems to be as bad as it looks.
- SahAssar 3y ago
  Given google and chromes involvement with AOMedia I think that its pretty natural that anyone focused on image/video codecs in chrome would have some sort of (distant or direct) connection to AOMedia. If AOMedia was profit driven in any way (like MPEGLA sorta is via patent pools) it'd look worse, but in this case I just think it's the case that the pool of people working on codec support in a particular browser probably isn't that large so the overlap is to be expected.
- fngjdflmdflg 3y ago
  I see this comment here[0] from one of the developers of av1/avif[1] but it is important to note that nowhere is it mentioned that it is him who made the decision to reject jxl. [0] https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/xX-NnWtTBQAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc... [1] https://research.google/people/james-bankoski/ https://research.google/people/james-bankoski/
- cjawdb 3y ago
  The commit to add the flag saying JXL was being removed soon was reviewed and approved by James Zern, who also created and authored the commit that actually ripped out the JXL code from Chromium. Zern is one of the co-authors of WebP and is the primary contributor to libwebp.
  - brucethemoose2 3y ago
    Hmm, wasn't the name I remembered. I hate to claim something without a citation, but for the life of me I can't find my Phoronix comment... Only my other comments referencing it.
geor9e 3y ago
Edit: Nevermind, Mac & Safari support both formats now. Good to hear. Original comment: Ironically, .JXL opens natively on the Mac, but can't open in any browser. It's the exact opposite of .WEBP which can't open on Mac but too many websites seem to use it. https://jpegxl.info/test-page/ https://jpegxl.info/test-page/
- kristofferR 3y ago
  > can't open in any browser. Are you sure? When I click that link Firefox downloads the image file, which then opens correctly in Safari.
  - geor9e 3y ago
    Oh you're right, Safari does show it. If I go to the URL directly it downloads the file, which is why I assumed it couldn't view it. But it does show on the page https://jpegxl.info/test-page/ https://jpegxl.info/test-page/
    - barkerja 3y ago
      Safari was an early adopter of JPEG XL. In the past couple years, actually, the team at Apple responsible for Safari has been making inroads on features and spec work. Jen Simmons especially has been astounding, particularly with her engagement with the community. She was recently on the Syntax Podcast, and I thoroughly enjoyed the talk. Can catch a bit here: https://www.threads.net/@syntax_fm/post/C22hyslOABy/ https://www.threads.net/@syntax_fm/post/C22hyslOABy/
- gbear605 3y ago
  That link works perfectly on any iOS browser
- alwillis 3y ago
  > It's the exact opposite of .WEBP which can't open on Mac I suppose it depends on what version of macOS you're running; on my Mac running Sonoma, WebP files open just like JPEGs, PNGs, etc. and have for the last 2 or 3 macOS versions.
rwmj 3y ago
From the browser makers' point of view there's quite a bit of risk with introducing a new image format. libjxl is written in C++ so undoubtedly will be full of undiscovered security issues. I'm sure that someone will write a decoder in a safer language, but that work still needs to be done and/or finished, and then integrated with the browser. At the same time there are to 5 significant places probably 0% of websites that host .jxl files. So at the start it's all downside and almost no upside. (Chicken and egg problem here of course which is no one will create the websites until there is wide browser support.)
- cesarb 3y ago
  > libjxl is written in C++ so undoubtedly will be full of undiscovered security issues. There's the WebAssembly sandboxing trick (https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ https://hacks.mozilla.org/2021/12/webassembly-and-back-again...) which might mitigate that, but an image decoder might fall into the "too performance-sensitive to accept the modest overhead incurred" case.
- apichat 3y ago
  Two rust implementation projects : https://github.com/tirr-c/jxl-oxide https://github.com/tirr-c/jxl-oxide https://github.com/libjxl/jxl-rs https://github.com/libjxl/jxl-rs
  - rwmj 3y ago
    Unfortunately a Rust implementation doesn't solve everything that could go wrong in a browser. You need to think about amongst other things: total memory that an image could allocate, safety of network references (if the format allows that, like SVG or XML), any kind of unbounded processing or memory usage caused by the image (such as a "zip bomb"), and what could possibly go wrong for every corner case in the standard. The Wikipedia page says that JPEG XL supports up to 1 terapixel images, which is unlikely to be a good idea for a browser even if it's handled in a memory safe way. A while back I fuzz tested qemu's handling of various different disk image formats (I know, a different type of "image", but bear with me!) I found many cases where qemu could consume huge amounts of memory or CPU time on some inputs. Often times the inputs were quite small too, allowing nasty amplification attacks. As a result of this standard advice for clouds that allow you to upload untrusted images is to decode in a separate process. That process is protected with ulimits, so it will die, rather than trying to allocate all memory in the machine or consume huge amounts of CPU.
cyb_ 3y ago
Related discussion: JPEG XL support has officially been removed from Chromium https://news.ycombinator.com/item?id=33933208 https://news.ycombinator.com/item?id=33933208 (292 points, 378 comments)
apichat 3y ago
To see how deep this is madness : https://github.com/web-platform-tests/interop/issues/430#issuecomment-1745728757 https://github.com/web-platform-tests/interop/issues/430#iss... And Microsoft seems to be interested and want to integrate it into Windows : https://news.ycombinator.com/item?id=39163181 https://news.ycombinator.com/item?id=39163181
- scorpio241 3y ago
  After Adobe and Apple, also Samsung has recently started support (with S24): https://news.ycombinator.com/item?id=39064820 https://news.ycombinator.com/item?id=39064820
  - out_of_protocol 3y ago
    Unfortunately that's just DNG (raw image) format with jxl compression
mirsadm 3y ago
JPEG XL would have been a much better choice for HDR photos on Android than the abomination that is UltraHDR.
- JyrkiAlakuijala 3y ago
  It is difficult to understand the benefits of the gainmap approach over HDR first and high quality local tone mapping. Especially when there is a modern local tone mapping algorithm with oss implementation that runs in real time. Some industry leads believe that the tone mapping is part of artistic creativity and belongs to the photographer. I don't share this viewpoint, but I'm looking at this from a purely technical and philosophical viewpoint. I think we should have HDR first world, and SDR is a temporary fallback.
  - brucethemoose2 3y ago
    > tone mapping is part of artistic creativity And its done incorrectly way too often. (I am sitting on no high horse here, I'm guilty of it as well).
jokoon 3y ago
I wonder how hard it would be for smartphone to output JXL instead of jpeg their jpeg encoder often barely compress anything
- JyrkiAlakuijala 3y ago
  Jpeg xl team at Google has opensourced a new JPEG encoder, too. It is called jpegli. It compresses very well.
qalmakka 3y ago
Google has been acting even stupider than usual lately, but snubbing JXL goes beyond stupidity - it's clearly malicious, it must be, otherwise I really can't even fathom the rationale behind such a moronic decision may ever be.
- ur-whale 3y ago
  > I really can't even fathom the rationale If you take into account that jxl was and is in large part an effort supported internally by Google teams, and fought against by another, a fairly occam's razor like explanation is that someone at Google with influence is deeply butthurt because another team built a better toaster.
hardcopy 3y ago
I wish we'd see more passive aggressive activism, for example, HN switching their logo (y18.svg) for y18.jxl
ur-whale 3y ago
This only points to one things: developers strictly don't understand how politics work. They keep harping about JXL's technical superiority (who disagrees btw?) when at this point it is utterly clear that the choice to boot it from browsers have precisely nothing to do with technical concerns.
- alwillis 3y ago
  > This only points to one things: developers strictly don't understand how politics work. No lies detected and so painfully obvious.
jmull 3y ago
> "But instead this was just another development thread Google single-handedly stopped out of nothing but ego?" There's a reasonable cost/benefit argument against standardizing JPEG XL in browsers. You don't have to agree with it, but JPEG XL proponents shouldn't just ignore it. The argument is: (1) the cost is large -- implementation and maintenance of a complex image codec takes time, and image codecs are high-risk from a security perspective. (2) the benefit is relatively small -- it needs to provide a clear advantage over existing alternatives like jpg, png, webp, avif in some significant general use cases. Now, you don't have to agree with that argument -- e.g. you can argue the cost isn't that high, or that there are valuable advantages to jxl for significant use cases that aren't covered by existing alternative. But you do need to engage that argument. Otherwise what else do you have? Popular demand isn't going to work, because you're in a chicken-and-egg situation. I suppose you can try to bribe and/or bully key decision makers for all the major browsers, though I hope that wouldn't work.
- spider-mario 3y ago
  There is popular demand (including from Adobe https://github.com/web-platform-tests/interop/issues/430#issuecomment-1753109905 https://github.com/web-platform-tests/interop/issues/430#iss..., https://crbug.com/40168998#comment62 https://crbug.com/40168998#comment62), which is arguably evidence against (2). (Disclaimer: I’m a JPEG XL contributor.)
- alwillis 3y ago
  > The argument is: (1) the cost is large -- implementation and maintenance of a complex image codec takes time, and image codecs are high-risk from a security perspective. If you look at the history of Google employees created the basis for JPEG XL [1], having it included in beta builds of Chrome and then removing it "for reasons", it's pretty obvious it wasn't pulled for technical or security reasons. Obviously Apple didn't think there were significant security and implementation issues preventing them from enabling JPEG XL on over 2 billion devices. The Chrome team has proposed a number of web features and APIs that Apple, Mozilla and sometimes Microsoft don't want to implement due to security and privacy reasons. Usually that doesn't stop Chrome from going ahead and shipping them anyway. > (2) the benefit is relatively small -- it needs to provide a clear advantage over existing alternatives like jpg, png, webp, avif in some significant general use cases. JPEG XL does provide advantages over existing alternatives—The Case for JPEG XL [2]: In the past, new image formats have been introduced that brought improvements in some areas while also introducing regressions in others. For example, PNG was a great improvement over GIF, except that it did not support animation. WebP brought compression improvements over JPEG in the low to medium fidelity range but at the cost of losing progressive decoding and high-fidelity 4:4:4 encoding. AVIF improved compression further, but at the cost of both progressive decoding and deployable encoders. We looked at six aspects of JPEG XL where it brings significant benefits over existing image formats: * Lossless JPEG recompression (20% on average) * Progressive decoding * Lossless compression performance * Lossy compression performance * Deployable encoder * Works across the workflow [1]: https://github.com/google/pik https://github.com/google/pik [2]: https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl
boatsie 3y ago
This isn’t some conspiracy, it’s about money. JPEG XL is likely patent encumbered and this including it may require paying licensing fees. The companies involved can’t admit that because if they do, they’d be willfully infringing if they do end up including it at some point…
- DaveFlater 3y ago
  What makes it seem probable that it is patent-encumbered? Is there something specific I can read about or is it just the track record of previous standards (starting with arithmetic encoding in the first JPEG)?
  - boatsie 3y ago
    Pretty much all modern video/audio/image codecs are, look at HEIC for example.
    - cjawdb 3y ago
      HEIC is barely used and seems very cherry-picked to find something that IS still royalty encumbered. >Pretty much all modern video/audio/image codecs are The exact opposite is true. The most popular modern codecs are almost all royalty-free. WebP, AVIF, JXL are all royalty-free. VP9/AV1 are royalty-free. Opus is royalty-free.
- cjawdb 3y ago
  I'm not sure why you didn't bother looking this up before commenting but JPEG XL is royalty-free and open source. There were some concerns raised well over a year ago about some specific subset of JXL's compression and they were completely settled and it's a non-issue. Google's decisions have nothing to do with paying royalties or licensing fees.

99 points by DaveFlater 3y ago

> The Firefox maker said it's neutral with regard to the technology, citing cost Since they pay their CEO $7MM per year, this is a profoundly infuriating argument.

jokoon 3y ago
why 2 M in $7MM? 2 millions millions dollars? that's 10^12 dollars.
- anotherhue 3y ago
  It's the accepted financial notation, perhaps you're confusing it with 7M$ which would be an SI like encoding. https://corporatefinanceinstitute.com/resources/fixed-income/mm-millions/ https://corporatefinanceinstitute.com/resources/fixed-income...
  - themerone 3y ago
    That page says MM is antiquated, falling out of favor, and M is the more modern way to represent a million.
    - zamadatix 3y ago
      You have to be careful about separating your interpretation of what something is saying when referring to the claims of the content directly like that. Nowhere does the page say antiquated, that's just one particularly strong interpretation of "becoming less common". It'll probably eventually be antiquated but it certainly isn't yet - it's still very popular and accepted.
- NelsonMinar 3y ago
  Roman numerals. 1000 1000
  - LinAGKar 3y ago
    Then it would be 2000
- wongarsu 3y ago
  Because finance has weird conventions about numbers, and $7M could be misread as $7000 in the wrong context
rwmj 3y ago
With the CEO getting that much, they do have to be careful about other costs.
dist-epoch 3y ago
Technically Google is the one paying Mozilla CEO's $7m salary. Clearly a good investment, Firefox market share is lower and lower, and has been steadily declining since Google became Mozilla's main income source.

brucethemoose2 3y ago

When the Google JXL controversy first went down, I found that Google's commit rejecting JXL was authored by someone with AOMedia contributions, and that the manager who signed off and commented on it had some interview about the benefits of AV1. The links are buried somewhere on Phoronix, I am looking... But what I am saying is Google's rejection of JXL seems to be as bad as it looks.

SahAssar 3y ago
Given google and chromes involvement with AOMedia I think that its pretty natural that anyone focused on image/video codecs in chrome would have some sort of (distant or direct) connection to AOMedia. If AOMedia was profit driven in any way (like MPEGLA sorta is via patent pools) it'd look worse, but in this case I just think it's the case that the pool of people working on codec support in a particular browser probably isn't that large so the overlap is to be expected.
fngjdflmdflg 3y ago
I see this comment here[0] from one of the developers of av1/avif[1] but it is important to note that nowhere is it mentioned that it is him who made the decision to reject jxl. [0] https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/xX-NnWtTBQAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc... [1] https://research.google/people/james-bankoski/ https://research.google/people/james-bankoski/
cjawdb 3y ago
The commit to add the flag saying JXL was being removed soon was reviewed and approved by James Zern, who also created and authored the commit that actually ripped out the JXL code from Chromium. Zern is one of the co-authors of WebP and is the primary contributor to libwebp.
- brucethemoose2 3y ago
  Hmm, wasn't the name I remembered. I hate to claim something without a citation, but for the life of me I can't find my Phoronix comment... Only my other comments referencing it.

geor9e 3y ago

Edit: Nevermind, Mac & Safari support both formats now. Good to hear. Original comment: Ironically, .JXL opens natively on the Mac, but can't open in any browser. It's the exact opposite of .WEBP which can't open on Mac but too many websites seem to use it. https://jpegxl.info/test-page/ https://jpegxl.info/test-page/

kristofferR 3y ago
> can't open in any browser. Are you sure? When I click that link Firefox downloads the image file, which then opens correctly in Safari.
- geor9e 3y ago
  Oh you're right, Safari does show it. If I go to the URL directly it downloads the file, which is why I assumed it couldn't view it. But it does show on the page https://jpegxl.info/test-page/ https://jpegxl.info/test-page/
  - barkerja 3y ago
    Safari was an early adopter of JPEG XL. In the past couple years, actually, the team at Apple responsible for Safari has been making inroads on features and spec work. Jen Simmons especially has been astounding, particularly with her engagement with the community. She was recently on the Syntax Podcast, and I thoroughly enjoyed the talk. Can catch a bit here: https://www.threads.net/@syntax_fm/post/C22hyslOABy/ https://www.threads.net/@syntax_fm/post/C22hyslOABy/
gbear605 3y ago
That link works perfectly on any iOS browser
alwillis 3y ago
> It's the exact opposite of .WEBP which can't open on Mac I suppose it depends on what version of macOS you're running; on my Mac running Sonoma, WebP files open just like JPEGs, PNGs, etc. and have for the last 2 or 3 macOS versions.

rwmj 3y ago

From the browser makers' point of view there's quite a bit of risk with introducing a new image format. libjxl is written in C++ so undoubtedly will be full of undiscovered security issues. I'm sure that someone will write a decoder in a safer language, but that work still needs to be done and/or finished, and then integrated with the browser. At the same time there are to 5 significant places probably 0% of websites that host .jxl files. So at the start it's all downside and almost no upside. (Chicken and egg problem here of course which is no one will create the websites until there is wide browser support.)

cesarb 3y ago
> libjxl is written in C++ so undoubtedly will be full of undiscovered security issues. There's the WebAssembly sandboxing trick (https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ https://hacks.mozilla.org/2021/12/webassembly-and-back-again...) which might mitigate that, but an image decoder might fall into the "too performance-sensitive to accept the modest overhead incurred" case.
apichat 3y ago
Two rust implementation projects : https://github.com/tirr-c/jxl-oxide https://github.com/tirr-c/jxl-oxide https://github.com/libjxl/jxl-rs https://github.com/libjxl/jxl-rs
- rwmj 3y ago
  Unfortunately a Rust implementation doesn't solve everything that could go wrong in a browser. You need to think about amongst other things: total memory that an image could allocate, safety of network references (if the format allows that, like SVG or XML), any kind of unbounded processing or memory usage caused by the image (such as a "zip bomb"), and what could possibly go wrong for every corner case in the standard. The Wikipedia page says that JPEG XL supports up to 1 terapixel images, which is unlikely to be a good idea for a browser even if it's handled in a memory safe way. A while back I fuzz tested qemu's handling of various different disk image formats (I know, a different type of "image", but bear with me!) I found many cases where qemu could consume huge amounts of memory or CPU time on some inputs. Often times the inputs were quite small too, allowing nasty amplification attacks. As a result of this standard advice for clouds that allow you to upload untrusted images is to decode in a separate process. That process is protected with ulimits, so it will die, rather than trying to allocate all memory in the machine or consume huge amounts of CPU.

cyb_ 3y ago

Related discussion: JPEG XL support has officially been removed from Chromium https://news.ycombinator.com/item?id=33933208 https://news.ycombinator.com/item?id=33933208 (292 points, 378 comments)

apichat 3y ago

To see how deep this is madness : https://github.com/web-platform-tests/interop/issues/430#issuecomment-1745728757 https://github.com/web-platform-tests/interop/issues/430#iss... And Microsoft seems to be interested and want to integrate it into Windows : https://news.ycombinator.com/item?id=39163181 https://news.ycombinator.com/item?id=39163181

scorpio241 3y ago
After Adobe and Apple, also Samsung has recently started support (with S24): https://news.ycombinator.com/item?id=39064820 https://news.ycombinator.com/item?id=39064820
- out_of_protocol 3y ago
  Unfortunately that's just DNG (raw image) format with jxl compression

mirsadm 3y ago

JPEG XL would have been a much better choice for HDR photos on Android than the abomination that is UltraHDR.

JyrkiAlakuijala 3y ago
It is difficult to understand the benefits of the gainmap approach over HDR first and high quality local tone mapping. Especially when there is a modern local tone mapping algorithm with oss implementation that runs in real time. Some industry leads believe that the tone mapping is part of artistic creativity and belongs to the photographer. I don't share this viewpoint, but I'm looking at this from a purely technical and philosophical viewpoint. I think we should have HDR first world, and SDR is a temporary fallback.
- brucethemoose2 3y ago
  > tone mapping is part of artistic creativity And its done incorrectly way too often. (I am sitting on no high horse here, I'm guilty of it as well).

jokoon 3y ago

I wonder how hard it would be for smartphone to output JXL instead of jpeg their jpeg encoder often barely compress anything

JyrkiAlakuijala 3y ago
Jpeg xl team at Google has opensourced a new JPEG encoder, too. It is called jpegli. It compresses very well.

qalmakka 3y ago

Google has been acting even stupider than usual lately, but snubbing JXL goes beyond stupidity - it's clearly malicious, it must be, otherwise I really can't even fathom the rationale behind such a moronic decision may ever be.

ur-whale 3y ago
> I really can't even fathom the rationale If you take into account that jxl was and is in large part an effort supported internally by Google teams, and fought against by another, a fairly occam's razor like explanation is that someone at Google with influence is deeply butthurt because another team built a better toaster.

hardcopy 3y ago

I wish we'd see more passive aggressive activism, for example, HN switching their logo (y18.svg) for y18.jxl

ur-whale 3y ago

This only points to one things: developers strictly don't understand how politics work. They keep harping about JXL's technical superiority (who disagrees btw?) when at this point it is utterly clear that the choice to boot it from browsers have precisely nothing to do with technical concerns.

alwillis 3y ago
> This only points to one things: developers strictly don't understand how politics work. No lies detected and so painfully obvious.

jmull 3y ago

> "But instead this was just another development thread Google single-handedly stopped out of nothing but ego?" There's a reasonable cost/benefit argument against standardizing JPEG XL in browsers. You don't have to agree with it, but JPEG XL proponents shouldn't just ignore it. The argument is: (1) the cost is large -- implementation and maintenance of a complex image codec takes time, and image codecs are high-risk from a security perspective. (2) the benefit is relatively small -- it needs to provide a clear advantage over existing alternatives like jpg, png, webp, avif in some significant general use cases. Now, you don't have to agree with that argument -- e.g. you can argue the cost isn't that high, or that there are valuable advantages to jxl for significant use cases that aren't covered by existing alternative. But you do need to engage that argument. Otherwise what else do you have? Popular demand isn't going to work, because you're in a chicken-and-egg situation. I suppose you can try to bribe and/or bully key decision makers for all the major browsers, though I hope that wouldn't work.

spider-mario 3y ago
There is popular demand (including from Adobe https://github.com/web-platform-tests/interop/issues/430#issuecomment-1753109905 https://github.com/web-platform-tests/interop/issues/430#iss..., https://crbug.com/40168998#comment62 https://crbug.com/40168998#comment62), which is arguably evidence against (2). (Disclaimer: I’m a JPEG XL contributor.)
alwillis 3y ago
> The argument is: (1) the cost is large -- implementation and maintenance of a complex image codec takes time, and image codecs are high-risk from a security perspective. If you look at the history of Google employees created the basis for JPEG XL [1], having it included in beta builds of Chrome and then removing it "for reasons", it's pretty obvious it wasn't pulled for technical or security reasons. Obviously Apple didn't think there were significant security and implementation issues preventing them from enabling JPEG XL on over 2 billion devices. The Chrome team has proposed a number of web features and APIs that Apple, Mozilla and sometimes Microsoft don't want to implement due to security and privacy reasons. Usually that doesn't stop Chrome from going ahead and shipping them anyway. > (2) the benefit is relatively small -- it needs to provide a clear advantage over existing alternatives like jpg, png, webp, avif in some significant general use cases. JPEG XL does provide advantages over existing alternatives—The Case for JPEG XL [2]: In the past, new image formats have been introduced that brought improvements in some areas while also introducing regressions in others. For example, PNG was a great improvement over GIF, except that it did not support animation. WebP brought compression improvements over JPEG in the low to medium fidelity range but at the cost of losing progressive decoding and high-fidelity 4:4:4 encoding. AVIF improved compression further, but at the cost of both progressive decoding and deployable encoders. We looked at six aspects of JPEG XL where it brings significant benefits over existing image formats: * Lossless JPEG recompression (20% on average) * Progressive decoding * Lossless compression performance * Lossy compression performance * Deployable encoder * Works across the workflow [1]: https://github.com/google/pik https://github.com/google/pik [2]: https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl

boatsie 3y ago

This isn’t some conspiracy, it’s about money. JPEG XL is likely patent encumbered and this including it may require paying licensing fees. The companies involved can’t admit that because if they do, they’d be willfully infringing if they do end up including it at some point…

DaveFlater 3y ago
What makes it seem probable that it is patent-encumbered? Is there something specific I can read about or is it just the track record of previous standards (starting with arithmetic encoding in the first JPEG)?
- boatsie 3y ago
  Pretty much all modern video/audio/image codecs are, look at HEIC for example.
  - cjawdb 3y ago
    HEIC is barely used and seems very cherry-picked to find something that IS still royalty encumbered. >Pretty much all modern video/audio/image codecs are The exact opposite is true. The most popular modern codecs are almost all royalty-free. WebP, AVIF, JXL are all royalty-free. VP9/AV1 are royalty-free. Opus is royalty-free.
cjawdb 3y ago
I'm not sure why you didn't bother looking this up before commenting but JPEG XL is royalty-free and open source. There were some concerns raised well over a year ago about some specific subset of JXL's compression and they were completely settled and it's a non-issue. Google's decisions have nothing to do with paying royalties or licensing fees.