19 ms·

JPEG XL and the Pareto Front

497 points by botanical 3y ago

eviks 3y ago
Welcome efficiency improvements And in general, Jon's posts provide a pretty good overview on the topic of codec comparison Pity such a great format is being held back by the much less rigorous reviews
mikae1 3y ago
If only Google could be convinced to adopt this marvelous codec... Not looking super positive at the moment: https://issues.chromium.org/issues/40270698 https://issues.chromium.org/issues/40270698 https://bugs.chromium.org/p/chromium/issues/detail?id=1451807&no_tracker_redirect=1 https://bugs.chromium.org/p/chromium/issues/detail?id=145180...
- pgeorgi 3y ago
  All those requests to revert the removal are funny: you want Chrome to re-add jxl behind a feature flag? Doesn't seem very useful. Also, all those Chrome offshoots (Edge, Brave, Opera, etc) could easily add and enable it to distinguish themselves from Chrome ("faster page load", "less network use") and don't. Makes me wonder what's going on...
  - silisili 3y ago
    Simply put these offshoots don't really seem to do browser code, and realize how expensive it would be for them to diverge at the core.
  - eviks 3y ago
    No, obviously to re-add jxl without a flag
    - pgeorgi 3y ago
      "jxl without a flag" can't be re-added because that was never a thing.
      - albert180 3y ago
        [flagged]
      - deleted 3y ago
        [deleted]
      - elygre 3y ago
        Or (re-add jxl) (without a flag).
      - eviks 3y ago
        It can, that's why you didn't say "re-add jxl", but had to mention the flag, 're-add' has no flag implication, that pedantic attempt to constraint is somehing you've made up, that's not what people want, just read those linked issues
        pgeorgi 3y ago
        It has a flag implication because jpeg-xl never came without being hidden behind a flag. Nothing was taken away from ordinary users at any point in time. And I suppose the Chrome folks have the telemetry to know how many people set that damn flag.
        jdiff 3y ago
        >"But the plans were on display…” > “On display? I eventually had to go down to the cellar to find them.” > “That’s the display department.” > “With a flashlight.” > “Ah, well, the lights had probably gone.” > “So had the stairs.” > “But look, you found the notice, didn’t you?” > “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.’”
        3y ago
  - lonjil 3y ago
    > you want Chrome to re-add jxl behind a feature flag? Doesn't seem very useful. Chrome has a neat feature where some flags can be enabled by websites, so that websites can choose to cooperate in testing. They never did this for JXL, but if they re-added JXL behind a flag, they could do so but with such testing enabled. Then they could get real data from websites actually using it, without committing to supporting it if it isn't useful. > Also, all those Chrome offshoots (Edge, Brave, Opera, etc) could easily add and enable it to distinguish themselves from Chrome ("faster page load", "less network use") and don't. Makes me wonder what's going on... Edge doesn't use Chrome's own codec support. It uses Windows's media framework. JXL is being added to it next year.
    - firsching 3y ago
      > Edge doesn't use Chrome's own codec support. It uses Windows's media framework. JXL is being added to it next year. Interesting!
  - deleted 3y ago
    [deleted]
- sergioisidoro 3y ago
  It's so frustrating how the chromium team is ending up as a gatekeeper of the Internet by pick and choosing what gets developed or not. I recently come across another issue pertaining to the chromium team not budging on their decisions, despite pressure from the community and an RFC backing it up - in my case custom headers in WebSocket handshakes, that are supported by other Javascript runtimes like node and bun, but the chromium maintainer just disagrees with it - https://github.com/whatwg/websockets/issues/16#issuecomment-1961031987 https://github.com/whatwg/websockets/issues/16#issuecomment-...
  - hwbunny 3y ago
    Question is for how long. Time to slam the hammer on them.
    - hhh 3y ago
      Why not make a better product than slam some metaphorical hammer?
      - mort96 3y ago
        That's not how this works. Firefox is the closest we have, and realistically the closest we will get to a "better product" than Chromium for the foreseeable future, and it's clearly not enough.
        KingOfCoders 3y ago
        And Firefox does not support the format. Mozilla is the same political company as everyone else.
        bombcar 3y ago
        The only hammer at all left is Safari, basically on iPhones only. That hammer is very close to going away; if the EU does force Apple to really open the browsers on the iPhone, everything will be Chrome as far as the eye can see in short order. And then we fully enter the chromE6 phase.
- jillesvangurp 3y ago
  They didn't "lose interest", their lawyers pulled the emergency brakes. Blame patent holders, not Google. Like Microsoft: https://www.theregister.com/2022/02/17/microsoft_ans_patent/ https://www.theregister.com/2022/02/17/microsoft_ans_patent/. Microsoft could probably be convinced to be reasonable. But there may be a few others. Google actually also holds some patents over this but they've done the right thing and license those patents along with their implementation. To fix this, you'd need to convince Google, and other large companies that would be exposed to law suits related to these patents (Apple, Adobe, etc.), that these patent holders are not going to insist on being compensated. Other formats are less risky; especially the older ones. Jpeg is fine because it's been out there for so long that any patents applicable to it have long expired. Same with GIF, which once was held up by patents. Png is at this point also fine. If any patents applied at all they will soon have expired as the PNG standard dates back to 1997 and work on it depended on research from the seventies and eighties.
  - lifthrasiir 3y ago
    > [...] other large companies that would be exposed to law suits related to these patents (Apple, Adobe, etc.) [...] Adobe included JPEG XL support to their products and also the DNG specification. So that argument is pretty much dead, no?
    - jillesvangurp 3y ago
      Not that simple. Maybe they struck a deal with a few of the companies or they made a different risk calculation. And of course they have a pretty fierce patent portfolio themselves so there's the notion of them being able to retaliate in kind to some of these companies.
      - lifthrasiir 3y ago
        I don't think that's true (see my other comment for what the patent is really about), but even when it is, Adobe's adoption means that JPEG XL is worth the supposed "risk". And Google does ship a lot of technologies that are clearly patent-encumbered. If the patent is the main concern, they could have answered so because there are enough people wondering about the patent status, but the Chrome team's main reason against JPEG XL was quite different.
- Pikamander2 3y ago
  Mozilla effectively gave up on it before Google did. https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 It's a real shame, because this is one of those few areas where Firefox could have lead the charge instead of following in Chrome's footsteps. I remember when they first added APNG support and it took Chrome years to catch up, but I guess those days are gone. Oddly enough, Safari is the only major browser that currently supports it despite regularly falling behind on tons of other cutting-edge web standards. https://caniuse.com/jpegxl https://caniuse.com/jpegxl
  - JyrkiAlakuijala 3y ago
    I followed Mozilla/Firefox integration closely. I was able to observe enthusiasm from their junior to staff level engineers (linkedin-assisted analysis of the related bugs ;-). However, an engineering director stepped in and locked the discussions because they were in "no new information" stage, and their position has been neutral on JPEG XL, and the integration has not progressed from the nightly builds to the next stage. Ten years ago Mozilla used to have the most prominent image and video compression effort called Daala. They posted inspiring blog posts about their experiments. Some of their work was integrated with Cisco's Thor and On2's/Chrome's VP8/9/10, leading to AV1 and AVIF. Today, I believe, Mozilla has focused away from this research and the ex-Daala researchers have found new roles.
    - lonjil 3y ago
      Daala's and Thor's features were supposed to be integrated into AV1, but in the end, they wanted to finish AV1 as fast as possible, so very little that wasn't in VP10 made it into AV1. I guess it will be in AV2, though.
      - JyrkiAlakuijala 3y ago
        I like to think that there might be an easy way to improve AV2 today — drop the whole keyframe coding and replace it with JPEG XL images as keyframes.
      - 3y ago
- deleted 3y ago
  [deleted]
Zamicol 3y ago
> The new version of libjxl brings a very substantial reduction in memory consumption, by an order of magnitude, for both lossy and lossless compression. Also the speed is improved, especially for multi-threaded lossless encoding where the default effort setting is now an order of magnitude faster. Very impressive! The article too is well written. Great work all around.
- deleted 3y ago
  [deleted]
Modified3019 3y ago
At the very low quality settings, it's kinda remarkable how jpeg manages to to keep a sharper approximation of detail that preserves the holistic quality of the image better in spite of the obvious artifacts making it look like a mess of cubism when examined close. It's basically converting the image into some kind of abstract art style. Whereas jxl and avif just become blurry.
- porker 3y ago
  Yes, that was my takeaway from this that JPEG keeps edge sharpness really well (e.g. the eyelashes) while the jxl and avif smooth all detail out of the image.
  - mort96 3y ago
    No, JXL and AVIF keep keep the same level of edge sharpness but without all the blocking artifacts when given the same amount of bits per pixel as the lowest-quality jpeg.
