JPEG XL

Post images where JXL compresses worse than PNG, WebP or GIF. (Formerly "lossless e9 fails".)

I'll start with an e10 fail. ```cjxl v0.10.0 26d32cab 11813 readme.d0e9.jxl 7129 readme.d0e10.jxl 7116 readme.z9.webp 7023 readme.d0e9P0I1g3patches0.jxl 6968 readme.png```

2 377 120 fm.gif 2 568 214 fm.png 2 460 333 fm.png.jxl

It's pretty cheap to find animation fails, harder otherwise, I think.

```7334 i34r6p4.d0e9.jxl 4282 i34r6p4.d0e10.jxl 3260 i34r6p4.z9.webp 2330 i34r6p4.png cjxl v0.10.0 26d32cab```

Most of my animation samples are compressed better with jxl than with apng\gif

WebP exists, but looking back, my testing was with more practical effort (e7 vs m6) so I guess I extrapolated. Older cjxl failed to produce output entirely in many cases, but in viable cases, it did edge out WebP in the practical test on average.

For animation, often the difference is caused by having full frames vs cropped frames — libjxl/cjxl just encode frames literally, they don't try to avoid re-encoding unchanged parts using a cropped frame, so that can lead to surprisingly bad results sometimes. Though there can be other issues like palette ordering or gifs that were made with lzw-friendly dithering patterns which jxl might have more trouble with.

Examples of poor lossless compression are good to have in any case, it's very useful to see where the current heuristics are not doing a good job — tricky thing is improving them in a way that doesn't make that particular image compress better while making others compress worse...

```bpp MP/s (u+s) command 14.6256 21 cwebp_1.2.4_z2metadataall 14.6294 7.0 oxipng_9.0.0_o1 15.4014 (ImageMagick default PNG) 16.2701 0.05450 cjxl_v0.9.0-a16a3e22_d0e9E3I100g2modular_palette_colors0X0Y0 17.9964 0.07671 cjxl_v0.9.0-a16a3e22_d0e9```

```bpp MP/s (u+s) command 0.127413 1.3 cwebp_1.2.4_z9metadataall 0.138103 70 cwebp_1.2.4_z4metadataall 0.139606 0.318 cjxl_v0.9.0-a16a3e22_d0e9P0I0g3patches0 0.202177 2.2 cjxl_v0.9.0-a16a3e22_d0e8 0.300294 0.354 cjxl_v0.9.0-a16a3e22_d0e9```

```bpp MP/s (u+s) command 2.14600 0.228 cwebp_1.2.4_z9metadataall 2.39284 4.0 cwebp_1.2.4_z4metadataall 2.71056 0.1643 cjxl_v0.9.0-a16a3e22_d0e9P0I1g3patches0 3.18760 0.0046428 oxipng_9.0.0_o6Za 3.23468 0.1078 cjxl_v0.9.0-a16a3e22_d0e9 3.66485 30 oxipng_9.0.0_o0 4.01182 (ImageMagick default PNG) 4.42924 0.547 cjxl_v0.9.0-a16a3e22_d0e8 4.81630 41 cwebp_1.2.4_z0metadataall 5.92038 1.26 cjxl_v0.9.0-a16a3e22_d0e7 14.2595 41 cjxl_v0.9.0-a16a3e22_d0e1```

```bpp MP/s (u+s) command 0.602018 0.337 cwebp_1.2.4_z9metadataall 0.616708 23 cwebp_1.2.4_z7metadataall 1.10011 0.03314 cjxl_v0.9.0-a16a3e22_d0e9P0I1g3patches0 1.57614 45 cwebp_1.2.4_z2metadataall 1.84035 0.0873 cjxl_v0.9.0-a16a3e22_d0e9```

``` $ wc -c ascii_grey.* 62185 ascii_grey.e9.jxl 55248 ascii_grey.png ```

