JPEG XL

Yes clearly you need to have a large block size.

But still it's kinda unexpected. It gets significant savings compared to JXL

Compress multiple jxl with 7zip

jpeg coding is comparably much simpler than jxl, and it is easier to group images so that similarly coded images are near each other

I'm less sure if solid compression with jxl will give a better result, I bet not

Hmm... Come to think of it the 7z contained variants of similar images.

Theoretically we could do multi-frame jxl to store similar images more effectively.

Too bad there isn't multi page like TIFF...

We can just define the max frame duration to mean 'pagebreak after this frame'.

Let's have patience with Dominik

well **benchmarks:** avif speed 5 - 200+ min jpeg xl e 5 - 21 min avif speed 10 - 14 min jpeg xl e 3 - 6 min webp - 4 min jpeg xl e 1 - 4 min jpegXr - 3 min jpeg - 2 min

to compress my 2000 images of all various and sizes

JPEG XL QUALITY d 0.823 s8

Good

Better than AV2

At least AV2 at cpu 3 is good and not too slow

It received an inportant speed update this night

https://gitlab.com/AOMediaCodec/avm/-/merge_requests/568/diffs?commit_id=cb9a9b283a56452e218866ad4a5b04f10cc7f794

I've been setting min qp 41 max 88

Is it not good at d 0.824?

I used comparable settings

non-integer preview with nearest neighbor <:NotLikeThis:805132742819053610>

``` Before, NEON: 42.940 MP/s 11.895 bits/pixel After, NEON: 48.943 MP/s 11.895 bits/pixel ``` now I feel silly for having ever trusted the autovectorizer xD

is `-mavx2` removed for lodepng only for compatibility or because it had no effect on performance?

it shouldn't have a significant effect - and for sure it didn't for the main fast-lossless lib 😛

```Single-threaded: fjxl 0 gcc 12.2.0 124.659 MP/s 9.987 bits/pixel fjxl 0 clang 15.0.5 166.137 MP/s 9.987 bits/pixel fjxl 1 gcc 12.2.0 125.233 MP/s 9.381 bits/pixel fjxl 1 clang 15.0.5 165.411 MP/s 9.381 bits/pixel fjxl 2 gcc 12.2.0 124.155 MP/s 9.381 bits/pixel fjxl 2 clang 15.0.5 165.838 MP/s 9.381 bits/pixel```

```8-threads: fjxl 0 gcc 12.2.0 428.648 MP/s 9.987 bits/pixel fjxl 0 clang 15.0.5 549.657 MP/s 9.987 bits/pixel fjxl 1 gcc 12.2.0 429.265 MP/s 9.381 bits/pixel fjxl 1 clang 15.0.5 540.739 MP/s 9.381 bits/pixel fjxl 2 gcc 12.2.0 411.817 MP/s 9.381 bits/pixel fjxl 2 clang 15.0.5 540.254 MP/s 9.381 bits/pixel```

nice speedup with gcc 😄 what's the CPU?

haswell gen or something like that

```Single-threaded: fjxl 0 gcc 12.2.0 157.706 MP/s 9.987 bits/pixel fjxl 0 clang 15.0.5 169.076 MP/s 9.987 bits/pixel fjxl 1 gcc 12.2.0 165.931 MP/s 9.381 bits/pixel fjxl 1 clang 15.0.5 170.519 MP/s 9.381 bits/pixel fjxl 2 gcc 12.2.0 163.878 MP/s 9.381 bits/pixel fjxl 2 clang 15.0.5 170.593 MP/s 9.381 bits/pixel```

```8-threads: fjxl 0 gcc 12.2.0 544.475 MP/s 9.987 bits/pixel fjxl 0 clang 15.0.5 554.431 MP/s 9.987 bits/pixel fjxl 1 gcc 12.2.0 537.857 MP/s 9.381 bits/pixel fjxl 1 clang 15.0.5 554.869 MP/s 9.381 bits/pixel fjxl 2 gcc 12.2.0 523.112 MP/s 9.381 bits/pixel fjxl 2 clang 15.0.5 545.603 MP/s 9.381 bits/pixel```

yup, as I thought, gcc's autovec was even worse than clang's 😛

some strange slowdown on 8-threads with effort 2, which is not repeatable on other images, gcc is the non per-channel version (and I noticed on low-color images even with gcc it can be faster) ```Single-threaded: fjxl 0 gcc 12.2.0 276.277 MP/s 3.620 bits/pixel fjxl 0 clang 15.0.5 269.002 MP/s 3.621 bits/pixel - fjxl 1 gcc 12.2.0 265.076 MP/s 3.683 bits/pixel fjxl 1 clang 15.0.5 281.107 MP/s 3.569 bits/pixel - fjxl 2 gcc 12.2.0 217.439 MP/s 3.572 bits/pixel fjxl 2 clang 15.0.5 217.790 MP/s 3.569 bits/pixel ----------------------- 8-threads: fjxl 0 gcc 12.2.0 839.034 MP/s 3.620 bits/pixel fjxl 0 clang 15.0.5 766.142 MP/s 3.621 bits/pixel - fjxl 1 gcc 12.2.0 841.951 MP/s 3.683 bits/pixel fjxl 1 clang 15.0.5 803.115 MP/s 3.569 bits/pixel - fjxl 2 gcc 12.2.0 462.759 MP/s 3.572 bits/pixel fjxl 2 clang 15.0.5 459.385 MP/s 3.569 bits/pixel```

Could be the palette detection

Yeah could be

Nice gcc improvement

```Single-threaded: fjxl 0 gcc 12.2.0 151.658 MP/s 9.831 bits/pixel fjxl 0 clang 15.0.5 154.896 MP/s 9.831 bits/pixel - fjxl 1 gcc 12.2.0 153.658 MP/s 9.358 bits/pixel fjxl 1 clang 15.0.5 156.887 MP/s 9.358 bits/pixel - fjxl 2 gcc 12.2.0 148.912 MP/s 9.358 bits/pixel fjxl 2 clang 15.0.5 155.039 MP/s 9.358 bits/pixel```

```8-threads: fjxl 0 gcc 12.2.0 454.044 MP/s 9.831 bits/pixel fjxl 0 clang 15.0.5 451.709 MP/s 9.831 bits/pixel - fjxl 1 gcc 12.2.0 450.117 MP/s 9.358 bits/pixel fjxl 1 clang 15.0.5 466.001 MP/s 9.358 bits/pixel - fjxl 2 gcc 12.2.0 439.819 MP/s 9.358 bits/pixel fjxl 2 clang 15.0.5 457.029 MP/s 9.358 bits/pixel```

thanks but I just updated the PR xD

should recover a little bit of speed

<:Poggers:805392625934663710> but it seems that the memory consumption also has become noticeably higher

uhhhh, how so? by how much?

that ought not to happen...

though I haven't really made a comparison, just a feeling

maybe something has changed in my system since then

on some big images, I think it's mostly palette images, before it was like 50-60% free memory when encoding, and now it's something like 5-10%

updated

Memory use should be mostly just the size of the input buffer plus the size of the compressed output file plus something proportional to the number of threads used.

btw since you're doing these benchmarks, it could be really useful if you also generated some flame graphs - I know what's faster on *my* system(s), but not on yours 🙂

It would also be nice to have updated pareto front plots, with webp/libpng/lodepng/qoi/whatever

Speed on one axis, density on another, for some kind of corpus

(perhaps more clarifying is to do one photo corpus and one nonphoto corpus)

(since both speed and compression tend to behave very differently for photo vs nonphoto)