- JyrkiAlakuijala 3y ago
  It is because JPEG is given 0.5 bits per pixel, where JPEG XL and AVIF are given around 0.22 and 0.2. These images attempt to be at equal level of distortion, not at equal compression. Bpps are reported beside the images. In practice, use of quality 65 is rare in the internet and only used at the lowest quality tier sites. Quality 75 seems to be usual poor quality and quality 85 the average. I use quality 94 yuv444 or better when I need to compress.
- bmacho 3y ago
  You refer to this? https://res.cloudinary.com/jon/qp-low.png https://res.cloudinary.com/jon/qp-low.png Bitrates are in the left column, jpg low quality is the same size as jxl/avif med-low quality (0.4bpp), so you should compare the bottom left picture to the top mid and right pictures.
- mrob 3y ago
  JPEG bitrates are higher, so all it means is that SSIMULACRA2 is the wrong metric for this test. It seems that SSIMULACRA2 heavily penalizes blocking artifacts but doesn't much care about blur. I agree that the JPEG versions look better at the same SSIMULACRA2 score.
aidenn0 3y ago
One does wonder how much of JXL's awesomeness is the encoder vs. the format. Its ability to make high quality, compact images just with "-d 1.0" is uncanny. With other codecs, I had to pass different quality settings depending on the image type to get similar results.
- kasabali 3y ago
  That's a very good point. At this rate of development I wouldn't be surprised if libjxl becomes x264 of image encoders. On the other hand, libvpx has always been a mediocre encoder which I think might be the reason for disappointing performance (I mean in general, not just speed) of vp8/vp9 formats, which inevitably also affected performance of lossy WebP. Dark Shikari even did a comparison of still image performances of x264 vs vp8 [0]. [0] https://web.archive.org/web/20150419071902/http://x264dev.multimedia.cx/archives/541 https://web.archive.org/web/20150419071902/http://x264dev.mu...
  - JyrkiAlakuijala 3y ago
    While WebP lossy still has image quality issues it has improved a lot over the years. One should not consider a comparison done with 2010-2015 implementations indicative of quality performance today.
    - kasabali 3y ago
      I'm sure it's better now than 13 years ago, but the conclusion I got from looking at very recent published benchmark results is that lossy webp is still only slightly better than mozjpeg at low bitrates and still has worse max. PQ ceiling compared to JPEG, which in my opinion makes it not worth using over plain old JPEG even in web settings.
      - JyrkiAlakuijala 3y ago
        That matches my observations. I believe that WebP lossy does not add value when Jpegli is an option and is having hard time to compete even with MozJPEG.
anewhnaccount2 3y ago
Should the Pareto front not be drawn with line perpendicular to the axes rather than diagonal lines?
- penteract 3y ago
  Yes, it should, but it looks like they just added a line to the jxl 0.10 series of data on whatever they used to make the graph, and labelled it the Pareto front. Looking closely at the graphs, they actually miss some points where version 0.9 should be included in the frontier.
  - lifthrasiir 3y ago
    I think it can be understood as an expected Pareto frontier if enough options are added to make it continuous, which is often implied in this kind of discussions.
    - penteract 3y ago
      I'm not sure that's reasonable - The effort parameters are integers between 1 and 10, with behavior described here: https://github.com/libjxl/libjxl/blob/main/doc/encode_effort.md https://github.com/libjxl/libjxl/blob/main/doc/encode_effort..., the intermediate options don't exist as implemented programs. This is a comparison of concrete programs, not an attempt to analyze the best theoretically achievable. Also, the frontier isn't convex, so it's unlikely that if intermediate options could be added then they would all be at least as good as the lines shown; and the use of log(speed) for the y-axis affects what a straight line on the graph means. It's fine for giving a good view of the dataset, but if you're going to make a guess about intermediate possibilities, 'speed' or 'time' should also be considered.
      - jonsneyers 3y ago
        You are right, but that would make an uglier plot :) Some of the intermediate options are available though, through various more fine-grained encoder settings than what is exposed via the overall effort setting. Of course they will not fall exactly on the line that was drawn, but as a first approximation, the line is probably closer to the truth than the staircase, which would be an underestimate of what can be done.
kasabali 3y ago
I'm surprised mozjpeg performed worse than libjpeg-turbo at high quality settings. I thought its aim was having better pq than libjpeg-turbo at the expense of speed.
- JyrkiAlakuijala 3y ago
  It is consistent to what I have seen. Both in metrics and in eyeballing. Mozjpeg gives good results around quality 75, but less good at 90+++
AceJohnny2 3y ago
I do not understand why this article focuses so much on encode speed, but for decode, which I believe represents 99% of usage in this web-connected world, give a cursory... > Decode speed is not really a significant problem on modern computers, but it is interesting to take a quick look at the numbers.
- lifthrasiir 3y ago
  Anything more than 100 MB/s is considered "enough" for the internet because at that point your bottleneck is no longer decoding. Most modern compression algorithms are asymmetric, that is, you can spend much more time on compression without significantly affecting the decompression performance, so it is indeed less significant once the base performance is achieved.
  - oynqr 3y ago
    When you actually want good latency, using the throughput as a metric is a bit misguided.
    - lifthrasiir 3y ago
      As others pointed out, that's why JPEG XL's excellent support for progressive decoding is important. Other formats do not support progressive decoding at all or made it optional, so it cannot be even compared at this point. In the other words, the table can be regarded as an evidence that you can have both progressive decoding and performance at once.
    - lonjil 3y ago
      If you don't have progressive decoding, those metrics are essentially the same.
    - mort96 3y ago
      There is no "throughput vs latency" here, there is no "start-up time" for decoding an image that's already in RAM. If a decoder decodes at 100MiB/s, and a picture is 10MiB, it's decoded in 0.1 seconds. If the decoder decodes at 1 MiB/s, the same picture is decoded in 10 seconds.
mips_r4300i 3y ago
This is really impressive even compared to WebP. And unlike WebP, it's backwards compatible. I have forever associated Webp with macroblocky, poor colors, and a general ungraceful degradation that doesn't really happen the same way even with old JPEG. I am gonna go look at the complexity of the JXL decoder vs WebP. Curious if it's even practical to decode on embedded. JPEG is easily decodable, and you can do it in small pieces at a time to work within memory constraints.
- bombcar 3y ago
  Everyone hates WebP because when you save it, nothing can open it. That's improved somewhat, but the formats that will have an easy time winning are the ones that people can use, even if that means a browser should "save JPGXL as JPEG" for awhile or something.
  - ComputerGuru 3y ago
    Everyone hates webp for a different reason. I hate it because it can only do 4:2:0 chroma, except in lossless mode. Lossless WebP is better than PNG, but I will take the peace of mind of knowing PNG is always lossless over having a WebP and not knowing what was done to it.
    - 149765 3y ago
      > peace of mind of knowing PNG is always lossless There is pngquant: > a command-line utility and a library for lossy compression of PNG images.
      - bombcar 3y ago
        You also have things like https://tinypng.com https://tinypng.com which do (basically) lossy PNG for you. Works pretty well.
        ComputerGuru 3y ago
throwaway81523 3y ago
Does JPEG XL have patent issues? I half remember something about that. Regular JPG seems fine to me. Better compression isn't going to help anyone since they will find other ways to waste any bandwidth available.
- lifthrasiir 3y ago
  The main innovation claimed by Microsoft's rANS patent is about the adaptive probability distribution, that is, you should be able to efficiently correct the distribution so that you can use less bits. While that alone is an absurd claim (that's a benefit shared with arithmetic coding and its variants!) and there is a very clear prior art, JPEG XL doesn't dynamically vary the distribution so is thought to be not related to the patent anyway.
- jonsneyers 3y ago
  No it doesn't. And yes, regular JPEG is still a fine format. That's part of the point of the article. But for many use cases, better compression is always welcome. Also having features like alpha transparency, lossless, HDR etc can be quite desirable, and those things are not really possible in JPEG.