(From https://shkspr.mobi/blog/2024/01/compressing-text-into-images/)

```Pareto front for user+system time and size | mean Mpx/(user+system s) | mean bpp | best of U 0.15525000 1.08 cwebp_1.2.4_z9 U 0.15612500 23 cwebp_1.2.4_z7 · 0.15612500 17 cwebp_1.2.4_z8 · 0.16512500 21 cwebp_1.2.4_z6 · 0.16575000 21 cwebp_1.2.4_z4 · 0.16575000 21 cwebp_1.2.4_z5 · 0.16750000 21 cwebp_1.2.4_z3 U 0.17412500 3.e+01 cwebp_1.2.4_z2 U 0.17918750 5.e+01 cwebp_1.2.4_z1 · 0.18896875 2.7 cjxl_0.9.0_d0e9P0I1g3patches0num_threads0 · 0.19143750 0.000474159 cjxl_0.9.0_d0e10 · 0.20518750 0.499 cjxl_0.9.0_d0e9num_threads0 · 0.23584375 2.6 cjxl_0.9.0_d0e8num_threads0 · 0.24096875 4.2 cjxl_0.9.0_d0e7num_threads0 · 0.24303125 4.3 cjxl_0.9.0_d0e6num_threads0 · 0.24415625 4.3 cjxl_0.9.0_d0e5num_threads0 U 0.27331250 >3.e+02 original · 0.37643750 15 cjxl_0.9.0_d0e2num_threads0 · 0.39640625 8.8 cjxl_0.9.0_d0e4num_threads0 · 0.64859375 13 cjxl_0.9.0_d0e3num_threads0 · 0.84784375 9.e+01 cjxl_0.9.0_d0e1num_threads0 · 1.00593750 4.e+01 cwebp_1.2.4_z0```

```Pareto front for user+system time and size | mean Mpx/(user+system s) | mean bpp | best of U 0.51707235 0.554 cwebp_1.2.4_z9 U 0.53444050 14 cwebp_1.2.4_z7 · 0.53444050 10 cwebp_1.2.4_z8 U 0.58709432 15 cwebp_1.2.4_z6 · 0.59609533 0.0002444794 cjxl_0.9.0_d0e10 · 0.64120605 1.09 cjxl_0.9.0_d0e9P0I0g3modular_palette_colors10000patches0num_threads0 U 0.65174949 15 cwebp_1.2.4_z5 · 0.65174949 15 cwebp_1.2.4_z4 · 0.65183401 15 cwebp_1.2.4_z3 · 0.78361646 0.2516 cjxl_0.9.0_d0e9num_threads0 U 0.80468222 29 cwebp_1.2.4_z2 U 0.83768594 38 cwebp_1.2.4_z1 · 0.88761410 1.52 cjxl_0.9.0_d0e8num_threads0 · 0.91863168 3.08 cjxl_0.9.0_d0e7num_threads0 · 0.93084432 3.35 cjxl_0.9.0_d0e6num_threads0 · 0.95757268 3.61 cjxl_0.9.0_d0e5num_threads0 · 1.42129395 4.5 cjxl_0.9.0_d0e4num_threads0 · 1.53784229 16 cjxl_0.9.0_d0e2num_threads0 U 1.62975406 9.e+01 cjxl_0.9.0_d0e1num_threads0 U 1.69485294 4.e+02 original · 1.70748817 10 cjxl_0.9.0_d0e3num_threads0 · 1.97658891 5.e+01 cwebp_1.2.4_z0```

```Pareto front for user+system time and size | mean Mpx/(user+system s) | mean bpp | best of U 0.05103143 8.9 cwebp_1.2.4_z8 · 0.05109595 0.422 cwebp_1.2.4_z9 U 0.05141853 25 cwebp_1.2.4_z7 U 0.05367655 3.e+01 cwebp_1.2.4_z6 · 0.05493460 0.1979 cjxl_0.9.0_d0e9P0I0g3patches0num_threads0 · 0.05493460 0.000293646 cjxl_0.9.0_d0e10 U 0.06916017 4.e+01 cwebp_1.2.4_z4 · 0.06916017 3.e+01 cwebp_1.2.4_z5 · 0.07232141 3.6 oxipng_9.0.0_o4a-fast-t1 · 0.07367623 5.5 oxipng_9.0.0_o3a-fast-t1 · 0.07686973 3.7 oxipng_9.0.0_o5a-fast-t1 · 0.07686973 3.6 oxipng_9.0.0_o6a-fast-t1 · 0.07709553 9.9 oxipng_9.0.0_o1a-fast-t1 · 0.07767617 4.e+01 cwebp_1.2.4_z3 · 0.07838583 8.3 oxipng_9.0.0_o2a-fast-t1 U 0.08990178 2.e+02 original · 0.08990178 13 oxipng_9.0.0_o0a-fast-t1 · 0.10651441 4.e+01 cwebp_1.2.4_z2 · 0.10683699 8.e+01 cwebp_1.2.4_z0 · 0.10774020 5.e+01 cwebp_1.2.4_z1 · 0.13619135 0.561 cjxl_0.9.0_d0e9num_threads0 · 0.14551378 2.6 cjxl_0.9.0_d0e8num_threads0 · 0.15202981 7.8 cjxl_0.9.0_d0e7num_threads0 · 0.16590055 8.0 cjxl_0.9.0_d0e6num_threads0 · 0.18815826 8.3 cjxl_0.9.0_d0e5num_threads0 · 0.20370639 19 cjxl_0.9.0_d0e2num_threads0 · 0.20886760 9.9 cjxl_0.9.0_d0e4num_threads0 · 0.26760859 8.e+01 cjxl_0.9.0_d0e1num_threads0 · 0.60273221 15 cjxl_0.9.0_d0e3num_threads0```

[original source](https://dsp.stackexchange.com/questions/2010/what-is-the-least-jpg-compressible-pattern-camera-shooting-piece-of-cloth-sca/25618#25618) ```Pareto front for user+system time and size | mean Mpx/(user+system s) | mean bpp | best of U 0.02362061 0.608 cwebp_1.2.4_z9 U 0.02380371 6.6 cwebp_1.2.4_z8 · 0.02655029 0.04672 cjxl_0.9.0_d0e9P0I0g3patches0num_threads0 · 0.02655029 0.0001540604 cjxl_0.9.0_d0e10 · 0.02685547 17 cwebp_1.2.4_z6 U 0.02685547 17 cwebp_1.2.4_z7 U 0.03930664 19 cwebp_1.2.4_z5 U 0.03997803 22 cwebp_1.2.4_z4 · 0.04345703 20 cwebp_1.2.4_z3 · 0.04910278 0.660 cjxl_0.9.0_d0e9num_threads0 · 0.05175781 2.7 cjxl_0.9.0_d0e8num_threads0 U 0.06356812 >3.e+02 original · 0.10269165 8.7 cjxl_0.9.0_d0e7num_threads0 · 0.15722656 22 cwebp_1.2.4_z2 · 0.17083740 26 cwebp_1.2.4_z1 · 0.17498779 7.e+01 cwebp_1.2.4_z0 · 0.34426880 9.0 cjxl_0.9.0_d0e6num_threads0 · 0.80313110 9.0 cjxl_0.9.0_d0e5num_threads0 · 1.31115723 10 cjxl_0.9.0_d0e4num_threads0 · 1.52557373 3.e+01 cjxl_0.9.0_d0e2num_threads0 · 2.57080078 22 cjxl_0.9.0_d0e3num_threads0 · 7.00042725 9.e+01 cjxl_0.9.0_d0e1num_threads0```

ohhh this thread is pain

you're welcome

Lossless nonphoto is such a very, very different game from any other kind of image compression. Very nice to get examples where there's room for improvement 🙂

<@794205442175402004> you designed lossless to perform well on photographic images initially ?

I didn't, the weighed predictor which is used in e3 was designed for that. Modular is designed to be flexible enough to do all kinds of images, photo and nonphoto, but the search space is just so huge that making a good encoder is tricky.

yet, in the usages, I see a richer use of lossless for screenshots, mangas, sharp edges stuff than photos which are very very well compressed (without blatant artifact) with varDCT

but it's nice to have margin of improvement 😄

``` mean Mpx/(real s) | Pareto front for real time and size mean bpp | | best of 0.00052643 ..... . jxl_from_tree_0.10.1 0.00399780 12 R cwebp_1.2.4_z1 0.00588226 0.4294 · cjxl_0.9.0_d0e9E3I99g3patches0num_threads0 0.02443695 1.20 · cjxl_0.9.0_d0e9P5I100g3num_threads0 0.02570343 0.4112 · cjxl_0.9.0_d0e9num_threads0 0.05286407 2.53 · cjxl_0.9.0_d0e8num_threads0 0.05921936 12 · oxipng_9.0.0_o1a-fast-t1 0.05933380 4.54 · cjxl_0.9.0_d0e7num_threads0 0.06312561 23 R oxipng_9.0.0_o0a-fast-t1 0.06694794 4.83 · cjxl_0.9.0_d0e6num_threads0 0.07440186 4.88 · cjxl_0.9.0_d0e5num_threads0 0.09666443 1.e+03 R original 0.12020874 5.22 · cjxl_0.9.0_d0e4num_threads0 0.13626099 11 · cjxl_0.9.0_d0e3num_threads0 0.26112366 1.e+02 · cjxl_0.9.0_d0e1num_threads0 0.27323914 19 · cjxl_0.9.0_d0e2num_threads0```

Funny enough webp -z 9 and jxl 0.9 -e10 produced exact the same size - 580 bytes. But used time..

cwebp z1 is 524B. e10 finds d0e9E4I100g3, but with ModularOptions::TreeMode::kNoWP, which is not otherwise exposed to cjxl CLI except via DCT.

[source](<https://steamcommunity.com/games/1181000/announcements/detail/4228270796643251261>), [direct link](https://steamcdn-a.akamaihd.net/steamcommunity/public/images/clans/33198961/cd55258fb998427db3de0f3ac6d67df544da7dc7.png) cwebp z1 186x faster, 9% smaller; z7 22x faster, 19% smaller than cjxl e9 ``` mean Mpx/(real s) | Pareto front for real time and size mean bpp | | best of 5.24676539 1.64 R cwebp_1.2.4_z7 5.29886214 5.99 R cwebp_1.2.4_z6 5.30501496 0.049050 · cjxl_0.9.0_d0e9E3I100g3modular_palette_colors0Y0patches0num_threads0 5.75002550 11 R cwebp_1.2.4_z2 5.80246167 0.1484 · cjxl_0.9.0_d0e9P0E3I100modular_palette_colors10000X0Y0patches0num_threads0 5.90056735 14 R cwebp_1.2.4_z1 6.04422699 0.8521 · oxipng_9.0.0_o4a-fast-t1 6.10030286 3.96 · oxipng_9.0.0_o1a-fast-t1 6.47121237 0.075170 · cjxl_0.9.0_d0e9num_threads0 6.62034601 18 R oxipng_9.0.0_o0a-fast-t1 7.15607451 >1.e+03 R original 8.65211210 0.3991 · cjxl_0.9.0_d0e8num_threads0 9.32654622 30 · cwebp_1.2.4_z0 9.56911314 0.9436 · cjxl_0.9.0_d0e7num_threads0 10.06510830 1.22 · cjxl_0.9.0_d0e6num_threads0 10.14838078 1.46 · cjxl_0.9.0_d0e5num_threads0 12.47681816 12 · cjxl_0.9.0_d0e2num_threads0 12.89968721 2.74 · cjxl_0.9.0_d0e4num_threads0 13.68801347 25 · cjxl_0.9.0_d0e1num_threads0 14.59940331 7.54 · cjxl_0.9.0_d0e3num_threads0```

```cwebp_1.2.4_z9 2.8x faster, 24% smaller than cjxl_0.9.0_d0e9num_threads0 mean Mpx/(real s) | Pareto front for real time and size mean bpp | | best of 2.61125772 0.2228 R cwebp_1.2.4_z9 2.88304012 0.13725 · cjxl_0.9.0_d0e9P0I100g3patches0num_threads0 2.90565201 0.16549 · cjxl_0.9.0_d0e9P0I1g3patches0num_threads0 3.46738812 0.079527 · cjxl_0.9.0_d0e9num_threads0 3.81318673 2.15 R oxipng_9.0.0_o2a-fast-t1 3.90722608 0.4688 · cjxl_0.9.0_d0e8num_threads0 4.16973765 4.20 R oxipng_9.0.0_o1a-fast-t1 4.35080633 1.233 · cjxl_0.9.0_d0e7num_threads0 4.74133488 >2.e+03 R original 5.01478395 1.671 · cjxl_0.9.0_d0e6num_threads0 5.28252315 2.12 · cjxl_0.9.0_d0e5num_threads0 5.76341049 3.31 · cjxl_0.9.0_d0e4num_threads0 5.92378472 9.87 · cjxl_0.9.0_d0e3num_threads0 6.34503858 15.5 · cjxl_0.9.0_d0e2num_threads0 7.99598380 65 · cjxl_0.9.0_d0e1num_threads0```

```cwebp_1.2.4_z9 8.5x faster, 66% smaller than cjxl_0.9.0_d0e9num_threads0 mean Mpx/(real s) | Pareto front for real time and size mean bpp | | best of 0.64711837 0.7209 R cwebp_1.2.4_z9 0.86649850 0.1911 · cjxl_0.9.0_d0e9E3I100g3modular_palette_colors10000Y0patches0num_threads0 0.88094817 0.3366 · cjxl_0.9.0_d0e9P0I0g3modular_palette_colors10000patches0num_threads0 1.92914411 0.08459 · cjxl_0.9.0_d0e9num_threads0 2.46915921 0.6183 · cjxl_0.9.0_d0e8num_threads0 2.79213998 4.85 R cwebp_1.2.4_z6 2.93149526 1.41 · cjxl_0.9.0_d0e7num_threads0 3.24589620 39 R cwebp_1.2.4_z0 3.57653561 1.77 · cjxl_0.9.0_d0e6num_threads0 3.59964010 18 · oxipng_9.0.0_o0a-fast-t1 3.73706733 1.97 · cjxl_0.9.0_d0e5num_threads0 4.00242078 >7.e+02 R original 5.04909569 2.99 · cjxl_0.9.0_d0e4num_threads0 5.16089055 7.8 · cjxl_0.9.0_d0e3num_threads0 5.61606067 12 · cjxl_0.9.0_d0e2num_threads0 6.00161742 68 · cjxl_0.9.0_d0e1num_threads0```

```cwebp_1.2.4_z4 89x faster, 7% smaller; cwebp_1.2.4_z9 3.84x faster, 16% smaller than cjxl_0.9.0_d0e9num_threads0 mean Mpx/(real s) | Pareto front for real time and size mean bpp | | best of 0.25065104 1.17 R cwebp_1.2.4_z9 0.25771077 26 R cwebp_1.2.4_z6 0.27042643 0.3318 · cjxl_0.9.0_d0e9P0I1g3patches0num_threads0 0.27724202 27 R cwebp_1.2.4_z4 0.29367065 0.6609 · cjxl_0.9.0_d0e9P1I100g3patches0num_threads0 0.29843140 0.3052 · cjxl_0.9.0_d0e9num_threads0 0.35321045 44 R cwebp_1.2.4_z1 0.36874390 2.10 · cjxl_0.9.0_d0e8num_threads0 0.40989176 4.42 · cjxl_0.9.0_d0e7num_threads0 0.42677816 4.52 · cjxl_0.9.0_d0e6num_threads0 0.44033813 4.82 · cjxl_0.9.0_d0e5num_threads0 0.55985514 56 R cwebp_1.2.4_z0 0.57178752 8.7 · cjxl_0.9.0_d0e4num_threads0 0.61086019 17 · cjxl_0.9.0_d0e2num_threads0 0.73307292 >8.e+02 R original 0.95154826 14 · cjxl_0.9.0_d0e3num_threads0 1.08156331 1.e+02 · cjxl_0.9.0_d0e1num_threads0```

```vs cjxl_0.10.1_d0e10num_threads0: time size command 1.18% 95.0% cwebp_1.3.2_z1 60.993% 92.1% cwebp_1.3.2_z9 mean Mpx/(real s) | Pareto front for real time and size mean bpp | | best of 8.56108796 0.14005 R cwebp_1.3.2_z9 8.83606481 7.25 R cwebp_1.3.2_z1 9.12212577 0.093557 · cjxl_0.9.0_d0e9g3num_threads0 9.23631944 0.19439 · cjxl_0.9.0_d0e9P1I100g2patches0num_threads0 9.29800540 0.085421 · cjxl_0.10.1_d0e10num_threads0 9.33728009 0.2521 · cjxl_0.10.1_d0e9num_threads0 9.38915123 0.3471 · cjxl_0.10.1_d0e8num_threads0 9.42290509 0.9008 · cjxl_0.10.1_d0e7num_threads0 10.46108025 1.267 · cjxl_0.10.1_d0e6num_threads0 10.49486883 2.27 · cjxl_0.10.1_d0e5num_threads0 10.72720293 3.73 · cjxl_0.10.1_d0e4num_threads0 10.77122299 9.43 R cjxl_0.10.1_d0e3num_threads0 11.41498457 14.8 R cjxl_0.10.1_d0e2num_threads0 12.17617284 >2.e+03 R original 12.38359568 51 · cjxl_0.10.1_d0e1num_threads0```

```vs cjxl_0.10.1_d0e10num_threads0: time size command 5.020% 96.1% cwebp_1.3.2_z4 47.072% 85.0% cwebp_1.3.2_z9 mean Mpx/(real s) | Pareto front for real time and size mean bpp | | best of 3.80757716 0.20232 R cwebp_1.3.2_z9 3.98006559 0.13188 · cjxl_0.9.0_d0e9g3num_threads0 4.09309028 0.2878 R cjxl_0.9.0_d0e9P1I100g3patches0num_threads0 4.30757716 1.897 R cwebp_1.3.2_z4 4.48028935 0.095237 · cjxl_0.10.1_d0e10num_threads0 4.60761188 0.3664 · cjxl_0.10.1_d0e9num_threads0 4.65226852 0.6274 · cjxl_0.10.1_d0e8num_threads0 4.78345679 1.598 · cjxl_0.10.1_d0e7num_threads0 4.88682099 3.75 R cwebp_1.3.2_z2 4.92001157 2.13 · cjxl_0.10.1_d0e6num_threads0 4.99876929 2.71 · cjxl_0.10.1_d0e5num_threads0 5.45851852 26 R cwebp_1.3.2_z0 6.42608410 3.61 · cjxl_0.10.1_d0e4num_threads0 6.79450617 >2.e+03 R original 7.98173997 15.7 · cjxl_0.10.1_d0e2num_threads0 8.43692901 9.87 · cjxl_0.10.1_d0e3num_threads0 8.82295910 58 · cjxl_0.10.1_d0e1num_threads0```

```vs cjxl_0.10.1_d0e10num_threads0: time size command 52.251% 96.6% cwebp_1.3.2_z9 mean Mpx/(real s) | Pareto front for real time and size mean bpp | | best of 3.48629804 0.17003 R cwebp_1.3.2_z9 3.60766808 0.088843 · cjxl_0.10.1_d0e10num_threads0 3.73871127 0.3176 R cjxl_0.9.0_d0e9P0E3I100modular_palette_colors10000X0Y0patches0num_threads0 3.85140016 2.79 R cwebp_1.3.2_z5 3.88780510 0.3168 · cjxl_0.10.1_d0e9num_threads0 3.95989019 0.4976 · cjxl_0.10.1_d0e8num_threads0 3.98422493 2.06 · cwebp_1.3.2_z3 4.10638453 1.471 · cjxl_0.10.1_d0e7num_threads0 4.58962959 5.33 R cwebp_1.3.2_z1 4.72036101 1.916 · cjxl_0.10.1_d0e6num_threads0 4.90775877 2.49 · cjxl_0.10.1_d0e5num_threads0 5.34284048 22 R cwebp_1.3.2_z0 5.55684045 3.40 · cjxl_0.10.1_d0e4num_threads0 5.85539656 >2.e+03 R original 6.03226277 16.1 · cjxl_0.10.1_d0e2num_threads0 6.57390311 58 · cjxl_0.10.1_d0e1num_threads0 7.67883404 9.69 · cjxl_0.10.1_d0e3num_threads0```

```vs cjxl_0.10.1_d0e10num_threads0: time size command 24.11% 99.6% cjxl_0.9.0_d0e9P5I100g3num_threads0 25.40% 93.6% cwebp_1.3.2_z9 mean Mpx/(real s) | Pareto front for real time and size mean bpp | | best of 2.43143519 0.3613 R cwebp_1.3.2_z9 2.48073302 0.13973 · cjxl_0.9.0_d0e9g3num_threads0 2.58572531 0.3807 R cjxl_0.9.0_d0e9P5I100g3num_threads0 2.59670910 0.091773 · cjxl_0.10.1_d0e10num_threads0 2.68321759 0.3857 R cjxl_0.9.0_d0e9P1I100g3patches0num_threads0 2.78604167 3.86 R cwebp_1.3.2_z6 2.78981867 0.3266 · cjxl_0.10.1_d0e9num_threads0 2.93591049 33 R cwebp_1.3.2_z0 2.97319444 0.5259 · cjxl_0.10.1_d0e8num_threads0 3.25605710 7.57 · cwebp_1.3.2_z1 3.27352238 1.497 · cjxl_0.10.1_d0e7num_threads0 3.34464506 3.32 · oxipng_9.0.0_o1a-fast-t1 3.58155864 2.14 · cjxl_0.10.1_d0e6num_threads0 3.71557099 >2.e+03 R original 3.74884259 4.14 · cjxl_0.10.1_d0e4num_threads0 3.78620756 2.73 · cjxl_0.10.1_d0e5num_threads0 3.83995370 10.9 · cjxl_0.10.1_d0e3num_threads0 4.98264275 18.5 · cjxl_0.10.1_d0e2num_threads0 5.16990355 72 · cjxl_0.10.1_d0e1num_threads0```

Thanks for finding all these cases where cjxl is messing up — one thing I noticed though is that some images contain Exif/xmp metadata, which cwebp strips by default and cjxl keeps by default. That's not really a fair comparison, so to keep things simple you may want to strip everything from the source png files before comparing

Thanks, it was done with `-metadata all`, but I see I captured the webp size incorrectly on https://discord.com/channels/794206087879852103/1187313089612369991/1215587887907741776 (apparently cwebp's `Output` line doesn't include icc profile size =/ ). I'm not aware of anything here where cjxl actually keeps something cwebp does not, and in the case above, cjxl is more efficient at storing the icc profile anyway. I do think metadata is important, but understanding there are practical limitations, I intentionally avoided extravagant examples. If there is actually a general issue across the results, I can investigate later.

I found a few examples, they all come from one artist. The common characteristic is they are mostly flat colored with a noisy texture applied over the entire image.

Wasn't jyrki the author of lossless webp? Doesn't he remember the best tricks he used which may explain the rare cases where webp outperform jxl? 😊

`310644 cwebp -z 9 367347 cjxl --allow_expert_options -d 0 -e 11 436289 cjxl -d 0 -e 10 458266 oxipng -o max --zopfli 461306 cjxl -d 0 -e 9` The `-e 11` also triggers the spec related palette transform issue.

I hesitated to post this here but it's for science, I guess.

What is this spec related issue I missed?

The recently discovered discrepancy between the spec and libjxl. https://discord.com/channels/794206087879852103/1021189485960114198

It only triggers when combining large palettes and lz77, and can only happen at e8 or higher. In practice there will be no problem because we'll just update the spec and keep libjxl as it is.

Oh, this one, I didn't understood it had an impact on size 😅

It's just a coincidence this particular image triggers two unrelated issues.

But how do you know the issue is present then?

I suppose the issue is only when using jxl-oxide, which interprets it according to the spec as it is now. When using only libjxl, there should not be an issue.

``` $ ~/dev/libjxl/build/tools/cjxl cat.png -d 0 -e 10 cat.png.new.jxl -g 3 JPEG XL encoder v0.10.0 c8451c52 [NEON] Encoding [Modular, lossless, effort: 10] Compressed to 337.5 kB including container (2.060 bpp). ``` (I don't have the patience for e11 but I'm assuming this is one of the things e11 will try)

still not as good as webp, but getting closer

I understand that, as I'm still daily driving an old i5-3570, the `-e 11` took a while. I have my own script with bunch of presets to try and they all include `-E 3`. However it seems that in this case the `-E 3` hurts the compression. Curiously `-e 10 -g 3` also beats `-e 11`.

current release of jxl-oxide (v0.7.2) tries spec method, then libjxl method. the next release will default to libjxl method

Yes, I'm using the older version of jxl-oxide for reference. However because the spec method may perform incorrect decoding without giving an error, I ended up comparing the pixels decoded by djxl and jxl-oxide.

you can give `--lz77-mode std` to force jxl-oxide use the spec method

That's convenient. Thank you!

Nope, e11 would do E4I100 where e10 does E0I50 by default.

As I mentioned above, -e 11 was worse than -e 10 -e 3 in this case.

```vs cjxl_0.10.1_d0e10num_threads0: time size command 35.93% 90.3% cwebp_1.3.2_z9 fastest smaller Pareto front for bpp and real time B bpp Mpx/real_s best of 277232 2.820150 0.4486 R cwebp_1.3.2_z9 290973 2.959930 0.2974 · cjxl_0.10.1_d0e10P14I100g3num_threads0 295241 3.003347 0.3855 · cjxl_0.10.1_d0e10P1I100g3patches0num_threads0 306867 3.121613 0.1612 · cjxl_0.10.1_d0e10num_threads0 315273 3.207123 0.946 R cjxl_0.10.1_d0e10P0I0g3modular_palette_colors10000patches0num_threads0 336085 3.418833 0.6217 · cjxl_0.10.1_d0e9num_threads0 348399 3.544098 1.02 R cjxl_0.10.1_d0e8num_threads0 351864 3.579346 4.12 R cjxl_0.10.1_d0e4num_threads0 357403 3.635691 9.6 R cjxl_0.10.1_d0e3num_threads0 360978 3.672058 2.33 · cjxl_0.10.1_d0e7num_threads0 375853 3.823374 2.88 · cjxl_0.10.1_d0e6num_threads0 382448 3.890462 3.57 · cjxl_0.10.1_d0e5num_threads0 403682 4.106466 15 R cjxl_0.10.1_d0e2num_threads0 554917 5.644908 >8.e+02 R original 877906 8.930522 56 · cjxl_0.10.1_d0e1num_threads0```

```vs cjxl_0.10.1_d0e10num_threads0: time size command 2.0% 93.3% cwebp_1.3.2_z3 fastest smaller 20.2% 90.3% cjxl_0.10.1_d0e10P0I1g3patches0num_threads0 smallest faster Pareto front for bpp and real time B bpp Mpx/real_s best of 74670 2.28874 0.750 R cjxl_0.10.1_d0e10P0I1g3patches0num_threads0 76200 2.33563 6.9 R cwebp_1.3.2_z4 76869 2.35614 0.850 · cjxl_0.10.1_d0e10P0I0g3modular_palette_colors10000patches0num_threads0 77114 2.36365 7.5 R cwebp_1.3.2_z3 82686 2.53444 0.1516 · cjxl_0.10.1_d0e10num_threads0 88556 2.71436 0.709 · cjxl_0.10.1_d0e9num_threads0 91892 2.81661 14 R cwebp_1.3.2_z2 93726 2.87283 1.14 · cjxl_0.10.1_d0e8num_threads0 95686 2.93290 2.7 · cjxl_0.10.1_d0e7num_threads0 96444 2.95614 3.2 · cjxl_0.10.1_d0e6num_threads0 99009 3.03476 3.6 · cjxl_0.10.1_d0e5num_threads0 108358 3.32132 17 R cwebp_1.3.2_z1 116762 3.57891 6.7 · cjxl_0.10.1_d0e4num_threads0 118025 3.61762 11 · cjxl_0.10.1_d0e2num_threads0 133185 4.08230 10 · cjxl_0.10.1_d0e3num_threads0 169133 5.18415 >3.e+02 R original 289226 8.86516 4.e+01 · cjxl_0.10.1_d0e1num_threads0```

```vs cjxl_0.10.1_d0e10num_threads0: time size command 32.95% 88.6% cwebp_1.3.2_z9 fastest smaller Pareto front for bpp and real time B bpp Mpx/real_s| best of 107984 0.416605 0.6732 R cwebp_1.3.2_z9 121893 0.470266 0.2218 · cjxl_0.10.1_d0e10num_threads0 126903 0.489595 0.7846 R cjxl_0.10.1_d0e9num_threads0 129438 0.499375 1.451 R cjxl_0.10.1_d0e8num_threads0 136848 0.527963 6.73 R cwebp_1.3.2_z2 136940 0.528318 3.39 · cjxl_0.10.1_d0e7num_threads0 149070 0.575116 10.8 R cwebp_1.3.2_z1 151186 0.583279 3.80 · cjxl_0.10.1_d0e6num_threads0 158789 0.612612 4.46 · cjxl_0.10.1_d0e5num_threads0 196636 0.758627 >2.e+03 R original 232663 0.897620 4.45 · cjxl_0.10.1_d0e4num_threads0 258082 0.995687 20.5 · cjxl_0.10.1_d0e2num_threads0 294658 1.13680 1.2e+02 · cjxl_0.10.1_d0e1num_threads0 544223 2.09963 11.5 · cjxl_0.10.1_d0e3num_threads0```

```vs cjxl_0.10.1_d0e10num_threads0: time size command 0% 99.8% original fastest smaller 40.57% 68.5% cwebp_1.3.2_z9 smallest faster Pareto front for bpp and real time B bpp Mpx/real_s| best of 385038 1.485486 0.2687 R cwebp_1.3.2_z9 461116 1.778997 16.3 R cwebp_1.3.2_z1 462609 1.784757 0.3747 · cjxl_0.10.1_d0e10P0E3I100modular_palette_colors10000X0Y0patches0num_threads0 533952 2.060000 25 R oxipng_9.0.0_o0a-fast-t1 544620 2.101157 0.3996 · cjxl_0.10.1_d0e10P0I0g3modular_palette_colors10000patches0num_threads0 561137 2.164880 >2.e+03 R original 562038 2.168356 0.10903 · cjxl_0.10.1_d0e10num_threads0 607189 2.342550 0.5896 · cjxl_0.10.1_d0e10P0I100g3patches0num_threads0 716850 2.765625 0.3376 · cjxl_0.10.1_d0e9num_threads0 748680 2.888426 0.6585 · cjxl_0.10.1_d0e8num_threads0 844838 3.259406 1.510 · cjxl_0.10.1_d0e7num_threads0 908058 3.503310 1.832 · cjxl_0.10.1_d0e6num_threads0 941434 3.632076 2.017 · cjxl_0.10.1_d0e5num_threads0 1378507 5.318314 18.2 · cjxl_0.10.1_d0e2num_threads0 1577304 6.085278 3.81 · cjxl_0.10.1_d0e4num_threads0 1672208 6.451420 99 · cjxl_0.10.1_d0e1num_threads0 2405265 9.279572 10.4 · cjxl_0.10.1_d0e3num_threads0```

```vs cjxl_0.10.1_d0e10num_threads0: time size command 1.7% 95.7% cwebp_1.3.2_z1 fastest smaller 19.32% 49.4% cwebp_1.3.2_z9 smallest faster Pareto front for bpp and real time B bpp Mpx/real_s| best of 54982 0.431638 0.8869 R cwebp_1.3.2_z9 68268 0.535940 0.4942 · cjxl_0.10.1_d0e10P0I0g3modular_palette_colors10000num_threads0 71275 0.559546 0.6252 · cjxl_0.10.1_d0e10P0I0g3modular_palette_colors10000patches0num_threads0 106608 0.836929 10 R cwebp_1.3.2_z1 111407 0.874604 0.1714 · cjxl_0.10.1_d0e10num_threads0 122780 0.963888 0.6150 · cjxl_0.10.1_d0e9num_threads0 124962 0.981017 1.34 · cjxl_0.10.1_d0e8num_threads0 129149 1.01389 2.88 · cjxl_0.10.1_d0e7num_threads0 137217 1.07723 3.31 · cjxl_0.10.1_d0e6num_threads0 140479 1.10283 24 R oxipng_9.0.0_o0a-fast-t1 140716 1.10469 3.37 · cjxl_0.10.1_d0e5num_threads0 142737 1.12056 >1.e+03 R original 228643 1.79497 4.19 · cjxl_0.10.1_d0e4num_threads0 265602 2.08512 19 · cjxl_0.10.1_d0e2num_threads0 278514 2.18648 1.0e+02 · cjxl_0.10.1_d0e1num_threads0 358627 2.81541 11 · cjxl_0.10.1_d0e3num_threads0```

```vs cjxl_0.10.1_d0e10num_threads0: time size command 0.52% 97.2% cwebp_1.3.2_z2 fastest smaller 16.20% 26.1% cwebp_1.3.2_z9 smallest faster Pareto front for bpp and real time B bpp Mpx/real_s| best of 32806 0.313131 0.5812 R cwebp_1.3.2_z9 36436 0.347780 17 R cwebp_1.3.2_z6 39239 0.374534 0.3846 · cjxl_0.10.1_d0e10P0I0g3modular_palette_colors10000patches0num_threads0 41308 0.394283 0.4024 · cjxl_0.10.1_d0e10P0I0g3modular_palette_colors10000num_threads0 122070 1.16515 18 R cwebp_1.3.2_z2 125628 1.19911 0.09418 · cjxl_0.10.1_d0e10num_threads0 133392 1.27322 23 R cwebp_1.3.2_z1 133964 1.27868 0.2525 · cjxl_0.10.1_d0e9num_threads0 135427 1.29264 0.882 · cjxl_0.10.1_d0e8num_threads0 197928 1.88921 >8.e+02 R original 479706 4.57877 2.25 · cjxl_0.10.1_d0e7num_threads0 590582 5.63707 2.82 · cjxl_0.10.1_d0e6num_threads0 647840 6.18360 3.37 · cjxl_0.10.1_d0e5num_threads0 1108664 10.5821 3.58 · cjxl_0.10.1_d0e4num_threads0 1127916 10.7659 14 · cjxl_0.10.1_d0e2num_threads0 1255550 11.9842 70 · cjxl_0.10.1_d0e1num_threads0 1500661 14.3237 9.1 · cjxl_0.10.1_d0e3num_threads0```

```vs cjxl_0.10.1_d0e10num_threads0: time size command 1.2% 77.2% cwebp_1.3.2_z6 fastest smaller 27.3% 70.3% cwebp_1.3.2_z9 smallest faster Pareto front for bpp and real time B bpp Mpx/real_s best of 25444 0.426868 0.652 R cwebp_1.3.2_z9 27958 0.469045 14 R cwebp_1.3.2_z6 34300 0.575443 0.2486 · cjxl_0.10.1_d0e10g3num_threads0 34635 0.581063 0.3947 · cjxl_0.10.1_d0e10E3I100g3modular_palette_colors10000Y0num_threads0 36198 0.607285 0.1784 · cjxl_0.10.1_d0e10num_threads0 37813 0.634380 1.04 · cjxl_0.10.1_d0e10P0I0g3modular_palette_colors10000patches0num_threads0 40316 0.676372 0.573 · cjxl_0.10.1_d0e9num_threads0 40978 0.687478 1.42 · cjxl_0.10.1_d0e8num_threads0 44347 0.743999 2.71 · cjxl_0.10.1_d0e7num_threads0 45875 0.769634 3.06 · cjxl_0.10.1_d0e6num_threads0 46451 0.779297 3.14 · cjxl_0.10.1_d0e5num_threads0 71863 1.20563 >5.e+02 R original 76865 1.28955 3.43 · cjxl_0.10.1_d0e4num_threads0 86987 1.45936 7.9 · cjxl_0.10.1_d0e3num_threads0 89760 1.50588 7.e+01 · cjxl_0.10.1_d0e1num_threads0 94018 1.57732 13 · cjxl_0.10.1_d0e2num_threads0```

Since [AllRGB.com](https://AllRGB.com) has been mentioned before, has anyone looked into recreating any of the high-compressed images there using `tree_to_jxl`? I think a # of such images fail to be smaller JxL's via typical `cjxl` than best equivalent PNG or WebP. I _did_ post some JxL winners there, but here's 1 couldn't. _(Reposting from https://discord.com/channels/794206087879852103/824000991891554375/1269696743654686763 since maybe a better fit here?)_

2KiB in JXL, 1KiB in WebP

Lossless? Did you tried with -e 10 -I 100?

I confirm, 960 bytes in webp, 2357 in jxl with -e 10 -I 100. Speed is also incomparable

Damn! 😅

The simpler the image, the better webp lossless is. Jyrky rocked... Perhaps some handcrafted jxl tree could beat webp on this one

```vs cjxl_0.10.1_d0e10num_threads0: time size command 4.81% 33.1% cwebp_1.3.2_z1 fastest smaller 24.5% 28.6% cwebp_1.3.2_z9 smallest faster Pareto front for bpp and real time B bpp Mpx/s real| best of 1114 0.004298 13.0 R cwebp_1.3.2_z1 3362 0.01297 0.6238 · cjxl_0.10.1_d0e10num_threads0 3952 0.01525 1.880 · cjxl_0.10.1_d0e10g3num_threads0 4016 0.01549 41 R cwebp_1.3.2_z8 4100 0.01582 1.732 · cjxl_0.10.1_d0e9num_threads0 4179 0.01612 3.99 · cjxl_0.10.1_d0e4E4g3num_threads0 4649 0.01794 3.34 · cjxl_0.10.1_d0e8num_threads0 6057 0.02337 16.2 · cjxl_0.10.1_d0e2g3num_threads0 6574 0.02536 5.71 · cjxl_0.10.1_d0e7num_threads0 6597 0.02545 5.79 · cjxl_0.10.1_d0e6num_threads0 6705 0.02587 6.15 · cjxl_0.10.1_d0e5g2num_threads0 7074 0.02729 5.99 · cjxl_0.10.1_d0e5num_threads0 7436 0.02869 17.0 · cjxl_0.10.1_d0e2g2num_threads0 9482 0.03658 5.39 · cjxl_0.10.1_d0e4num_threads0 10186 0.03930 1.2e+02 R cjxl_0.10.1_d0e1num_threads0 10616 0.04096 16.7 · cjxl_0.10.1_d0e2num_threads0 12264 0.04731 10.7 · cjxl_0.10.1_d0e3num_threads0```

maybe some AI/ML based jxl tree generator?

That was the idea to eventually add Splines when encoding, instead of heuristics

png 1410 kb Modular, lossless 0.10.3 4a3b22d -e 5 2418 kB -e 7 2382 kB -e 9 1741 kB -e 9 -g 3 1375 kB **webp 667 kb**

what does `-g 3 -e 10 -I 0` do?

and/or `--patches 1`

-g 3 -e 9 -I 0 1143.2 kB -g 3 -e 9 -I 0 --patches 1 219.0 kB <:JXL:805850130203934781>

yeah, thought so 😄

why not here

it also works outside modular mode

Moreover, it is not even explained what it is and how it can affect it.

-g 3 -e 5 -I 1 --patches 1 138.1 kB

Is there something you don't know?

well, the bruteforce will have to go through all the options of the parameters to understand

<:JXL:805850130203934781> 🤙

`cjxl -d 0 a4_blocks.png Test.jxl --patches=1`

Sometimes simplicity is best

-e 2 2933.1 kB -e 3 3423.6 kB -e 4 4570.1 kB

<:monkaMega:809252622900789269>

Seems like even with `--patches=1` they only actually enable at `-e 5` or higher

Interesting, optimizing the PNG into greyscale first increases the filesize of the JXL

-g 3 -e X** -I 0 **--patches 1 -e 1 3337.6 kB -e 2 2933.1 kB -e 3 3423.6 kB -e 4 4570.1 kB -e 5 222.7 kB -e 6 222.7 kB -e 7 222.7 kB -e 8 219.1 kB -e 9 218.9 kB -g 3 -e X** -I 1 **--patches 1 -e 1 3337.6 kB -e 2 2933.1 kB -e 3 3423.6 kB -e 4 2816.3 kB -e 5 137.5 kB -e 6 136.8 kB -e 7 134.7 kB -e 8 131.3 kB -e 9 129.9 kB

-g 3 -e 9 -I 3 --patches 1 125.6 kB

-g 3 -e 10 -I 3 --patches 1 119.4 kB

-g 3 -e 10 -I 50 --patches 1 115.5 kB

Bruteforce has been banned 😢

-g 3 -e 10 -I 100 --patches 1 115.2 kB

-g 2 same size for -i 100

patches is a very powerful coding tool for things like screen content / text, but it's pretty hard to make an encoder that is both fast and does a good job at using patches effectively

also there's lz77 and MA trees that interact in very nontrivial ways with eachother and with patches, making it hard to estimate signaling cost vs compression advantage for candidate patches

14 times stronger than the PNG bruteforce and 6 times stronger than the maximum WEBP parameters

```vs cjxl_0.10.1_d0e10num_threads0: time size command 25.983% 98.1% cjxl_0.10.1_d0e10g3num_threads0 fastest smaller 32.197% 97.1% cjxl_0.10.1_d0e10E3I100g3Y0num_threads0 smallest faster milestone |Pareto front for bpp and real time B bpp Mpx/s real || best of 114716 0.0519077 1.2003 ·R cjxl_0.10.1_d0e10E3I100g3Y0num_threads0 115992 0.0524851 1.4873 ·R cjxl_0.10.1_d0e10g3num_threads0 118184 0.0534769 0.38646 M· cjxl_0.10.1_d0e10num_threads0 1061134 0.480151 52.8 ·R cwebp_1.3.2_z1 1396536 0.631917 3.732 ·· cjxl_0.10.1_d0e8g3num_threads0 1493228 0.675669 56.8 ·R cwebp_1.3.2_z0 1739161 0.786951 2.888 M· cjxl_0.10.1_d0e8num_threads0 1741283 0.787911 0.88440 M· cjxl_0.10.1_d0e9num_threads0 2167844 0.980925 8.566 ·· cjxl_0.10.1_d0e6g3num_threads0 2382253 1.07794 6.498 M· cjxl_0.10.1_d0e7num_threads0 2418038 1.09413 8.779 ·· cjxl_0.10.1_d0e5g3num_threads0 2506287 1.13407 7.385 M· cjxl_0.10.1_d0e6num_threads0 2598040 1.17558 8.106 M· cjxl_0.10.1_d0e5num_threads0 2875491 1.30113 6.735 M· cjxl_0.10.1_d0e4num_threads0 3025268 1.36890 24.7 M· cjxl_0.10.1_d0e2num_threads0 3337662 1.51025 131 MR cjxl_0.10.1_d0e1num_threads0 3575200 1.61774 12.68 M· cjxl_0.10.1_d0e3num_threads0```

lossless e10 fails

<:kekw:808717074305122316>

PNG 414 bytes WEBP 580 bytes JXL 2375 bytes

269 bytes

how

Even 262. Save file as uncompressed png, then just -d 0 -e 10. ~~Without resaving as uncompressed jxl achieves 357 bytes.~~ Disregard that, the cause was in some garbage after the data, so jxl had to use container

Best webp - 340 bytes, and it does not care about compressed or not was png

oh yeah

my bad <:galaxybrain:821831336372338729>

cwebp_1.3.2_z8 gives 328 B. but cwebp refuses to keep the exif. with stripped metadata, cjxl_0.10.1_d0e9 achieves 269 B.

Nice

If source PNG uses palette, cjxl would encode as RGB rather than grayscale. There's EXIF at the end of the file but it seems to be empty.

What does `-g 3` do?

chunk 1024x1024

In this case it was possible not to use it. It saves several bytes of service information on large images. And it can also compress a little better due to the continuity of the chunk

<@226977230121598977> Any ideas w/ this I posted a few months ago?

I had my own project where I recorded all the colors of the image on a RGB cube map. But this your project doesn't look particularly personally interesting

Actually not my project. My personal contribution was just improving the compression ratios, & the image I posted is 1 of my testcases since ~25 years (when original PNG standard was still in development). So far, WebP is best, but Idk why JxL shouldn't beat it. Do you have any insight?

my opinion about webp vs jpeg xl? if you are specifically talking about those pictures, then. well, the pictures are okay

<@226977230121598977> No, I mean specifically this image. (Sorry, I just figured out how to refer directly to the pic.)

Well, it looks powerful. There are no common algorithms for images and programs for a similar image to better compress. But knowing the principles of "Kolmogorov complexity", you can write a program that will generate this image. And it will size much less than Webp. Purely from the point of view of information value, here it is fun test pic, not more

You mean the spline/"vector" concept?

what?

https://en.wikipedia.org/wiki/Kolmogorov_complexity

I thought you meant a JxL tree like https://github.com/wwww-wwww/spline

no. that's not what i was talking about. jpeg xl can create your image with a few dozen bytes of algorithm. it's possible. just like: <#824000991891554375>

But it is unlikely to compress standard compression method, it is not stronger than webp

I think it uses same structures? https://jpegxl.info/old/art/

yes

IIUC, playing around on https://jxl-art.surma.technology/ … will give it a shot.

I think it would be better to ask more specifically about this in the general chat to those who draw such art <#794206170445119489>

Well, it compressed better than the most powerful thing I know, paq8pxd is at hand

ECB Tux: https://commons.wikimedia.org/wiki/File:Tux_encrypted_ecb.png `pngcrush` gets it to 637.1 kB, `cjxl -d 0 -e 10` (commit `445e90984346b632ab3d039e1a3f790b5ade5b0f`, from 2025-10-31) gets it to 852.3 kB

weirdly, my build is denser ```vs cjxl_0.12.0_445e9098_d0e10num_threads0: time size command 0.13% 94.3% cwebp_1.3.2_z0 fastest smaller 0.59% 74.6% cwebp_1.3.2_z7 smallest faster Pareto front for bpp and real time B bpp Mpx/s real | best of 549196 4.965965 13 R cwebp_1.3.2_z7 600180 5.426975 44 R cwebp_1.3.2_z1 635867 5.749665 0.2183 · ect_0.9.5_8 637513 5.764549 18 · ect_0.9.5_1 645521 5.836959 9.e+02 R original 694808 6.282624 59 · cwebp_1.3.2_z0 718809 6.499647 0.029542 · cjxl_0.12.0_445e9098_d0e10E3I100g3num_threads0 736669 6.661142 0.076820 · cjxl_0.12.0_445e9098_d0e10num_threads0 780953 7.061569 1.36 · cjxl_0.12.0_445e9098_d0e7num_threads0 783092 7.080910 0.2965 · cjxl_0.12.0_445e9098_d0e9num_threads0 784228 7.091182 0.6482 · cjxl_0.12.0_445e9098_d0e8num_threads0 789166 7.135833 1.76 · cjxl_0.12.0_445e9098_d0e6num_threads0 827357 7.481165 2.01 · cjxl_0.12.0_445e9098_d0e5num_threads0 875633 7.917688 2.71 · cjxl_0.12.0_445e9098_d0e4num_threads0 928620 8.396810 80 · cjxl_0.12.0_445e9098_d0e1num_threads0 1016827 9.194399 8.12 · cjxl_0.12.0_445e9098_d0e3num_threads0 1062936 9.611328 14 · cjxl_0.12.0_445e9098_d0e2num_threads0```

ah, my bad! I was reusing a command from my bash history, and I didn't notice I had progressive mode on because I had set that before the file names., with all the other options after the file names. now without it I get the same 736669 B