generating flame graphs would be more difficult because I use windows and I do these tests on a remote server system, so this is just very basic and not very accurate comparisons yeah, having updated plots would be nice also maybe someone will try these benchmarks on their system and with clang (because they don't compile under windows) <https://github.com/nigeltao/qoir>

ah I see no idea how to do flame graphs on windows

oh well

also it is an old xeon cpu, so I don't think it is very useful

I'm still trying to figure out how to update these benchmarks, it seems like the new fast_lossless changes have broken some things...

uh that's not great

quite possible, perhaps because this benchmark is more deeply integrated

It seems the easiest way to make them run is to replace the fast_lossless "adapter" with one that just calls the regular encoder with effort 1

Or, maybe it's easier because I don't have too much experience with C++ code, so I don't know how to adapt the current fast-lossless adapter code to the new fast lossless encode APIs...

can you point me to the code? I'll send you a PR 🙂

holy speed

cjxl -e 1 q 100 same speed than optipng -o0 but size 25% less

also +qoir and zpng, because when I compared, zpng encoding is not as fast as fjxl, with 4-5% worse compression and qoir is not faster than fjxl with 15% worse compression but what they are really good at is decoding speed

isn't optipng absurdly slow?

? its option -o0 is faster png

oh i didnt see the -o0 when i first read it

Isn't optipng -o0 basically just libpng with some heuristic choice of parameters?

if you use optipng with exhaustive parameter search it is, but 99% of the time you can just use `optipng -zc9 -zm8 -zs1 -f5` and get the best results or very close to

it still does palette reduction and de-alpha-ing and all that stuff

Yes, which is why people use ECT instead.

ECT is windows only

and closed-source

iirc

unless I'm thinking of a different tool

No, ECT is open source and available on all platforms: https://github.com/fhanau/Efficient-Compression-Tool

then which one am I thinking of lol

pingo?

maybe?

but with optipng I just force specific zlib settings

~~actually what I do is I use -zc1 -zm0 -zs1 -f5 and then recompress it with zopfli

I wrote a script to recompress idat chunks with zopfli and pass others through

yeah, pingo is windows only and closed source (even though most likely based on ect) https://css-ig.net/benchmark/png-lossless

I know it violates some licenses, we found it earlier

🥱 png 🥱

PNG <:5_chad:862625638238257183>

"even though most likely based on ect" -> is it even likely? to my knowledge an image that went through ECT can be further compressed by pingo and vice versa (but only by an inch), and the parameter space of ECT seems tight enough---this holds true even after trying all parameters with ECT successively.

yes, judging from some old discussions pingo was based on ect, but with various changes and improvements since then, on older versions or for other formats the results and speed were very similar (with minor changes) though ect is also a collection of multiple codecs and optimizers (also with plenty of additional improvements), but it is open-source and does not claim to be some unique optimizer written from scratch but now it's unknown how many changes and how much own code has pingo, no doubt it has some even further improvements, but anyway, given the closed source there is no mention of authorship anywhere (at least it still uses mozjpeg, libwebp, zopfli and others)

or wavif <https://css-ig.net/wavif>, I doubt it is an av1/avif encoder written from scratch (most likely libavif+libaom with some changes)

it's got libaom in it according to `strings`

yeah, I don't doubt pingo has big license issues, just that I'm not sure if it is based on ECT's changes to those libraries specifically.

also according to the website

ah, they added that disclaimer

it wasn't there when we checked before

hmm, yeah

about ect, it has some unique optimizations, also for mozjpeg, which pingo also added, it may not be a complete copy, but at least pingo took many tricks from ect as well

I didn't understand what it even after reading. but the saddest thing is that it doesn't work. more precisely, it determines that a file with the same name is already in the folder, but if you just start compressing the image - does not save the output file lol

and with other pngs or images with different names? or `wavif *.png` with png in the same folder?

Wha I just want to compress one picture

I mean maybe it's a locked file or file name or something, for me wavif works fine

meh

I just compressed a PNG image with cjxl -e 1, and got 281k

rebuilt from master, tried again, 219k

it was also much faster

451 MP/s compared to 19.58 MP/s

although that's likely because fjxl just replaced -e 1 and I wasn't using fjxl before

the original PNG is 123k but that's because it's zopflipnged, so a fair comparison there is cjxl -e 9, which was 108k

although I bet a fair amount could be saved by using RLE

the image in question is a screenshot of a website so there's a lot of redundancy

yeah, now fjxl and -e 1 should have the same speed and results, but it looks like I found some differences

eeeeh not bad 😄

<:monkaMega:809252622900789269> https://github.com/libjxl/libjxl/pull/2028

something like bruteforcing everything?

pretty much

does it also try jpeg recompression vs pixels

`kGlacier = 0` so it's the opposite to --effort, for that reason -e 0 is not very convenient to add?

there is no real reason why -e 0 wouldn't be convenient to add

it's more common as in other encoders (cwebp, avifenc, aom, svt, ...), also it is reversed and shifted compared to the SpeedTier [0-9] `"Encode effort has to be in [1..10]");` ``` SpeedTier kGlacier = 0, kTortoise = 1, kKitten = 2, kSquirrel = 3, kWombat = 4, kHare = 5, kCheetah = 6, kFalcon = 7, kThunder = 8, kLightning = 9```

”effort” used to be called ”speed” in cjxl before 0.5 I think

It was a bit counter intuitive since larger speed value actually meant slower encoding

We had --speed 3 equal to falcon and --speed 9 equal to tortoise, so larger value meant slower / more effort

So we renamed to --effort since that made more sense

Libaom has cpu-used where larger values mean faster / less effort / less "cpu used", which also doesn't make sense but in the other way

We assumed eventually we may want to have an effort setting that goes from 0 to 11

Adding -e 11 might be a bit tricky, is SpeedTier a signed or unsigned type?

reversed is ok, but the shift creates even more confusion, also I mean that 0 is quite common for encoders, not only for libs ` -z <int> ............... activates lossless preset with given level in [0:fast, ..., 9:slowest]` `--cpu-used=<arg> Speed setting (0..6 in good mode, 6..9 in realtime mode)` ` -s,--speed S : Encoder speed (0-10, slowest-fastest, 'default' or 'd' for codec internal defaults. default speed: 6)`

and `SpeedTier [0-9]` vs `effort [1..10]`

I suppose we could at some point split current e1 into e0 and e1

```Doesn't really matter because this code never actually gets executed as of now :)``` -e 10 doesn't work yet? it would be good to know what parameters were used for best compression (jxlinfo I suppose only for some basic info) theoretically it would even be able to estimate the parameters and various combinations value in terms of speed and efficiency with machine learning, like is being done for some video encoders <:KekDog:805390049033191445> though it's complicated, especially if the encoder hasn't reached some optimization limits

<:monkaMega:809252622900789269> holy

-e 10 does work, but that code doesn't get executed because e10 just does e9 with various settings, so in that part of the code, the max actual effort is 9

it's sloooow

like, 12 minutes for 256x256 kind of slow

for those that don't want to do the math, it's ~100 pixels/second

In terms of efficiency, will this be the most powerful lossless image compression ever?

hard to say, probably things like LEA/EMMA can still do better

Now this is true guetzli mode <:KekDog:805390049033191445>

NOW optipng -o7 -zm1-9 in jpeg xl <:KekDog:805390049033191445>

Effort 10 is still not quite exhaustive, but I don't think really exhaustive jxl is feasible to do within, say, the expected lifetime of the earth

need release -e10 for cuda for mining now

it doesn't look like that PR actually creates -e10

it just makes it exist and defaults it to e9

oh I missed enc_frame.cc nvm

Considering how AI is misused to do silly stuff these days, could AI perform the perfect lossless encoding? I wouldn't trust AI to do lossy, but nothing should go wrong with lossless.

you'd think... I have been trying 😛

I know, right? JXL is very expressive, AI could take the full advantage of JXL's features.

Maybe some kind of hybrid approach where AI produces candidate nodes for an MA tree and a classical algorithm uses that to construct a tree, i.e. heavily pruning the search space using AI...

Using AI directly to produce a good tree could work too, but it feels like a somewhat weirdly shaped search space, perhaps not sufficiently smooth for AI to work well

I thought it would be more like searching for the optimal tuning of the encoder. Also it could use patches more extensively.

Can't wait to read all the marketing speak about the new AI powered JXL encoder

The question is, if it would be practical for general use.

early versions of libaom had a small neural network in part of the rate control algorithm iirc

if jpeg-xl saw adoption, we would probably (eventually) see some way of using an FPGA for encode that would just brute-force some massively parallel MA tree searches

Also I was speaking strictly about lossless compression, where the failure would be only suboptimal compression. Having a lossy encoder with unpredictable results is imo bad idea.

It still does for calculating mini GOP size. The problem is that it works for lossy, not lossless.

libopus uses a neural network apparently to switch between SILK and CELT

Stockfish uses a neural network in the evaluation function to help judge the favorability of a chess position

I'm sure neural networks can be useful for at least a small subset of the tasks involved in lossy coding.

After all lossy compression uses a lot of the same techniques as lossless

Such an entropy coding

the stockfish approach isn’t particularly helpful, as we already have very good algorithms for classically determining various metrics for determining loss. if we’re going to allude to chess, the standard approach for this sort of thing (have some end goal, many possible choices at each step, want to execute a search that tells you what a good next step is) in industry is very similar to alphazero/lc0/etc: MCTS + some neural network that provides policy priors to your MCTS algorithm

gets used in everything from vehicle path planning (which I found neat) to Go. it does really well even when the search space is very strange. the problem is that training is far from trivial (the katago tricks aren’t likely to help that much either), parallelizing MCTS is extremely annoying, and the compute cost is probably insane even at inference time

very visible blocking in red (enc-dec-jpegli-bd16 compared to mozjpeg) <https://unsplash.com/photos/eLHsbiCipc8> resized from the original size to 1920x2688 jpegli jpeg q80 + png (with jpegli-bd16-dec)

mozjpeg

q91 (better)

mozjpeg

q80 jpegli - mozjpeg

in particular here

you also get blockiness here

corresponding mozjpeg

and something is broken for this random manga cover ```Encoding kPixels Bytes BPP Max norm SSIMULACRA2 pnorm ------------------------------------------------------------------------------------------------------------- jpeg:enc-jpegli:q80:dec-jpegli:bd16 2219 490732 1.7688817 89.95503998 12.64377208 16.13637347 jpeg:enc-jpegli:q81:dec-jpegli:bd16 2219 502626 1.8117545 90.36291504 8.12862842 16.65479380 jpeg:enc-jpegli:q82:dec-jpegli:bd16 2219 520392 1.8757935 90.37894440 9.47885354 16.42418035 jpeg:enc-jpegli:q83:dec-jpegli:bd16 2219 540914 1.9497666 91.79074860 6.58171330 17.35863986 jpeg:enc-jpegli:q84:dec-jpegli:bd16 2219 555072 2.0008002 90.26593781 3.75515449 17.10367704 jpeg:enc-jpegli:q85:dec-jpegli:bd16 2219 571453 2.0598468 97.88761139 2.36206109 18.28821461 jpeg:enc-jpegli:q86:dec-jpegli:bd16 2219 600188 2.1634243 87.28949738 -2.93264907 17.95547487 jpeg:enc-jpegli:q87:dec-jpegli:bd16 2219 628512 2.2655204 102.27484131 -10.71859464 20.35412859 jpeg:enc-jpegli:q88:dec-jpegli:bd16 2219 656425 2.3661350 102.30054474 -2.64473454 20.03825618 jpeg:enc-jpegli:q89:dec-jpegli:bd16 2219 685623 2.4713815 102.17871857 -9.81744339 20.38091220 jpeg:enc-jpegli:q90:dec-jpegli:bd16 2219 713075 2.5703343 98.04635620 -12.78606165 20.04473534 jpeg:enc-jpegli:q91:dec-jpegli:bd16 2219 734233 2.6466000 98.00187683 -6.78548521 18.76490758 jpeg:enc-jpegli:q92:dec-jpegli:bd16 2219 782309 2.8198937 107.66781616 4.49950387 19.49597085```

seems to be a decoder for non-xyb jpegli

```Encoding kPixels Bytes BPP Max norm SSIMULACRA2 pnorm ----------------------------------------------------------------------------------------------------------------- jpeg:q83 2219 610022 2.1988718 2.79324722 86.21449334 0.83514355 jpeg:q83:dec-jpegli 2219 610022 2.1988718 77.86694336 29.41114753 13.35322977 jpeg:q83:dec-jpegli:bd16 2219 610022 2.1988718 77.86669922 29.42202507 13.35255489 jpeg:enc-jpegli:q88 2219 656425 2.3661350 1.60545588 84.36873286 0.57766172 jpeg:enc-jpegli:q88:dec-jpegli 2219 656425 2.3661350 102.29298401 -2.65251884 20.03833136 jpeg:enc-jpegli:q88:dec-jpegli:bd16 2219 656425 2.3661350 102.30054474 -2.64473454 20.03825618 jpeg:enc-jpegli:xyb:q93 2219 678863 2.4470145 1.44632685 84.90054819 0.50148861 jpeg:enc-jpegli:xyb:q93:dec-jpegli 2219 678863 2.4470145 1.50155556 84.68694477 0.50180967 jpeg:enc-jpegli:xyb:q93:dec-jpegli:bd16 2219 678863 2.4470145 1.44506371 85.08306567 0.48657300 jxl:q96:3 2219 507761 1.8302640 1.56963921 88.14221072 0.59136184 jxl:q96:4 2219 511876 1.8450969 1.57371497 88.68837783 0.58998264 jxl:q96:5 2219 464771 1.6753032 1.45894945 87.44297991 0.54723276 jxl:q96:6 2219 468528 1.6888456 1.26435709 87.60899208 0.53606737```

that's really bad. also this is a really good codec testing image because of all of the different shades of red.

Any image that has lots of fine details in red shaded areas with a lot of detailed bright and dark areas makes a great codec stress test

jpeg xl compresses 1-bit images better than 1-bit BMP + paq8px 👏

some more fjxl benchmarks using my own artworks. not a fair comparison since all the PNGs were encoded with libpng compression level 8, but pretty amazing that fjxl aced it most of the time~

how about trying fast_lossless instead of cjxl -e 1 on these images? -e 1 does not identify palette images as fast_lossless for png

<https://github.com/libjxl/libjxl/pull/2076> still buggy dec-jpegli, but `disable adaptive quantization` has better metrics scores, although visually I see more artifacts ```Encoding kPixels Bytes Max norm SSIMULACRA2 pnorm BPP*pnorm ------------------------------------------------------------------------------------------------ jpeg:enc-jpegli:q88 2219 656425 1.60545588 84.36873286 0.57766172 1.366825617010 jpeg:enc-jpegli:q88:noaq 2219 630827 1.55808163 89.06986108 0.55069406 1.252203945743```

A follow up to this. When compressing multiple JPEGs (variants of the same image with edits, saved with the same encoder and encode settings) LZMA2 with a large block size compresses the images more effectively when they are in JPEG format compared to losslessly transforming them to JXL first before archiving with LZMA2 (3 files, 2 threads). So there must be less entropy or more correlation in the files in JPEG format compared to after they are losslessly transformed than JXL. The archive size is larger.

It's surprising that such a generic archiving tool is so effective at reducing the size of JPEG

Well JPEG encodes blocks independently, so if there are repeated blocks then if the huffman and quant tables are the same and you're lucky with byte alignment, the compressed bitstream will be identical in some regions, which will be good for general-purpose compressors.

Likely if you do more restarts in jpeg (which makes the files larger), the total compressed archive size will be even smaller.

(since byte alignment will be better)

If it's so independent then why does an error cause the rest of the image to look funky until the end?

Because alignment will get messed up, and it's still sharing a single huffman stream

I took a look at the dataset described in https://ds.jpeg.org/documents/jpegaic/wg1n100334-097-ICQ-JPEG_AIC_CTC_for_subjective_quality_assessment.pdf, where they estimated JNDs for images compressed with JPEG, J2K, JXL, HEIC and VVC. Looking at the average curves linking metric scores to JNDs, I see the following biases in metrics: PSNR (either PSNR-Y or ImageMagick’s default PSNR): overestimates HEIC, VVC, J2K. Underestimates JXL and JPEG. Butteraugli: overestimates HEIC and JXL. Underestimates JPEG. (more or less neutral to VVC and J2K) SSIMULACRA2: overestimates HEIC. Underestimates JPEG. (more or less neutral to the rest: VVC, J2K, JXL) PSNR-HVS: overestimates HEIC. Underestimates JXL and JPEG. (more or less neutral to VVC and J2K) MS-SSIM: overestimates HEIC. Underestimates JPEG. (more or less neutral to the rest) VMAF: overestimates J2K at all qualities, HEIC at higher qualities and JPEG at lower qualities. Underestimates JXL at all qualities, and VVC, HEIC at lower qualities and JPEG at higher qualities. DSSIM: overestimates HEIC and VVC. Underestimates JPEG, JXL at lower qualities and J2K at higher qualities.

Interestingly, basically all metrics are giving HEIC higher scores than they should, and many metrics are underestimating JPEG and JXL.

the above is without image 4, for which I think the JND results are messed up

``` metric | Kendall | Spearman | Pearson PSNR | 0.41334 | 0.56043 | 0.57799 Butteraugli max-norm | -0.5760 | -0.7387 | -0.7025 Butteraugli 3-norm | -0.6338 | -0.8076 | -0.7950 SSIMULACRA 2 | 0.74869 | 0.90119 | 0.88999 PSNR-HVS | 0.66028 | 0.83201 | 0.82635 SSIM | 0.37014 | 0.50133 | 0.36463 MS-SSIM | 0.67328 | 0.84114 | 0.80623 VMAF | 0.67723 | 0.84157 | 0.81652 DSSIM | -0.7025 | -0.8660 | -0.8218 ```

looks like a good validation for ssimulacra2

sadly the jpegli-decoder is still broken, looks like some incorrectly decoded 8x8 blocks (even for some xyb encodings) <https://unsplash.com/photos/zHcI7_TA5Yg>

```Encoding kPixels Bytes BPP Max norm SSIMULACRA2 pnorm -------------------------------------------------------------------------------------------------------- jpeg:enc-jpegli:q77:dec-jpegli:bd16 4270 506467 0.9487932 136.28828430 -19.66365224 28.69669831 jpeg:enc-jpegli:q78:dec-jpegli:bd16 4270 517770 0.9699678 136.17242432 -19.65461055 28.69878841 jpeg:enc-jpegli:q79:dec-jpegli:bd16 4270 539942 1.0115038 136.35876465 -19.51233277 28.69276517 jpeg:enc-jpegli:q80:dec-jpegli:bd16 4270 558322 1.0459361 136.31909180 -18.50234908 29.04873686 jpeg:enc-jpegli:q81:dec-jpegli:bd16 4270 584871 1.0956718 135.07215881 -13.64525888 27.86054494 jpeg:enc-jpegli:q82:dec-jpegli:bd16 4270 605818 1.1349130 135.13157654 -13.09396603 27.83956163 jpeg:enc-jpegli:q83:dec-jpegli:bd16 4270 626056 1.1728260 135.04438782 -14.04418433 27.88352163 jpeg:enc-jpegli:q84:dec-jpegli:bd16 4270 658955 1.2344576 135.62678528 -17.32125784 28.63664983 jpeg:enc-jpegli:q85:dec-jpegli:bd16 4270 676199 1.2667617 135.75309753 -17.21376382 28.63755474 jpeg:enc-jpegli:q86:dec-jpegli:bd16 4270 727943 1.3636967 135.72795105 -22.43448568 28.95907792 jpeg:enc-jpegli:q87:dec-jpegli:bd16 4270 750174 1.4053433 131.95985413 4.48420770 24.67779789 jpeg:enc-jpegli:q88:dec-jpegli:bd16 4270 797480 1.4939643 156.63969421 -5.87667081 27.41512382 jpeg:enc-jpegli:q89:dec-jpegli:bd16 4270 833215 1.5609087 156.64601135 -8.21494064 27.60544189 jpeg:enc-jpegli:q90:dec-jpegli:bd16 4270 858588 1.6084413 134.41885376 -0.62536848 25.45361695 jpeg:enc-jpegli:q91:dec-jpegli:bd16 4270 915529 1.7151121 158.59341431 -11.43010326 29.72990926 jpeg:enc-jpegli:q92:dec-jpegli:bd16 4270 990559 1.8556701 158.30972290 -14.02209638 29.97293925 jpeg:enc-jpegli:q93:dec-jpegli:bd16 4270 1028262 1.9263012 159.12585449 -4.53117767 28.32048932```

```Encoding kPixels Bytes BPP Max norm SSIMULACRA2 pnorm ------------------------------------------------------------------------------------------------------ jpeg:enc-jpegli:q77:xyb:dec-jpegli 4270 440755 0.8256912 2.57653522 73.83731587 1.08323953 jpeg:enc-jpegli:q78:xyb:dec-jpegli 4270 448209 0.8396552 2.46053791 74.12077303 1.07571795 jpeg:enc-jpegli:q79:xyb:dec-jpegli 4270 469636 0.8797956 2.31674862 75.04041524 1.02801235 jpeg:enc-jpegli:q80:xyb:dec-jpegli 4270 481438 0.9019050 2.27511597 75.40451765 1.00002946 jpeg:enc-jpegli:q81:xyb:dec-jpegli 4270 511347 0.9579352 2.22766042 76.61113140 0.94573886 jpeg:enc-jpegli:q82:xyb:dec-jpegli 4270 520716 0.9754867 2.11857700 77.09132426 0.94801233 jpeg:enc-jpegli:q83:xyb:dec-jpegli 4270 546882 1.0245049 2.13817835 78.24623401 0.90216890 jpeg:enc-jpegli:q84:xyb:dec-jpegli 4270 573754 1.0748457 2.13797522 78.86015560 0.87542524 jpeg:enc-jpegli:q85:xyb:dec-jpegli 4270 593800 1.1123990 1.99826527 79.57994231 0.82144321 jpeg:enc-jpegli:q86:xyb:dec-jpegli 4270 626401 1.1734723 1.80742538 80.06207563 0.78408051 jpeg:enc-jpegli:q87:xyb:dec-jpegli 4270 665462 1.2466475 1.79822123 81.04907356 0.73527516 jpeg:enc-jpegli:q88:xyb:dec-jpegli 4270 686695 1.2864245 1.62478518 81.31783304 0.70662563 jpeg:enc-jpegli:q89:xyb:dec-jpegli 4270 734165 1.3753527 1.70427763 82.28476303 0.81580474 jpeg:enc-jpegli:q90:xyb:dec-jpegli 4270 778534 1.4584717 1.46675730 82.80288597 0.62502899 jpeg:enc-jpegli:q91:xyb:dec-jpegli 4270 830618 1.5560436 1.73360562 83.61609663 0.86297484 jpeg:enc-jpegli:q92:xyb:dec-jpegli 4270 891308 1.6697376 1.56471860 84.36080824 0.71326347 jpeg:enc-jpegli:q93:xyb:dec-jpegli 4270 959696 1.7978527 1.55117285 84.59052930 0.70106243```

<https://unsplash.com/photos/7Aj3WuHOgtM>

xyb

```Encoding kPixels Bytes BPP Max norm SSIMULACRA2 pnorm ---------------------------------------------------------------------------------------------------- jpeg:enc-jpegli:q77:dec-jpegli 5532 486612 0.7036439 133.04379272 -14.49615687 22.28802677 jpeg:enc-jpegli:q78:dec-jpegli 5532 501600 0.7253167 133.05514526 -12.27793198 22.24198255 jpeg:enc-jpegli:q79:dec-jpegli 5532 514678 0.7442275 135.58435059 -19.15237382 23.69608168 jpeg:enc-jpegli:q80:dec-jpegli 5532 529287 0.7653522 135.58409119 -16.72918914 22.48391403 jpeg:enc-jpegli:q81:dec-jpegli 5532 549683 0.7948450 127.24156189 -2.72853989 20.07771740 jpeg:enc-jpegli:q82:dec-jpegli 5532 568713 0.8223625 127.27835083 -4.17448154 20.07561954 jpeg:enc-jpegli:q83:dec-jpegli 5532 591524 0.8553473 125.41096497 -5.51799462 19.81012298 jpeg:enc-jpegli:q84:dec-jpegli 5532 611947 0.8848791 125.40847015 -7.13729803 20.03092070 jpeg:enc-jpegli:q85:dec-jpegli 5532 643516 0.9305281 137.93171692 -11.79842853 22.90897979 jpeg:enc-jpegli:q86:dec-jpegli 5532 669916 0.9687026 137.95727539 -15.22964194 22.74869022 jpeg:enc-jpegli:q87:dec-jpegli 5532 714181 1.0327101 68.47742462 -9.79819919 13.67024590 jpeg:enc-jpegli:q88:dec-jpegli 5532 745805 1.0784386 68.33783722 -19.76422160 13.83092302 jpeg:enc-jpegli:q89:dec-jpegli 5532 799633 1.1562742 73.66311646 -18.14493015 12.63958809 jpeg:enc-jpegli:q90:dec-jpegli 5532 812859 1.1753991 66.94897461 -19.09748908 12.06024470 jpeg:enc-jpegli:q91:dec-jpegli 5532 881885 1.2752111 107.37985992 -18.71724947 16.67591801 jpeg:enc-jpegli:q92:dec-jpegli 5532 956604 1.3832552 107.28179169 -16.90508134 16.83103876 jpeg:enc-jpegli:q93:dec-jpegli 5532 1031530 1.4915987 78.80941772 -22.08231051 14.14055037```

```Encoding kPixels Bytes BPP Max norm SSIMULACRA2 pnorm ------------------------------------------------------------------------------------------------------ jpeg:enc-jpegli:q77:xyb:dec-jpegli 5532 435254 0.6293800 9.88808060 67.96276485 1.91975512 jpeg:enc-jpegli:q78:xyb:dec-jpegli 5532 445074 0.6435797 9.54435825 68.38660486 1.86519500 jpeg:enc-jpegli:q79:xyb:dec-jpegli 5532 460681 0.6661476 9.59946251 68.92551213 1.86795871 jpeg:enc-jpegli:q80:xyb:dec-jpegli 5532 472928 0.6838568 2.48481417 70.67981377 1.04270666 jpeg:enc-jpegli:q81:xyb:dec-jpegli 5532 492416 0.7120366 6.40297413 70.70687798 1.35580168 jpeg:enc-jpegli:q82:xyb:dec-jpegli 5532 512724 0.7414020 6.45031261 71.31698220 1.34709810 jpeg:enc-jpegli:q83:xyb:dec-jpegli 5532 530277 0.7667838 10.81851101 70.26461499 1.90298127 jpeg:enc-jpegli:q84:xyb:dec-jpegli 5532 549742 0.7949303 11.13633347 69.58965599 2.12506658 jpeg:enc-jpegli:q85:xyb:dec-jpegli 5532 570472 0.8249060 11.09750748 70.08839280 2.11339572 jpeg:enc-jpegli:q86:xyb:dec-jpegli 5532 601213 0.8693577 6.73269033 73.36321044 1.32186981 jpeg:enc-jpegli:q87:xyb:dec-jpegli 5532 626568 0.9060212 1.93637526 75.24245529 0.86236665 jpeg:enc-jpegli:q88:xyb:dec-jpegli 5532 661893 0.9571013 12.80215454 72.66036916 2.16158320 jpeg:enc-jpegli:q89:xyb:dec-jpegli 5532 700917 1.0135303 12.79846287 73.14141777 2.15291847 jpeg:enc-jpegli:q90:xyb:dec-jpegli 5532 735382 1.0633669 12.82965851 73.57953140 2.14843630 jpeg:enc-jpegli:q91:xyb:dec-jpegli 5532 779395 1.1270099 1.62044144 77.40647337 0.76951391 jpeg:enc-jpegli:q92:xyb:dec-jpegli 5532 852897 1.2332943 1.54923189 78.33942532 0.72773519 jpeg:enc-jpegli:q93:xyb:dec-jpegli 5532 913782 1.3213344 1.47751951 79.08779795 0.68925159```

open a bug report, that's the usual suggestion they give

yeah, I did that already 🥳 <https://github.com/libjxl/libjxl/pull/2097>

```Encoding kPixels Bytes BPP Max norm SSIMULACRA2 pnorm ------------------------------------------------------------------------------------------------------ jpeg:enc-jpegli:q77:dec-jpegli:bd16 4270 506467 0.9487932 2.72684336 77.56081328 0.95369086 jpeg:enc-jpegli:q78:dec-jpegli:bd16 4270 517770 0.9699678 2.65700030 77.55883662 0.93917341 jpeg:enc-jpegli:q79:dec-jpegli:bd16 4270 539942 1.0115038 2.77928925 78.53916234 0.89930998 jpeg:enc-jpegli:q80:dec-jpegli:bd16 4270 558322 1.0459361 2.85500360 78.85773219 0.88113728 jpeg:enc-jpegli:q81:dec-jpegli:bd16 4270 584871 1.0956718 2.57502866 79.90858541 0.82815398 jpeg:enc-jpegli:q82:dec-jpegli:bd16 4270 605818 1.1349130 2.63401079 80.42285602 0.80861482 jpeg:enc-jpegli:q83:dec-jpegli:bd16 4270 626056 1.1728260 2.48551631 80.83351512 0.78469510 jpeg:enc-jpegli:q84:dec-jpegli:bd16 4270 658955 1.2344576 2.26984620 81.85873616 0.72832107 jpeg:enc-jpegli:q85:dec-jpegli:bd16 4270 676199 1.2667617 2.23942900 82.35300166 0.71008788 jpeg:enc-jpegli:q86:dec-jpegli:bd16 4270 727943 1.3636967 1.93581724 83.15091152 0.65912585 jpeg:enc-jpegli:q87:dec-jpegli:bd16 4270 750174 1.4053433 1.77398717 83.57974444 0.63642079 jpeg:enc-jpegli:q88:dec-jpegli:bd16 4270 797480 1.4939643 1.72937787 83.69506242 0.59862877 jpeg:enc-jpegli:q89:dec-jpegli:bd16 4270 833215 1.5609087 1.58554494 84.24703823 0.56027005 jpeg:enc-jpegli:q90:dec-jpegli:bd16 4270 858588 1.6084413 1.63803422 84.49327837 0.55449904 jpeg:enc-jpegli:q91:dec-jpegli:bd16 4270 915529 1.7151121 1.59495139 85.86511935 0.50916213 jpeg:enc-jpegli:q92:dec-jpegli:bd16 4270 990559 1.8556701 1.33545852 86.14141714 0.46475208 jpeg:enc-jpegli:q93:dec-jpegli:bd16 4270 1028262 1.9263012 1.30757749 86.92874562 0.44365930```

```Encoding kPixels Bytes BPP Max norm SSIMULACRA2 pnorm ----------------------------------------------------------------------------------------------------- jpeg:enc-jpegli:q77:xyb:dec-jpegli 4270 440755 0.8256912 2.57653522 73.83731587 1.08323953 jpeg:enc-jpegli:q78:xyb:dec-jpegli 4270 448209 0.8396552 2.46053791 74.12077303 1.07571795 jpeg:enc-jpegli:q79:xyb:dec-jpegli 4270 469636 0.8797956 2.31674862 75.04041524 1.02801235 jpeg:enc-jpegli:q80:xyb:dec-jpegli 4270 481438 0.9019050 2.27511597 75.40451765 1.00002946 jpeg:enc-jpegli:q81:xyb:dec-jpegli 4270 511347 0.9579352 2.22766042 76.61113140 0.94573886 jpeg:enc-jpegli:q82:xyb:dec-jpegli 4270 520716 0.9754867 2.11857700 77.09132426 0.94801233 jpeg:enc-jpegli:q83:xyb:dec-jpegli 4270 546882 1.0245049 2.13817835 78.24623401 0.90216890 jpeg:enc-jpegli:q84:xyb:dec-jpegli 4270 573754 1.0748457 2.13797522 78.86015560 0.87542524 jpeg:enc-jpegli:q85:xyb:dec-jpegli 4270 593800 1.1123990 1.99826527 79.57994231 0.82144321 jpeg:enc-jpegli:q86:xyb:dec-jpegli 4270 626401 1.1734723 1.80742538 80.06207563 0.78408051 jpeg:enc-jpegli:q87:xyb:dec-jpegli 4270 665462 1.2466475 1.79822123 81.04907356 0.73527516 jpeg:enc-jpegli:q88:xyb:dec-jpegli 4270 686695 1.2864245 1.62478518 81.31783304 0.70662563 jpeg:enc-jpegli:q89:xyb:dec-jpegli 4270 734165 1.3753527 1.70427763 82.28476303 0.81580474 jpeg:enc-jpegli:q90:xyb:dec-jpegli 4270 778534 1.4584717 1.46675730 82.80288597 0.62502899 jpeg:enc-jpegli:q91:xyb:dec-jpegli 4270 830618 1.5560436 1.73360562 83.61609663 0.86297484 jpeg:enc-jpegli:q92:xyb:dec-jpegli 4270 891308 1.6697376 1.56471860 84.36080824 0.71326347 jpeg:enc-jpegli:q93:xyb:dec-jpegli 4270 959696 1.7978527 1.55117285 84.59052930 0.70106243```

```Encoding kPixels Bytes BPP Max norm SSIMULACRA2 pnorm ------------------------------------------------------------------------------------------------- jpeg:enc-jpegli:q77:dec-jpegli 5532 486612 0.7036439 2.39953136 71.65202106 1.00502228 jpeg:enc-jpegli:q78:dec-jpegli 5532 501600 0.7253167 2.75782180 72.21801605 0.97967721 jpeg:enc-jpegli:q79:dec-jpegli 5532 514678 0.7442275 2.33501077 72.54523663 0.96377555 jpeg:enc-jpegli:q80:dec-jpegli 5532 529287 0.7653522 2.22937679 72.84296049 0.94489784 jpeg:enc-jpegli:q81:dec-jpegli 5532 549683 0.7948450 2.15364552 73.37476724 0.91669055 jpeg:enc-jpegli:q82:dec-jpegli 5532 568713 0.8223625 2.14751482 74.17753353 0.89466890 jpeg:enc-jpegli:q83:dec-jpegli 5532 591524 0.8553473 1.99748659 74.75211395 0.86822956 jpeg:enc-jpegli:q84:dec-jpegli 5532 611947 0.8848791 1.99582553 75.43981382 0.84466982 jpeg:enc-jpegli:q85:dec-jpegli 5532 643516 0.9305281 1.86209989 76.16199395 0.81308184 jpeg:enc-jpegli:q86:dec-jpegli 5532 669916 0.9687026 1.89331925 76.61815939 0.80118657 jpeg:enc-jpegli:q87:dec-jpegli 5532 714181 1.0327101 1.70116842 77.45964155 0.75665667 jpeg:enc-jpegli:q88:dec-jpegli 5532 745805 1.0784386 1.65578604 78.00792635 0.73780008 jpeg:enc-jpegli:q89:dec-jpegli 5532 799633 1.1562742 1.56718040 78.49469715 0.69675601 jpeg:enc-jpegli:q90:dec-jpegli 5532 812859 1.1753991 1.47841942 79.01235813 0.68392626 jpeg:enc-jpegli:q91:dec-jpegli 5532 881885 1.2752111 1.47080064 79.68642896 0.65018029 jpeg:enc-jpegli:q92:dec-jpegli 5532 956604 1.3832552 1.29623413 80.74501217 0.59380554 jpeg:enc-jpegli:q93:dec-jpegli 5532 1031530 1.4915987 1.24743545 81.19958677 0.56947431```

```Encoding kPixels Bytes BPP Max norm SSIMULACRA2 pnorm ----------------------------------------------------------------------------------------------------- jpeg:enc-jpegli:q77:xyb:dec-jpegli 5532 435254 0.6293800 2.88526392 69.18842530 1.10358122 jpeg:enc-jpegli:q78:xyb:dec-jpegli 5532 445074 0.6435797 2.66324234 69.62329350 1.08546132 jpeg:enc-jpegli:q79:xyb:dec-jpegli 5532 460681 0.6661476 2.55543423 70.20905078 1.06358181 jpeg:enc-jpegli:q80:xyb:dec-jpegli 5532 472928 0.6838568 2.48481417 70.67981377 1.04270666 jpeg:enc-jpegli:q81:xyb:dec-jpegli 5532 492416 0.7120366 2.40248656 71.80530363 1.01292492 jpeg:enc-jpegli:q82:xyb:dec-jpegli 5532 512724 0.7414020 2.26550627 72.45684021 0.98994962 jpeg:enc-jpegli:q83:xyb:dec-jpegli 5532 530277 0.7667838 2.22364569 72.95387236 0.95430152 jpeg:enc-jpegli:q84:xyb:dec-jpegli 5532 549742 0.7949303 2.05206013 73.43388111 0.93784557 jpeg:enc-jpegli:q85:xyb:dec-jpegli 5532 570472 0.8249060 2.00240016 74.00596888 0.91469587 jpeg:enc-jpegli:q86:xyb:dec-jpegli 5532 601213 0.8693577 1.97627652 74.66762988 0.88284717 jpeg:enc-jpegli:q87:xyb:dec-jpegli 5532 626568 0.9060212 1.93637526 75.24245529 0.86236665 jpeg:enc-jpegli:q88:xyb:dec-jpegli 5532 661893 0.9571013 2.01312304 75.58584974 0.83912196 jpeg:enc-jpegli:q89:xyb:dec-jpegli 5532 700917 1.0135303 1.82577336 76.16010496 0.81066594 jpeg:enc-jpegli:q90:xyb:dec-jpegli 5532 735382 1.0633669 1.65119314 76.64671150 0.79583838 jpeg:enc-jpegli:q91:xyb:dec-jpegli 5532 779395 1.1270099 1.62044144 77.40647337 0.76951391 jpeg:enc-jpegli:q92:xyb:dec-jpegli 5532 852897 1.2332943 1.54923189 78.33942532 0.72773519 jpeg:enc-jpegli:q93:xyb:dec-jpegli 5532 913782 1.3213344 1.47751951 79.08779795 0.68925159```

What's your guess as to why this is the case with HEIC? Do you think that its design is purposely modeled around the tests? Seems like that would be tough to do with so many different and varied eval tools. But maybe not.

HM is a reference encoder based to absolutely maximize PSNR scores at all costs. VTM is actually a decent bit better in this regard, but it makes sense since we're comparing 2020 encoder design vs 2013 encoder design. What seems to be happening in all of these metrics is that structure retention is better to them than frequency detail retention. IE, even with butteraugli and SSIMULACRA2 being quite strong psy wise, they're not perfect metrics, and as such have flaws.

it is rather suspicious that psnr-hvs has better performance than butteraugli, that is quite the opposite what I observe in several experiments -- possibly something went wrong with selection of deformations or human eval

I like it very much that jpegli is getting some attention -- we need it desperately to get all things right -- jpegli has quite significant potential in shaking the compression world and giving us instant benefits

The eval wasn't very accurate, only based on 15 test subjects. Also they didn't use mozjpeg but Thomas Richter's libjpeg, which makes a difference — mozjpeg is optimized for psnr-hvs so it will cause psnr-hvs to be overly optimistic and correlate worse, but that didn't happen here.

are you planning on writing some sort of blog post or something like that when jpegli is ready to be shown off? right now only places I've seen it mentioned is this discord and the jxl repository so there's very little info about it available

Also they only did pairwise comparisons within the same codec, so I'm not convinced that the JND scale they end up getting is actually fully consistent between codecs — it could be that 2 JNDs in HEIC is on average less distorted than 2 JNDs in other codecs for some reason, and then maybe it's not the metrics overestimating HEIC but the subjective results underestimating HEIC. These things will become more clear when more accurate subjective data will become available.

if they had used mozjpeg in another session that has lower standards, smaller pixels or larger viewing distance, that would have easily explained the mystery why psnr-hsv is doing so well

It is not time for getting a lot of publicity on jpegli yet -- it is still a (buggy) expert tool. We are getting feedback here and from some capable industry partners. We are working towards libjpeg-functionality parity and I hope that we will eventually be able to replace libjpeg with jpegli in linux distributions, browsers, operating systems, cameras, graphics software and similar. I'm hoping that we will reach technical readiness during 2023, but a lot will depend on the feedback that we will be receiving.

good to know 🙂 looking forward to hearing more details about jpegli in the future

does jpegli encode anything other than XYB jpeg with an iccv4 profile?

yeah, without :xyb it's just normal jpegs

`jpeg:q83` - libjpeg(-turbo) `jpeg:enc-jpegli:q88` - jpegli encoder `jpeg:enc-jpegli:q88:dec-jpegli` - jpegli encoder/decoder `jpeg:enc-jpegli:q88:dec-jpegli:bd16` - jpegli encoder/decoder (16 bit output buffer) `jpeg:enc-jpegli:xyb:q93` - jpegli xyb encoder `jpeg:enc-jpegli:q88:yuv420` - jpegli encoder yuv420 (also for yuv422, yuv444)

what improvement does it have over mozjpeg for non-XYB jpegs?

just targetting butteraugli distance?

https://discord.com/channels/794206087879852103/794206170445119489/1055590417225240617 from what i understand, jpegli is currently more tuned for higher quality when i compared, jpegli was better on q90+ than mozjpeg, on lower qualities mozjpeg is mostly better (but not always) jpegli-xyb has even better quality, but also not enough to be always better than mozjpeg at lower qualities and jpegli-decoder increases the visual quality and the ssimulacra2 score by 1-1.7 points on average (roughly q88-q89 with jpegli-decoder = q90 with a normal decoder), just by changing the decoder

From a paper I'm currently writing:

benchmarking metrics is fun 🙂

Ssimulacra2 doesn't really count since it was tuned using part of these subjective results, but butteraugli and ssimulacra1 doing well is quite cool to see confirmed. Now I just need to finish this paper and get it published...

I hope future cameras shoot in JXL :)