taylorius 3y ago
The article mentions encoding speed as something to consider, alongside compression ratio. I would argue that decoding speed is also important. A lot of the more modern formats (webp, avif etc) can take significantly more CPU cycles to decode than a plain old jpg. This can slow things down noticeably,especially on mobile.
- oynqr 3y ago
  JPEG and JXL have the benefit of (optional) progressive decoding, so even if the image is a little larger than AVIF, you may still see content faster.
  - lifthrasiir 3y ago
    Note that JPEG XL always supports progressive decoding, because the top-level format is structured in that way. The optional part is a finer-grained adjustment to make the output more suitable for specific cases.
  - izacus 3y ago
    That's great, are there any comparison graphs and benchmarks showing that in real life (similarly to this article)?
    - 149765 3y ago
      A couple of videos comparing progressive decoding of jpeg, jxl and avif: https://www.youtube.com/watch?v=UphN1_7nP8U https://www.youtube.com/watch?v=UphN1_7nP8U https://www.youtube.com/watch?v=inQxEBn831w https://www.youtube.com/watch?v=inQxEBn831w There's more on the same channel, generation loss ones are really interesting.
      - izacus 3y ago
        Awesome, thanks.
    - JyrkiAlakuijala 3y ago
bmacho 3y ago
How is lossless webp 0.6th of the size of lossless avif? I find it hard to believe that.
- 149765 3y ago
  Lossless webp is actually quite good, especially on text heavy images, e.g. screenshots of a terminal with `cwebp -z9` are usually smaller than `jxl -d 0 -e 9` in my experience.
- lonjil 3y ago
  Lossless AVIF is just really quite bad. Notice that how for photographic content, it is barely better than PNG, and for non-photographic content, it is far worse than PNG.
  - edflsafoiewq 3y ago
    It's so bad you wonder why AV1 even has a lossless mode. Maybe lossy mode has some subimages it uses lossless mode on?
    - jonsneyers 3y ago
      It has lossless just to check a box in terms of supported features. A bit like how JPEG XL supports animation just to have feature parity. But in most cases, you'll be better off using a video codec for animation, and an image format for images.
      - samatman 3y ago
        There are some user-level differences between an animated image and a video, which haven't really been satisfactorily resolved since the abandonment of GIF-the-format. An animated image should pause when clicked, and start again on another click, with setting separate from video autoplay to control the default. It should not have visible controls of any sort, that's the whole interface. It should save and display on the computer/filesystem as an image, and degrade to the display frame when sent along a channel which supports images but not animated ones. It doesn't need sound, or CC, or subtitles. I should be able to add it to the photo roll on my phone if I want. There are a lot of little considerations like this, and it would be well if the industry consolidated around an animated-image standard, one which was an image, and not a video embedded in a way which looks like an image.
a-french-anon 3y ago
Pretty good article, though I would have used oxipng instead of optipng in the lossless comparisons, it's the new standard, there.
- jonsneyers 3y ago
  Thanks for the suggestion, oxipng is indeed a better choice. Next time I will add it to the plots!
gaazoh 3y ago
The inclusion of QOI in the lossless benchmarks made me smile. It's a basically irrelevant format, that isn't supported by default by any general-public software, that aims to be just OK, not even good, yet it has a spot on one of these charts (non-photographic encoding). Neat.
- lifthrasiir 3y ago
  And yet didn't reach the Pareto frontier! It's quite obvious in hindsight though---QOI decoding is inherently sequential and can't be easily parallelized.
  - gaazoh 3y ago
    Of course it didn't, it wasn't designed to be either the fastest nor the best. Just OK and simple. Yet in some cases it's not completely overtaken by competition, and I think that's cool. I don't believe QOI will ever have any sort of real-world practical use, but that's quite OK and I love it for it has made me and plenty of others look into binary file formats and compression and demystify it, and look further into it. I wrote a fully functional streaming codec for QOI, and it has taught me many things, and started me on other projects, either working with more complex file formats or thinking about how to improve upon QOI. I would probably never have gotten to this point if I tried the same thing starting with any other format, as they are at least an order of magnitude more complex, even for the simple ones.
    - lonjil 3y ago
      > Of course it didn't, it wasn't designed to be either the fastest nor the best. Just OK and simple. Yet in some cases it's not completely overtaken by competition, and I think that's cool. Actually, there was a big push to add QOI to stuff a few years ago, specifically due to it being "fast". It was claimed that while it has worse compression, the speed can make it a worthy trade off.
    - p0nce 3y ago
      It can be interesting if you need fast decode on low complexity, and it's an easy to improve format (-20 to -30%). Base QOI isn't that great.
btdmaster 3y ago
Missing from the article is rav1e, which encodes AV1, and hence AVIF, a lot faster than the reference implementation aom. I've had cases where aom would not finish converting an image in a minute of waiting what rav1e would do in less than 10 seconds.
- JyrkiAlakuijala 3y ago
  Is rav1e pareto-curve ahead of libaom pareto-curve? Does fast rav1e look better than jpegli at high encode speeds?
  - btdmaster 3y ago
    Difficult to know without reproduction steps from the article, but I would think it behaves better than libaom for the same quality setting. Edit: found https://github.com/xiph/rav1e/issues/2759 https://github.com/xiph/rav1e/issues/2759
    - JyrkiAlakuijala 3y ago
      If Rav1e found better ways of encoding, why would the aom folks copy it in libaom?
  - pornel 3y ago
    rav1e is generally head to head with libaom on static images, and which one wins on the speed/quality/size frontier depends a lot on the image and settings, as much as +/- 20%. I suspect rav1e has an inefficient block size selection algorithm, so the particular shape of blocks is a make or break for it. I’ve only compared rav1e to mozjpeg and libwebp, and at fastest speeds it’s only barely ahead.
- jonsneyers 3y ago
  Both rav1e and libaom have a speed setting. At similar speeds, I have not observed huge differences in compression performance between the two.
jug 3y ago
Pay attention to just how good WebP is at _lossless_ comparison though! I've always thought that one as flying under the radar. Most get stuck on WebP not offering tangible enough benefits (or even worse) over MozJPEG encoding, but WebP _lossless_ is absolutely fantastic for performance/speed! PNG or even OptiPNG is far worse. And very well supported online now, and leaving the horrible lossless AVIF in the dust too of course.
- jonsneyers 3y ago
  Lossless WebP is very good indeed. The main problem is that it is not very future-proof since it only supports 8-bit. For SDR images that's fine, but for HDR this is a fundamental limitation that is about as bad as GIF's limitation to 256 colors.
  - jug 3y ago
    Ah, I didn't know this and I agree this is a fairly big issue and increasingly so over time. I think smartphones in particular hastened the demand for HDR quite a bit, what was once a premium/enthusiast feature you only had to explicitly buy into.
    - fluidcruft 3y ago
      HDR is also important for medical imaging applications (which have been moving to web)
  - omoikane 3y ago
    I haven't ran across websites that serves up HDR images, I am not sure I would notice the difference. WebP seems appropriately named and optimized for image delivery on the web. Maybe you are thinking of high bit depth for archival use? I can see some use cases there where 8-bit is not sufficient, though personally I store high bit depth images in whatever raw format was produced by my camera (which is usually some variant of TIFF).
    - lonjil 3y ago
jug 3y ago
Wow, that new jpegli encoder. Just wow. Look at those results. Haha, JPEG has many years left still.
- kasabali 3y ago
  > JPEG has many years left still Such a shame arithmetic coding (which is already in the standard) isn't widely supported in the real world. Because converting Huffman coded images losslessly to arithmetic coding provides an easy 5-10% size advantage in my tests. Alien technology from the future indeed.
  - mort96 3y ago
    The benefits of JPEG kind of go away if you start adopting more recent changes to the format, no? JPEG is nice because everything has supported it for 20+ years. JPEG-with-arithmetic-coding is essentially a new, incompatible format, why not use JXL or AVIF instead?
    - gruturo 3y ago
      Yes, but this is really a pity in the specific case of Arithmetic Coding, because, unlike "more recent changes to the format", it's been in the standard since the very beginning - but is not supported by a lot of implementations due to software patents (which meanwhile expired, but their damage remains).
      - adgjlsfhk1 3y ago
        arithmetic encoding is old, but around 2010 (when all the patents expired), there was a ton of really good research on how to to table based ans and vectorized rans to make the performance good. Aside from the patent issues Arithmetic encoding wasn't pursued much because the CPU cost was too high. Now that multiply is cheap and the divisions can be avoided, ANS is a lot better than it used to be.
        3y ago
