JPEG XL

Second set is SD

Second set MULTI resolution

plz stop it fab

I like the tea-towel tho

I evaluated 30 tik tOk videos and 20 images

Latest image

Original

Send to everyone: Benchmarks studies Three resolutions

Not in whatsapp only to compression enngineer

Generation loss is still fun <:CatSmile:805382488293244929>

what's the intermediate format you're using between generations? 8-bit png, 16-bit png, 32-bit pfm?

16-bit png

<@532010383041363969> I think generation loss is a good argument for constraining enc gaborish to be as close as possible to the inverse of dec gaborish, rather than allowing it to apply "anything that works" for a single generation and according to Butteraugli. If there are reasons to deviate from that (e.g. compensating for subsequent quantization errors) then that's fine with me, as long as the goal is still to make the roundtrip as close as possible to the identity and not introducing artifacts that improve metric scores in one generation but accumulate into something bad over several generations, i.e. the tuning could be done by optimizing for the result of not just one roundtrip but say the end result of 5 or 10 generations (yes, that makes tuning N times slower but I think it's worth it).

Adding an option to benchmark_xl to do multiple generations of encoding would be useful. A change might fool the metrics in one generation and look good while it actually does introduce artifacts that when amplified through multi-generation encoding become problematic enough to no longer fool the metrics.

what is the point of gaborish again

It's basically a way to get the advantages of a lapped transform without doing a lapped transform: encoder side it applies a kind of sharpening before doing DCT, decoder side it applies a kind of blurring after doing DCT that undoes the sharpening the encoder did and also reduces blocking and DCT artifacts.

also jpegli block artifacts are still there in the latest version something similar with generation loss blockiness

is this XYB jpegli or YCbCr? Either way, I wonder where the blockiness is coming from, I would assume this is something that should be avoidable...

both (but less for xyb)

we need to improve on this in cjxl and cjpegli

we will think what to do -- one possibility is to optimize the quantization heuristics exactly for the generation loss (as a mixed objective, partially for image quality, partially for generation loss)

but I like the approach where we first acknowledge the problem and stay open to it for awhile before deciding how to react 🙂

do we have an open issue for this in the github?

I believe this (optimization for the generation loss) should be top priority given how often and how many times pictures are recompressed in the Internet

why does cjpegli have worse generation loss than mozjpeg here?

jxl is supposed to have convergent generation loss, iirc

most likely because of the variable dead zone quantization

https://www.w3.org/Graphics/Color/Workshop/slides/talk/lilley this talk shows some nice plots of how uniform various spaces are w.r.t. DeltaE 2000

would be interesting to see what a plot like that looks like for XYB

On a similar subject i stumbled upon this fancy oklch color picker https://oklch.com/#70,0.1,2,90.17

Perhaps there is some code which could be scavenged from https://bottosson.github.io/posts/oklab/ as he displays similar plots

What is the robust way to aggregate timings of a single command over different images? sum(pixels)/sum(seconds) has a downside when applied to timings below the precision of measurement, but is median(pixels)/median(seconds) better?

Or rather median([pixels/seconds for each image])

if you have the data for each one, why not just do pixels/second for each image, and then take the mean of those?

total pixels / total seconds has the effect of making small images not count very much toward the average

let's say I have a large image and a small iamge

the large image takes 1 MP/s, and the small one is much faster. 10 MP/s

if you total the pixels and divide by total time, that 10 MP/s will barely contribute to the average at all

then again that's probably OK, since the measurement for the small image will likely be less accurate and include more stuff that isn't asymptotically important (depending on how you run the benchmark, you might be counting things like loading the binary and initializing some stuff as part of the enc/dec time)

Okay, then I have to learn how to incorporate samples of zero seconds.

`--num_reps=100` 🙂

while elaspsed_time < time_unit: _time command_

num_reps makes more sense

if your samples are too small then most of the overhead for a single execution is going to be unrelated to JXL

But it should be fair across encoders, and anyway the overhead is part of the practical implications of invoking the command. num_reps should be more representative of using the library directly.

In most use cases, you would use the library directly, not call cjxl/djxl on intermediate files...

I'm looking at transcoding existing files. Maybe it's useless to most people, but that's in line with everything else I make.

are you producing benchmarks to measure solely how you use it? because the library is how most users will use it

The WebP/AVIF team has added a new benchmark tool to their page: https://storage.googleapis.com/demos.webmproject.org/webp/cmp/index.html

They test at all qualities from 0 to 99 so results are a bit messy, especially the results they suggest to look at

But it's a nice visualization tool that can be used to make relevant plots too, e.g. something like https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2024_01_25/index.html?load=all.json#WebP+method+4-quality=90..90&matcher_ssim=off

If you just aggregate over the entire range from q0 to q99, you end up giving a _lot_ of weight to very low quality settings that no sane person would use.

I made a little animation to illustrate what happens if you compare at something equivalent to WebP q30 vs WebP q95 (which is not super high quality, due to obligatory 4:2:0 and limited range YCbCr which makes it often worse than q90 JPEG).

So around q70 JXL seems to be at a better ratio than AVIF, with the gap significantly increasing after 80 and 90

Yes, well it also depends on what speed you look at, even at q30, jxl still gives better bang for buck if you want fast encoding.

I'm also not sure if the set of images they used for testing is very representative, I should check the full corpus though (haven't found a convenient way to see all source images yet though). If you have few images with natural content like a human face, and many with hard straight diagonal lines (like modern, very 'clean' architecture), then AVIF will tend to look better since it's good at those kind of images.

Would be helpful illustrating the kind of visual quality some of those numbers map to. I recall seeing in the past a low filesize output for avif that was of unacceptably low quality comparable to bit starved ancient jpeg

"good argument, unfortunately i have depicted AVIF as the soyjak and JXL as the chad"

ofc once you get _really_ small, JXL starts winning again

how do you get the curve at webp q90 ? I struggle to select it. and in all cases avif seems to win... what a shitty presentation

that's not the most usable UI I've seen in my life, no

Easiest way imo is changing the url. https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2024_01_25/index.html?load=all.json#WebP+method+4-quality=90..90&matcher_ssim=off

thanks 😄

the "presets" the interface suggests are mostly based on comparisons at qualities like this: https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2024_01_25/visualizer.html?bimg=..%2Fclic_validation_2021_2022_2024%2Fimages%2Fcd272a9d4ae2d9eabbe58474facc4da00f280be40137597bf1e497f459eda284.png&btxt=original&rimg=encoded%2Fcd272a9d4ae2d9eabbe58474facc4da00f280be40137597bf1e497f459eda284.e6q016.avif&rtxt=AVIF+speed+6&limg=encoded%2Fcd272a9d4ae2d9eabbe58474facc4da00f280be40137597bf1e497f459eda284.e7q003.jxl.png&ltxt=JPEG+XL+effort+7

(your last link gives me an error)

that's a 10kb jxl and only a 6kb avif yet they have similar ssim and ssimulacra2 scores, so percentage-wise that image is a big win for avif

strange, it works for me. what error?

'the image .... cannot be displayed because it contains errors' (under firefox)

was it a jxl pic ?

it might be an error of the jxl plugin

https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2024_01_25/encoded/cd272a9d4ae2d9eabbe58474facc4da00f280be40137597bf1e497f459eda284.e6q016.avif

no they show the jxl as a png

only the avif is shown as an avif in that interface