Camera apps on smartphones could be faster.

I wonder if existing hardware codecs are so specialized that they cannot be made to output JXL with a firmware update.

Only because, for a camera app, hardware encoding might theoretically save power or reduce the time it takes to save a photo.

I wonder if hardware encoding can compete with software encoding for high-fidelity lossy compression

discord not support xyb lol for create preview

It does not support color profiles in general

Well whatever they are using to re-encode downsampled preview images is ignoring color profiles.

It looks like a server side problem

Whatever image resizing library/tool their server is using

I did a much bigger 8-bit screenshots benchmark via ffmpeg large amount of various videos and animations movies have a decent percentage of 4k 10-bit hdr with proper conversion to 8-bit sdr images using libplacebo besides the final results i can say that jxl e1 and e4 have the most stable compression, on some titles jxl e2 (or even e5, e6) and webp z0 can be worse than jxl e1 even if they are better on average fpnge better than the internal ffmpeg png encoder with default settings and overall fpnge results might be even better, but it's noticeably worse on something like opening/final credits or flat colors

**Animation** (mostly new and 2d, some cg, some old, western and anime): ```scss 13 753 454 557 libvips 1 9 307 079 808 libvips 9 030 312 569 ffmpeg png 8 797 781 837 FPNGE 8 782 277 078 FPNGE 5 4 687 025 737 JXL e1 4 519 150 101 JXL e2 5 239 330 470 JXL e3 3 259 031 338 JXL e4 3 625 116 930 JXL e5 3 613 206 845 JXL e6 4 925 632 028 webp z0 5 226 483 424 ZPNG 4 249 402 514 HALIC 5 832 866 997 QLIC2 3 139 394 072 LEA ```