dancemethis 3y ago
"Pareto" being used outside the context of Brazil's best prank call ever (Telerj Prank) will always confuse me. I keep thinking, "what does the 'thin-voiced lawyer' have to do with statistics?"...
MikeCapone 3y ago
I really hope this can become a new standard and be available everywhere (image tools, browsers, etc). While in practice it won't change my life much, I like the elegance of using a modern standard with this level of performance an efficiency.
TacticalCoder 3y ago
Without taking into account whether JPEG XL shines on its own or not (which it may or may not), JPEG XL completely rocks for sure because it does this: .. $ ls -l a.jpg && shasum a.jpg ... 615504 ... a.jpg 716744d950ecf9e5757c565041143775a810e10f a.jpg .. $ cjxl a.jpg a.jxl Read JPEG image with 615504 bytes. Compressed to 537339 bytes including container .. $ ls -l a.jxl ... 537339 ... a.jxl But, wait for it: .. $ djxl a.jxl b.jpg Read 537339 compressed bytes. Reconstructed to JPEG. .. $ ls -l b.jpg && shasum b.jpg ... 615504 ... b.jpg 716744d950ecf9e5757c565041143775a810e10f b.jpg Do you realize how many billions of JPEG files there are out there which people want to keep? If you recompress your old JPEG files using a lossy format, you lower its quality. But with JPEG XL, you can save 15% to 30% and still, if you want, get your original JPG 100% identical, bit for bit. That's wonderful. P.S: I'm sadly on Debian stable (12 / Bookworm) which is on ImageMagick 6.9 and my Emacs uses (AFAIK) ImageMagick to display pictures. And JPEG XL support was only added in ImageMagick 7. I haven't looked more into that yet.
- izacus 3y ago
  I'm sure that will be hugely cherished by users which take screenshots of JPEGs so they can resend them on WhatsApp :P
  - F3nd0 3y ago
    This particular feature might not, but if said screenshots are often compressed with JPEG XL, they will be spared the generation loss that becomes blatantly visible in some other formats: https://invidious.protokolla.fi/watch?v=w7UDJUCMTng https://invidious.protokolla.fi/watch?v=w7UDJUCMTng
    - IshKebab 3y ago
      Maybe. But to know for sure you need to offset the image and change encoder settings.
- JyrkiAlakuijala 3y ago
  I managed to add that requirement to jpeg xl. I think it will be helpful to preserve our digital legacy intact without lossy re-encodings.
kodabbb 3y ago
Looks like there are more savings coming on lossless AVIF: https://www.reddit.com/r/AV1/comments/1b3lh08/comment/kstmbru/ https://www.reddit.com/r/AV1/comments/1b3lh08/comment/kstmbr...
- JyrkiAlakuijala 3y ago
  I plan to add 15–25 % more quality in the ugly lowest end quality in JPEG XL in the coming two months.
JyrkiAlakuijala 3y ago
It is worth noting that the JPEG XL effort produced a nice new parallelism library called Highway. This library is powering not only JPEG XL but also Google's latest Gemma AI models.
- jhalstead 3y ago
  [0] for those interested in Highway. It's also mentioned in [1], which starts off > Today we're sharing open source code that can sort arrays of numbers about ten times as fast as the C++ std::sort, and outperforms state of the art architecture-specific algorithms, while being portable across all modern CPU architectures. Below we discuss how we achieved this. [0] https://github.com/google/highway https://github.com/google/highway [1] https://opensource.googleblog.com/2022/06/Vectorized%20and%20performance%20portable%20Quicksort.html https://opensource.googleblog.com/2022/06/Vectorized%20and%2..., which has an associated paper at https://arxiv.org/pdf/2205.05982.pdf https://arxiv.org/pdf/2205.05982.pdf.
  - janwas 3y ago
    :) Thanks for the mention. Highway/vqsort TL here, happy to discuss. PS: I used to work on JPEG XL. It is great to see these outstanding improvements, congrats to the team!
- a-french-anon 3y ago
  And VIPS! It seems like the best way to get portable SIMD in C++, to me.
sandstrom 3y ago
JPEG XL is awesome! One thing I think would help with its adoption, is if they would work with e.g. the libvips team to better implement it. For example, streaming encoder and streaming decoder would be the preferred integration method in libvips.
ImageXav 3y ago
Maybe someone here will know of a website that describes each step of the jpeg xl format in detail? Unlike for traditional jpeg, I have found it hard to find a document providing clear instructions on the relevant steps, which is a shame as there are clearly tons of interesting innovations that have been compiled together to make this happen, and I'm sure the individual components are useful in their own right!
- adgjlsfhk1 3y ago
  https://github.com/libjxl/libjxl/blob/main/doc/format_overview.md https://github.com/libjxl/libjxl/blob/main/doc/format_overvi... is a pretty detailed but good overview. The highlights are variable size DCT (up to 128x128), ANS entropy prediction, and chroma from luminance prediction. https://github.com/libjxl/libjxl/blob/main/doc/encode_effort.md https://github.com/libjxl/libjxl/blob/main/doc/encode_effort... also gives a good breakdown of features by effort level.
  - ImageXav 3y ago
    Thank you for sharing. This gives me a good idea of where to start looking.
jeffbee 3y ago
The choice to represent the speed based on multithreaded encoding strikes me as somewhat arbitrary. If your software has a critical path dependent on minimal latency of a single image, then it makes some sense, but you still may have more or fewer than 8 cores. On the other hand if you have another source of parallelism, for example you are encoding a library of images, then it is quite irrelevant. I think the fine data in the article would be even more useful if the single threaded speed and the scalability of the codec were treated separately.
redder23 3y ago
AVIF looks better here: JPEG XL looks very blurred out on the bottom with high compression. AVIF preserves much more detail and sharpness. https://res.cloudinary.com/jon/qp-low.png https://res.cloudinary.com/jon/qp-low.png
jiggawatts 3y ago
The problem with JPEG XL is that it is written in an unsafe language and has already had several memory safety vulnerabilities found in it. Image codecs are used in a wide range of attacker-controlled scenarios and need to be completely safe. I know Rust advocates sound like a broken record, but this is the poster child for a library that should never have been even started in C++ in the first place. It’s absolute insanity that we write codecs — pure functions — in an unsafe language that has a compiler that defaults to “anything goes” as an optimisation technique.
- lonjil 3y ago
  Pretty much every codec in every browser is written in an unsafe language, unfortunately. I don't see why JXL should be singled out. On the other hand, there is a JXL decoder in Rust called jxl-oxide [1] which works quite well, and has been confirmed by JPEG as conformant. Hopefully it will be adopted for decode-only usecases. [1] https://github.com/tirr-c/jxl-oxide/pull/267 https://github.com/tirr-c/jxl-oxide/pull/267 > It’s absolute insanity that we write codecs — pure functions — in an unsafe language that has a compiler that defaults to “anything goes” as an optimisation technique. Rust and C++ are exactly the same in how they optimize, compilers for both assume that your code has zero UB. The difference is that Rust makes it much harder to accidentally have UB.
  - jiggawatts 3y ago
    "We've never had to wear helmets before, why start now?" There are only a handful of image codecs that are widely accepted. Essentially just GIF, PNG, and JPG. There's a smattering of support for more modern formats, but those three dominate. Adding a fourth image format is increasing this attack surface by a substantial margin across a huge range of software. Not just web browsers, but chat apps, server software (thumbnail generators), editors, etc... This is the kind of thing that gets baked into standard libraries, operating systems, and frameworks. It's up there with JSON or XML. You had better be damned sure what you're doing is not going to cause a long list of CVEs! JPEG XL is a complex codec, with a lot of code. This increases the chance of bugs and increases the attack surface. A (surprisingly!) good metric for complexity is the size of the zip file of the code. Libjpeg is something like 360 kB, libpng is 350 kB, and giflib is 90 kB. The JXL source is 1.4 MB zipped, making more than twice the size of the above three combined! The other libraries use C/C++ not because that's a better choice, but because it was the only choice back in the ... checks Wikipedia ... 1980s and 90s! We live in the future. We have memory-safe languages now. We're allowed to use them. You won't get in trouble from anyone, I promise.
jshier 3y ago
I have an existing workflow where I take JPEGs (giant PNGs) from designers and reencode them using mozjpeg. However, I can't find a way to invoke jpegli tool in the same way, especially since it seems to just be part of the jpeg-xl tool? Is that right? Are there any sample invocations anywhere?
- chungy 3y ago
  You should be able to use the `cjpegli` command the same way you'd use cjxl. The simplest invocation would be `cjpegli input.png output.jpg`
  - JyrkiAlakuijala 3y ago
    Or replace/ldconfig the jpeg library with the jpegli library. It is API/ABI compatible with libjpeg-turbo and mozjpeg.
  - jshier 3y ago
    Thanks. It seems the macOS release is a bit behind on brew (0.9.1) and doesn't include the cjpegli tool yet.
deleted 3y ago
[deleted]
ksec 3y ago
It is nice 0.10 finally landed those memory and speed optimisation. But the King remains HALIC. In terms of MT encoder it still uses 3.5x more memory than HALIC, and 6x encoding time compared to HALIC. While offering the same or smaller files size in Lossless. Hopefully JPEG XL could narrow those gaps some days.