https://storage.googleapis.com/demos.webmproject.org/webp/cmp/clic_validation_2021_2022_2024/images/cd272a9d4ae2d9eabbe58474facc4da00f280be40137597bf1e497f459eda284.png is the original

the avif works 😄

I'll do some benchmark_xl on this flower to understand better how a similar ssimulacra2 can be reached

anyway, if you compare mostly at such horrible qualities, avif is indeed good — being a video codec, it is designed to do something not too bad looking even at very low bitrates. This is not a quality anyone would want to use for a still image though.

(benchmark_xl with "jxl:d1.0:glacier" returns me a core dump with commit ae50ce4b)

I agree, at this resolution the image is ugly

file a bug?

I'm checking if I didn't messed something but I will

thanks 🙂

testing image codecs at such low qualities is like testing how well car can drive underwater — sure, if you design for it, you can make a car drive underwater, and that's quite impressive and nice, but it still doesn't mean it's a very relevant thing to test for most people's needs

or off-roads 😄 i'm looking at you, sellers of urban 4WD with a snorkel

```Encoding kPixels Bytes BPP E MP/s D MP/s Max norm SSIMULACRA2 PSNR pnorm BPP*pnorm QABPP Bugs ------------------------------------------------------------------------------------------------------------------------------------------------ jxl:d1.0:lightning 393 131272 2.6707357 6.189 20.943 1.34717049 87.27117148 41.28 0.59798734 1.597066130660 3.598 0 ```

among the results returned by benchmark_xl, is one of them a butteraugli score ?

max norm is butteraugli, pnorm is the 3-norm butteraugli

thank you 🙂

another small question in benchmark_xl, how to set the effort of avif ? `--codec=avif:q85:???`

s0/.../s9

thx

what metric?

here the comparison is at similar ssimulacra2 score

👍

I'm trying a new way to plot scores which will enable real comparison at similar quality... Hope it will be more readable

the q parameter seems to have no impact on the bpp with avif... shoundn't it represent quality in 0..100 ? in `--codec=avif:q85:s0`

you need to have avif >= 1.0.3 for it to do anything

and git libjxl

oki, I pulled libjxl with all the submodules, avif is not included ?

(that's when they added a `--quality` flag to avifenc, AFAIU)

it is the one of my system ?

yeah I am pretty sure it's the system one

oki, I'll try to derail it to a new version

is there a way to tell the libjxl cmake to pick the libavif available in the LD_LIBRARY_PATH instead of the one found in /lib/ ... ?

this trick worked for all projects I compiled up to now... that's strange

perhaps setting the PKG_CONFIG_PATH will help 😄

yeah something like that should work

(you also need to point it to the correct libavif at *compile time*)

make sense, but many projects link correctly only with the LD_LIBRARY_PATH, that's why I failed

success !

The battle of the codecs goes on. I've got news from the Pareto front regarding lossless compression.

do you have a link for better quality ?

For smallish images (smaller than 4 Mpx) not too much changes between libjxl 0.9 and libjxl 0.10

0.10 is out !?

I'll eventually clean up stuff and share the google sheets link, but the screenshot should be OK (if you open it in browser, not the discord previews)

indeed, my bad 😄 thanks for sharing

0.10 is not yet out but one of the main changes — streaming encoding — has been implemented

For large images the difference will be very noticeable:

nice

basically libjxl 0.10 beats libjxl 0.9 by a big margin here. On these images, the new e7 is faster than the old e4 and also 0.5 bpp smaller on average.

For large non-photographic images (this is some set of manga), the same thing is true:

what are the cyan plots very close from the purple ones ?

(zooming in a bit on the left part of that previous plot, since avif is clearly very far from the Pareto front)

the cyan is if you explicitly tell the encoder to use non-streaming mode — it then behaves more like the 0.9 encoder behaves (still slightly faster). But the default would be the turquoise points.

so what you can see here for these non-photographic images is that libjxl 0.9 was beating webp but not by a big margin. Now, libjxl 0.10 is beating webp more substantially.

(for photo, jxl was already beating webp substantially but now it beats it even harder)

I didn't follow the subject, is there a flag to explicitely require non-streaming mode ?

is encode speed real time or cpu time

i always complain about this

I assume it wouldn’t mention “8 threads” on the y axis if it were cpu time

well sometimes it scales differently

It's real time.

Basically before, lossless encoding was mostly single-threaded and now it properly parallelizes. But it also became more efficient because it uses less memory and uses it more locally so the speedup is actually more than 8x

(when running with 8 threads)

is it possible to have a max memory option?

also what about single threaded mode for all codecs? i think that might also be a claim, because it's possible to encode multiple images in parallel

and the opposite, on some even higher-core cpu, with more threads for encoders and just on very large images

Even though I don't think QOI and friends are particularly useful, it might be good to include them for when this is posted publicly.

right, but it would be kind of strange to have just this one graph then

my inference wasn’t pure deduction

then, instead of QOI it would be better to use fpnge or QOI just to compare that it's not a better format even compared to the old PNG (if use a different, faster encoder)

I used benchmark_xl, maybe we should add qoi and fpnge there...

It would be useful context, since a lot of people have heard about QOI and fpnge being very fast at their respective compression ratios. Also, did someone make an improved version of QOI at some point? I feel like I saw something new in that area, but I don't recall what it was called.

<https://github.com/nigeltao/qoir>

thanks

While looking I came across this https://github.com/jido/seqoia

yeah, there are many forks with some changes

Maybe I will just manually measure some of these

At the other end, you could also add various png optimizers (this is just default libpng)

but, optimizers can usually only optimize pngs, so it's not a very fair comparison or also it's basically the combined time spent on the first png encoding and then the time on optimization for qoi forks I don't think it's useful, those are very task specific codecs

Was the new e1 hitting 130 MP/s? May be worth having a value on the axis where the highest result is

I got about 380 MPx/s for e1, didn't measure accurately though (just one encode per image)

this is on my laptop, a macbook pro M3

Riight, I see now. Each 'block' on the chart is an order of magnitude increase with the intermediaries at 1/10ths

isn't threadless encode speed more relevant? because batch converting can be done via processes etc.

Both are relevant. Especially the higher speeds are probably more relevant to "live" encoding than bulk encoding.

Hm

Depends on the use case. For saving an image in an editor, or maybe in a camera, threaded makes sense. For batch encoding, single-threaded is indeed more relevant.

Yeah you need a log scale for speed since otherwise anything slower than e1 just is at the bottom of the plot 🙂

for webp it would be better to use `-z <int> ............... activates lossless preset with given level in [0:fast, ..., 9:slowest]` which enables lossless automatically and has a wider range and `-z 0` is also pretty balanced but, dont know if benchmark_xl has this

It only has m1-6. I guess we have webp experts in the room here. Does it make a difference to configure it with -z instead of -m? Besides having more steps of effort (but if that's the only difference, I don't really care, the range between m1 and m6 is not that huge anyway, compared to the range of efforts you have in libjxl and libaom)

I'm not really exactly sure though after looking around it seems like this is how mapping between the two is done. only problem is I don't really know how to read code that well but hope this helps either way!

oh I was looking at it wrong and just realized the table/array or whatever it's called changes both `-m` and `-q` based on `-z` from a preset selection (I thought it was doing some kinda weird scaling of the values because I didn't realize it had a value set for each of the 10/9 levels because my brain counted it wrong)

also cwebp is weird because `-q`/quality doesn't always mean visual quality since in the case of lossless it directly relates to effort. I know that `-m 6` with `-q 99` won't activate the brute force "lossless cruncher" but `-m 6` with `-q 100` will