**Movies** (mostly new, some old movies, tv-shows and music videos): ```scss 17 851 292 019 libvips 1 11 435 279 928 libvips 11 111 663 621 ffmpeg png 9 730 664 134 FPNGE 9 719 759 364 FPNGE 5 6 324 851 181 JXL e1 5 140 996 726 JXL e2 5 566 614 138 JXL e3 4 077 238 945 JXL e4 4 560 331 798 JXL e5 4 548 864 282 JXL e6 5 160 464 834 webp z0 7 411 335 649 ZPNG 5 229 353 117 HALIC 6 217 644 552 QLIC2 3 667 660 416 LEA ```

jxl e4 is pretty good and if it got faster it would be cool, though it doesn't feel slower than png in mpv (but still not snappy) and if fpnge would compress some simple images better, it would be a true png king for screenshots <:Stonks:806137886726553651>

e5 being worse than e4 is unexpected, could you open an issue for that with an example image where that happens?

(I thought e5 could only be better than e4, since it should be doing basically the same thing but more exhaustively)

and e6 is more different? because it is also worse and e5 is pretty similar to e6 in compression

e4+ should all be similar but just more exhaustive, trying more types of MA tree nodes, more RCTs, etc

though some things are still only driven by heuristics, not trying full encode and picking the smallest result