497 points by botanical 3y ago

Welcome efficiency improvements And in general, Jon's posts provide a pretty good overview on the topic of codec comparison Pity such a great format is being held back by the much less rigorous reviews

mikae1 3y ago

If only Google could be convinced to adopt this marvelous codec... Not looking super positive at the moment: https://issues.chromium.org/issues/40270698 https://issues.chromium.org/issues/40270698 https://bugs.chromium.org/p/chromium/issues/detail?id=1451807&no_tracker_redirect=1 https://bugs.chromium.org/p/chromium/issues/detail?id=145180...

pgeorgi 3y ago
All those requests to revert the removal are funny: you want Chrome to re-add jxl behind a feature flag? Doesn't seem very useful. Also, all those Chrome offshoots (Edge, Brave, Opera, etc) could easily add and enable it to distinguish themselves from Chrome ("faster page load", "less network use") and don't. Makes me wonder what's going on...
- silisili 3y ago
  Simply put these offshoots don't really seem to do browser code, and realize how expensive it would be for them to diverge at the core.
- eviks 3y ago
  No, obviously to re-add jxl without a flag
  - pgeorgi 3y ago
    "jxl without a flag" can't be re-added because that was never a thing.
    - albert180 3y ago
      [flagged]
    - deleted 3y ago
      [deleted]
    - elygre 3y ago
      Or (re-add jxl) (without a flag).
    - eviks 3y ago
      It can, that's why you didn't say "re-add jxl", but had to mention the flag, 're-add' has no flag implication, that pedantic attempt to constraint is somehing you've made up, that's not what people want, just read those linked issues
      - pgeorgi 3y ago
        It has a flag implication because jpeg-xl never came without being hidden behind a flag. Nothing was taken away from ordinary users at any point in time. And I suppose the Chrome folks have the telemetry to know how many people set that damn flag.
        jdiff 3y ago
        >"But the plans were on display…” > “On display? I eventually had to go down to the cellar to find them.” > “That’s the display department.” > “With a flashlight.” > “Ah, well, the lights had probably gone.” > “So had the stairs.” > “But look, you found the notice, didn’t you?” > “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.’”
        3y ago
- lonjil 3y ago
  > you want Chrome to re-add jxl behind a feature flag? Doesn't seem very useful. Chrome has a neat feature where some flags can be enabled by websites, so that websites can choose to cooperate in testing. They never did this for JXL, but if they re-added JXL behind a flag, they could do so but with such testing enabled. Then they could get real data from websites actually using it, without committing to supporting it if it isn't useful. > Also, all those Chrome offshoots (Edge, Brave, Opera, etc) could easily add and enable it to distinguish themselves from Chrome ("faster page load", "less network use") and don't. Makes me wonder what's going on... Edge doesn't use Chrome's own codec support. It uses Windows's media framework. JXL is being added to it next year.
  - firsching 3y ago
    > Edge doesn't use Chrome's own codec support. It uses Windows's media framework. JXL is being added to it next year. Interesting!
- deleted 3y ago
  [deleted]
sergioisidoro 3y ago
It's so frustrating how the chromium team is ending up as a gatekeeper of the Internet by pick and choosing what gets developed or not. I recently come across another issue pertaining to the chromium team not budging on their decisions, despite pressure from the community and an RFC backing it up - in my case custom headers in WebSocket handshakes, that are supported by other Javascript runtimes like node and bun, but the chromium maintainer just disagrees with it - https://github.com/whatwg/websockets/issues/16#issuecomment-1961031987 https://github.com/whatwg/websockets/issues/16#issuecomment-...
- hwbunny 3y ago
  Question is for how long. Time to slam the hammer on them.
  - hhh 3y ago
    Why not make a better product than slam some metaphorical hammer?
    - mort96 3y ago
      That's not how this works. Firefox is the closest we have, and realistically the closest we will get to a "better product" than Chromium for the foreseeable future, and it's clearly not enough.
      - KingOfCoders 3y ago
        And Firefox does not support the format. Mozilla is the same political company as everyone else.
      - bombcar 3y ago
        The only hammer at all left is Safari, basically on iPhones only. That hammer is very close to going away; if the EU does force Apple to really open the browsers on the iPhone, everything will be Chrome as far as the eye can see in short order. And then we fully enter the chromE6 phase.
jillesvangurp 3y ago
They didn't "lose interest", their lawyers pulled the emergency brakes. Blame patent holders, not Google. Like Microsoft: https://www.theregister.com/2022/02/17/microsoft_ans_patent/ https://www.theregister.com/2022/02/17/microsoft_ans_patent/. Microsoft could probably be convinced to be reasonable. But there may be a few others. Google actually also holds some patents over this but they've done the right thing and license those patents along with their implementation. To fix this, you'd need to convince Google, and other large companies that would be exposed to law suits related to these patents (Apple, Adobe, etc.), that these patent holders are not going to insist on being compensated. Other formats are less risky; especially the older ones. Jpeg is fine because it's been out there for so long that any patents applicable to it have long expired. Same with GIF, which once was held up by patents. Png is at this point also fine. If any patents applied at all they will soon have expired as the PNG standard dates back to 1997 and work on it depended on research from the seventies and eighties.
- lifthrasiir 3y ago
  > [...] other large companies that would be exposed to law suits related to these patents (Apple, Adobe, etc.) [...] Adobe included JPEG XL support to their products and also the DNG specification. So that argument is pretty much dead, no?
  - jillesvangurp 3y ago
    Not that simple. Maybe they struck a deal with a few of the companies or they made a different risk calculation. And of course they have a pretty fierce patent portfolio themselves so there's the notion of them being able to retaliate in kind to some of these companies.
    - lifthrasiir 3y ago
      I don't think that's true (see my other comment for what the patent is really about), but even when it is, Adobe's adoption means that JPEG XL is worth the supposed "risk". And Google does ship a lot of technologies that are clearly patent-encumbered. If the patent is the main concern, they could have answered so because there are enough people wondering about the patent status, but the Chrome team's main reason against JPEG XL was quite different.
Pikamander2 3y ago
Mozilla effectively gave up on it before Google did. https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 It's a real shame, because this is one of those few areas where Firefox could have lead the charge instead of following in Chrome's footsteps. I remember when they first added APNG support and it took Chrome years to catch up, but I guess those days are gone. Oddly enough, Safari is the only major browser that currently supports it despite regularly falling behind on tons of other cutting-edge web standards. https://caniuse.com/jpegxl https://caniuse.com/jpegxl
- JyrkiAlakuijala 3y ago
  I followed Mozilla/Firefox integration closely. I was able to observe enthusiasm from their junior to staff level engineers (linkedin-assisted analysis of the related bugs ;-). However, an engineering director stepped in and locked the discussions because they were in "no new information" stage, and their position has been neutral on JPEG XL, and the integration has not progressed from the nightly builds to the next stage. Ten years ago Mozilla used to have the most prominent image and video compression effort called Daala. They posted inspiring blog posts about their experiments. Some of their work was integrated with Cisco's Thor and On2's/Chrome's VP8/9/10, leading to AV1 and AVIF. Today, I believe, Mozilla has focused away from this research and the ex-Daala researchers have found new roles.
  - lonjil 3y ago
    Daala's and Thor's features were supposed to be integrated into AV1, but in the end, they wanted to finish AV1 as fast as possible, so very little that wasn't in VP10 made it into AV1. I guess it will be in AV2, though.
    - JyrkiAlakuijala 3y ago
      I like to think that there might be an easy way to improve AV2 today — drop the whole keyframe coding and replace it with JPEG XL images as keyframes.
    - 3y ago
deleted 3y ago
[deleted]

Zamicol 3y ago

> The new version of libjxl brings a very substantial reduction in memory consumption, by an order of magnitude, for both lossy and lossless compression. Also the speed is improved, especially for multi-threaded lossless encoding where the default effort setting is now an order of magnitude faster. Very impressive! The article too is well written. Great work all around.

deleted 3y ago
[deleted]

Modified3019 3y ago

At the very low quality settings, it's kinda remarkable how jpeg manages to to keep a sharper approximation of detail that preserves the holistic quality of the image better in spite of the obvious artifacts making it look like a mess of cubism when examined close. It's basically converting the image into some kind of abstract art style. Whereas jxl and avif just become blurry.