there's also the whole thing of `-mt`(multithreading) being off by default which makes sense if you plan to mass encode WebPs with each core working on one image however in almost all other cases it doesn't make sense, also iirc cwebp can only use up to like 2 threads and it only spins up the second thread for specific things with the most impactful thing being the lossless cruncher which outputs the same result but in almost half the time with the second thread

does `-z 9` set both `-m 6` and `-q 100` though?

yes, and the image in my first message shows what each level of `-z` hooks up to

ohh, I see

also `-mt` is of limited use in `cwebp`

it is but It makes a big difference with `-z 9` since the lossless cruncher can be multithreaded

yeah, but it *only* helps with `-z 9`

...and even then, only 2 threads, no more

some stages of "analysis" can get done on the second thread but uhhh I'm not sure exactly how much of a difference it makes in the end and I don't know enough about cwebp to know when it even happens during encoding

honestly the most annoying part of cwebp is that you can't count on higher `-z` levels being the same size or smaller

I have images where `-z 3` is smaller than all higher levels <:SadOrange:806131742636507177>

This can happen also in libjxl. It's quite hard to avoid — unless you make each higher effort also try all lower efforts.

Similar to e10 using 100% CPU on brute force

well I think it's mostly an issue of "how often and how bad" than anything

if it only occurs rarely (like, 1 in 1000) and it's not bad when it does occur (< 1% savings) it's not so much of an issue

once 0.10 comes out I'm going to be doing a lot of benchmarks though, as I've got a lot of images I'd like to move over to <:JXL:805850130203934781>

The best way is to find out why it does so on higher efforts, such as this case https://discord.com/channels/794206087879852103/804324493420920833/1196974617982685318

Halved at g2 and then doubled at g3

Pareto front plot for lossy, where I adjusted the quality knob for each encoder+effort until the corpus average ssimulacra2 score was as close as possible to 85

So basically avif s1 has the same compression performance as jxl e4 but is 100 times slower, and avif s0 more or less matches jxl e6 in compression and is also 100 times slower

At reasonable speeds (avif s6+), it's a clear win for jxl

Note also that lossy webp is obsoleted by jpegli, which is faster than any webp effort and also better than any webp effort.

(this is for a specific quality point though, for lower quality it may be different)

Thank you for the graphs! I find it not easy to find convincing and unbiased representations. Where the quality / speed / size tradeoff should be plotted in 3d 🙃

is that xyb jpegli?

where on that charts mozjpeg would roughly be?

I dunno, what does benchmark_xl do by default when you select jpeg:enc_jpegli?

I could test but for high quality it didn't improve much on libjpeg-turbo in previous experiments, just a lot slower...

what's the x axis? bpp?

oops I cut the label, yes, bpp

also I mislabeled some of the avif points

at s0, I could get away with q76 where at s9 it needed q82 to get the same target corpus-avg ssimulacra2 score of 85

(jxl at e3/e4 seems to produce slightly higher ssimulacra2 scores than at higher effort settings when both are set to d1, but starting at e5 it's relatively consistent)

less consistent quality, makes sense tbh

i didn't try to measure consistency of quality _across_ images here, this is just aligned on the corpus average ssimu2 score, which actually favors inconsistent codecs like webp and avif since basically while their average score is the same as jxl's (around 85 here), they reach it by getting a score of 90+ on the easy images and a much lower score on the hard images, so they save lots of bytes on the hard images (by not delivering the desired quality)

oops again, those s0 points are not for the exact same corpus (accidentally included some other images)

here's the correct plot

same info in table form:

table also shows decode speed and the actual metric scores — the q-settings were chosen to get close to ssimulacra2=85 but there's of course still some variation (in jxl in principle I could get rid of that by tweaking the distance, in most others the q-settings have integer steps so you can't get arbitrarily close)

this is using 8 threads on a macbook M3, and speeds were not measured accurately (just a single iteration)