especially for patches and (channel) palettes, it could be that the heuristics to balance signaling cost vs compression gain are not very good

thanks!

looks like it is applying palette at e5 on that image and it is not a good idea

so basically that image is dark, and YCbCr has reduced precision in the R and B channels, so the number of distinct colors per 256x256 group is small, causing it to apply a palette transform

and this happens on most images and only some are better compressed

but on images like this, palette is not likely to be a good idea — while it does reduce things from 3 channels to 1, all the spatial smoothness that made things well-predictable gets ruined by doing palette

so what happens in particular here, is that also at e4 global channel palettes are used, changing the range for R to 0..83, G to 0..77 and B to 0..83

those channel palettes don't help with compression though

hmm, interesting, so needs a new heuristic for such screenshots? and it would be nice to have yuv420p10le (and maybe yuv420p) compatible modes to save similar frames from video content, maybe not directly, but something that is more compact (than 16 bpc) and losslessly convertible maybe ffv1 does something similar?

I don't understand how the ffmpeg png encoder can be worse than fpnge

only guess I have is if they just do huffman coding with fixed tables and no lz77/rle, but even then, it should at least be pretty fast and IIRC from what people said it isn't

I guess ffmpeg uses libpng and that probably isn't optimized for speed.

IIRC *all* libpng modes compress better than fpnge