porker 3y ago
Yes, that was my takeaway from this that JPEG keeps edge sharpness really well (e.g. the eyelashes) while the jxl and avif smooth all detail out of the image.
- mort96 3y ago
  No, JXL and AVIF keep keep the same level of edge sharpness but without all the blocking artifacts when given the same amount of bits per pixel as the lowest-quality jpeg.
JyrkiAlakuijala 3y ago
It is because JPEG is given 0.5 bits per pixel, where JPEG XL and AVIF are given around 0.22 and 0.2. These images attempt to be at equal level of distortion, not at equal compression. Bpps are reported beside the images. In practice, use of quality 65 is rare in the internet and only used at the lowest quality tier sites. Quality 75 seems to be usual poor quality and quality 85 the average. I use quality 94 yuv444 or better when I need to compress.
bmacho 3y ago
You refer to this? https://res.cloudinary.com/jon/qp-low.png https://res.cloudinary.com/jon/qp-low.png Bitrates are in the left column, jpg low quality is the same size as jxl/avif med-low quality (0.4bpp), so you should compare the bottom left picture to the top mid and right pictures.
mrob 3y ago
JPEG bitrates are higher, so all it means is that SSIMULACRA2 is the wrong metric for this test. It seems that SSIMULACRA2 heavily penalizes blocking artifacts but doesn't much care about blur. I agree that the JPEG versions look better at the same SSIMULACRA2 score.

aidenn0 3y ago

One does wonder how much of JXL's awesomeness is the encoder vs. the format. Its ability to make high quality, compact images just with "-d 1.0" is uncanny. With other codecs, I had to pass different quality settings depending on the image type to get similar results.

kasabali 3y ago
That's a very good point. At this rate of development I wouldn't be surprised if libjxl becomes x264 of image encoders. On the other hand, libvpx has always been a mediocre encoder which I think might be the reason for disappointing performance (I mean in general, not just speed) of vp8/vp9 formats, which inevitably also affected performance of lossy WebP. Dark Shikari even did a comparison of still image performances of x264 vs vp8 [0]. [0] https://web.archive.org/web/20150419071902/http://x264dev.multimedia.cx/archives/541 https://web.archive.org/web/20150419071902/http://x264dev.mu...
- JyrkiAlakuijala 3y ago
  While WebP lossy still has image quality issues it has improved a lot over the years. One should not consider a comparison done with 2010-2015 implementations indicative of quality performance today.
  - kasabali 3y ago
    I'm sure it's better now than 13 years ago, but the conclusion I got from looking at very recent published benchmark results is that lossy webp is still only slightly better than mozjpeg at low bitrates and still has worse max. PQ ceiling compared to JPEG, which in my opinion makes it not worth using over plain old JPEG even in web settings.
    - JyrkiAlakuijala 3y ago
      That matches my observations. I believe that WebP lossy does not add value when Jpegli is an option and is having hard time to compete even with MozJPEG.

anewhnaccount2 3y ago

Should the Pareto front not be drawn with line perpendicular to the axes rather than diagonal lines?

penteract 3y ago
Yes, it should, but it looks like they just added a line to the jxl 0.10 series of data on whatever they used to make the graph, and labelled it the Pareto front. Looking closely at the graphs, they actually miss some points where version 0.9 should be included in the frontier.
- lifthrasiir 3y ago
  I think it can be understood as an expected Pareto frontier if enough options are added to make it continuous, which is often implied in this kind of discussions.
  - penteract 3y ago
    I'm not sure that's reasonable - The effort parameters are integers between 1 and 10, with behavior described here: https://github.com/libjxl/libjxl/blob/main/doc/encode_effort.md https://github.com/libjxl/libjxl/blob/main/doc/encode_effort..., the intermediate options don't exist as implemented programs. This is a comparison of concrete programs, not an attempt to analyze the best theoretically achievable. Also, the frontier isn't convex, so it's unlikely that if intermediate options could be added then they would all be at least as good as the lines shown; and the use of log(speed) for the y-axis affects what a straight line on the graph means. It's fine for giving a good view of the dataset, but if you're going to make a guess about intermediate possibilities, 'speed' or 'time' should also be considered.
    - jonsneyers 3y ago
      You are right, but that would make an uglier plot :) Some of the intermediate options are available though, through various more fine-grained encoder settings than what is exposed via the overall effort setting. Of course they will not fall exactly on the line that was drawn, but as a first approximation, the line is probably closer to the truth than the staircase, which would be an underestimate of what can be done.

kasabali 3y ago

I'm surprised mozjpeg performed worse than libjpeg-turbo at high quality settings. I thought its aim was having better pq than libjpeg-turbo at the expense of speed.

JyrkiAlakuijala 3y ago
It is consistent to what I have seen. Both in metrics and in eyeballing. Mozjpeg gives good results around quality 75, but less good at 90+++

AceJohnny2 3y ago

I do not understand why this article focuses so much on encode speed, but for decode, which I believe represents 99% of usage in this web-connected world, give a cursory... > Decode speed is not really a significant problem on modern computers, but it is interesting to take a quick look at the numbers.

lifthrasiir 3y ago
Anything more than 100 MB/s is considered "enough" for the internet because at that point your bottleneck is no longer decoding. Most modern compression algorithms are asymmetric, that is, you can spend much more time on compression without significantly affecting the decompression performance, so it is indeed less significant once the base performance is achieved.
- oynqr 3y ago
  When you actually want good latency, using the throughput as a metric is a bit misguided.
  - lifthrasiir 3y ago
    As others pointed out, that's why JPEG XL's excellent support for progressive decoding is important. Other formats do not support progressive decoding at all or made it optional, so it cannot be even compared at this point. In the other words, the table can be regarded as an evidence that you can have both progressive decoding and performance at once.
  - lonjil 3y ago
    If you don't have progressive decoding, those metrics are essentially the same.
  - mort96 3y ago
    There is no "throughput vs latency" here, there is no "start-up time" for decoding an image that's already in RAM. If a decoder decodes at 100MiB/s, and a picture is 10MiB, it's decoded in 0.1 seconds. If the decoder decodes at 1 MiB/s, the same picture is decoded in 10 seconds.

mips_r4300i 3y ago

This is really impressive even compared to WebP. And unlike WebP, it's backwards compatible. I have forever associated Webp with macroblocky, poor colors, and a general ungraceful degradation that doesn't really happen the same way even with old JPEG. I am gonna go look at the complexity of the JXL decoder vs WebP. Curious if it's even practical to decode on embedded. JPEG is easily decodable, and you can do it in small pieces at a time to work within memory constraints.

bombcar 3y ago
Everyone hates WebP because when you save it, nothing can open it. That's improved somewhat, but the formats that will have an easy time winning are the ones that people can use, even if that means a browser should "save JPGXL as JPEG" for awhile or something.
- ComputerGuru 3y ago
  Everyone hates webp for a different reason. I hate it because it can only do 4:2:0 chroma, except in lossless mode. Lossless WebP is better than PNG, but I will take the peace of mind of knowing PNG is always lossless over having a WebP and not knowing what was done to it.
  - 149765 3y ago
    > peace of mind of knowing PNG is always lossless There is pngquant: > a command-line utility and a library for lossy compression of PNG images.
    - bombcar 3y ago
      You also have things like https://tinypng.com https://tinypng.com which do (basically) lossy PNG for you. Works pretty well.
      - ComputerGuru 3y ago

throwaway81523 3y ago

Does JPEG XL have patent issues? I half remember something about that. Regular JPG seems fine to me. Better compression isn't going to help anyone since they will find other ways to waste any bandwidth available.

lifthrasiir 3y ago
The main innovation claimed by Microsoft's rANS patent is about the adaptive probability distribution, that is, you should be able to efficiently correct the distribution so that you can use less bits. While that alone is an absurd claim (that's a benefit shared with arithmetic coding and its variants!) and there is a very clear prior art, JPEG XL doesn't dynamically vary the distribution so is thought to be not related to the patent anyway.
jonsneyers 3y ago
No it doesn't. And yes, regular JPEG is still a fine format. That's part of the point of the article. But for many use cases, better compression is always welcome. Also having features like alpha transparency, lossless, HDR etc can be quite desirable, and those things are not really possible in JPEG.

taylorius 3y ago

The article mentions encoding speed as something to consider, alongside compression ratio. I would argue that decoding speed is also important. A lot of the more modern formats (webp, avif etc) can take significantly more CPU cycles to decode than a plain old jpg. This can slow things down noticeably,especially on mobile.

oynqr 3y ago
JPEG and JXL have the benefit of (optional) progressive decoding, so even if the image is a little larger than AVIF, you may still see content faster.
- lifthrasiir 3y ago
  Note that JPEG XL always supports progressive decoding, because the top-level format is structured in that way. The optional part is a finer-grained adjustment to make the output more suitable for specific cases.
