JPEG XL

how long did that take 💀

but only with transcoding, no re-encode

ohh okay

haven't tried reencoding

I like to preserver the originals as far as possible

If possible, I want literally every file I have to be lossless

Makes sense

I mean Modular mode gets surprisingly close to virtually lossless VarDCT levels sometimes

Need that Blender support for my textures 😩

I logged my cmd output so I can retrieve settings

WebP does okay... Then you remember it's 8-bit so broke normal maps

WebP certainly has its uses, but high fidelity is not among them

8-bit normal maps are quite usable

Of course, but it is a limitation nonetheless

true

We should really just make the encoder do a no op when effort 11 is called for anything but lossless.

It's mentioned in the documentation, but I think the program yelling, "STOP! This does nothing! You are wasting your time." in your face is better.

Well, it just does effort 10 effectively doesn't it?

It falls back to effort 10 yeah.

But that can still lead to a lot of wasted time

I think the devs underestimated how obsessively people would try e11 on *everything*

Which is a clear indication of a need for e 12 to e 20 <:KekDog:805390049033191445>

I mean I do up to e10 for research purposes but for everyday use I use anywhere between e1 (e.g. on screenshots) and e7

e1 is perfect for screenshots indeed

Ironically enough, it does not waste time when it's a no op, and wastes a lot of time when it's doing lossless <:galaxybrain:821831336372338729>

I think at least? I remember doing lossless transcoding at e11 and it finished like instantly

Oh vardct would probably work

It was mentioned multiple times already I believe, but lossless trancoding doesn't really improve upon setting an effort greater than 8, maybe 9

I myself haven't really tested this, but from the few times I did it was so

Effort 9 does increase density by ~8-10% but it takes ~20x more encoding time compared to effort 7.

Tried exporting an image from Kirta, this time with RGB noise, one time in an extra layer, the other time flattened. Interestingly, the exact opposite situation to the crt scanline texture from last time, the JXL with the noise in a separate layer is massively larger than the flattened image

``` 47M gradient_test_lossless_noise_layers.jxl 12M gradient_test_lossless_noise_no_layers.jxl ```

The noise layer was exported from GIMP at 25% opacity since JXL or Kita's implementation of JXL do not support layers with reduced opacity

I produced transparent layers in Krita by using the eraser tool, setting it to the biggest size and some opacity, and then erasing the whole layer in one sweep

That is certainly one option

You effectively just gotta do any sort of transparency by using the alpha channel, or maybe a layer in the multiplication blend mode, but idk if krita supports outputting the multiplication blend mode in JXL

Those test results are interesting though

I also encoded the image wth cjxl and --photon_noise_iso 64000 to get a similar noise level. The noise doesn't llok as nice, but at 1.5MB it handily beats both JXLs with the noise overlay created in GIMP

Hm, I don't really have a lot of experience with Krita, but I'll have to check if this is possible

My expectations were for the size to be about the same. Since input noise just can't be predicted period, I would expect the noise to take up like 99% of the data, and the gradient is just slight upticks or downticks in the prediction residuals, barely adding up to anything, regardless of whether the gradient is encoded separately or within the noise. But I don't know why it got so much worse

Ohh

I was just trying to reencode the image with layers at higher effort only to realize that cjxl flattens layers together upon encoding

Very unfortunate

If the noise was fairly subtle in the no-layers version, the residuals are small, for example maybe a difference from 0 to 20 (out of 255) per pixel. But since the layered image was exported at full opacity like it says in that notice above, the differences in the noise are from 0 to 255

Could that be it?

idk what your noise looks like

like this

Random RGB noise created with GIMP

Right, and what did it look like in the no-layers, blended with the gradient?

like this

I have to say that the noise looks quite nice though

Ahhh yeah that explains it

In that combined image the noise looks very minimal. If a pixel in the top right is green, the one next to it will probably be green-ish too, despite the noise. It's predictable. But your noise-only layer is basically pure information, there is no pattern, it's all over the place, it goes from the minimum pixel value to the maximum pixel value, The current pixel doesn't tell you anything about the next one. It effectively just cannot be compressed

Right, random noise

Always hard to compress

So, I assume that predictable patterns will do better in a separate layer while random noise will do better flattened?

Because the flattening will make it more predictable?

I think the issue here specifically isn't to do with whether it's flattened or not. It's just that one image has more noise. In the flattened image, the base image effectively makes up 95% of the image as a whole, and the noise 5% (these are blended together) In the layered image, the base image takes up 100% of the first layer, and the noise takes up 100% of the second layer. They are *visually* blended so the base image and noise look like they make up 95% and 5% respectively, but that's only what it's showing you, not now it's stored So it's not really the layering approach that's at play here, it's that one image actually has more noise, because Krita reducing the opacity just makes it *look* like there is less noise, but that noise is actually stored in the file in full. I think if you do the experiment again, but set every layer to 100% opacity and make the noise layer transparent using the alpha channel (like by using the eraser tool), you'll see similar sizes in both of them, or hopefully the layered one being better since it's able to see the patterns in the base image more easily

Krita's layer opacity setting is like listening to a playlist only at 30% volume. You hear less sound but your music takes the same amount of disk space. What happens when Krita flattens it or makes the actual texture itself transparent, is like re-exporting the music at 30% of the original volume. Now it actually has reduced disk space

The noise was already made transparent in GIMP, since Krita does not support exporting JXL at reduced opacity

It's just hard to see in discord

Oh - my bad

Just preview shenanigans due to discord's dark background

Okay then I would definitely expect this to be better. It should make the background more predictable <:Thonk:805904896879493180>

super weird

I can share the files tomorrow

Yeah I'd love to see that

I also prepared another test with a real bayer dithering pattern this time, to see how that goes

But uhh it's 03:30 here so good night. jxl keeping me up 😶

e11 overrides all of `-P`, `-E`, `-I`, `-g`, `--modular_palette_colors`, `-X`, `-Y` and `--patches`. instead, it tries various set combinations of settings. it does happen to try all group sizes, but each in conjunction with different combinations of other settings.

Yesterday me and a friend realised they'd accidentally made a 16K image instead of an 8K one in Blender years ago, so why not run some tests... Original, ECT -1 at 512 MB RAM 100 Seconds, Effort 1 at 1.2GB RAM 3 Seconds, Effort 2 at 1.1GB RAM 7 Seconds

`-g 0` actually improved effort 2. Wonder if that applies generally due to the fixed MA tree

1st + 2nd = 3rd

One thing that's a bit unfortunate: the subtracted-out pattern isn't always just a single value. Especially for artistic use or palette images, the difference between any two colors that are dithered can be pretty large and also different throughout the image. Whereas 'real' dithering like turning a 16-bit gradient into an 8-bit one, will probably have values that are a bit closer together. But this is a palette image, so you'd get a palette for the base image and another palette for the delta layer

These are the PNG, flattened (single-layer) and decomposed (separate dither and base layers) files, all exported at the maximum encoding efforts Krita supports (9, for both JXL and PNG)

nice

I had an idea to not store the subtract values of the pattern and then kAdd-blending it on, but instead making it an overlay that's already the right color and just kReplace-blending it on, so that the dither pattern layer can be made up of indices to the same palette that the base image uses. Useful in images like pixel art where the dither pattern isn't just one value away from the surrounding pixels, which I think it otherwise would be for 'true' dithering. But I realized that in this particular example with the dithered sky, it's not worth it to do this at all and it would be more effective to just store all the 2x2 tile combinations of the pattern *with* the background in patches and apply them everywhere, which should then run length encode really good (so should this dither pattern in the first place, but something else in the pipeline appears to be messing with the values a bit before LZ77 has a chance to compress them)

Would it be preferred if I posted things related to optimizing repeating patterns and image decomposition using layers in its own thread?

I think a thread would make sense for having continuity

This is the exact same data, just plotted with the axes differently: First one is how it is traditionally done, with bpp on a logscale and the metric on a linear scale. This has the effect of enlarging the low bitrates and low qualities. Second one is how I like to do it: bpp on a linear scale, metric on a suitable scale to actually see what's happening. Linear scale bpp makes the most sense to me since the cost of storage/transfer is also linear. So if 2 bpp can be reduced to 1.5 bpp, that is a larger actual saving than if 0.5 bpp can be reduced to 0.25 bpp, assuming same number of pixels. From the plot on the left you'd conclude that AVIF > JXL > WebP >> JPEG. From the plot on the right you'd conclude something different.