im pretty sure ffmpeg has a native encoder

it doesn't even link libpng

Doesn't libpng have an option to do basically uncompressed (deflate only using fallback raw blocks)?

Probably, but then it would be a lot bigger than fpnge 😛

I'm 99% sure it's compressing at least somewhat

you can configure libpng to use various zlib settings and filtering strategies

``` #include zlib.h /* Set the zlib compression level */ png_set_compression_level(png_ptr, Z_BEST_COMPRESSION); /* Set other zlib parameters for compressing IDAT */ png_set_compression_mem_level(png_ptr, 8); png_set_compression_strategy(png_ptr, Z_DEFAULT_STRATEGY); png_set_compression_window_bits(png_ptr, 15); png_set_compression_method(png_ptr, 8); png_set_compression_buffer_size(png_ptr, 8192) /* Set zlib parameters for text compression * If you don't call these, the parameters * fall back on those defined for IDAT chunks */ png_set_text_compression_mem_level(png_ptr, 8); png_set_text_compression_strategy(png_ptr, Z_DEFAULT_STRATEGY); png_set_text_compression_window_bits(png_ptr, 15); png_set_text_compression_method(png_ptr, 8); ```

optipng basically just calls libpng with various options for zlib and various settings for `png_set_filter()`, just brute-force trying things (only optimization being that it does streaming encode and aborts an attempt as soon as it gets larger than the current best attempt)

you can definitely configure libpng to encode a lot faster (and worse) than what it does by default

I think libpng defaults are more or less set to whatever compresses best in a single attempt and only using zlib (no custom/image-specific deflate)

ffmpeg uses its own internal png encoder, perhaps it is also tuned for faster speed by default because its often used as an intermediate format even for video encoding but for these screenshots it's not very good except for credits, titles, black frames and flat colors maybe it could be better configured, but anyway it would be good to have some fpnge mode for such images, I guess they are well compressed because ffmpeg uses zlib and bigger window size, I will show some examples

FPNGE

No big deal, if I need png as the destination format, I will run it through pngout anyway.

After all, PNGs I came across most of the times, are fully opaque images encoded as RGBA. Even resaving in IrfanView will significantly reduce the file size.