- izacus 3y ago
  That's great, are there any comparison graphs and benchmarks showing that in real life (similarly to this article)?
  - 149765 3y ago
    A couple of videos comparing progressive decoding of jpeg, jxl and avif: https://www.youtube.com/watch?v=UphN1_7nP8U https://www.youtube.com/watch?v=UphN1_7nP8U https://www.youtube.com/watch?v=inQxEBn831w https://www.youtube.com/watch?v=inQxEBn831w There's more on the same channel, generation loss ones are really interesting.
    - izacus 3y ago
      Awesome, thanks.
  - JyrkiAlakuijala 3y ago

bmacho 3y ago

How is lossless webp 0.6th of the size of lossless avif? I find it hard to believe that.

149765 3y ago
Lossless webp is actually quite good, especially on text heavy images, e.g. screenshots of a terminal with `cwebp -z9` are usually smaller than `jxl -d 0 -e 9` in my experience.
lonjil 3y ago
Lossless AVIF is just really quite bad. Notice that how for photographic content, it is barely better than PNG, and for non-photographic content, it is far worse than PNG.
- edflsafoiewq 3y ago
  It's so bad you wonder why AV1 even has a lossless mode. Maybe lossy mode has some subimages it uses lossless mode on?
  - jonsneyers 3y ago
    It has lossless just to check a box in terms of supported features. A bit like how JPEG XL supports animation just to have feature parity. But in most cases, you'll be better off using a video codec for animation, and an image format for images.
    - samatman 3y ago
      There are some user-level differences between an animated image and a video, which haven't really been satisfactorily resolved since the abandonment of GIF-the-format. An animated image should pause when clicked, and start again on another click, with setting separate from video autoplay to control the default. It should not have visible controls of any sort, that's the whole interface. It should save and display on the computer/filesystem as an image, and degrade to the display frame when sent along a channel which supports images but not animated ones. It doesn't need sound, or CC, or subtitles. I should be able to add it to the photo roll on my phone if I want. There are a lot of little considerations like this, and it would be well if the industry consolidated around an animated-image standard, one which was an image, and not a video embedded in a way which looks like an image.

a-french-anon 3y ago

Pretty good article, though I would have used oxipng instead of optipng in the lossless comparisons, it's the new standard, there.

jonsneyers 3y ago
Thanks for the suggestion, oxipng is indeed a better choice. Next time I will add it to the plots!

gaazoh 3y ago

The inclusion of QOI in the lossless benchmarks made me smile. It's a basically irrelevant format, that isn't supported by default by any general-public software, that aims to be just OK, not even good, yet it has a spot on one of these charts (non-photographic encoding). Neat.

lifthrasiir 3y ago
And yet didn't reach the Pareto frontier! It's quite obvious in hindsight though---QOI decoding is inherently sequential and can't be easily parallelized.
- gaazoh 3y ago
  Of course it didn't, it wasn't designed to be either the fastest nor the best. Just OK and simple. Yet in some cases it's not completely overtaken by competition, and I think that's cool. I don't believe QOI will ever have any sort of real-world practical use, but that's quite OK and I love it for it has made me and plenty of others look into binary file formats and compression and demystify it, and look further into it. I wrote a fully functional streaming codec for QOI, and it has taught me many things, and started me on other projects, either working with more complex file formats or thinking about how to improve upon QOI. I would probably never have gotten to this point if I tried the same thing starting with any other format, as they are at least an order of magnitude more complex, even for the simple ones.
  - lonjil 3y ago
    > Of course it didn't, it wasn't designed to be either the fastest nor the best. Just OK and simple. Yet in some cases it's not completely overtaken by competition, and I think that's cool. Actually, there was a big push to add QOI to stuff a few years ago, specifically due to it being "fast". It was claimed that while it has worse compression, the speed can make it a worthy trade off.
  - p0nce 3y ago
    It can be interesting if you need fast decode on low complexity, and it's an easy to improve format (-20 to -30%). Base QOI isn't that great.

btdmaster 3y ago

Missing from the article is rav1e, which encodes AV1, and hence AVIF, a lot faster than the reference implementation aom. I've had cases where aom would not finish converting an image in a minute of waiting what rav1e would do in less than 10 seconds.

JyrkiAlakuijala 3y ago
Is rav1e pareto-curve ahead of libaom pareto-curve? Does fast rav1e look better than jpegli at high encode speeds?
- btdmaster 3y ago
  Difficult to know without reproduction steps from the article, but I would think it behaves better than libaom for the same quality setting. Edit: found https://github.com/xiph/rav1e/issues/2759 https://github.com/xiph/rav1e/issues/2759
  - JyrkiAlakuijala 3y ago
    If Rav1e found better ways of encoding, why would the aom folks copy it in libaom?
- pornel 3y ago
  rav1e is generally head to head with libaom on static images, and which one wins on the speed/quality/size frontier depends a lot on the image and settings, as much as +/- 20%. I suspect rav1e has an inefficient block size selection algorithm, so the particular shape of blocks is a make or break for it. I’ve only compared rav1e to mozjpeg and libwebp, and at fastest speeds it’s only barely ahead.
jonsneyers 3y ago
Both rav1e and libaom have a speed setting. At similar speeds, I have not observed huge differences in compression performance between the two.

jug 3y ago

Pay attention to just how good WebP is at _lossless_ comparison though! I've always thought that one as flying under the radar. Most get stuck on WebP not offering tangible enough benefits (or even worse) over MozJPEG encoding, but WebP _lossless_ is absolutely fantastic for performance/speed! PNG or even OptiPNG is far worse. And very well supported online now, and leaving the horrible lossless AVIF in the dust too of course.

jonsneyers 3y ago
Lossless WebP is very good indeed. The main problem is that it is not very future-proof since it only supports 8-bit. For SDR images that's fine, but for HDR this is a fundamental limitation that is about as bad as GIF's limitation to 256 colors.
- jug 3y ago
  Ah, I didn't know this and I agree this is a fairly big issue and increasingly so over time. I think smartphones in particular hastened the demand for HDR quite a bit, what was once a premium/enthusiast feature you only had to explicitly buy into.
  - fluidcruft 3y ago
    HDR is also important for medical imaging applications (which have been moving to web)
- omoikane 3y ago
  I haven't ran across websites that serves up HDR images, I am not sure I would notice the difference. WebP seems appropriately named and optimized for image delivery on the web. Maybe you are thinking of high bit depth for archival use? I can see some use cases there where 8-bit is not sufficient, though personally I store high bit depth images in whatever raw format was produced by my camera (which is usually some variant of TIFF).
  - lonjil 3y ago

jug 3y ago

Wow, that new jpegli encoder. Just wow. Look at those results. Haha, JPEG has many years left still.

kasabali 3y ago
> JPEG has many years left still Such a shame arithmetic coding (which is already in the standard) isn't widely supported in the real world. Because converting Huffman coded images losslessly to arithmetic coding provides an easy 5-10% size advantage in my tests. Alien technology from the future indeed.
- mort96 3y ago
  The benefits of JPEG kind of go away if you start adopting more recent changes to the format, no? JPEG is nice because everything has supported it for 20+ years. JPEG-with-arithmetic-coding is essentially a new, incompatible format, why not use JXL or AVIF instead?
  - gruturo 3y ago
    Yes, but this is really a pity in the specific case of Arithmetic Coding, because, unlike "more recent changes to the format", it's been in the standard since the very beginning - but is not supported by a lot of implementations due to software patents (which meanwhile expired, but their damage remains).
    - adgjlsfhk1 3y ago
      arithmetic encoding is old, but around 2010 (when all the patents expired), there was a ton of really good research on how to to table based ans and vectorized rans to make the performance good. Aside from the patent issues Arithmetic encoding wasn't pursued much because the CPU cost was too high. Now that multiply is cheap and the divisions can be avoided, ANS is a lot better than it used to be.
      - 3y ago

dancemethis 3y ago

"Pareto" being used outside the context of Brazil's best prank call ever (Telerj Prank) will always confuse me. I keep thinking, "what does the 'thin-voiced lawyer' have to do with statistics?"...

MikeCapone 3y ago

I really hope this can become a new standard and be available everywhere (image tools, browsers, etc). While in practice it won't change my life much, I like the elegance of using a modern standard with this level of performance an efficiency.

TacticalCoder 3y ago