Potentially found a good category of images on Wikimedia Commons for benchmarking lossless compression: [Category:PNG that should use vector graphics ](<https://commons.wikimedia.org/wiki/Category:PNG_that_should_use_vector_graphics>)

75000 images

Some of these appear to be photographic in nature, probably miscategorized because they look like symbols if you don't look closely

mostly digital maps, charts, symbols, logos, chemical compounds, etc

Hmm. Upon closer inspection some of these have pretty clear lossy compression artifacts...

Yeah, this seems to be mostly a category with the idea that people eventually replace these with SVGs, not necessarily that they're PNGs that look like they could have been SVG renderer output, so it includes some transcoded photos and such...

Almost everything in this image can use patches https://xkcd.com/radiation/

And cjxl does use patches, pretty well (distance 1, effort 7)

Interestingly it only uses patches for the outer tiles in those grids. I wonder why that is

How do you view the use of patches?

`~/Programs/jxlatte/jxlatte.jar 1528229508475.jxl out.png`

The patch preview only works on lossy images, at least in this (possibly outdated) version of jxlatte

do patches work at all on lossless?

Yeah

``` 72kB d0-patches0.jxl 34kB d0-patches1.jxl ```

djxl -s 8 also works

It's related to the heuristic for text detection, which looks for some threshold of similar pixels in a region to identify background content. The perimeters of the grids met the threshold for possible patch extraction, but not the inner areas.

Interesting

because I'm bad at writing code 😛

more seriously, probably in the center of the grid the code thinks there's a different "background" color

no! no self deprecating >:(

what would happen if you disabled the heuristic, would it not create patches at all or would it try way too hard and take a lot of time, but get most of the patch candidates in the end?

i don't know how patch detection works in detail but i was pleasantly surprised to see it got basically all of the text, which is what it was designed for, so i'd say you did pretty good :)

no patches at all

I even have a fairly good idea of a better heuristic, but who has time

do you have time to write about it instead? because I am curious how it'd work 👀

I mean, a vague idea is to do it the same way you do a lempel-ziv compressor, but with something like 4x4 patches that get hashed

and $some way of extending the 4x4

if you did the extending part with some sort of recursion, as in first running it on 4x4 pixels, then again on some 2x2 of those, and so on, you might even be able to utilize that logic directly to achieve a 'hierarchical patches' idea I had. The idea was that since patches work on the letters level, not on the words level, you have the level 0 patch layer which contains the letters, then a level 1 patch layer which contains indices into that to create words, then using that as another patch layer. Then the final image can index into both, prioritizing using larger patches like for words, but also being able to index into the sole letters that make up the words for encoding uncommon words that don't deserve their own larger patch. Letters and words are just an example, could word for anything though. If that's possible at least, it was just an idea I had

Incidentally I also have an active project for a cheap lz77 heuristic that could tell predictors how likely their residuals are lz77-able, instead of just scoring them by the residuals themselves

(sorry for yapping)

This server is all about yapping, no need to apologize

i think it can seem a little rude since i show genuine interest in what someone else is up to and post a memory dump of my own right after, so i've been trying to recognize it ahead of time

trying to keep my adhd in check a bit

The current design looks for features surrounded by background. You can relax the parameters of the heuristic identifying areas of background, and you can relax the constraint that a patch candidate needs to be surrounded by background. But using more patches is not helpful where other tools would be more efficient. It's a more complex problem than simply extracting all repeated content, considering both density and compute efficiency.

so i guess the problem here is that it sees too much green tiles compared to white background. I guess if a floodfill type of algorithm was used for the background it might have worked?

in this specific case I mean

My point is even if you find more patches, you may not benefit density at some compute target.

that's fair, I was mostly asking about the first part of your message. it makes sense that patches everywhere aren't always the best solution (but that seems like a separate thing from how they're detected, unless the background algorithm also works to not detect them where they usually wouldn't be beneficial)

Every four pixels it looks at the surrounding area and identifies how many of those pixels are the same as the pixel in question. if there are enough, then it will later search for patches in that area. So, for any color in the inner part of the grid, there are not enough pixels of the same color according to the heuristic. Yes, you can change how it works. Yes, it was designed to be effective by some measure.

I posted some results from tweaking patches here: https://discord.com/channels/794206087879852103/803645746661425173/1246697827069857852, eventually adding tile detection on top of the text detection. While I could improve outcomes for many images, It was a more complex task to accurately predict whether any individual patch would benefit density.

I'm a bit skeptical about those squares for example, I imagine they're not as important as the text in that image.

What are some ways in which using patches could get worse? I can see some ways in which it might not be *better*, like yeah those green tiles will probably lz77 compress really well regardless of the predictor used (so long as the MA tree keeps the one that is used consistent), but using patches for it would also lz77 compress well since it's the same indices over and over

If the patches are large enough it should usually be a good idea to use them. Main question is how much time to spend on finding patches...

This is one example https://discord.com/channels/794206087879852103/803645746661425173/1326476011654873098

Hmm - detect background color (flood fill, common 4x4 colors, etc) - do contrast based edge detection, and create bounding boxes around good-patch-sized blobs of edges that include or are inside of much of that background color - if many blobs turn out to have bounding boxes of the same size, you might have found a good patch candidate - now do more expensive patch candidate selection on those previous candidates

that's adorable it's trying so hard

I downclocked my ram to see how much memory speed impacts performance. The image is 45 MP, all tests ran at lossless effort 1, 20 reps. ```╔════════════╤═════════════════════════╗ ║ Decoding │ i5 12400 - 32 GB DDR4 ║ ╠════════════╪════════════╤════════════╣ ║ │ 2133 MHz │ 3200 MHz ║ ╟────────────┼────────────┼────────────╢ ║ 1 Thread │ 29.9 MP/s │ 32.4 MP/s ║ ╟────────────┼────────────┼────────────╢ ║ 4 Threads │ 108.1 MP/s │ 120.1 MP/s ║ ╟────────────┼────────────┼────────────╢ ║ 8 Threads │ 175.0 MP/s │ 186.0 MP/s ║ ╟────────────┼────────────┼────────────╢ ║ 12 Threads │ 214.6 MP/s │ 216.2 MP/s ║ ╚════════════╧════════════╧════════════╝ ╔════════════╤═════════════════════════╗ ║ Encoding │ i5 12400 - 32 GB DDR4 ║ ╠════════════╪════════════╤════════════╣ ║ │ 2133 MHz │ 3200 MHz ║ ╟────────────┼────────────┼────────────╢ ║ 1 Thread │ 41.2 MP/s │ 43.2 MP/s ║ ╟────────────┼────────────┼────────────╢ ║ 4 Threads │ 120.8 MP/s │ 125.2 MP/s ║ ╟────────────┼────────────┼────────────╢ ║ 8 Threads │ 163.7 MP/s │ 172.7 MP/s ║ ╟────────────┼────────────┼────────────╢ ║ 12 Threads │ 182.3 MP/s │ 186.6 MP/s ║ ╚════════════╧════════════╧════════════╝ ```

Would be interesting to test on an AMD Ryzen, which are more sensitive to lower RAM speeds

I'm on a Ryzen 1700, 16 GB of DDR4 at 2400mhz. Those speeds seem about the same as mine, so no major differences at least

Just a quick follow up, this image is cursed in more ways than I thought. WebP actually performs *worse* than PNG which is surprising. First time I've seen that happen.``` Optimized PNG - 356,474 bytes WebP -z 9 ----- 408,200 bytes Libjxl 0.11 --- 313,266 bytes```Parameters are `cjxl in.png out.jxl -d 0 -e 10 -P 0 -E 4 --patches 0` For images like these it's often the case that the "none" predictor works best, similar to PNG.

AVIF performs better than the WebP here, interesting 318437 Optimized.avif

Terrifying <:tfw:843857104439607327>

Weird indeed

It is even almost better than your e10 JXL

It's not as bad as that one time GIF beat JXL though 😅

I should test this again on a larger GIF set. But as we've found out by now, GIF -> optimised APNG -> JXl will often result in smaller filesizes than just GIF -> JXL

I have that file here. GIF beat *everything*

A mythical image beyond our realm of reality. <:NotLikeThis:805132742819053610> It defies all logic somehow

Interesting

All while being a real-world example

Group size had no improvement?

-g 2 was optimal iirc

Or was it -g 1 I don't remember

Time to bust out e11

Dammit, still larger

e11 is only marginally smaller than WebP <:KekDog:805390049033191445>

Eugh... Just got sent an image by a friend, was practically uncompressed so ran ECT... Hardly improved, I open it and look a bit closer....

Not even dithering, just pure, RGB noise.... God damn it

For what purpose did he have that image lying around?

Commissioned artwork. They had sent me it before but much smaller. Turns out it was a WIP so the noise filter hadn't been applied, along with being a re-compressed JPEG

This JXL uses around 40% of my 7950x to play lol

cwebp turns it into RGB. That may be the cause

It should still be palletized tho since there are only 256 discreet colors

was this a challenge because of what you have in your bio? replace it with photon noise, I doubt they'd notice :3

I can't 'just' replace the noise. I'd need the original file, and photon noise doesn't work properly on Lossless

nah i know, i just meant you could probably manually recreate something that looked close enough to the original if you wanted to

```50 files (libjxl v0.11.1) 2,615,247,628 bytes oxipng -o 0 1,590,449,934 bytes cjxl -d 0 (e7) ~22 minutes 1,355,276,849 bytes cjxl -d 0 -e 10 -E 4 -I 100 -g 3 ~61 hours```

```e7 5859 x 7680, 2.498 MP/s [2.50, 2.50] e10 10500 x 10500, 0.002 MP/s [0.00, 0.00]``` The slowest of each

Now compare how long it takes to open in an image viewer

Or use ffmpeg -benchmark

Which is a while lot slower than opening the image normally, but at least it is repeatable and gives proper output

Not really relevant on macOS

Elaborate

Already slow for Preview to open a normal-sized JXL

Darn

I would still be interest ed in an ffmpeg comparison if you are inclibed

I don't have ffmpeg installed

Oh well

Nevermind then

Yeah posted publicly (SFW) and nothing new from what I posted here https://meow.pro/meow/e-10-e-4-i-100-g-3/

I think I won't use that again soon

wait what OneDrive has thumbnails for JXL [⠀](https://cdn.discordapp.com/emojis/852007419474608208.webp?size=48&name=av1_woag)

quite a strange collection for benchmarking tho <:kekw:808717074305122316>

Oh, you didn't time oxipng?

The blog post is SFW, but the OneDrive folder certainly isn't. Also surprised the thumbnails load for JXL, guess we can add another to <#803574970180829194>

I just wanted to make a fair test so I used -o 0 only for faster optimisation and removing metadata before testing further

I used that -e 10 for normal-sized ones too but they're not in this test

You must click three different links for reaching NSFW

Hmm saw a French word

Indeed

Oh a few. Download, ago [number] days

I could have used `oxing -o 4` but it's just too good comparing to most of available PNG files

`-o 0` already reduced significantly

Nah, nothing strange about a "Bustycat in Heat" <:KekDog:884736660376535040>

But I can't blame him as I did the same once with that one: || https://cdn.discordapp.com/attachments/673202643916816384/1127986007724261498/1104459542487633950.webp || <:KekDog:805390049033191445>

At least it doesn't reveal anything XD

true I was surprised by the fact that FFmpeg defaults settings give a different output than dwebp

to fix that you'd need `-sws_flags full_chroma_inp+full_chroma_int+accurate_rnd` <:KekDog:805390049033191445>

I think I tried to bench those Fuck off windows I'm ranting about FFMPEG

I tried to bench those arguments to see how much of a difference it made, since there's conflicting info about if `accurate_rnd` actually does anything in newer versions or if `full_chroma_inp` applies automatically. I know `full_chroma_int` did have an effect, though I don't recall how drastic it was

Oh, interesting, the mouse didn't show

it sounds like it’s trying to get you to think about your retirement plan or something

It's more like telling me to buy a funeral plan. This system is 8 years old so I need to kill it off before their pestering can do anything anyway

Doesn't help the only upgrade paths are being discontinued. So I'll have to build an entire new system most likely, which I certainly can't afford

Just wait for Windows 12 /s

or maybe install ReactOS

Trying a Clang build <@207980494892040194> cooked up ``` Distance 1 Effort 7 Github 7680 x 4320, 5.436 MP/s [5.44, 5.44], , 1 reps, 16 threads. Wall time: 0 days, 00:00:06.749 (6.75 seconds) User time: 0 days, 00:00:05.406 (5.41 seconds) Kernel time: 0 days, 00:00:50.781 (50.78 seconds) Distance 1 Effort 7 Clang 7680 x 4320, 7.146 MP/s [7.15, 7.15], , 1 reps, 16 threads. Wall time: 0 days, 00:00:05.332 (5.33 seconds) User time: 0 days, 00:00:04.890 (4.89 seconds) Kernel time: 0 days, 00:00:35.140 (35.14 seconds) Lossless Effort 1 Github 7680 x 4320, 114.661 MP/s [114.66, 114.66], , 1 reps, 16 threads. Wall time: 0 days, 00:00:00.938 (0.94 seconds) User time: 0 days, 00:00:00.062 (0.06 seconds) Kernel time: 0 days, 00:00:02.781 (2.78 seconds) Lossless Effort 1 Clang 7680 x 4320, 305.596 MP/s [305.60, 305.60], , 1 reps, 16 threads. Wall time: 0 days, 00:00:00.785 (0.79 seconds) User time: 0 days, 00:00:00.093 (0.09 seconds) Kernel time: 0 days, 00:00:01.703 (1.70 seconds) Lossless Effort 7 Github 7680 x 4320, 3.809 MP/s [3.81, 3.81], , 1 reps, 16 threads. Wall time: 0 days, 00:00:09.356 (9.36 seconds) User time: 0 days, 00:00:04.296 (4.30 seconds) Kernel time: 0 days, 00:01:48.828 (108.83 seconds) Lossless Effort 7 Clang 7680 x 4320, 5.416 MP/s [5.42, 5.42], , 1 reps, 16 threads. Wall time: 0 days, 00:00:06.814 (6.81 seconds) User time: 0 days, 00:00:04.578 (4.58 seconds) Kernel time: 0 days, 00:01:14.546 (74.55 seconds)```

``` Github djxl 15000 x 13746, 188.104 MP/s [188.10, 188.10], , 1 reps, 16 threads. Creation time 2025/02/12 22:45:56.717 Exit time 2025/02/12 22:45:58.055 Wall time: 0 days, 00:00:01.338 (1.34 seconds) User time: 0 days, 00:00:02.187 (2.19 seconds) Kernel time: 0 days, 00:00:13.500 (13.50 seconds) Clang djxl 15000 x 13746, 239.420 MP/s [239.42, 239.42], , 1 reps, 16 threads. Wall time: 0 days, 00:00:01.107 (1.11 seconds) User time: 0 days, 00:00:02.390 (2.39 seconds) Kernel time: 0 days, 00:00:10.078 (10.08 seconds)```

This is neat, Ill have to check about doing this locally on my phone, I also want to try and compare using png-rs eventually but it has no c api T.T

My next benchmark project would be WebP near-lossless but using JXL as one of metrics

Only one source image will be mine this time

Earlier tests showed that WebP near-lossless 0, 20, 40, 60, and 80 roughly correspond to JXL distance 2.0, 1.2, 0.5, 0.3, and 0.2

I love meow's discord "about me"

Why did I read it <:KekDog:884736660376535040>

Something about data compression always makes one either an otaku or furry for some reason

It’s something I’ve noticed

1.7, 0.95, 0.55, 0.35 and 0.25 in the new test

A lot of anime watchers seem to care about video quality and so the path from that to being interested in codecs seems straightforward. See e.g. dark shikari.

What ever happened to dark shikari

There used to be a blog and everything

disappeared into the ether at some point, never to be heard from again

How else are you going to compress all those terabytes of waifu data

Fair point

The data collection is done https://docs.google.com/spreadsheets/d/1vq0VLsB580yGS9LXAuxf6LTv8CVM_Jv-tBln5ruQ5do/edit?usp=sharing

including corresponding lossy WebP, Jpegli, and JXL quality/distance

The JXL sheet is there for a reference. The main comparison is to its own lossy part, and Jpegli.

I may test the WebP part again, but without `-m 6`

About 8 to 10 times slower than JXL with `-m 6`

The next benchmark project is finding JXL distances corresponding to ssimulacra2 for almost 400 digital artworks

d0.5 shows average at 90.72142788 that's higher than my expectation

Tested four today. Interesting `d0.3 91.96229814 d0.5 90.72142788 d1.0 87.68818199 d3.0 77.23289308`

The higher distance brings some more significant outliers. For d3.0 in this benchmark, one reaches as low as 58.63179688, but can be as high as 84.63561018

I've updated again for adding the 10th image. This is my first time of doing a detailed benchmark, any comment?

Not sure about if 10 distinct images are enough for a benchmark

<@263300458888691714> Not sure how much hassle it is for you to run tests, but any chance you could try running `-d 0 -e 2` with and without `-g 0`? I've been seeing it consistently outperform the default of 1 but want to see if it holds up with a larger corpus. If it does, we could change the group size by default for effort 2

I'll try it

benchmark_xl v0.12.0 f73fc6f0 [\_AVX2\_,SSE4,SSE2] 20 total threads, 2030 tasks, 0 threads, 20 inner threads ``` 1015 images Encoding kPixels Bytes BPP E MP/s D MP/s ------------------------------------------------------------- jxl:d0:2 1039647 800359291 6.1586958 61.534 264.353 jxl:d0:2:g0 1039647 800953474 6.1632680 68.347 353.244 Aggregate: 1039647 800656327 6.1609815 64.851 305.583 ``` benchmark_xl v0.12.0 f73fc6f0 [\_AVX2\_,SSE4,SSE2] 20 total threads, 2030 tasks, 0 threads, 0 inner threads ``` 1015 images Encoding kPixels Bytes BPP E MP/s D MP/s ------------------------------------------------------------- jxl:d0:2 1039647 800359291 6.1586958 24.545 38.439 jxl:d0:2:g0 1039647 800953474 6.1632680 24.185 37.945 Aggregate: 1039647 800656327 6.1609815 24.364 38.191 ```

Hmm, so good for multithreaded (de)code but not a density improvement

my guess is it will depend quite a bit on the image contents: e.g. for photo it likely doesn't make much difference, for simple illustrations with lines and gradients that are well-predicted by gradient it could help a bit to bump up the group size (fewer poorly predicted pixels), while for images with more "local" characteristics might benefit from a smaller group size so the histograms fit better to the local contents.

some categories **LPCB** 20 inner threads ``` 107 images Encoding kPixels Bytes BPP E MP/s D MP/s -------------------------------------------------------------- jxl:d0:2 1154190 1266224502 8.7765409 141.070 471.324 jxl:d0:2:g0 1154190 1272288235 8.8185703 163.681 519.575 ``` 0 inner threads ``` 107 images Encoding kPixels Bytes BPP E MP/s D MP/s -------------------------------------------------------------- jxl:d0:2 1154190 1266224502 8.7765409 27.191 38.685 jxl:d0:2:g0 1154190 1272288235 8.8185703 26.222 37.993 ``` **Scope ITAP** 20 inner threads ``` 255 images Encoding kPixels Bytes BPP E MP/s D MP/s -------------------------------------------------------------- jxl:d0:2 1125814 1281053819 9.1031291 103.148 383.918 jxl:d0:2:g0 1125814 1280877871 9.1018788 112.521 431.984 ``` **Scope Art** 20 inner threads ``` 443 images Encoding kPixels Bytes BPP E MP/s D MP/s -------------------------------------------------------------- jxl:d0:2 2663857 1435281564 4.3103848 132.347 473.021 jxl:d0:2:g0 2663857 1439479421 4.3229916 145.857 524.062 ``` **Scope Pixiv** 20 inner threads ``` 637 images Encoding kPixels Bytes BPP E MP/s D MP/s -------------------------------------------------------------- jxl:d0:2 1157230 1021934712 7.0646900 76.394 289.462 jxl:d0:2:g0 1157230 1020343798 7.0536919 83.989 342.313 ``` **Scope Manga** 20 inner threads ``` 349 images Encoding kPixels Bytes BPP E MP/s D MP/s ------------------------------------------------------------- jxl:d0:2 1005250 453271317 3.6072323 94.127 459.246 jxl:d0:2:g0 1005250 454549965 3.6174080 102.502 516.090 ```

**Scope GameScreens** 0 inner threads ``` 590 images Encoding kPixels Bytes BPP E MP/s D MP/s -------------------------------------------------------------- jxl:d0:2 2748558 2368756369 6.8945405 27.853 39.110 jxl:d0:2:g0 2748558 2361767219 6.8741978 26.321 38.320 ``` **Scope PixelArt** 0 inner threads ``` 2051 images Encoding kPixels Bytes BPP E MP/s D MP/s ------------------------------------------------------------- jxl:d0:2 3929080 293349229 0.5972884 28.522 47.610 jxl:d0:2:g0 3929080 302902542 0.6167399 29.290 47.506 ``` **Scope GameSets** 20 inner threads ``` 545 images Encoding kPixels Bytes BPP E MP/s D MP/s ------------------------------------------------------------- jxl:d0:2 222827 106846745 3.8360335 28.826 152.352 jxl:d0:2:g0 222827 107011990 3.8419661 32.104 225.266 ``` 0 inner threads ``` 545 images Encoding kPixels Bytes BPP E MP/s D MP/s ------------------------------------------------------------- jxl:d0:2 222827 106846745 3.8360335 18.495 35.072 jxl:d0:2:g0 222827 107011990 3.8419661 18.505 35.046 ``` **Scope LowPoly** 20 inner threads ``` 431 images Encoding kPixels Bytes BPP E MP/s D MP/s ------------------------------------------------------------- jxl:d0:2 1306519 829813172 5.0810617 85.794 374.639 jxl:d0:2:g0 1306519 826829751 5.0627938 93.495 432.108 ``` **Scope Fractals** 0 inner threads ``` 308 images Encoding kPixels Bytes BPP E MP/s D MP/s -------------------------------------------------------------- jxl:d0:2 1105849 1445407312 10.4564492 23.220 34.870 jxl:d0:2:g0 1105849 1442358292 10.4343918 21.973 34.302 ```

Interesting, my bpp are between 0.01 and 0.08 bpp lower with `-g 0`, averaging around 0.05. Though encode speed is also lower too, suggesting the heuristics are doing something extra

``` byte sec 857,192 (gif) 1,039,970 2.010 -d 0 682,581 39.250 -d 0 -e 10 -E 4 -I 100 -g 3```

A delicious benchmark

>see spoilered benchmark image >"oh this is probably just porn or whatever" >*dies instantly upon clicking*

[roach](https://cdn.discordapp.com/emojis/626353358445477888.gif?size=128&animated=true&name=roach)

dr kel when no MREs

why does the background of that gif have such flickering dithering going on?

probably it could be quite a bit smaller if it was 'cleaner'

Just a quick search after a news report about some customer accidentally eating the head of a cockroach inside a taro ice pop

Oh a cockroach leg only

never heard of that until now, and I wont be having it ever thanks

Probably naiive video to gif converter

Per frame palette

Almost full with only three JXL (d3) images on this device ``` 551,522 566,845 222,794 = 1,341,161```

this is the SFW folder? 🥵

maybe 💾 means "not"

I remember when I first saw a 3.5 inch floppy I thought "oh so this is a hard disk?"

I was used to 5.25 inch floppies which were actually, you know, floppy

it didn't help that there was often this "HD" symbol on them (for "high density", 1.44 MB) which of course I would interpret as "hard disk"

took me a while before I understood that a hard disk was actually something else and that this hard-case floppy with "HD" on it was actually also just a floppy 🙂

i didn't know there were floppy disks that were actually floppy when assembled. i always thought the 'floppy' part was referring to the internal disk in the casing

||the images are there to turn your floppy disk into a hard drive||

||yeah I had a teacher in college that had a thick accent and pronounces the word 'disks' like 'dicks'... you can see where I'm going with this one when it came to floppies and HDs||

lmao

Meanwhile I never had the privilege of seeing a floppy in person, until last year when a friend brought an old digital camera that used floppies to store the photos. I was going to JXL them, but we ran out of time 😔

5.25 inch floppies are floppy. You could quite easily fold one in two if you wanted to (though it would destroy it)

I never used those larger 8 inch floppies but I heard rumors that they were such low density that you could in fact fold them, mail them to someone, and still recover the data

oh, interesting

I’ve seen them but I don’t remember ever seeing them _in use_

the memories I have of seeing, holding and manipulating one in person are well after they fell out of fashion

I don’t think I had a floppy drive

ah, it was a 3.5"

try it with the DMF format, so you can squeeze four

or port that weird driver that allows writing the full 2 MB on a floppy

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

Not a solution for macOS

hmm, it used to be that you could use them on macOS, but apparently today's USB floppy drives have trouble reading them from the hardware side anyway

I have the USB (Type-A) floppy drive only. Apple is the first to ditch such device

```byte sec command 943,880 (PNG) 654,838 1.958 oxipng -o 4 448,367 0.968 cjxl -d 0 436,728 3.841 cwebp -lossless -m 6 -q 100 370,601 35.539 cjxl -d 0 -e 10 -E 4 -I 100 -g 3```

A simple benchmark for the "floppy disk" itself

So the default JXL can't completely beat WebP lossless for 💾

``` Floppy.webp.png Encoding kPixels Bytes BPP E MP/s D MP/s Max norm SSIMULACRA2 PSNR pnorm BPP*pnorm QABPP Bugs ---------------------------------------------------------------------------------------------------------------------------------------- webp:ll:m1 1048 457188 3.4880676 1.277 103.932 nan 100.00000000 52.16 0.00000000 0.000000000000 3.488 0 webp:ll:m2 1048 444712 3.3928833 0.830 92.640 nan 100.00000000 52.16 0.00000000 0.000000000000 3.393 0 webp:ll:m5 1048 445408 3.3981934 0.687 101.428 nan 100.00000000 52.28 0.00000000 0.000000000000 3.398 0 webp:ll:m6 1048 439566 3.3536224 0.219 125.650 nan 100.00000000 52.28 0.00000000 0.000000000000 3.354 0 jxl:d0:1 1048 564380 4.3058777 80.209 23.010 nan 100.00000000 99.99 0.00000000 0.000000000000 4.306 0 jxl:d0:3 1048 469729 3.5837479 5.147 7.379 nan 100.00000000 99.99 0.00000000 0.000000000000 3.584 0 jxl:d0:4 1048 451626 3.4456329 1.641 6.050 nan 100.00000000 99.99 0.00000000 0.000000000000 3.446 0 jxl:d0:7 1048 447550 3.4145355 1.008 11.069 nan 100.00000000 99.99 0.00000000 0.000000000000 3.415 0 jxl:d0:8 1048 441631 3.3693771 0.480 14.250 nan 100.00000000 99.99 0.00000000 0.000000000000 3.369 0 jxl:d0:9 1048 426955 3.2574081 0.270 9.963 nan 100.00000000 99.99 0.00000000 0.000000000000 3.257 0 jxl:d0:10 1048 408316 3.1152039 0.094 13.717 nan 100.00000000 99.99 0.00000000 0.000000000000 3.115 0 Aggregate: 1048 459965 3.5092554 1.211 26.337 0.00000000 100.00000000 78.36 0.00000000 0.000000000000 3.509 0 ```

so webp m2 -m5 are smaller than jxl e7 (but slower to encode) and faster than jxl e8 (but larger), so they're still on the Pareto front

probably the more important thing where libjxl is lagging behind is decode speed — which I think is to some extent caused by webp being able to hardcode everything for 8-bit while libjxl is still decoding everything to float32

And cwebp uses `-m 4` by default 👀

but not for lossless?

or isn't this about lossless

I'm trying to recall, there's no fast decode like e1 encode right? Just the fixed MA tree used for e1 and e2 that probably aids caching

There is some specialization of some decode paths in terms of MA trees mostly, which makes e1 decode faster than e7.

But modular decode always decodes to int32 buffers which then get converted to float32 buffers and only at the API interface do they get converted to uint8 buffers if it's an 8-bit image.

So there is some room left for speeding up special cases like 8-bit or <= 16-bit.

I know a while back you also mentioned using JIT compiling to avoid 'branching traversal of the MA trees' or something along those lines

we're not doing that, but there is some on the fly tree simplification and special casing going on

in other news: tweaked jpeg recompression a bit, improving compression by 0.2% or so: https://github.com/libjxl/libjxl/pull/4130

for 8-bit images, could the decoder instead enter a code path where `u16` is used internally instead of `f32`?

yes, the main reason we normalize everything to f32 is for convenience: this way everything that might happen after modular decode like adding splines or noise, blending frames, color conversions etc only has to be implemented for f32 buffers. But it should be possible to detect the "simple" case where it's just a single-frame 8-bit image with no fancy extra stuff, and avoid the excessive precision (i32 in modular decode, then converted to f32, then back to u8). That should improve memory locality and SIMD effectiveness, and thus also speed.

i feel like at least in this era, 99% of the images people are going to be decoding are 8-bit single-frame images, so if that significantly improves performance that might be worth considering 👀

in the rust based decoder this would probably be a lot less tedious to implement with generics; you can write functions with generic arguments and use them in the `u16` and `f32` code paths, and thanks to monomorphization the compiler will optimize the functions for their specific data types used individually

I'm talking only about lossless / modular mode here btw, in vardct things are "natively float"

ahh okay, it's a lot less than 99% then haha

Ah this is something I did in jxlatte that sped up lossless quite a bit

I had my buffers be (effectively) unions of float32 and int32

and modular rectangles decoded to int32 but could be converted to float if needed for, e.g. blending

if they weren't ever needed it would remain int all the way to png output

we could use f16 though 😄

I'm seeing a minor file size regression (~0.4% larger) ~~and a significant performance regression (~37% slower). ~~ ``` Main -------------------- time ./cjxl chen.jpg main.jxl -d 0 -e 9 -I 100 -g 3 -j 1 -E 4 -P 0 --brotli_effort 11 JPEG XL encoder v0.12.0 c6355600 [AVX2,SSE4,SSE2] Encoding [JPEG, lossless transcode, effort: 9] Compressed to 2474.1 kB including container real 0m5.306s user 0m5.600s sys 0m0.164s PR -------------------- time ./cjxl chen.jpg PR.jxl -d 0 -e 9 -I 100 -g 3 -j 1 -E 4 -P 0 --brotli_effort 11 JPEG XL encoder v0.12.0 [_AVX2_,SSE4,SSE2] Encoding [JPEG, lossless transcode, effort: 9] Compressed to 2485.3 kB including container real 0m7.295s user 0m7.647s sys 0m0.132s ```

Are the file size improvements only for effort 7?

Weird, now ~~I'm seeing a performance improvement (~9%) but~~ still the same file size increase (~0.4%) at effort 7 ``` Main -------------------- time ./cjxl chen.jpg main.jxl -j 1 JPEG XL encoder v0.12.0 c6355600 [AVX2,SSE4,SSE2] Encoding [JPEG, lossless transcode, effort: 7] Compressed to 2484.2 kB including container real 0m0.309s user 0m0.541s sys 0m0.092s PR -------------------- time ./cjxl chen.jpg PR.jxl -j 1 JPEG XL encoder v0.12.0 [_AVX2_,SSE4,SSE2] Encoding [JPEG, lossless transcode, effort: 7] Compressed to 2495.4 kB including container real 0m0.281s user 0m0.476s sys 0m0.152s ```

Keep in mind I'm testing larger images around 10 MP. Seems like effort 9 is just ~~overall worse. Effort 7 is slightly faster but~~ slightly less dense.

I *do* see file size improvements with smaller images around 0.5 MP.

Still overall less dense compared to libjxl 0.9 though

Hm, so your corpus behaves differently from the test corpora I used then...

I think it just depends on the resolution. Most image corpora I've seen don't really test above 2-3 MP.

maybe I should get a better test corpus

I used these: https://imagecompression.info/test_images/

but maybe I better test on just some random photos from my phone, that's probably more representative

Try these on for size: https://www.hasselblad.com/learn/sample-images/ Free 50-100 MP jpegs for extreme cases 👍

Okay, so the performance regression has something to do with my Ubuntu VM, I recompiled on Windows natively and both perform within margin of error. Bad testing environment, sorry. 😅 I still see a small 0.2-0.4% increase in file size with my test images. FYI I don't use image corpora, I just gather random images on my computer. They cover a wide range of content/resolutions.

That's how I found the regression from 0.8 btw, I was just compressing anything & everything on my computer lol. <:PepeOK:805388754545934396>

I don't expect speed differences, but in terms of compression when I test it on some random jpeg photos from an Android phone and from an iPhone, I do see a small increase in file size so that means those test images / encoder settings I was using are not representative for my "in the wild" examples

whenever I want to test an image encoder, I just download 20k images from a booru and call it good, eventually I want to make an app that just rips all the images from websites I view

For "real world" photographic sources my phone's camera roll works well enough

Also downloading random funny images from google/Wikipedia/reddit also works for a "in the wild" corpus

I don't think that Kodak image set represents today's modern internet memes/screenshots/generation-loss'ed jpegs

For example, this random Twitter meme featuring a big-chested anime woman illustrates these issues. Can the Kodak image set do the same? I don't think so.

what do you mean kodak doesn't accurately represent an image that has been jpeg to jpeg transcoded 200 times because of a discord meme

*Know Your Meme* is more representative of the modern internet than any scientifically homogenous, carefully curated, sterile image set out there.

I hate that I have nothing I could possibly say to refute that

The issues in question: e10 larger than e9, Jon's PR not being better, 0.9 being able to use `-E` and being the overall densest. ``` cjxl params: -j 1 -e 9 -I 100 Jon's PR --- 726,879 bytes main + e10 - 721,921 bytes main ------- 721,633 bytes 0.9 -------- 721,328 bytes 0.9 + E2 --- 721,141 bytes ```

I recently ran the ssimulacra2 benchmark with over 400 mostly NSFW PNG artworks

They're all done in 2024 so quite new

Huh... I didn't think transcoding used MA trees, unless those gains are purely from the DC

could you retry with the changes I made?

the DC coeffs are encoded using modular, like in standard JXL

the MA tree gains are in that area

oh this is *really* nice

Ah unfortunately a lot of them are rather noisy. i really like when there's basically no noise so you can evaluate the the performance of image coding, especially lossless, just on the patterns of the image subject

though at that resolution, good luck with that...

Ah damn, I forgot to take a good monochrome image while I was in London. Wanted to get a nice one for greyscale tests

just downscale to get a less noisy image

not a bad idea

That poses the question, what downscaling method is best to remove noise?

without prior knowledge on this, the first thing i would try (after simply averaging pixels), would be averaging some amount of pixels, weighted by how similar they already are to each other. so for example if a single pixel were to throw off the average a lot even though though the others are already very similar it contributes less to the final average.

Maybe take a median?

Best imo to get rid of noise is to do gaussian blur first with a sigma equivalent to half a downscaled pixel, then just a box filter.

Avoid downscaling filters with negative weights like lanczos since they introduce ringing

bicubic b=1 c=0 will reduce noise cause it has a blurring effect

if you want it to be a cardinal cubic then you can try hermite (b=0, c=0)

<@245794734788837387>

A note to self: Test `-P 3` on progressive lossless images. First results hint it's best for the Squeeze

Running a benchmark for WebP near-lossless vs WebP lossy / JXL / Jpegli again with 353 artworks this time

After further testing, it's not `-P 3`, for some reason effort 5+ causes significantly larger progressive lossless files. Using effort 4 has minimal overhead compared to non-progressive

```JPEG XL encoder v0.11.0 0185fcd [AVX2,SSE2] Encoding [Modular, lossless, effort: 4] Compressed to 8739.9 kB including container (5.921 bpp). 3968 x 2976, 2.850 MP/s [2.85, 2.85], , 1 reps, 16 threads. Encoding [Modular, lossless, effort: 5] Compressed to 13702.1 kB including container (9.283 bpp). 3968 x 2976, 1.388 MP/s [1.39, 1.39], , 1 reps, 16 threads.``` Adding `-Y 0` to disable local palette seems to help, but still a long way off (Patches were disabled on both e5 runs for speed) ```Encoding [Modular, lossless, effort: 5] Compressed to 12258.6 kB including container (8.305 bpp). 3968 x 2976, 1.534 MP/s [1.53, 1.53], , 1 reps, 16 threads.```

```byte sec ssimulacra2 command 970,483,716 (PNG) 969,921,289 (Alpha converted to grey bg) ---- 747,496,648 6,396 100.0000000 cwebp -lossless -m 6 -q 100 677,263,619 1,140 100.0000000 cjxl -d 0 ---- 655,460,446 6,653 92.39339902 cwebp -near_lossless 80 -m 6 -q 100 620,081,602 144 92.28029366 cjpegli -q 100 411,639,120 312 92.49223606 cjxl -d 0.2 -a 0.2 ---- 602,689,220 6,507 91.61000444 cwebp -near_lossless 60 -m 6 -q 100 432,434,134 74 91.50709178 cjpegli -q 99 285,565,253 290 91.54658918 cjxl -d 0.35 -a 0.35 ---- 573,363,544 6,663 90.17948322 cwebp -near_lossless 40 -m 6 -q 100 290,696,672 66 90.15305513 cjpegli -q 97 198,763,445 279 90.36016919 cjxl -d 0.55 -a 0.55 ---- 558,806,258 6,588 87.73899044 cwebp -near_lossless 20 -m 6 -q 100 232,007,806 567 87.54638977 cwebp -sharp_yuv -m 6 -q 99 189,430,551 64 87.43204715 cjpegli -q 93 131,084,991 328 87.63679506 cjxl -d 1.0 -a 1.0 ---- 550,627,860 6,521 84.10761986 cwebp -near_lossless 0 -m 6 -q 100 139,203,521 60 84.10544909 cjpegli -q 88 122,573,156 478 84.13292201 cwebp -sharp_yuv -m 6 -q 92 93,210,924 324 84.11337606 cjxl -d 1.65 -a 1.65```

This is a more objective benchmark based on the 353 digital artworks in various styles

It's much better! I'm no longer seeing file size regressions with high res images. File sizes measured in bytes. ``` 10MP Photo ╔══════════╤═══════════╤═══════════╤═════════════════╗ ║ │ effort 7 │ effort 9 │ max (I100 & E2) ║ ╠══════════╪═══════════╪═══════════╪═════════════════╣ ║ new-PR │ 1,111,384 │ 1,103,200 │ 1,100,923 ║ ╟──────────┼───────────┼───────────┼─────────────────╢ ║ old-PR │ 1,111,359 │ 1,103,225 │ 1,100,948 ║ ╟──────────┼───────────┼───────────┼─────────────────╢ ║ jxl-0.11 │ 1,110,628 │ 1,102,531 │ 1,100,254 ║ ╟──────────┼───────────┼───────────┼─────────────────╢ ║ jxl-0.9 │ 1,110,659 │ 1,100,953 │ 1,089,308 ║ ╚══════════╧═══════════╧═══════════╧═════════════════╝ 50MP Photo ╔══════════╤════════════╤════════════╤═════════════════╗ ║ │ effort 7 │ effort 9 │ max (I100 & E2) ║ ╠══════════╪════════════╪════════════╪═════════════════╣ ║ new-PR │ 15,662,021 │ 15,606,378 │ 15,602,688 ║ ╟──────────┼────────────┼────────────┼─────────────────╢ ║ old-PR │ 16,855,906 │ 17,507,564 │ 17,503,872 ║ ╟──────────┼────────────┼────────────┼─────────────────╢ ║ jxl-0.11 │ 15,714,786 │ 15,660,344 │ 15,656,653 ║ ╟──────────┼────────────┼────────────┼─────────────────╢ ║ jxl-0.9 │ 15,714,846 │ 15,660,286 │ 15,653,181 ║ ╚══════════╧════════════╧════════════╧═════════════════╝ 100MP Photo ╔══════════╤════════════╤════════════╤═════════════════╗ ║ │ effort 7 │ effort 9 │ max (I100 & E2) ║ ╠══════════╪════════════╪════════════╪═════════════════╣ ║ new-PR │ 50,760,429 │ 50,591,277 │ 50,573,301 ║ ╟──────────┼────────────┼────────────┼─────────────────╢ ║ old-PR │ 53,523,780 │ 53,625,598 │ 53,607,623 ║ ╟──────────┼────────────┼────────────┼─────────────────╢ ║ jxl-0.11 │ 50,734,605 │ 50,566,598 │ 50,548,622 ║ ╟──────────┼────────────┼────────────┼─────────────────╢ ║ jxl-0.9 │ 50,734,611 │ 50,562,417 │ 50,472,014 ║ ╚══════════╧════════════╧════════════╧═════════════════╝ YouTube Thumbnail ╔══════════╤══════════╤══════════╤═════════════════╗ ║ │ effort 7 │ effort 9 │ max (I100 & E2) ║ ╠══════════╪══════════╪══════════╪═════════════════╣ ║ new-PR │ 90,380 │ 88,924 │ 88,759 ║ ╟──────────┼──────────┼──────────┼─────────────────╢ ║ old-PR │ 90,537 │ 89,092 │ 88,928 ║ ╟──────────┼──────────┼──────────┼─────────────────╢ ║ jxl-0.11 │ 90,684 │ 89,193 │ 89,028 ║ ╟──────────┼──────────┼──────────┼─────────────────╢ ║ jxl-0.9 │ 90,731 │ 89,173 │ 89,030 ║ ╚══════════╧══════════╧══════════╧═════════════════╝ Twitter meme ╔══════════╤══════════╤══════════╤═════════════════╗ ║ │ effort 7 │ effort 9 │ max (I100 & E2) ║ ╠══════════╪══════════╪══════════╪═════════════════╣ ║ new-PR │ 732,394 │ 727,348 │ 726,539 ║ ╟──────────┼──────────┼──────────┼─────────────────╢ ║ old-PR │ 732,406 │ 727,687 │ 726,879 ║ ╟──────────┼──────────┼──────────┼─────────────────╢ ║ jxl-0.11 │ 727,401 │ 722,441 │ 721,633 ║ ╟──────────┼──────────┼──────────┼─────────────────╢ ║ jxl-0.9 │ 727,402 │ 721,737 │ 721,141 ║ ╚══════════╧══════════╧══════════╧═════════════════╝ ``` The new PR performs much better overall and is consistently beating the old PR. Sometimes it even trades blows with 0.9! It could improve even more with medium resolution content like the twitter meme (which I posted earlier) and the 10MP photo.

predictors/residuals/context visualizations

Should I add more formats such as AVIF? https://docs.google.com/spreadsheets/d/1nTYDRiI5IDpBU5fiMuQEMVIpWRaK_66N5YcVoUmDhyA/edit?usp=sharing

`--tune iq` libaom might be worth giving it a test

What is that `--tune iq` for?

it's the newest tune, optimized for Image Quality (IQ), heuristics were guided by SSIMULACRA2 but double-checked with subjective quality checks

as opposed to any other particular metric like PSNR or SSIM

Hmm I should experiment that before doing a full benchmark

[I know it really belongs to other-codecs, but just a quickie…] I wanted to get rid of some blockiness on AVIF effort `6`, but going to `5`, which gets rid of it, takes ~twice longer to encode… Are there any speed benchmarks available for `tune=iq` (and for efforts in general), what’s the performance hit? I couldn’t find any mass speed benchmarks and me encoding 5 images isn’t really a proper way…

I did some testing based around enabling resampling at lower distance values. The current default is 20, but I found at distance 15 with an adjusted scale it's already higher quality and lower bpp. More interestingly though, version 0.8 beat both by a mile, with the resampling tweak only improving it further. I'll probably do a few more tests and then make a PR. One result had significantly worse scores, around -30 with ssimulacra2, but visually looked better. Encode speed also suffers significantly due to this PR https://github.com/libjxl/libjxl/pull/471 . Ssimulacra2 results below have either identical or lower bpp resampled ```Distance 20 7.34862819 Distance 5.75 Resampling 2 9.68362533 Distance 20 v0.8 12.12171614 Distance 5.75 Resampling 2 v0.8 15.37069878```

there are no speed benchmarks on tune iq AFAIK (it's relatively new), but speed is roughly proportional to other tunings, of which there are some benchmarks out there

Comparing two large resolution videos (6016x3384) comprised of photos did surprise me, because the lossless 521 MiB large JXL decodes much faster than the 2.1 GiB FFV1 MKV, with the latter also being more resource intensive. I had expected the animated JXL to be smaller, but slower

AVIF performed so badly, that I didn't even bother keeping it

```byte sec command 1,285,825,364 (PNG after djxl) 1,107,332,566 162 oxipng -o 0 -a 983,356,520 1,476 oxipng -a 975,553,116 2,366 oxipng -o 4 -a ---- 1,344,423,003 65 qoi 1,121,548,403 122 jxrencapp -l 0 1,055,738,327 45 cjxl -d 0 -e 1 933,718,761 920 avifenc -l 932,893,526 529 heif-enc -L -p chroma=444 --matrix_coefficients=0 747,496,648 6,396 cwebp -lossless -m 6 -q 100 677,263,619 1,140 cjxl -d 0``` More lossless benchmarks

`oxipng` uses `-o 2` by default if people don't know this

I could add AVIF, HEIC, and even JXR later as well when I'm free

Yeah encoding JXR is slightly larger and faster than the fastest OxiPNG

AVIF and HEIF are really close

are there any progress on the spline encoding talked about several months ago?

ahh these always feel good

massive decrease in file size from `e 9` to `e 10`. from 445 KB to 87 KB

original: PNG, 550 KB

Food? 🍔

lol

dyslexia moment

what program produces that?

what kind of graph even is that

it's the control flow graph of a disassembled function from some malware. the software is [Cutter](<https://cutter.re/>), useful for disassembling and reverse engineering compiled code

and generating large images perfect for benchmarks :)

how well does jpegli avif and webp perform on this?

webp lossless 90kb

I don't know how to use those from the command line so I can't easily test. but I'd imagine WebP lossless does pretty great and AVIF lossless does pretty poor

`cwebp -m 6 -lossless input.png -o output.webp`

as far as I know, how lossless AVIF works is that it encodes it as a lossy image first, and then stores a second image that contains all the values that it needs to add or subtract from that to get the original image back. this means it will create a bunch of compression artifacts around those lines - like any lossy format would - and then store a bunch of extra data to remove them. not ideal

I would recommend this instead: `cwebp -mt -lossless -z 9 -alpha_filter best -metadata icc -progress -v input.png -o output.webp` this is for max effort so it is a bit slow

tbh `-m 6` is already quite slow, this sounds overkill

probablt would reformat to `cwebp -mt -m 6 -z 9 -near_lossless 100 -alpha_filter best` later however...

`-z` contains presets for setting both `-q` and `-m` at the same time because `-q` relates to speed/effort when lossless is defined. check here for what is set at each preset level: https://github.com/webmproject/libwebp/blob/874069042ead095f8a8d6bdd35b9b145ce80af43/src/enc/config_enc.c#L140

I think I decided z6 was about the practical limit in my case dealing with a couple hundred thousand images. higher efforts scale poorly in general

and if you want the best WebP compression you should bruteforce `-z 1..9` <:KekDog:805390049033191445>

not only that but you would also have to probably do it between libwebp/cwebp 1.4.0 and 1.5.0 because in some testing I saw 1.5.0 making lossless images larger for some reason

too much of a hassle for me lol

You could add `-q 100` even if that's lossless

this is what I've noticed as well IME

but scale weighting does seem to be one of those things it's inherently hard to tune for because of each person's individual preferences can be significantly different (crisper and more distorted vs. smoother and less distorted)

so different cohorts end up with different aggregates with a different spectrum of preferences and thus different weights after training

Quick benchmark on a significantly slower laptop for just one image ```byte sec command ---- 64,267,322 4.417 oxipng -a -f 0 --zc 1 ---- 38,811,969 2.011 qoi 38,332,388 15.147 oxipng -a -o 0 36,019,648 4.001 cwebp -lossless -m 0 -f 0 -q 0 -mt 28,886,875 2.378 cjxl -d 0 -e 1```

Tried my best to find the quickest `cwebp` approach

surprised qoi is faster than e 1, though with such a large increase in size it's not really worth it for the small decrease in time

Ran again with `qoi` and `cjxl -d 0 -e 1` each taking 2.106 and 2.427 seconds respectively

QOI remained slightly faster

Maybe that's due to a slower environment

what CPU is this?

Intel Core i5-8350U

so, quad core and AVX2... yeah that surprises me a bit

still, not worth it to use qoi though, as the trade-off in actually writing that image to a drive probably negates any speed bonus you get from encoding it

It uses one thread only though

`cjxl` could easily surpass with a faster CPU

I would think even a 4-core would be faster though for cjxl

I don't have anything less than 6-core though to test on

well, except for low-power stuff like a Pi

Not sure about if there are other parameters for `cwebp -lossless` that can be smaller but not much slower than `-m 0 -f 0 -q 0`

well cwebp seems to only be single threaded for lossless, even with `-mt`, with the exception of `-z 9` (where it still only uses 2 threads)

Uh that should be why encoding lossy WebP is much faster

IDK, I don't really test lossy WebP, and I really only use it for uploading things to discord (though with cjpegli, I use it a lot less now)

there is *something* about effort 10 that makes these graphs like ~15% of the size they were for effort 9...

(context)

the larger the image the bigger the gains, it seems

for lossless e10 enables the mixed predictor `-P 15` instead of the Gradient and Weighted Predictors.

and for larger images chunked encoding is also disabled at e 10

`-e 9 -P 15 -E 3 -I 100 --num_threads 0` is still within the same order of magnitude as `-e 9`. they say effort 10 also enables the "global MA tree", it doesn't look like that's something I can enable for effort 9 using parameters. i guess that must be it, then

I know that the entropy coding effort and LZ77 search space also goes up, but I doubt an incremental increase to those is going to suddenly result in 1/10th the file size

patches

OH

yes! thank you

I honestly thought lossless modular effort 7 and up used patches by default

The speeds aren't very different with i5-9600K ```byte sec command ---- 64,267,322 4.808 oxipng -a -f 0 --zc 1 ---- 38,811,969 1.598 qoi 38,332,388 13.041 oxipng -a -o 0 36,019,648 3.258 cwebp -lossless -m 0 -f 0 -q 0 -mt 35,330,537 6.417 heif-enc -L -p preset=ultrafast --matrix_coefficients=0 34,204,919 5.610 avifenc -s 9 -j all -l 28,886,875 1.969 cjxl -d 0 -e 1```

Could you try with a clang compiled cjxl? That might tip the scales between QOI and effort 1 JXL. Assuming Windows, I can send my binary if you need it

Annoyingly, Discord seem to lower the preview quality further when it's a JPEG file. They do the same for WebP but not as badly

Only in images under 2048 x 2048, due to chunked encoding. Effort 10 disabled chunked, so patches get re-enabled. I fixed the documentation for it in my PR yesterday while fiddling with resampling

ahh I see

Hackintosh 👀 but that 8350U is with Windows 11

Worth a shot

Not with that laptop now. To test tomorrow possibly

well they can't even get the colors right for sRGB so no matter what you do you're screwed

Yes the speed of `cjxl` is faster ```byte sec command ---- 38,811,969 2.086 qoi 28,886,875 1.785 cjxl -d 0 -e 1```

Why does the clang-compiled library encode faster?

Differing compiler optimisations probably

Clang is better than MSVC, not a big surprise

```byte sec command ---- 84,018 0.041 qoi 83,936 0.038 cjxl -d 0 -e 1 65,798 1.291 oxipng -o 4 47,660 0.836 cjxl -d 0 35,702 1.342 cwebp -lossless -m 6 -q 100 28,103 10.502 cjxl -d 0 -e 10 -E 4 -I 100 -g 3```

Nice

Added qoi back. How can I miss that

How does lower effort jxl compare?

Maybe even clang vs normal

I would expect e1 to be quite ok for such an image

add [fpnge](<https://github.com/veluca93/fpnge>)!

Yeah 82 bytes smaller and 0.003 seconds faster

Quite OK JXL

Needs some research first

Seems people really interest in that drawing board icon

what kind of research?

I was trying to think if splitting it into separate layers or using spines could help

Figuring out what it is and how to use it

It's a very fast PNG encoder

I heard of fpng before

Don't know how to use that fpnge

don't bother

IIRC that's the one that only takes PNG input, so it's useless as a fast encoder

it’s also a library that could be integrated in a tool that reads from other formats (or generates pixels directly)

only the bundled `fpnge_main.cc` is limited to PNG input

QOJXL

-e 11 is bigger...? ``` JPEG XL encoder v0.11.1 0.11.1 [NEON] Encoding [Modular, lossless, effort: 11] Compressed to 30018 bytes (0.229 bpp). 1024 x 1024, 0.002 MP/s [0.00, 0.00], , 1 reps, 14 threads. cjxl gimp.png -d 0 -e 11 gimp.jxl --allow_expert_options 1535.08s user 6.70s system 97% cpu 26:14.66 total ```

not likely if you compare for the same input and encoder version.

Maybe the original file compared to this under the alpha?

The genuine file

SVG source

I have been slowly setting up MacBook4,1 as another benchmark platform

Its Geekbench 6 scores indicate it would be good for benchmarks https://browser.geekbench.com/v6/cpu/122599

Multi-core Score is <10% of my main device

I've installed `qoi`, `libjxl`, `webp`, `libavif`, `libheif` and `oxipng` on it via MacPorts

The benchmark for the same image on MacBook4,1 is done ```byte sec command ---- 64,267,322 10.833 oxipng -a -f 0 --zc 1 ---- 43,662,994 4.300 qoi 40,848,451 30.326 avifenc -s 9 -j all -l 38,332,388 30.078 oxipng -a -o 0 36,019,648 8.105 cwebp -lossless -m 0 -f 0 -q 0 -mt 29,846,465 6.145 cjxl -d 0 -e 1```

What really surprised me is there are significant filesize differences except PNG and WebP

Only the `qoi` utility is different, and `avifenc` is slightly older, and all libraries are installed via MacPorts on that Mac. How could such differences happen?

I've made sure about that the JXL file can be opened

Was that using the clang version of cjxl again?

Hmm it says depending on clang-17 https://ports.macports.org/port/libjxl/details/

But the clang version of cjxl binary on Windows didn't produce size differences

Might take a while to unravel the code spaghetti and fix this

I know how, it'll just take time

I simply copied workflows from my main computer to that old Mac

Neat, 4x faster decoding than PNG on a random file I found in a game's cache folder of all places

```20,088,614 FD1.jxl 20,088,614 FD2.jxl 9,867,679 FD3.jxl 9,867,679 FD4.jxl 5,510,643 New-FD1.jxl 6,797,611 New-FD2.jxl 7,152,288 New-FD3.jxl 8,902,969 New-FD4.jxl 5,477,158 Default.jxl``` Still work to do, but progress. Now the different levels actually increase decode speed at the cost of filesize, while being smaller than current.

Still working on Faster Decoding 4, may turn it into 3 levels instead

Oh, also progressive lossless now ranges from 20%-50% larger instead of 100%. Lots more tweaking to do though since this is just a side effect of fixing Faster Decoding ```1,552,046 Normal.jxl 3,159,831 Old-Progressive.jxl 2,336,824 New-Progressive.jxl```

More progress for Lossless Faster Decoding``` Summary PNG 7,106,592 djxl --disable_output --num_reps 10 FD4.jxl ran 6,031,578 1.07 ± 0.01 times faster than djxl --disable_output --num_reps 10 FD3.jxl 5,765,455 2.02 ± 0.06 times faster than djxl --disable_output --num_reps 10 FD2.jxl 4,932,279 2.37 ± 0.03 times faster than djxl --disable_output --num_reps 10 FD1.jxl 4,807,033 3.66 ± 0.05 times faster than djxl --disable_output --num_reps 10 Normal.jxl 4,807,964``` Depends on image content, effort and resolution, but overall a lot better than it was

are all of these optimizations only for lossless?

Yeah, lossy has separate parameters that already work well enough

Gonna try and fix progressive lossless too, and did a flyby fix of allowing different predictors with Delta Palette which was added years ago but got removed again in a recent PR

ill DM you some lines to mess with that I tried to get sapien to mess with

eh, I could *always* use faster decode speed, especially in lossy

mainly because I'd love to find something I can use to replace prores

I've got ideas, but I'll need to figure out what it already does for lossy

Did some work on Progressive Lossless too``` (Oxi)PNG 8,482,827 bytes Adam7 PNG 9,940,041 bytes (Full image at 2.2%) Effort 1 8,135,838 bytes (Not progressive) Effort 2 7,566,316 bytes Effort 3 7,962,127 bytes (Weighted predictor) Effort 4 7,099,777 bytes Effort 5 7,130,420 bytes Effort 6 7,081,891 bytes Effort 7 7,019,834 bytes Default 7 5,628,080 bytes (Not progressive) Effort 8 6,750,659 bytes Effort 9 6,728,930 bytes Effort 10 6,722,822 bytes (Full image at 1%)```

More results in <#1358733203619319858>

So, libjxl *really* doesn't like dark areas. Original, `-d 1`, `-d 0.1` and classic JPEG at under half the bpp of `-d 0.1` while still looking better

And jpegli changes the brightness entirely

What does butteraugli say?