png optimization or recompression is not always possible or convenient and requires extra effort having a fast encoder with still good compression (or when it's better and faster than others) is very useful, even for screenshots most people will just be too lazy or don't want to spend time on it or for frames sequences for further processing, they consume a lot of space and png is a pretty universal format and has good compression, unlike many other formats that may be slower or not have (enough) compression or are not as supported

`fpnge -5` just a little bit better lib`vips [compression=1]` <:monkaMega:809252622900789269> so nothing wrong with the ffpmeg png encoder, libvips with the default settings is even slightly worse

This is very funny, actually. In the interest of taking arguments away from browser vendors’ hands: is this only implementation in browsers that is responsible for decode time? Or can something be done in the library too? And if the latter, is it being looked at? (another argument being less competitive lower quality spectrum, but here I know JXL is constantly improving)

decode time in JXL is very fast, I don't believe that data you pinged is correct

what he posted is an edited version of this

Both are just illustrations, not actual plots.

also a comment from fhanau (<https://github.com/fhanau/Efficient-Compression-Tool/>) https://css-ig.net/submit/view?1118818738

interesting

There are now benchmarks by one side, or the other - while to really convince, it would be great to have some unquestionably objective ones. Maybe it is worth to make e.g. a separate github with neutral datasets, clear scripts to calculate various metrics, inviting AVIF and others e.g. JPEG members, media to participate to make it as neutral, objective as possible ...

The thing with metrics is that no perfect metric exists, and most existing metrics are quite bad and biased towards codecs that use YCbCr420 (e.g. because they only look at Y).

the "everybody does own benchmark" current situation is quite problematic for objective evaluation, also might be the reason Mozilla doesn't give any details, media are not certain who is right here ... maybe e.g. JPEG with collaborators could establish some looking neutral and objective benchmarking pipeline also for future image compressors?

This is what the JPEG AIC-3 effort is aiming to do.

But imo even the comparison done by the avif team is actually showing jxl performs quite well, it's just that you need to click through to the actual data and the 'summary' they put on the landing page is completely zooming in on all the wrong things because they're trying to make avif look good.

On the landing page they show this: https://storage.googleapis.com/avif-comparison/images/main/charts/Main_filesize_vs_TurboJPEG_MS-SSIM.png

which looks like avif is like 15% smaller than jxl for the same quality according to ms-ssim

but then if you click through to the actual data, you see that this was based on avif at the slowest speed. The plot looks like this: https://storage.googleapis.com/avif-comparison/images/subset1/rateplots/subset1_avif-jxl_t-1_avif-s0_jxl-s9_msssim_2022-09-01_23d3bb6d_bpp-0.1-3.0.png

if you look at more relevant encode speeds, the plot already starts to look a bit different: https://storage.googleapis.com/avif-comparison/images/subset1/rateplots/subset1_avif-jxl_t-8_avif-s7_jxl-s6_msssim_2022-09-01_23d3bb6d_bpp-0.1-3.0.png

or even if you allow avif encoding to be extremely slow, but just look at a more modern and non-colorblind metric (ms-ssim ignores color and only looks at the luma component), you also get a different picture: https://storage.googleapis.com/avif-comparison/images/subset1/rateplots/subset1_avif-jxl_t-1_avif-s0_jxl-s9_ssimulacra2__bpp-0.1-3.0.png

here you see avif being 13% better at the very low end and jxl being 9% better around 1bpp (and 20% better or so around 2bpp)

when looking at the same time at relevant encode speeds and at relevant metrics, you get this: https://storage.googleapis.com/avif-comparison/images/subset1/rateplots/subset1_avif-jxl_t-1_avif-s7_jxl-s6_ssimulacra2__bpp-0.1-3.0.png

now avif is 8% better at the very low end, jxl is 17% better around 1 bpp (and 22% better or so around 2bpp)

'web quality' ranges more or less from ssimulacra2=50 (web devs who don't care about quality and only about bandwidth) to ssimulacra2=85 (web devs who don't care about bandwidth and only about quality)

I understand, but it is still one side against the other - to convince the general public, there is needed a neutral pipeline ... e.g. a github in which all sides decides to choose as neutral and objective benchmarking pipeline as possible

this is not really one side against the other: these plots come from the avif team, not from me

so there is no controversy about the benchmarking pipeline

i'm fine with these plots

the disagreement is only on which plot to look at and put on the 'front page', and which part of that plot to give the most weight

ok, so the problem is how to stimulate a real discussion? media coverage could do it ...

e.g. JPEG members writing articles, contacting media ...

the avif team is basically weighing things so that effectively the range of ssimulacra2 below 30 is considered more important than all the range of ssimulacra2 above 30, so they can arrive at the conclusion that avif has better compression — except that's the kind of quality you get when doing a video call on a bad network, nobody would use such low qualities on a web site

sure, avif has (somewhat) better compression at this type of quality: https://res.cloudinary.com/cloudinary-marketing/images/f_auto,q_auto/v1670951930/jpegxl2/jpegxl2-png?_i=AA

but that's only relevant for bandwidth-constrained video use cases. Nearly no still image use case would use such low qualities.

^ even **I** wouldn’t go that far! 😜

I think we need to somehow get independent benchmarks and opinions to be performed. Anything coming from me or from JPEG will (rightfully) be considered a biased source. At this point, I think we need e.g. a professional photographer or web dev or some other 'expert user' to just try jxl, compare it with avif/jpeg/webp/heic for their own use case, manually encoding images at the qualities they would like to use, and write about their experiences.

people seem to quote Nick Doyle (Akamai) for that matter, but that was also not a public benchmark. did you ever get more information from him?

no, he didn't respond to my questions

I dont understand how they can say AVIF is faster because its multithreaded. Its not like in the real world youre only decoding a single image at a time in browsers. Likewise for the actual encoding of images for use on websites. They are either done in parallel as part of a batch build or they are processed in parallel on workers as part of an image processing pipeline. And for those people that are actually saving out single images from an editor - they arent going to notice the difference between a second here or there. Then theres the ACTUAL cost of the energy involved in that CPU time...

Not to mention that multithreaded avif encoding comes at a ~3% cost in BD rate. Unlike multithreaded libjxl encoding which just produces the exact same bitstreams as single-threaded, only doing in parallel what can be done without changing the result.

i was flicking through social media the other day on my phone. just flicking through pages mindlessly. Well - almost mindlessly - i was waiting for the images to load so not scrolling too fast, and it occurred to me how perfect an example for the benefits of JXL that usecase would be

i wonder how hard it would be to put together some kind of demo to showcase jxl vs avif in that kind of case

scrolling through, viewing output from progressive decoding, etc

terminating downloads that are no longer on screen, etc

its a real usability concern in that respect

IMHO

<@794205442175402004> did you get my message on twitter the other day? Your website said its best place to reach out to you, but not sure if you got the message given how awful twitter is these days

Got it, forgot to check pending message requests

the dumbest thing is that they only show ms-ssim results without even attempting to perform any basic sanity-check validation by comparing the actual image data side by side to see what they are even comparing or what it even looks like.

This would be the most effective way to draw attention to the BS that's going on with web browsers right now. If anyone actually tried to use AVIF and JXL and compare them, most people would walk away from the experience wondering what the hell is mozilla and google thinking

most professional photographers have little understanding of file formats beyond "jpg = lossy" and "tiff/raw = better"

https://autocompressor.net/image_bench.html

That is a somewhat strange way to benchmark encoders. I am not convinced that this says much about how good an encoder is. It's an interesting experiment though, and I do think it does say something about the range an encoder is most suitable for.

Here it says JPEG XL's results are very promising at higher quality, which is where it really pulls ahead compared to video codecs. The testing methodology did confuse me a bit though but I think its interesting nonetheless

There are a lot of ABX programs for doing blind comparisons of audio. But I don't think there is something like that for images.

But it's probably not as needed.

Any comparison that doesn't let you see what the actual things being compared actually look like is a worthless comparison that has no value or purpose.

Using a metric to compare which image format is the best is like declaring which audio codec sounds the best without actually listening to any samples.

This article says they found an ideal quality level or bitrate for each codec but fails to show what the ideal for each codec actually LOOKS like at the end of the article...

So you have no reference for what AVIF's supposed ideal actually looks like compared to other codecs

Overall pretty useless and a missed opportunity

If someone presents an audio codec comparison and fails to include any actual samples for reference they would be laughed at and their hydrogenaudio forums account would probably get banned. Fail.

>Pretty useless >SSIMULACRA2

Basically, this is a good benchmark which shows the inflection points at which the highest visual quality/bit can be obtained using each encoder. `Absolutely no attention should be paid to the absolute SSIMULACRA2 values, only to the shape and peak of the curves. Target sizes differ.`

Supposedly. But without any reference at the end we don't even know how AVIF looks like at cq-level 32

So we don't even know if the "ideal" bitrate actually looks useable

since the ideal was judged by computer vision, not human vision

Not even that, the ideal is judged by downscaling the image, encoding, decoding, upscaling again, and then comparing that to the original

The graph shows which quality level packs the most amount of quality in the same amount of bits. At least in theory.

Which quality level has the best quality-bitrate economy.

It does not say whether or not that "ideal" quality level looks remotely acceptable to human eyes.

So without being able to LOOK at the results, it's a worthless test.

Like all tests that don't include any actual sample references.

I mean, it's not a worthless test. A worthless test would be to look at PSNR values between encoders, not even within the same encoder.

That's essentially what's happening here.

It does say something imo, but not the main thing that matters, which is (imo): how does it perform at 1:1 at reasonable qualities?

All that was done is a metric was used in order to attempt to determine for each encoder which quality level has theoretically the best bitrate economy. They determined ideal quality settings at the end, for each encoder. But they neglected to show what these ideal settings actually look like in practice so we can get an idea of what each codec's strength actually looks like.

Having a visual reference would have helped us determine when to use which codec.

Neglecting to include one is a serious omission.

Sorry if I sound harsh but I can't believe how common this is with images/video, it's something that would never ever fly in the audio world.

It would be outrageous and laughable over there.

And like I said they would probably get banned from hydrogenaudio

Because comparing audio with metrics is far harder to do than with images. Let alone doing it well.

Perhaps the author should have added a line of the sort: "This study could be further revised in a future article as to delve deeper in the subject."

Good image testing is done with blind subjective testing too. It's just expensive and time-consuming to do that, so metrics became a popular/necessary alternative. The main issue is when codec devs start trusting the metrics more than subjective results and optimize too much for the metrics even when it causes images to look workse.

No metric is perfect, I know for sure that there are cases where ssimulacra2, butteraugli, or any other 'good' metric will correlate poorly with subjective results.

(for the 'old' metrics like ssim and vmaf, correlation is quite clearly poor, especially when comparing an encoder that has been tuned to death to optimize for one of them to an encoder that doesn't care about those metrics)

Many metrics are colorblind (ignoring chroma completely, or not taking chroma properly into account), which is no doubt one of the reasons why there's such a widespread belief that chroma subsampling and other forms of chroma thrashing are OK.

While most of it is basically because academics were going "color is complicated, so let's start with grayscale, make a metric for that, and leave color for the future work section of the paper"

To be fair, with more advanced chroma scaling algorithms being used in more modern codecs, the benefits of full chroma resolution aren't always as high as they were compared to earlier codecs.

Now, I still don't want chroma subsampling... 🙂

Sure, but with better entropy coding there's also no reason to do subsampling as opposed to having lots of zeroes in the high frequencies (but the option to keep some nonzeroes there where needed)

The main reason why chroma subsampling is still a thing today imo, is because of hardware implementations of video codecs, where 4:4:4 is almost twice as costly as 4:2:0 due to buffer sizes

here's my source, just read some tests

here's the script:

written by the same person who did the autocompressor tests

this is still a very strange comparison, this test is only for one image comparing when resizing is a pretty significant loss in accuracy of comparisons it works for a larger difference, also this is used for video encoding to understand at what bitrate it needs to decrease resolutions to keep quality (like stay at 1080p or drop to 720p), and as other similar tests have shown, then more modern formats very rarely need to decrease resolution, unlike older ones but for a small difference this comparison has very low accuracy, also its almost unusable for web, I doubt that someone will use very high resolution with higher compression and lower resolution for viewing, also the resizing algorithms can be different, like different browsers can use different algorithms, even not very good bilinear resizing also strange conclusions about the ideal Q, but it's ideal only for this particular image with this resolution, with this complexity, with this size limitation, and for this metric it can show how effectively codecs can hold quality without resizing, but even that requires a lot more test images

Well the distortion introduced from resampling potentially adds noise to the data, which is why no one else does this, or why it's so unusual...

As a baseline, it would be interesting to see what that curve looks like when doing lossless and only doing the downscale/upscale thing

Drawing conclusions from one image is in any case very risky - but aggregating data from many images is also tricky, since you easily get into situations where you're drowning in a lake that is only 10cm deep on average...

yeah, but what I mean is that for any encoder there is no one best Q/quality, even with resizing and tests on other images would show different results

I wonder if they would have achieved the same results without any resizing being involved, simply by measuring the ssimu2/bitrate ratio for each quality setting. I fail to see why the resizing step was even necessary at all. Couldn't they have created the same graph without the resizing?

And without the wasted time trying to make each quality level match the same filesize by resizing the image

That would only introduce noise as far as I can tell.

I'm pretty sure a graph of y=ssimu2/bitrate, x=q-level would theoretically be the same curve, a graph of the same thing.

Just divide the ssimu2 score by the bitrate, instead of trying to match file sizes... That would save time and graph the same thing, no?

In theory? Am I missing something here?

The crest of that curve would show the most bit-efficient quality setting, in exactly the same way as these graphs.

And the "waviness" being measured here in these graphs is an artifact of resampling/resizing.

It's just noise in other words

Unless some codecs truly have a hard time with specific resolutions.

which is a weird assumption to make.

Pretty weird test...

literally, even in my limited testing with just mozjpeg i got better results by just disabling subsampling and using a lower q for chroma than by enabling subsampling and thats not even doing anything smart

this matches my experiences that led to dropping subsampling in jpeg xl/pik as a compression strategy

chroma subsampling is just weird -- it allows chromacity ringing to propagate 2x longer, and there is nothing in the eye that hints that it is a valid strategy

it worked well at a time when cameras didn't generate hf chroma, and thus made sense for early tv

when we built guetzli and guided it with butteraugli, we gave it an option to choose yuv420 --- it would only use that option a few percent of the time

like 4 % perhaps

when color tv was introduced and broadcast bands were already assigned for black&white signals, they literally had to squeeze the color info in a rather limited range since they wanted to keep things compatible with the old b&w TVs and they only had some room in the padding between the already assigned bands to put all of the chroma signal

I think that's the main reason why historically, chroma was just crap quality — because big compromises had to be made to be able to broadcast in color in a backwards compatible way. And then I think video folks got so used to bad chroma quality that they kept doing it and rationalized it away as being perceptually fine

yeah but guetzli was targeting q>85. I think below q80 or so, 420 does typically beat 444 in jpeg (mostly because jpeg's entropy coding is not very good; when looking at jxl-recompressed sizes, probably the difference disappears and 444 might even get better)

I may be wrong but I think both mozJPEG and (at least old) Adobe encoder dropped chroma quality at arbitrary q levels in JPEG. Can’† remember which level, though. I fear stuff happening without me knowing…

https://discord.com/channels/794206087879852103/803663417881395200/1068949307987857499

I briefly tried that with libjpeg-turbo (not moz) on just one image and the results seemed to favour 4:4:4 + lower chroma q at high qualities and either 4:2:0 or 4:4:4 + slightly lower luma q + lower chroma q at lower qualities

as in: 4:4:4 q100,97 matched the size of 4:2:0 q100 while retaining more detail,

but 4:4:4 q85,<n> required a very low <n> to match the size of 4:2:0 q85, at which point the 4:4:4 image was disgustingly bad

but it was much easier to match the size of 4:2:0 q85 with 4:4:4 q82,<n>, and then it was more comparable

https://cdn.discordapp.com/attachments/673202643916816384/1078879391024689192/chart.png

seems like well-tuned jpeg with arithmetic coding is kinda great

here's another on a non-photographic image

Well non

Can I somewhere see the picture ?

https://cdn.discordapp.com/attachments/673202643916816384/1078902630639751218/the_apps.png

<@532010383041363969> <@794205442175402004>

`cjxl v0.9.0 6280645e [AVX2,SSE4,SSSE3,Unknown]`

`cwebp the_apps.png -lossless -near_lossless 0 -z 9 -o the_apps_slightloss.webp`

would spline detection make a big difference w jxl in a situation like this?

https://slow.pics/c/zXYbKxAV

I think better patch detection would help more.

looks promising for fast image compression, but it seems to be some old jxl version, because e1 speed is almost the same as e2, also very strange that memory consumption is the same for all efforts <https://encode.su/threads/4025-HALIC-(High-Availability-Lossless-Image-Compression)>

> **HALIC (High Availability Lossless Image Compression)** > Fully one thread is running and SIMD, ASM or GPU is not used. > My goal was to make something as fast as possible, low-resource consuming and suitable for multithreading. The work is still very new at the moment and there are things I need to improve. I want to improve as much as I can without distractions. > Of course, I will share the codes later. This is not a secret especially if it's going to be open source

Some web benchmarks. Promising results for Thorium!

when will this be built into the source code? 🙂

It requires research, it's not trivial.

something funny I found with these tests is that the JavaScript ones were much faster on waterfox classic, and just a bit faster on waterfox for me as well

also I ended up getting different numbers on my end, Firefox was always slower for me than chromium

Yes Firefox is noticeably slower than chromium but Firefox fans always lie that they don't notice any difference.

here's one case where waterfox classic is faster for some reason

images from a few weeks ago

motionmark also did horrible on firefox for me as well

I have a theory that mozilla in their attempt to make the jit for their javascript engine easier to work with they ended up making it regress in performance

here's waterfox

thorium

yeah I think so too lol

also I had tested Brave and was getting numbers right around thorium, or slightly higher

We don't notice because we don't use both. I hate the way chrome hold an obnoxious connection to a single google account to work properly... The increased performance is not enough, after all, it's just browsing.

(tested at 788.44 on motion mark, for firefox 110... should be good enough)

I've always known Firefox is slower, but it's also just faster

I don't particularly care how many cums per fart the browser can do. What I do care about is how fast I can make a new tab with a mouse and stuff like that

there should be a benchmark measuring the time to do actions

that's heuristic & not as easy to quantify

Firefox consistently wins for me in WebXPRT 3/4 & MotionMark 1.2, so it isn't always "slower"

Lenna is not a very good test image. Also benchmarking is better done with a bigger corpus, because codecs do have behavior that depends on image content.

the benchmark was my answer to this posting https://discord.com/channels/794206087879852103/794206170445119489/1079857874488012942

What encode settings are you comparing here?

I think libaom s6 vs jxl e6 is the most relevant comparison. That still gives avif more time budget than jxl, but not a crazy factor like 30x. No image cdn is going to multiply their cpu bill and latency by 30. That's only something hobbyist blogs or the like can afford, or maybe some very high traffic images above the fold on important landing pages...

jxl -e 5 -q 0..95 avif -s 5 -j 8 -d 10 -y 444 --min 1 --max 63 -a end-usage=q cq-level=(63 - 0..60)

jxl e5 vs avif s5 😂

https://libwebpjs.hohenlimburg.org/avif-jxl-bench/charts.html

<@532010383041363969> You like bugs in jxl lossy? Here the link

It would be interesting indeed to compare settings which take roughly the same time to encode 🤔

encoding time should be third axis tbh

ooh, that could make an interesting 3D plot

Effort vs bbp vs quality metrics vs encode time.... 4D graph! Dimensions are like blades on razors, we always need one more than you expect 😅

Nah effort is not really required... 3D should be nice...

yeah different quality metrics could use different colors

this is a lot of images...

And these graphs look really strange. AVIF destroying AVIF at nearly the same bitrate...

AVIF wrecking JXL at pixel graphics and blocky nearest-neighbor upscaled graphics... This could be fixed with some sort of specialized encoder designed for non-photographic images or maybe a way to detect images that have an unusually low amount of entropy per pixel and using different techniques on those images...

on those upscaled images, jxl lossless does quite well

```console $ cjxl 0czt1ekqww531.png test.jxl JPEG XL encoder v0.9.0 984d6f1e [AVX2,SSE4,SSSE3,Unknown] Read 1152x1440 image, 65296 bytes, 387.0 MP/s Encoding [VarDCT, d1.000, effort: 7], Compressed to 243678 bytes (1.175 bpp). 1152 x 1440, 7.00 MP/s [7.00, 7.00], 1 reps, 32 threads. $ cjxl -d 0 0czt1ekqww531.png test.jxl JPEG XL encoder v0.9.0 984d6f1e [AVX2,SSE4,SSSE3,Unknown] Read 1152x1440 image, 65296 bytes, 385.0 MP/s Encoding [Modular, lossless, effort: 7], Compressed to 23977 bytes (0.116 bpp). 1152 x 1440, 3.94 MP/s [3.94, 3.94], 1 reps, 32 threads. ```

https://libwebpjs.hohenlimburg.org/avif-jxl-bench/charts_8-5.html

I updated the charts. At the beginning you need a little bit waiting time

In this charts y: ssimulacra2 x: bpp y: ssimulacra2 x: EncodingTime

I can't load that page on my phone, could you screenshot it?

it's a very large page

I see. Maybe split it in multiple pages?

Are you polyfilling those plots or something? My phone is choking on it

they're kinda interactive

should work now

is this still s5 vs e5 ?

for https://files.catbox.moe/1i2wyr.png there is no avif

also https://files.catbox.moe/0x96y3.png only has two avif data points

the times for https://i.redd.it/01tc6iemk2x31.png are somewhat atypical, how are you measuring time?

is this single-core or multithreaded? cpu time or wall time?

s8 vs e5

I removed bpp over < 3 for avif else the chart would look horrible

https://files.catbox.moe/1i2wyr.png cq-level filesize bpp ssimulacra encodingtime 0 142271 17.36706542968750000000 100.00000000 .072472467 5 99227 12.11267089843750000000 100.00000000 .047063700 10 82215 10.03601074218750000000 100.00000000 .051144220 15 72916 8.90087890625000000000 100.00000000 .049388151 20 67125 8.19396972656250000000 93.45713385 .052162421 25 62231 7.59655761718750000000 88.17699420 .041530926 30 56954 6.95239257812500000000 82.78476910 .040196861 35 51784 6.32128906250000000000 74.20391260 .038413292 40 47594 5.80981445312500000000 62.33402449 .036847730 45 44025 5.37414550781250000000 44.05832175 .035554697 50 41648 5.08398437500000000000 19.63478447 .031802677 55 40761 4.97570800781250000000 -3.74272099 .029050859 60 40333 4.92346191406250000000 -42.28387609 .028723501

oh, https://i.redd.it/01tc6iemk2x31.png has an alpha channel, that probably explains the slower encode times for jxl

it looks like an alpha channel that is only there to fool some things into keeping it as PNG, alpha is 255 everywhere except one pixel where it is 254

the kind of thing people resort to when they want to preserve fidelity

if you could add thumbnails of the images to the page, it would be useful — just to have an idea of what kind of image content it is

https://libwebpjs.hohenlimburg.org/avif-jxl-bench/charts_8-5-all.html all bpp

https://i.redd.it/0czt1ekqww531.png lossless jxl is a better idea than lossy on an image like that: ``` Encoding [Modular, lossless, effort: 5], Compressed to 28694 bytes (0.138 bpp). Encoding [Modular, lossless, effort: 9], Compressed to 21944 bytes (0.106 bpp). ```

avif multithread 8 jxl defaults

of course ideally we would detect these cases where lossless works better

start=`date +%s.%N` ./avifenc or ./cjxl end=`date +%s.%N` runtime=$(echo "$end - $start" | bc) echo "$runtime" >> $2

so wall time

for end-users encoding images on their laptop/desktop machine, that's fine

at Cloudinary we do image encoding using single-core, since if you need to do lots of encoding, that's always more effective

you can see here how the avif team's codec comparison arrived at the conclusion that avif encoding is fast

if you look mostly at the region of unusably low qualities (ssimulacra2 < 0), it does actually get quite fast

for video that range is still useful, so it's understandable that they looked at that range — they're mostly video codec engineers, I assume