Without taking into account whether JPEG XL shines on its own or not (which it may or may not), JPEG XL completely rocks for sure because it does this: .. $ ls -l a.jpg && shasum a.jpg ... 615504 ... a.jpg 716744d950ecf9e5757c565041143775a810e10f a.jpg .. $ cjxl a.jpg a.jxl Read JPEG image with 615504 bytes. Compressed to 537339 bytes including container .. $ ls -l a.jxl ... 537339 ... a.jxl But, wait for it: .. $ djxl a.jxl b.jpg Read 537339 compressed bytes. Reconstructed to JPEG. .. $ ls -l b.jpg && shasum b.jpg ... 615504 ... b.jpg 716744d950ecf9e5757c565041143775a810e10f b.jpg Do you realize how many billions of JPEG files there are out there which people want to keep? If you recompress your old JPEG files using a lossy format, you lower its quality. But with JPEG XL, you can save 15% to 30% and still, if you want, get your original JPG 100% identical, bit for bit. That's wonderful. P.S: I'm sadly on Debian stable (12 / Bookworm) which is on ImageMagick 6.9 and my Emacs uses (AFAIK) ImageMagick to display pictures. And JPEG XL support was only added in ImageMagick 7. I haven't looked more into that yet.

izacus 3y ago
I'm sure that will be hugely cherished by users which take screenshots of JPEGs so they can resend them on WhatsApp :P
- F3nd0 3y ago
  This particular feature might not, but if said screenshots are often compressed with JPEG XL, they will be spared the generation loss that becomes blatantly visible in some other formats: https://invidious.protokolla.fi/watch?v=w7UDJUCMTng https://invidious.protokolla.fi/watch?v=w7UDJUCMTng
  - IshKebab 3y ago
    Maybe. But to know for sure you need to offset the image and change encoder settings.
JyrkiAlakuijala 3y ago
I managed to add that requirement to jpeg xl. I think it will be helpful to preserve our digital legacy intact without lossy re-encodings.

kodabbb 3y ago

Looks like there are more savings coming on lossless AVIF: https://www.reddit.com/r/AV1/comments/1b3lh08/comment/kstmbru/ https://www.reddit.com/r/AV1/comments/1b3lh08/comment/kstmbr...

JyrkiAlakuijala 3y ago
I plan to add 15–25 % more quality in the ugly lowest end quality in JPEG XL in the coming two months.

JyrkiAlakuijala 3y ago

It is worth noting that the JPEG XL effort produced a nice new parallelism library called Highway. This library is powering not only JPEG XL but also Google's latest Gemma AI models.

jhalstead 3y ago
[0] for those interested in Highway. It's also mentioned in [1], which starts off > Today we're sharing open source code that can sort arrays of numbers about ten times as fast as the C++ std::sort, and outperforms state of the art architecture-specific algorithms, while being portable across all modern CPU architectures. Below we discuss how we achieved this. [0] https://github.com/google/highway https://github.com/google/highway [1] https://opensource.googleblog.com/2022/06/Vectorized%20and%20performance%20portable%20Quicksort.html https://opensource.googleblog.com/2022/06/Vectorized%20and%2..., which has an associated paper at https://arxiv.org/pdf/2205.05982.pdf https://arxiv.org/pdf/2205.05982.pdf.
- janwas 3y ago
  :) Thanks for the mention. Highway/vqsort TL here, happy to discuss. PS: I used to work on JPEG XL. It is great to see these outstanding improvements, congrats to the team!
a-french-anon 3y ago
And VIPS! It seems like the best way to get portable SIMD in C++, to me.

sandstrom 3y ago

JPEG XL is awesome! One thing I think would help with its adoption, is if they would work with e.g. the libvips team to better implement it. For example, streaming encoder and streaming decoder would be the preferred integration method in libvips.

ImageXav 3y ago

Maybe someone here will know of a website that describes each step of the jpeg xl format in detail? Unlike for traditional jpeg, I have found it hard to find a document providing clear instructions on the relevant steps, which is a shame as there are clearly tons of interesting innovations that have been compiled together to make this happen, and I'm sure the individual components are useful in their own right!

adgjlsfhk1 3y ago
https://github.com/libjxl/libjxl/blob/main/doc/format_overview.md https://github.com/libjxl/libjxl/blob/main/doc/format_overvi... is a pretty detailed but good overview. The highlights are variable size DCT (up to 128x128), ANS entropy prediction, and chroma from luminance prediction. https://github.com/libjxl/libjxl/blob/main/doc/encode_effort.md https://github.com/libjxl/libjxl/blob/main/doc/encode_effort... also gives a good breakdown of features by effort level.
- ImageXav 3y ago
  Thank you for sharing. This gives me a good idea of where to start looking.

jeffbee 3y ago

The choice to represent the speed based on multithreaded encoding strikes me as somewhat arbitrary. If your software has a critical path dependent on minimal latency of a single image, then it makes some sense, but you still may have more or fewer than 8 cores. On the other hand if you have another source of parallelism, for example you are encoding a library of images, then it is quite irrelevant. I think the fine data in the article would be even more useful if the single threaded speed and the scalability of the codec were treated separately.

redder23 3y ago

AVIF looks better here: JPEG XL looks very blurred out on the bottom with high compression. AVIF preserves much more detail and sharpness. https://res.cloudinary.com/jon/qp-low.png https://res.cloudinary.com/jon/qp-low.png

jiggawatts 3y ago

The problem with JPEG XL is that it is written in an unsafe language and has already had several memory safety vulnerabilities found in it. Image codecs are used in a wide range of attacker-controlled scenarios and need to be completely safe. I know Rust advocates sound like a broken record, but this is the poster child for a library that should never have been even started in C++ in the first place. It’s absolute insanity that we write codecs — pure functions — in an unsafe language that has a compiler that defaults to “anything goes” as an optimisation technique.

lonjil 3y ago
Pretty much every codec in every browser is written in an unsafe language, unfortunately. I don't see why JXL should be singled out. On the other hand, there is a JXL decoder in Rust called jxl-oxide [1] which works quite well, and has been confirmed by JPEG as conformant. Hopefully it will be adopted for decode-only usecases. [1] https://github.com/tirr-c/jxl-oxide/pull/267 https://github.com/tirr-c/jxl-oxide/pull/267 > It’s absolute insanity that we write codecs — pure functions — in an unsafe language that has a compiler that defaults to “anything goes” as an optimisation technique. Rust and C++ are exactly the same in how they optimize, compilers for both assume that your code has zero UB. The difference is that Rust makes it much harder to accidentally have UB.
- jiggawatts 3y ago
  "We've never had to wear helmets before, why start now?" There are only a handful of image codecs that are widely accepted. Essentially just GIF, PNG, and JPG. There's a smattering of support for more modern formats, but those three dominate. Adding a fourth image format is increasing this attack surface by a substantial margin across a huge range of software. Not just web browsers, but chat apps, server software (thumbnail generators), editors, etc... This is the kind of thing that gets baked into standard libraries, operating systems, and frameworks. It's up there with JSON or XML. You had better be damned sure what you're doing is not going to cause a long list of CVEs! JPEG XL is a complex codec, with a lot of code. This increases the chance of bugs and increases the attack surface. A (surprisingly!) good metric for complexity is the size of the zip file of the code. Libjpeg is something like 360 kB, libpng is 350 kB, and giflib is 90 kB. The JXL source is 1.4 MB zipped, making more than twice the size of the above three combined! The other libraries use C/C++ not because that's a better choice, but because it was the only choice back in the ... checks Wikipedia ... 1980s and 90s! We live in the future. We have memory-safe languages now. We're allowed to use them. You won't get in trouble from anyone, I promise.

jshier 3y ago

I have an existing workflow where I take JPEGs (giant PNGs) from designers and reencode them using mozjpeg. However, I can't find a way to invoke jpegli tool in the same way, especially since it seems to just be part of the jpeg-xl tool? Is that right? Are there any sample invocations anywhere?

chungy 3y ago
You should be able to use the `cjpegli` command the same way you'd use cjxl. The simplest invocation would be `cjpegli input.png output.jpg`
- JyrkiAlakuijala 3y ago
  Or replace/ldconfig the jpeg library with the jpegli library. It is API/ABI compatible with libjpeg-turbo and mozjpeg.
- jshier 3y ago
  Thanks. It seems the macOS release is a bit behind on brew (0.9.1) and doesn't include the cjpegli tool yet.

deleted 3y ago

[deleted]

ksec 3y ago

It is nice 0.10 finally landed those memory and speed optimisation. But the King remains HALIC. In terms of MT encoder it still uses 3.5x more memory than HALIC, and 6x encoding time compared to HALIC. While offering the same or smaller files size in Lossless. Hopefully JPEG XL could narrow those gaps some days.