(since I'm mostly interested in orders of magnitude, measuring very accurately is not really needed imo)

so, basically, we have: - same quality setting for all images, picking the one that yields the desired ssimulacra2 score on average (favours inconsistent codecs) but in principle, we could also do one of these: - individual quality setting for each image, so that each image has the desired ssimulacra2 score (corrects for inconsistent codecs) - same quality setting for all images, but pick such that the _worst_ ssimulacra2 is the desired one (_penalises_ inconsistent codecs)

I don't know how the chrome team was benchmarking that avif decode speed was so great compared to jxl decode speed, but the results I'm getting seem to show something different

That's right. Setting it individually per image is probably the most fair thing to do, but it's not a very realistic/typical way in which people use codecs. Often a single setting is determined based on looking what it does to a few images, and then that setting is used for all images. So the third thing (aligning on worst case, or let's say on p10), which penalizes inconsistent codecs, is actually the most relevant thing imo, but here I'll do the first thing (aligning on average, which favors inconsistent codecs) just to show that even when trying to favor avif, it still doesn't look good 🙂

I'll try to make such plots also for some "medium quality" point (averaging at ssimulacra2=70) and one for "camera quality" (something like d0.5).

can you select MT or not for avif from benchmark_xl ?

yes, add something like `:log2_cols=2:log2_rows=2` to make it MT

avif is a bit funky: you have to manually specify how it does tiling, and you need to encode MT in order to be able to decode MT

I'm assuming these two parameters set like that mean that it splits the image in tiles such that there are 2^log2_cols tiles horizontally and 2^log2_rows tiles vertically, so in 16 parts which should be enough when doing MT with 8 threads

and it makes quality/density worse of course

Thanks 😅 i couldn't have guessed

I do kind of like the calibration of this new avif quality scale, avif q50 (at e0) is actually a quality that I would call "medium quality", and it corresponds to jxl d2.6, webp q76, libjpeg-turbo q70

oh, so if one is fine with needing about a minute instead of 10 seconds for a Facebook-size medium-quality image, AVIF is actually kind of competitive

yes, at the lower qualities avif is competitive in compression, if you have the cpu time to throw at it

I dunno about others but for Cloudinary anything slower than default effort avif (s6) is too slow — the jump from s6 to s5 is quite steep, too

At lower qualities, avif outperform jxl for ssimulacra2 scores. But does it in subjective tests too? For ssimulacra2 scores in 60-70

if you're prepared to go to the extremely slow speeds, yes (we don't have a ton of data about these very slow speed settings since they're unusable to us, but the limited data we have does show that they are also subjectively indeed better)

But why! 😭 avif also uses some kind of dct based compression

basically the situation is like this: - if you are fine with using a LOT of encode cpu time, **and** you want relatively low quality, **and** you don't need progressive decode, then AVIF can save you a few percent compared to JPEG XL - in all other cases, JPEG XL matches or beats AVIF (by a big margin if you want reasonable speed **or** better than mediocre quality)

Here is how I encode AVIF for highest efficiency at very high qualit (at the expense of threading due to row-mt 0): `avifenc -d 10 -a tune=ssim -a quant-b-adapt=1 -a enable-chroma-deltaq=1 -a deltaq-mode=2 -j 8 -a row-mt=0 -s 0 -a cq-level=14 --cicp 1/2/1`

What are the ssimulacra2 scores and the compression ratios for this?

No idea... Deltaq-mode 2 is actually usually slightly disliked by ssimulacra2, btw, unless it isn't, overall it definitely increases consistency, almost as well as deltaq-mode 3, but without making things blurry (which it definitely does together with tune ssim). But quality consistency is the big issue with AVIF, and the one thing where JXL is always straight up superior. When doing automatic conversion to AVIF, you ideally want to do target quality encoding, performing multiple encodes and measuring the results. But when just comparing individual images, this holds up very well with JXL even at very high quality, but depends a lot on the specific content of course.

How long does it take to encode a 12 Mpx image with that setting? 😛

well, time to find out I guess

Why tune ssim?

Also why cicp 1/2/1?

That's bt709 matrix, unspecified primaries, bt709 trc

Always better.

By default, avifenc uses bt.601 color matrix, which is dumb for content in sRGB/BT.709 gamut, as the BT.709 will just perform better.

no

that's bt.709 primaries, unspecified trasnfer, bt.709 matrix

while with ffmpeg cicp is MC/CP/TC, with libavif it's CP/TC/MC

because for people who work on image and video stuff, agreeing with other projects would probably be fatal, better to just die I guess

Usually the order that's actually used during encoding is chosen. Or sometimes decoding.

And unless tonemapping is done, gamut reduction happens first, color matrix last during encoding.

Does avifenc convert arbitrary input to that space or is the only conversion it does rgb2yuv?

I thought it was the latter

i.e. no gamut reduction, just information about what the pixel data mean

So if you give it P3 input you are reinterpreting it as sRGB?

that’s my understanding of it

only the specified matrix influences encoding, the rest is just specification of color metadata

Metadata that can be wrong, if the input is not using those primaries...

although if the input has an ICC profile, it will _also_ include it unless you specify `--ignore-icc`

Oh

I’m not sure they specify which one takes precedence if both are present

but to be on the safe side, whenever I specify --cicp, I also pass --ignore-icc

Yes, that's why it normally shouldn't be specified. Maybe I should make a feature request to ask if they can use an optimal color matrix by default for common color gamuts...

It's quite annoying how video folks basically just say "color is your problem, we just encode unknown sample data here"

there’s this joke that “NTSC” stands for “never the same color”

well, avifenc does properly recognize and apply color metadata

just always encoded in bt.601 color matrix by default

How do you indicate full range vs tv range?

`-r,--range RANGE : YUV range [limited or l, full or f]. (JPEG/PNG only, default: full; For y4m or stdin, range is retained)` <:Thonk:805904896879493180>

Ah ok it already defaults to full, that's good

since when does cjxl not thread at effort 9 by default

Encoding a 60MP image at effort 9 takes 200 seconds on a Ryzen 7800X3D...

how much ram

effort 7 takes 4 seconds <:Thinkies:987903667388710962>

64GB

that's how much it uses or how much you have?

how much I have

it uses around 16GB or so

effort 8 is single-threaded, too <:Thinkies:987903667388710962>

for lossy? there is no real reason to use e9 for lossy

let me have fun 😠

effort 7: 4s effort 8: 46s effort 9: 200s

and at least effort 8 and 9 don't thread on this 60MP PNG image!!

5-6 is also typically not worse than 7 for the same size, but may not be as accurately hold a given butteraugli quality

effort 7 is already absurdly fast

and e9 can be worse subjectively, though maybe that's already been fixed

e8 and e9 target a signficantly different quality, I guess those are more consistent in quality?

anyway, what's going in with the threading, this looks like a serious bug to me

Should be better in current git version

But I don't think e8/e9 are that useful for lossy

well, it's not like cjxl threads badly, it doesn't thread at all, exactly one thread the whole time...

not a bug, just some greedy methods are difficult to parallelize

but it says it will use 16 threads, and it's a 16 thread machine

I am quite sure that effort 9 used to use more than 1 thread...

e8/e9 try too hard reaching a given butteraugli score imo. Optimizing too much for a metric is risky, no metric is perfect...

Currently I'm easily beating cjxl effort 8 distance 1 with avifenc effort 3...

For me current git e9 does parallelize

I'll send the source...

I got almost 1 Mpx/s at lossy e9 with 8 threads

Aaah wait

You may have an image with lots of patches

Patches can mess up speed by a lot

what are patches...

If that sky is solid white in some regions, patch heuristics will be wasting nonparallelized time on it

efforts 8/9 do thread a little, actually, but only a fraction of the time...

Try with --patches 0 to see if that helps

I don't think it is, there is some visible noise throughout

Can't see it on my phone on that discord preview 🙂

well, I need to zoom in on my 4K monitor to see it, haha

definitely not signficantly

btw, I just updated jxl, and now memory consumption is a lot lower <:Thinkies:987903667388710962>

effort 7 threads decently well

and effort 8 and 9 probably too, for the part that effort 7 does as well

if streaming mode for lossy in current git is still disabled for e7 and slower, then for e6 memory consumption will be even lower and most likely better multithreading

how would you get the version of avif used by benchmark_xl (the one linked to ?), ldd gives me access to a path, but I don't know the best way to extract a version id from this

`avifenc --version`, assuming your avifenc is linking to the same libavif

pas bête

I got a feedback from the author : https://github.com/webmproject/codec-compare/issues/3

"Not super crisp, but can be displayed as a background for example." — if you really want a blurry mess to use as a background, just apply some gaussian blur (or some bilateral filter if you like to preserve edges) before encoding the image, and you'll see it encodes way better in any codec. Using image encoders to do the blurring for you is kind of silly.

agreed 😄 or resize the original picture if you don't plan to look at it

Or use JXL art ;P

Though maybe this is something we should just start doing at ridiculous distances (say, d > 5) — first apply some heavy EPF and then encode (as opposed to encoding the input as-is and only doing EPF decode-side). Should produce "better looking" images even if it's obviously a bad idea in terms of fidelity.

Reminded me of my thought regarding low quality jpeg inputs. If EPF could be retroactively applied, but seemed out of scope at the time

you want a "cheat mode" optimized only for benchmark ? like WV ?

WV sounds like WB's evil twin, who sacrifices preservation to win at all costs

could be interesting though, activable only with a flag, you get agressive noise filtering (like bilateral) before encoding 😄

I consider d > 4 basically settings that are not relevant for real usage but only for benchmark/testing scenarios where people want to see what happens if you totally overcompress an image (and they somehow think this is useful information and says something about what happens at more reasonable qualities). So I don't really care if we do something funky at such distances.

If I recall the largest 256x256 VarDCT blocks aren't currently used yet either, although I don't know if they would have much of an effect

(or rather 128x256 if I recall)

at which distance jxl and avif crosses ssimulacra scores ?

seems like anything above 64x64 isn't used by libjxl's encoder currently https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit#slide=id.gad3f818ca8_0_20

Even more room for improvement then

> I noticed that your second plot only has 2521 comparisons, which may signal low confidence in the results due to the lack of data points. that's... an interesting statement

> I tried to minimize any bias in the default settings: > - The full input quality setting ranges are used.

so is that

> > I guess < 0.1bpp can not seriously be used for display > > From the <0.1bpp plot: > Top left point: bpp < 0.03 > Right-most point: bpp < 0.03 > Not super crisp, but can be displayed as a background for example.

...

So, we just cap the maximum distance in libjxl and problem solved, we win all benchmarks, horray!

or, as suggested wb, we enable agressive epf after d 4.0 in order to pump up the SSIM score (at the expense of fidelity)

haha just capping distance at d4 would be fun — it would mean there are just no data points to show for the very low qualities 🙂

btw avif and especially webp are benefitting from the other side of that phenomenon: for some images they just cannot reach a certain score so the comparison tool has no match to show for that image, and it doesn't count — even if I would consider it a quite big win for jxl when this happens 🙂

if funky stuff is changed/done to libjxl at higher distances to improve SSIM then it would probably be a good idea to comment the new behavior/code with something like "// Improve SSIM" or something so it's easier to find in the future.

and put it behind a flag in the command line (or a flag at compile time too :D)

as in enabled or disabled by default?

that reminds me

like : `cjxl --ssim-cheat -d 5.0 tutu.png` and also `cmake -DENABLE_SSIM_CHEAT`

(took me a second to find this) reminds me of this toggle that exists in Nvida's GPU video encoder https://docs.nvidia.com/video-technologies/video-codec-sdk/11.1/nvenc-video-encoder-api-prog-guide/index.html#spatial-aq

"``` Although spatial AQ improves the perceptible visual quality of the encoded video, the required bit redistribution results in PSNR drop in most of the cases. Therefore, during PSNR-based evaluation, this feature should be turned off. ```"

libjxl uses butteraugli for internal tuning, not ssimulacra 2.1

that's what I'm writing, I'll invite him here, easier to discuss

maybe change it a bit so they aren't *required* to find the link on another website, A rewording something like this might be better? " "( link can be found here: [jpegxl.info](https://jpegxl.info/), or here's a direct link if you prefer: https://discord.gg/DqkQgDRTFu ) "

oh it seems like they have seen your comment now

that's what i did first but I didn't wanted the raw discord link to be published outside official pages... (this is a not very convincing argument, I'm not convinced myself :D)

the link possibly getting picked up on github by bots or something I guess could be a worry. The thing is iirc the link has been posted into github comment sections before.

github does let you edit comments but they have already seen it so who knows if they will look at the comment again and be convinced to join for discussion 🤷

Interesting. For this set of not-so-large images (1 Mpx each), avif beats heic:

While for this set of larger images (11 Mpx on average), heic beats avif:

how...

if its x265 for heic it's not surprising, for higher qualities x265 is still better than any av1 encoder and images usually require much higher quality than video

this is libheif which indeed uses x265 for heic

and yes this is at ssimulacra around 85 (on average) which is a rather high quality, around d1

maybe the nature of the large and small images is just different?

Sure, the large ones have more camera noise and less entropy per pixel, the small ones are downscales from high res photos so they have less noise but more entropy per pixel.

Also I guess that Daala set was heavily used while designing Daala and av1, so maybe avif is performing a bit better than expected on that corpus 🙂

The famous "i didn't test it on something else" bias

Interesting... What would give the best result in term of size / quality ratio : reduce a photo by a factor of 2, encode it in high quality and display it as this. Or encode the original file, with a quality on par with the first test when viewed resized by a factor of 2?

it's complicated...

Agreed

You usually do not want to encode at resolutions higher than target resolution, because detail will be preserved and never displayed.

wasting a lot of bitrate

or file size, here

that tends to depend on the bitrate you target

and the format

and the downscaling method

Generally I wouldn't downscale as long as you want to remain in the "reasonable quality" range. For web delivery of course you should downscale to fit the layout of the page (taking into account that css pixels might be more than 1 pixel, though)

😄 if distance is 0.01, 0.02 or 0.03 cjxl gives an image bigger than the original png. And a negative correlation between the effort and the compression

is the distance rounded internally ? to how many decimals ?

Distances below 0.05 probably don't make sense on 8-bit input, and probably a lot of encoder heuristics are not well-tuned for distances below 0.3 or so

thanks, I'll take 0.3 as a lower limit

0.1 should still be ok, but I wouldn't go lower

I only just thought, does streaming mode have any effect on e10? (e11 now) Had the old idea of running it on a small image, saving the parameters it finds and then applying to other/larger similar images. Although that would require PRs for the parameter saving

I too like the idea of for example "cjxl -v -e 10" printing the selected best parameters

That would be nice but I guess we'll need some API for verbosity of libjxl — currently libjxl doesn't print anything to stdout except when compile-time verbosity is set to something nonzero and then it just always prints stuff. Basically we don't want to ship (all) debug output strings in release builds, but we could still do something like having a runtime verbosity in addition to a compile-time verbosity, or something.

The cleaner way would maybe to not let libjxl print stuff itself to stdout, but let it return some string as part of the return status or something.

maybe at least in benchmark_xl

Setting a custom logger function would be better. Application remains in full control.

Or a dedicated structure

Most combinations of settings are useless, meaning e11 does a lot of work for nothing. It can also find obscure configurations (particularly specific predictors) which work for a single image, but don't generalize. Larger images prefer g3, smaller images less so. Patches are generally bad.

this is not the type of look i did pioirirrty on my phone

I wonder about how things have evolved over the years 2021-2024. Is AVIF getting closer to JPEG XL? Or JPEG XL further increased distance?

Did a few quick tests on an 8K screenshot with/without streaming mode on a Ryzen 7 1700 Starting with e1, performance was the same between 0.9.1 and 0.10.0 ``` JPEG XL encoder v0.10.0 d990a37 [AVX2,SSE2] Encoding [Modular, lossless, effort: 1] Compressed to 34592.2 kB (8.341 bpp). 7680 x 4320, 103.346 MP/s [103.35, 103.35], 1 reps, 16 threads. PeakWorkingSetSize: 324.6 MiB PeakPagefileUsage: 416.6 MiB Wall time: 0 days, 00:00:00.423 (0.42 seconds) User time: 0 days, 00:00:00.109 (0.11 seconds) Kernel time: 0 days, 00:00:02.093 (2.09 seconds) ``` But Streaming input practically halved memory usage ``` JPEG XL encoder v0.10.0 d990a37 [AVX2,SSE2] Encoding [Modular, lossless, effort: 1] Compressed to 35417.2 kB (8.540 bpp). 7680 x 4320, 102.867 MP/s [102.87, 102.87], 1 reps, 16 threads. PeakWorkingSetSize: 230.4 MiB PeakPagefileUsage: 227.3 MiB Wall time: 0 days, 00:00:00.349 (0.35 seconds) User time: 0 days, 00:00:00.156 (0.16 seconds) Kernel time: 0 days, 00:00:02.000 (2.00 seconds) ```

Moving on to e3 ``` JPEG XL encoder v0.9.1 b8ceae3 [AVX2,SSE4,SSSE3,SSE2] Encoding [Modular, lossless, effort: 3] Compressed to 26824.0 kB (6.468 bpp). 7680 x 4320, 15.367 MP/s [15.37, 15.37], 1 reps, 16 threads. PeakWorkingSetSize: 2.173 GiB PeakPagefileUsage: 2.529 GiB Wall time: 0 days, 00:00:02.258 (2.26 seconds) User time: 0 days, 00:00:03.234 (3.23 seconds) Kernel time: 0 days, 00:00:12.031 (12.03 seconds) ``` Now 0.10.0 makes a difference without Streaming input ``` JPEG XL encoder v0.10.0 d990a37 [AVX2,SSE2] Encoding [Modular, lossless, effort: 3] Compressed to 26714.8 kB (6.442 bpp). 7680 x 4320, 20.714 MP/s [20.71, 20.71], 1 reps, 16 threads. PeakWorkingSetSize: 469 MiB PeakPagefileUsage: 525.6 MiB Wall time: 0 days, 00:00:01.704 (1.70 seconds) User time: 0 days, 00:00:04.906 (4.91 seconds) Kernel time: 0 days, 00:00:13.250 (13.25 seconds) ``` Streaming input makes roughly the same dent in memory usage as on e1 ``` JPEG XL encoder v0.10.0 d990a37 [AVX2,SSE2] Encoding [Modular, lossless, effort: 3] Compressed to 26714.8 kB (6.442 bpp). 7680 x 4320, 20.687 MP/s [20.69, 20.69], 1 reps, 16 threads. PeakWorkingSetSize: 373.9 MiB PeakPagefileUsage: 333.9 MiB Wall time: 0 days, 00:00:01.626 (1.63 seconds) User time: 0 days, 00:00:04.687 (4.69 seconds) Kernel time: 0 days, 00:00:12.406 (12.41 seconds) ```

And now for e7, AKA default lossless ``` JPEG XL encoder v0.9.1 b8ceae3 [AVX2,SSE4,SSSE3,SSE2] Encoding [Modular, lossless, effort: 7] Compressed to 22487.1 kB (5.422 bpp). 7680 x 4320, 0.277 MP/s [0.28, 0.28], 1 reps, 16 threads. PeakWorkingSetSize: 2.126 GiB PeakPagefileUsage: 2.475 GiB Wall time: 0 days, 00:01:59.703 (119.70 seconds) User time: 0 days, 00:00:40.312 (40.31 seconds) Kernel time: 0 days, 00:02:00.109 (120.11 seconds) ``` Much larger impact ``` JPEG XL encoder v0.10.0 d990a37 [AVX2,SSE2] Encoding [Modular, lossless, effort: 7] Compressed to 22456.5 kB (5.415 bpp). 7680 x 4320, 4.288 MP/s [4.29, 4.29], 1 reps, 16 threads. PeakWorkingSetSize: 470.8 MiB PeakPagefileUsage: 519.6 MiB Wall time: 0 days, 00:00:07.837 (7.84 seconds) User time: 0 days, 00:00:04.375 (4.38 seconds) Kernel time: 0 days, 00:01:34.843 (94.84 seconds) ``` Once again, Streamed input is a fixed reduction in memory ``` JPEG XL encoder v0.10.0 d990a37 [AVX2,SSE2] Encoding [Modular, lossless, effort: 7] Compressed to 22456.5 kB (5.415 bpp). 7680 x 4320, 4.217 MP/s [4.22, 4.22], 1 reps, 16 threads. PeakWorkingSetSize: 377.7 MiB PeakPagefileUsage: 337.5 MiB Wall time: 0 days, 00:00:07.890 (7.89 seconds) User time: 0 days, 00:00:04.843 (4.84 seconds) Kernel time: 0 days, 00:01:34.171 (94.17 seconds) ```

I'm a bit surprised that bitrate went down... not complaining ofc

also surprised that you have a 10x reduction in *user* time

Running e9 at the moment, naturally taking half my lifetime on 0.9.1

40 minutes on 0.9.1 for e9 (Almost 2500 seconds exactly) ``` JPEG XL encoder v0.9.1 b8ceae3 [AVX2,SSE4,SSSE3,SSE2] Encoding [Modular, lossless, effort: 9] Compressed to 21333.5 kB (5.144 bpp). 7680 x 4320, 0.013 MP/s [0.01, 0.01], 1 reps, 16 threads. PeakWorkingSetSize: 4.069 GiB PeakPagefileUsage: 4.114 GiB Wall time: 0 days, 00:41:39.986 (2499.99 seconds) User time: 0 days, 00:07:54.734 (474.73 seconds) Kernel time: 0 days, 00:35:54.125 (2154.12 seconds) ``` Naturally a massive improvement for 0.10.0 ``` JPEG XL encoder v0.10.0 d990a37 [AVX2,SSE2] Encoding [Modular, lossless, effort: 9] Compressed to 21367.2 kB (5.152 bpp). 7680 x 4320, 0.209 MP/s [0.21, 0.21], 1 reps, 16 threads. PeakWorkingSetSize: 551 MiB PeakPagefileUsage: 602.7 MiB Wall time: 0 days, 00:02:39.119 (159.12 seconds) User time: 0 days, 00:00:08.218 (8.22 seconds) Kernel time: 0 days, 00:33:38.203 (2018.20 seconds) ``` And Streaming input keeping it under half a GB of memory ``` JPEG XL encoder v0.10.0 d990a37 [AVX2,SSE2] Encoding [Modular, lossless, effort: 9] Compressed to 21367.2 kB (5.152 bpp). 7680 x 4320, 0.206 MP/s [0.21, 0.21], 1 reps, 16 threads. PeakWorkingSetSize: 461.5 MiB PeakPagefileUsage: 411.7 MiB Wall time: 0 days, 00:02:40.763 (160.76 seconds) User time: 0 days, 00:00:07.656 (7.66 seconds) Kernel time: 0 days, 00:33:43.906 (2023.91 seconds) ```

Interestingly bitrate went back up on e9

there's something very broken in the threading implementation on Windows, btw - those Wall/User times don't make any sense

that I am less surprised about

I got those times using this, so I wouldn't be surprised if they're inaccurate compared to native Linux https://github.com/cbielow/wintime

Here's the start and end times of 0.9 vs 0.10, removed from those results due to Discord's character limit e1 ``` 0.9 Creation time 2024/02/21 09:12:46.207 Exit time 2024/02/21 09:12:46.831 0.10 Creation time 2024/02/21 09:29:14.263 Exit time 2024/02/21 09:29:14.687``` e3 ``` 0.9 Creation time 2024/02/21 09:14:50.419 Exit time 2024/02/21 09:14:52.677 0.10 Creation time 2024/02/21 09:15:02.020 Exit time 2024/02/21 09:15:03.724 ``` e7 ``` 0.9 Creation time 2024/02/21 09:15:56.284 Exit time 2024/02/21 09:17:55.987 0.10 Creation time 2024/02/21 09:18:16.169 Exit time 2024/02/21 09:18:24.007 ``` e9 ``` 0.9 Creation time 2024/02/21 09:48:07.953 Exit time 2024/02/21 10:29:47.940 0.10 Creation time 2024/02/21 10:35:39.433 Exit time 2024/02/21 10:38:18.553 ```

And a quick VarDCT test for good measure ``` JPEG XL encoder v0.9.1 b8ceae3 [AVX2,SSE4,SSSE3,SSE2] Encoding [VarDCT, d1.000, effort: 7] Compressed to 4613.3 kB (1.112 bpp). 7680 x 4320, 1.325 MP/s [1.33, 1.33], 1 reps, 16 threads. PageFaultCount: 1153320 PeakWorkingSetSize: 1.631 GiB QuotaPeakPagedPoolUsage: 35.53 KiB QuotaPeakNonPagedPoolUsage: 80.48 KiB PeakPagefileUsage: 2.319 GiB Creation time 2024/02/21 11:45:15.585 Exit time 2024/02/21 11:45:40.726 Wall time: 0 days, 00:00:25.141 (25.14 seconds) User time: 0 days, 00:01:05.703 (65.70 seconds) Kernel time: 0 days, 00:01:43.859 (103.86 seconds) ``` Slightly slower yet more efficent ``` JPEG XL encoder v0.10.0 d990a37 [AVX2,SSE2] Encoding [VarDCT, d1.000, effort: 7] Compressed to 4273.9 kB (1.031 bpp). 7680 x 4320, 1.193 MP/s [1.19, 1.19], 1 reps, 16 threads. PageFaultCount: 949312 PeakWorkingSetSize: 463.8 MiB QuotaPeakPagedPoolUsage: 35.23 KiB QuotaPeakNonPagedPoolUsage: 20.45 KiB PeakPagefileUsage: 569.3 MiB Creation time 2024/02/21 11:45:56.165 Exit time 2024/02/21 11:46:24.065 Wall time: 0 days, 00:00:27.900 (27.90 seconds) User time: 0 days, 00:01:19.593 (79.59 seconds) Kernel time: 0 days, 00:01:53.531 (113.53 seconds) ``` And Streaming input once again keeping it under half a GB ``` JPEG XL encoder v0.10.0 d990a37 [AVX2,SSE2] Encoding [VarDCT, d1.000, effort: 7] Compressed to 4273.9 kB (1.031 bpp). 7680 x 4320, 1.160 MP/s [1.16, 1.16], 1 reps, 16 threads. PageFaultCount: 1054309 PeakWorkingSetSize: 368.1 MiB QuotaPeakPagedPoolUsage: 225.1 KiB QuotaPeakNonPagedPoolUsage: 20.31 KiB PeakPagefileUsage: 378 MiB Creation time 2024/02/21 11:51:11.688 Exit time 2024/02/21 11:51:40.306 Wall time: 0 days, 00:00:28.618 (28.62 seconds) User time: 0 days, 00:01:16.687 (76.69 seconds) Kernel time: 0 days, 00:01:53.703 (113.70 seconds) ```

I had already observed pretty bad scaling thread scaling from windows builds yesterday

so this is not surprising

e9 lossy hit 8GB of RAM for around 20 seconds before I killed the process, streaming input resulted in this ``` JPEG XL encoder v0.10.0 d990a37 [AVX2,SSE2] Encoding [VarDCT, d1.000, effort: 9] Compressed to 4272.0 kB (1.030 bpp). 7680 x 4320, 1.125 MP/s [1.13, 1.13], 1 reps, 16 threads. PageFaultCount: 996673 PeakWorkingSetSize: 432.4 MiB QuotaPeakPagedPoolUsage: 225.1 KiB QuotaPeakNonPagedPoolUsage: 20.71 KiB PeakPagefileUsage: 436.3 MiB Creation time 2024/02/21 11:59:36.841 Exit time 2024/02/21 12:00:06.357 Wall time: 0 days, 00:00:29.515 (29.52 seconds) User time: 0 days, 00:01:19.984 (79.98 seconds) Kernel time: 0 days, 00:01:57.781 (117.78 seconds) ```

In all lossless cases it actually scaled up to 100% CPU usage, although I assume you mean the speed/thread count increase

... I am not sure why it worked at all

yup

could just be that the speed measurement is broken, of course

Well whatever happened, it seemed to work pretty well haha

Ohh, wait...

No, nevermind... I was thinking maybe patches and streaming disabling that, but streaming input is seperate so they're disabled anyway.... I think....

I'm mostly looking forward to 0.10.0 getting into Squoosh, then I can test on my phone too without immediately hitting an out of memory error

Do they even maintain that? It's got so many PR's

<@228116142185512960> might be able to shed some light on that

from 2:30 to 30 seconds with cjxl v0.10.0, pretty significant improvements <:PepeOK:805388754545934396>

Ok. That's really impressive for the modular. <:Hypers:808826266060193874> ``` PS > [PSCustomObject]@{v092_s = (Measure-Command { v092/cjxl 0.jpg 092j.jxl }).TotalSeconds; v0100_s = (Measure-Command { v0100/cjxl 0.jpg 0100j.jxl }).TotalSeconds } | ft JPEG XL encoder v0.9.2 41b8cda [AVX2] Encoding [JPEG, lossless transcode, effort: 7] Compressed to 13369.8 kB including container JPEG XL encoder v0.10.0 19bcd82 [AVX2] Encoding [JPEG, lossless transcode, effort: 7] Compressed to 13369.8 kB including container v092_s v0100_s ------ ------- 0,96 1,07 PS > [PSCustomObject]@{v092_s = (Measure-Command { v092/cjxl 0.png 092j.jxl }).TotalSeconds; v0100_s = (Measure-Command { v0100/cjxl 0.png 0100j.jxl }).TotalSeconds } | ft JPEG XL encoder v0.9.2 41b8cda [AVX2] Encoding [VarDCT, d1.000, effort: 7] Compressed to 7017.0 kB (1.128 bpp). 5760 x 8640, 2.985 MP/s [2.99, 2.99], 1 reps, 16 threads. JPEG XL encoder v0.10.0 19bcd82 [AVX2] Encoding [VarDCT, d1.000, effort: 7] Compressed to 6963.2 kB (1.119 bpp). 5760 x 8640, 3.349 MP/s [3.35, 3.35], 1 reps, 16 threads. v092_s v0100_s ------ ------- 17,29 15,51 PS > [PSCustomObject]@{v092_s = (Measure-Command { v092/cjxl 0.png -m 1 -d 0 092j.jxl }).TotalSeconds; v0100_s = (Measure-Command { v0100/cjxl 0.png -m 1 -d 0 0100j.jxl }).TotalSeconds } | ft JPEG XL encoder v0.9.2 41b8cda [AVX2] Encoding [Modular, lossless, effort: 7] Compressed to 36444.0 kB (5.858 bpp). 5760 x 8640, 0.423 MP/s [0.42, 0.42], 1 reps, 16 threads. JPEG XL encoder v0.10.0 19bcd82 [AVX2] Encoding [Modular, lossless, effort: 7] Compressed to 36064.1 kB (5.797 bpp). 5760 x 8640, 15.967 MP/s [15.97, 15.97], 1 reps, 16 threads. v092_s v0100_s ------ ------- 118,39 3,92 ```

how did you toggle streaming?

Streaming input is seperate to streaming encoding

Although I mostly used the previous release (0.9) to measure with/without streaming encoding

But you have 2 runs for 0.10.0, with and without streaming. I thought there are no flags to toggle it

or is streaming input turned off by default and the flag enables it?

you can do `cjxl --streaming_input` but it requires ppm input atm — that will mostly impact memory though, not so much speed

> Streaming input is seperate to streaming encoding

All it does is feed the input image in a few pixels at a time, the only difference in those runs was around 200MB of RAM. The ***actual*** streaming was 0.9 versus either 0.10 runs

so, it looks like `e 7` is the fastest cjxl speed that (on average) beats cwebp's `z 9`: ``` eal rbp rrt lvl cpu mem 1 cjxl v0.10.0 1 1.1997896 0.0371686 1 Inf 30657.19 2 cjxl v0.10.0 2 0.9755219 0.3651210 2 17.3375226 244023.45 3 cjxl v0.10.0 3 1.0254203 0.5425397 3 19.2356366 243855.98 4 cjxl v0.10.0 4 0.8880205 1.1001987 4 21.2395977 274834.79 5 cjxl v0.10.0 5 0.8284132 1.1617858 5 20.9716307 267952.03 6 cjxl v0.10.0 6 0.8102338 1.4223768 6 21.1074809 274365.39 7 cjxl v0.10.0 7 0.7574005 1.8606330 7 21.2205659 283921.00 8 cjxl v0.10.0 8 0.7391769 5.4232358 8 22.1395608 536870.36 9 cjxl v0.10.0 9 0.7178132 24.2512006 9 22.4154769 633623.88 10 cjxl v0.10.0 10 0.7209015 26.4382343 10 22.3001730 634870.07 11 cwebp 1.3.2 0 1.0000000 1.0000000 0 0.9691077 151040.92 12 cwebp 1.3.2 1 0.8719663 7.1135803 1 0.9942246 208628.52 13 cwebp 1.3.2 2 0.8479628 8.1897254 2 0.9948469 221764.80 14 cwebp 1.3.2 3 0.8219334 10.8388722 3 0.9956001 224679.29 15 cwebp 1.3.2 4 0.8211225 11.3688304 4 0.9960652 223148.79 16 cwebp 1.3.2 5 0.8190413 10.9181859 5 0.9961888 221839.46 17 cwebp 1.3.2 6 0.8163690 14.8374114 6 0.9964598 219571.72 18 cwebp 1.3.2 7 0.8149141 17.9221753 7 0.9971695 218806.12 19 cwebp 1.3.2 8 0.8082165 23.0884559 8 0.9975708 262045.31 20 cwebp 1.3.2 9 0.7912807 74.0762189 9 1.8664396 519069.50```

which is good, because after that memory use goes up massively in cjxl, but `e 7` is still comparable to `z 8` (in mem use)

what images (and OS/CPU) are you using?

in particular that "cpu" column looks a bit weird

ah, it's a "number of CPUs used"

these are lossless screenshots I've taken from various games, running linux on a 7950X3D

ok, I see

it's a bit weird that the rbp is higher for effort 3 than 2... <:WhatThe:806133036059197491>

that's nonphoto for you

-e3 is tuned for photographic content

okay, fair enough

did you run cwebp with or without `-mt`? because `-z 9` benefits speed wise with it and produces the same final output

all of those are with `-mt` (you wouldn't see 1.8 CPU use with `-z 9` without it)

it's kind of crazy how much faster `e 10` is compared to `z 9` though, but it shows the power of good MT <:YEP:808828808127971399>

anyway, I'll have some graphs in a moment, and some other stats that I need to investigate manually

yeah, `e 1` is so fast that `time` doesn't really provide enough resolution of real time used to get a useful measurement, but everything else looks usable:

being too fast is a good problem to have though <:Hypers:808826266060193874>

peak memory use looks fairly comparable at most levels too, though cjxl's data is much more tightly grouped at some levels

you can use `--num_reps`

that's a lot more effort to script (if I just use it for `e 1`) or hours of additional testing (if I don't); but I think we can all agree that `e 1` lossless is "pretty damn fast" and certainly blows the pants off of cwebp `z 0`:

of course, still take the e 1 numbers there with a boulder of salt as several of the images had a real time of '0'

really interesting how `e 9` on average is smaller than `e 10`, but I assume that's again because the presets are tuned to photo?

I'm not sure actually...

how similar are different regions of your images?

uhhh, that's extremely tough to say...

it's a rather eclectic collection of screenshots, from > 100 different games

how are you getting multi threading on `-e 10`?

use both `--streaming_input` and `--streaming_output`

but it's basically `-e 9`

that's kind of weird, since `-e 10` uses global optimisations, should it work with that?

well in my case it was (usually) worse than e 9 🤷‍♂️

so maybe something isn't working properly?

how much worse, in kB?

`-e 9` is `-e 10` without streaming, though there were some changes later on

I've noticed it's worse by around 100B with `--patches 1` so I wonder if that's what you are seeing

uhh, not sure exactly; I tend to look at differences in %, not KB

and that was with a 1500x2250 image. on 10240x5760 it's 25 kB smaller (around 0.5%)

probably `--patches` are the difference because not optimized for multithreading/streaming?

and the variable predictor will also be off, already merged

yeah, so `-e 9` in v0.10.1 will be much faster, but somewhat worse

how will it compare to `e 8` then?

https://github.com/libjxl/libjxl/issues/3323

`num_threads 0` <:monkaMega:809252622900789269>

for threading is the same, because with streaming it's almost independent individual blocks encoding but it's only for one manga image, so maybe for other images it will be different <:PepeSad:815718285877444619>

anyway some separation between `e 9` and `e 10` is welcome as they're very close in speed right now

as long as it doesn't overlap `e 8` too much <:KekDog:805390049033191445>

I run everything single threaded because I thread per file. It's still faster

the main reason I don't do that is memory use

If you have a good corpus, tell me

yeah, I also rarely needs multithreading for a single image

even with 3000x4500 I can encode 16 images on 32 GB memory. thoug you have many more threads

I'm usually working with 8K images, and sometimes even larger than that

Yeah, when I encoded 10k I think 4 was the limit

with the new memory gains this might not be an issue anymore lol

well it's less of an issue, but honestly I can fully utilize my CPU with only 2 simultaneous <:JXL:805850130203934781> encodes now, so that has a bigger effect on reducing memory than all the other optimizations combined (compared to running ~16+ encodes in the past, which wasn't even possible without running out of RAM)

and for the best compression streaming still has efficiency loss, except for few cases when some algorithms don't work properly for the whole image

about `-e 3`, its improved with palette detection but can be still worse than `-e 2` for non photos https://canary.discord.com/channels/794206087879852103/804324493420920833/1118243657456304189

and it would be nice to have support for png streaming input, it's not that much gain as internal streaming, but still saves some more extra memory haven't checked, but does jpeg have streaming input?

not according to the help message about the flag. but idk

doesn't it reorder blocks and recompress Huffman coding in jpeg? would it make sense to stream at all?

for lossy recompression at least

if anyone is interested, here's the sizes of the images at all compression levels (this doesn't have the timing or memory usage data, so if you want that too just ask)

could you share the images ? or their url ?

right now they're all just on my NAS but I can upload if you're interested

what's the weight of the initial bundle ?

1.9 GiB RN

...which will take me quite some time to upload with how slow my upload speed is <:monkaMega:809252622900789269>

yep, don't 😄 you screenshoted them yourself ?

latest commit on `main` should massively speed up lossy multithreading on windows

(we found a tiny little mistake in an old commit that slowed things down on windows by *a lot*)

(old being ~October, if I recall correctly?)

Got any numbers?

-October being the gcc optimization level of "ctober"

```JPEG XL encoder v0.10.0 19bcd82 [AVX2,SSE2] Encoding [VarDCT, d1.000, effort: 7] Compressed to 509.4 kB (0.491 bpp). 3840 x 2160, geomean: 1.199 MP/s [1.16, 1.23], 5 reps, 16 threads.``` ```JPEG XL encoder v0.10.0 3d75236 [AVX2,SSE2] Encoding [VarDCT, d1.000, effort: 7] Compressed to 509.4 kB (0.491 bpp). 3840 x 2160, geomean: 8.977 MP/s [8.76, 9.08], 5 reps, 16 threads.``` 7x improvement and from around 60% CPU usage to around 100%

yep

that's more or less what I'd expect

Did a random test on lossless since there was mention of trying to match speed a while ago ```JPEG XL encoder v0.10.0 3d75236 [AVX2,SSE2] Encoding [Modular, lossless, effort: 5] Compressed to 5508.2 kB (5.313 bpp). 3840 x 2160, geomean: 8.911 MP/s [8.75, 8.93], 5 reps, 16 threads.``` Apparently in this instance `-e 5` lossless almost perfectly matches lossy, at around 10x the filesize