JPEG XL

factorio screenshots more than anything

Was just sticking to things I already had installed. JXL, WebP, ZSTD, 7z

7zip support creating xz archive <:KekDog:805390049033191445> but idk how good it is compared to official tools

For some reason compressing it as a .bmp gave the smallest results ¯\_(ツ)_/¯

And yes you read that right, it's bzip3 not bzip2 😅

Impressive. A bit disappointing that they limited block size to 511 MB

0.06 bpp JPEG XL

compared to AVIF @ same bpp

source image: <https://www.pexels.com/photo/pink-red-yellow-petaled-flower-in-close-up-shot-85773/>

is there a programm that can compress images much better than jxl at the cost of incredible high decompression times and or high ram usage?

high quality or low quality?

lossless or lossy?

mmh lossless

Avif is better in preserving high contrast details, jxl - in more uniform look

avif sucks for lossless

how does jpegli fare at 0.06 bpp

before i found jxl the only way to make a jpg smaller was using one of the pq8 compression programms and these have worse compression results than jxl recompression while making even effort 11 look like the flash

like don't bother with avif lossless

have you tried lossless webp?

lossless webp is almost always better than lossless avif from my testing

yep

imagine being worse than your predecessor

i also had no idea that avif exist before joining this discord

where did u learn about jxl?

https://www.youtube.com/watch?v=FlWjf8asI4Y

this video

we have had quite the influx since that video happened, may or may not be causally related

Wow. From a distance, JXL looks noticeably better than the AVIF. How did you make the AVIF? AVIF usually performs better.

`avifenc orig.png img.avif -q 21`

hmm

fair enough, if it has stupid defaults it's their own damn fault

im not an expert in AVIF options

jpegli is truly incredibly good at low bit rates

For ultra-low-quality, probably you could get more pleasing/"clean"/avif-like results by first applying some edge-preserving filter before passing the image to the jxl encoder. But I haven't really found any convincing use case where this kind of very low quality is really desirable. Expectations regarding image fidelity are getting higher, not lower. What's the point of making cameras and displays with ever-increasing fidelity (more pixels, higher bitdepth, wider gamut, higher dynamic range) if in the end you're going to ruin the images anyway by compressing them to 0.06 bpp.

And nobody should have to be

not as bad as i expected for JPEG 1

The AVIF version looks really, really bad.

I'm switching between the original, AVIF, and JXL and viewing all 3 from a distance.

`avifenc orig.png img.avif -q 26 -s 2`

Like from 8-bit game

no AC

just DC

lmao

actually there is some very basic AC

`-s 2` made a huge difference

Lossless webp mostly shines on artificial images like screenshots

it's more like png

just more advanced predictors

with -s 2 it looks better than jxl but it looks about the same when zoomed out

both look terrible though, right?

if you stand far enough away they look really good

only thing is JXL took 0.5s and AVIF took 2.2s

would probably be better to use a lower resolution though 😄

`Resolution : 2448x3264` probably would help

Not when zoomed out.

The first AVIF looked terrible even when zoomed out

here is the lowest quality AVIF with the slowest setting

`-q 0 -s 1`

Ah, these HEVC-like 'water paint' artefacts. Hate them

here's the flower image at the highest distance setting cjpegli lets you use (d=25). It's 0.137 bpp.

All of this very-low-bitrate stuff is all fun and interesting to look at, as long as you understand that it has very little to do with how codecs perform at usable qualities. To paraphrase <@532010383041363969> : it's like organizing a car race in a muddy swamp and concluding that a John Deere tractor is faster than a Ferrari.

I'm more likely to use d=0.1 than any of these quality levels 😄

for me it's JPEG: lossless jpeg->jxl PNG: lossless I hardly ever use lossy

very occasionally lossy modular at -d 0.02 or something

lossy could be used when producing resized photos from raws for display

anyways here's the lowest quality `cwebp` supports

fair

im keeping the raws anyways

0.0019 bpp?

0.019 i think

`0.0153326445 bpp`

No... 0.0019 I think...

Wait

I'm thinking bytes not bits

damn

it's 15314 bytes dimensions are 2448 x 3264 total pixels: 7,990,272 total bits: 122,512 122,512 / 7,990,272 = 0.0153326445 bpp

that makes sense

what image encoder supports setting the quality so low that you can barely call it an image?

can you send the original?

.

Any image format allows that, but not all encoders do

Try GIF or jpeg-turbo

question edited

You could change the distance limit in libjxl and see where you can get. With lossy modular you should in principle be able to reach arbitrarily low bpp. With vardct there is probably some minimum size that you can't get under.

do i have to compile from source?

there's this tool called `pngloss` which alters pixels of a png to make it more compressible

i set it to the max

and turned off dithering

lets say you have a set of images (all same resolution) that you want to compress together would it save space to throw them all into one big jxl image and treat it like a texture map?

or would it likely almost the same as compression them individual?

for icons probably as patches and multiple images can be in the same group

distance 2000 lossy modular

https://embed.moe/https://cdn.discordapp.com/attachments/803645746661425173/1281571738282627165/pexels-unchalee-srirugsar-14114-85773.jpg.jxl?ex=66dc3430&is=66dae2b0&hm=a35300ccee5d7b96b558cbdc91933e491a87e009155c297f5bfb746b6546457e&

looks like a not finished progressive jxl

distance 5000 lossy modular. Obviously it just becomes ridiculous at some point.

https://embed.moe/https://cdn.discordapp.com/attachments/803645746661425173/1281572140428296204/pexels-unchalee-srirugsar-14114-85773.jpg.jxl?ex=66dc3490&is=66dae310&hm=c314095bea0ec123f8f0c8d6cb8659dfd54bcbdc7834025fb7f16aece8243301&

set distance to INT_MAX

distance 20000 — no color at all survives

https://embed.moe/https://cdn.discordapp.com/attachments/803645746661425173/1281572426228174848/pexels-unchalee-srirugsar-14114-85773.jpg.jxl?ex=66dc34d4&is=66dae354&hm=cf05d222302da4eacfe45a58eb18ef3d13d7038bffc0a0a968b0e7255f5528cc&

is colour quantised more than luma

yeah — the scale is not comparable anyway, but yeah generally more bits end up going to luma

i truncated some bits

lol

that's so blocky that it might as well have been a lower resolution 😄

im guessing the later squeeze passes have been just set to 0

not entirely, I can see a few gradients inside the blocks

but probably very close to 0

Depends how similar they are. For satellite imagery it worked quite well https://discord.com/channels/794206087879852103/794206087879852106/1247491487181180940

Can channels reference previous channels in their prediction?

This specific case was using the -E flag https://discord.com/channels/794206087879852103/806898911091753051/1245440426824171541

I don't think there are any previous channel predictors, but values from previous pixels can be used in the decision tree

i wonder why, i guess devs decided that RCT and CfL would probably do enough for decorrelation

can you define custom RCT matricies for extra channels to interact with the main 3 colour channels?

lemme pull up the spec, one sec

I don't understand that part of the spec, to be honest, but I'm pretty sure you can put extra channels before or after the main 3 color channels.

for example, here is a bit of jxl art I made: https://jxl-art.lucaversari.it/?zcode=lZA9C8IwGIRn%2ByveXQr5bl0c7OKkokLnYqMNSJQSRP%2B9adqEgNri9twldwfvvjgCStaqrqUumkpreQWWrJSp5d00kCfbVkltKqNu2j6UqrbuQtiIVJfGALOYqDOcYGl7BsAeiAcaPjEP3Fm7Vj6oj3SCxYLHQjiRwkEawFQMlPMBqAfCPfE8bJC4aWqwTwsPBGe%2FNzChYQTHVVOLfRyFQhLWPkf6G7%2FcjQFS2MAcMKedsP7T%2BbMUSvvUhWZ%2FpzhGoylEvqUyMbrVlY6H3g%3D%3D

there are 4 extra channels before the color channels

does `HiddenChannel 4` tell it to put them before the main data?

so is a "hidden channel" an extra channel before the main colour channels and then "extra channel" a channel that goes after?

yeah. jxl_from_tree does something to tell the encoder to shuffle the channels around like that

"HiddenChannel" is just an option in the jxl_from_tree language, not a feature of the spec

it's all just extra channels

oh, so just jxl from tree terminology?

yeah

yeah no predictors that use previous channels

RCTs cannot have custom matrices but you do have several different RCTs to choose from. All RCTs operate on any 3 subsequent channels (where the channels are R, G, B, and then all the extra channels like alpha and whatever other extra channels you want). There are also RCTs that just do permutations (e.g. RGB to BGR). Chaining those allows you to arbitrarily reorder all the channels.

There are no predictors that use previous channels, but you can e.g. use an RCT to subtract the previous channel from the current, which boils down to something similar.

so there is limited support for channel communication / decorrelation

Also you can use Palette in funky ways in principle. E.g. you can make a palette for two 8-bit channels and replace them with a single 16-bit channel where each value encodes the combination of two 8-bit sample values, reordered in whatever way (e.g. the more common combinations first), which could also act as a kind of decorrelation.

there's EMMA <https://encode.su/threads/2459-EMMA-Context-Mixing-Compressor>

btw https://discord.com/channels/794206087879852103/803645746661425173/937627806408523777

i already like it

but it looks like jxl is still smaller

the author Marco Paìs said : "I've stopped working on this project, sorry. I've ported a lot of it to paq8px and cmix, so you can check those out."

In general? I doubt it, based on old benchmarks <https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/edit?gid=174429822#gid=174429822>. And make sure you are giving it PPM over PNG for best results since it is a general compressor.

and this is a different non-gui EMMA, faster and probably with better compression

I have tested one jpg file and but jxl won by a lot and the emma programm only accepts one file at a time as input so compressing all my files like that would be quite annoying

the cli version is more convenient for larger tests

it's also not for jpg, general compressors will lose to any sort of recompressors

Tried removing the almost empty Alpha channel (200 KB), and that shaved half a second off the e9 decode time, down to 2600 miliseconds roughly

did you use `-E 4`?

Tried from none up to 11, was a 100 milisecond decode difference and density only changed at `-E 1` and `-E 2`

Are we talking effort or extra channels?

Extra channels

not sure why alpha decoding would take 500 ms

It may be almost completely empty, but it is 80 Megapixels

is it libjxl taking the extra time or the PNG encoder?

This was opening in Irfanview since it has a built-in metric, so libjxl

Reloaded each image 3 times to get consistency, always was within a dozen miliseconds or so

did you try allowing more palette colors with larger groups?

Can do tomorrow

Hmm, I don't see any alpha chanel in that file

can someone tell me what the different effort presets are doing in detail? i assume that there are many parameter combinations and they are just testing a specific subset of them. is that correct?

https://github.com/libjxl/libjxl/blob/main/doc/encode_effort.md

e10 on there is now e11 I think

And what is now e10 is e9 + patches

yup I'm testing e11 for my lossless images

C'ya in a week

oh no thats gonna take months

do you know the kind of content up front, or is there a lot of variety? if you know the content, you can make smarter decisions than e11

there are a lot that are similar

but what better options do i have?

Well, I can suggest some. Like with photos, you only need to try 5 or 6 configurations rather than the 26 currently tried.

i didn't know i can specify the configurations myself

you can see here that a selection of 4 configurations outperformed former e11's gauntlet of 432 configurations: <https://loathra.com/jxl/bench/20240506.html#all-brute-2>

mmh ok but how can i specify specific configurations and where can i find out what my options are when i want to specify one?

just passing parameters to cjxl.

well i gues i have to read some documentation to find out what they are

cjxl -v -v -v -v ...

I'm getting inconsistent results, from 2200 to 2800. Jxl compressed to 3.022 bpp, btw

It looks empty, but the bottom left, bottom right and upper right corners have holes where terrain wasn't generated

Huh, what settings?

I mean I open it in PS and no layers, no alpha channel

e10 E3 g3 I100

Only WebP got 3.16 bpp with a stripped Alpha

I did notice the PNG header is set to RGB, but there's a transparency chunk which cjxl and some decoders don't ignore

Maybe we are talking about different files? This one, correct?

Yes

Splitted to parts because of discord. Created with 7z, don't know if it creates standartized files

On e9, g0 and I1 were best, maybe something about e10 reverses the trend. It takes an hour to encode for me so I couldn't really test many combinations

Idk, I did not try other parameters, can try now if it would fit currently free memory

Lower group size and MA learning also means less memory, so you already ran the worst case, bar e11

What about -E ?

-E 1 makes a slight difference, -E 2 and above shaved 6 MB off

I used the same command for e10

Let's wait some time 🙂

Thanks

cjxl -d 0 -e 10 -g 0 -E 3 -I 1 m.png me10.jxl JPEG XL encoder v0.10.2 e148959 [AVX2,SSE2] Encoding [Modular, lossless, effort: 10] Compressed to 34198.7 kB (3.286 bpp). 8880 x 9376, 0.123 MP/s [0.12, 0.12], , 1 reps, 32 threads. used 0:00:10:24.515

Well, either I'm doing something wrong, or I don't understand how did you get your results cjxl -d 0 -e 9 -g 0 -E 3 -I 1 m.png me9.jxl JPEG XL encoder v0.10.2 e148959 [AVX2,SSE2] Encoding [Modular, lossless, effort: 9] Compressed to 39364.4 kB (3.782 bpp). 8880 x 9376, 6.446 MP/s [6.45, 6.45], , 1 reps, 32 threads.

I'll have to rerun e9 at least, unless something drastic changed between our versions they should be the same

I'm running cjxl -d 0 -e 10 -g 0 -E 3 -I 100 right now, however it is already running much longer than -g 3

cjxl -d 0 -e 10 -g 0 -E 3 -I 100 m.png me10-1.jxl JPEG XL encoder v0.10.2 e148959 [AVX2,SSE2] Encoding [Modular, lossless, effort: 10] Compressed to 32023.3 kB (3.077 bpp). 8880 x 9376, 0.017 MP/s [0.02, 0.02], , 1 reps, 32 threads.

cjxl -d 0 -e 9 -g 0 -E 3 -I 1 minecraft.png e9g9E3I1.jxl JPEG XL encoder v0.10.2 4451ce9 [AVX2,SSE2] Encoding [Modular, lossless, effort: 9] Compressed to 45774.0 kB (4.398 bpp). 8880 x 9376, 1.316 MP/s [1.32, 1.32], , 1 reps, 16 threads.

So some kind of major regression since 0.10.2 released... 2x slowdown (16 vs 32 threads, so halved) and 0.7 bpp worse density

Let's ensure that I'm doing everything correct, because it is very strange. SHA256 from original png: 61453c464958cad62970675bf901f3a3d675a49d36be62edbf2a0338e04f8543 , correct?

Identical

Hmm

Hmm, could be this https://github.com/libjxl/libjxl/issues/3441#issuecomment-2024623501

> This is likely caused by my changes to the palette heuristics (#3420). It is expected when changing such heuristics that for some images, compression will be worse, for others it will be better. On larger sets of images, I saw an improvement on average (e.g. 0.25% improvement on the QOI test set), but such averages do hide a lot of per-image variation, e.g. one image might be 500 bytes larger and the other 600 bytes smaller. > > The only way to avoid such regressions is to try both the old and the new thing whenever a change is made, making the encoder twice as slow. But such an encoder slowdown generally is not justified :)

yeah, you really need to test on more than just 1 image

I recommend at least 500 images

I only have 458 for my regular testing corpus 🥹

I have 1542 for speed vs density, but a little over half that is unique image content since I have versions with metadata and without. Then I have additional 1542 with unique image content for testing density alone.

for studying highest-density settings, my benchmark applied 4608 settings to 1245 out of roughly 2300 available images (plus a couple thousand settings against smaller subsets)

e11 can be improved more by further differentiating images. currently it runs 2 trials followed by either 24 or 20 additional based on result (and technically one of the initial trials is probably redundant for density most of the time). run six initial trials, then run 16 or fewer additional trials based on results, it should be denser and faster

you can imagine continuing to iterate to some logical conclusion, but this technique has the side effect of code bloat, I think

with four trials, I can distinguish a group containing all photos, a group performing best with lots of allowed palette colors, and a group performing best with no allowed palette colors

cjxl -d 0 -e 9 -E 3 -g 3 -I 100 m.png m.jxl JPEG XL encoder v0.6.1 a205468 [AVX2,SSE4,Scalar] Read 8880x9376 image, 78.2 MP/s Encoding [Modular, lossless, tortoise], 16 threads. Compressed to 31581648 bytes (3.035 bpp). 8880 x 9376, 0.01 MP/s [0.01, 0.01], 1 reps, 16 threads.

cjxl -d 0 -e 9 -E 3 -g 3 -I 100 m.png m.jxl JPEG XL encoder v0.9.2 41b8cda [AVX2,SSE4,SSSE3,SSE2] Encoding [Modular, lossless, effort: 9] Compressed to 31796.6 kB (3.055 bpp). 8880 x 9376, 0.014 MP/s [0.01, 0.01], 1 reps, 32 threads.

<@238552565619359744> 0.11.0 achieves lowest bpp: cjxl -d 0 -e 10 -E 3 -g 3 -I 100 m.png m.jxl JPEG XL encoder v0.11.0 3786abb [AVX2,SSE2] Encoding [Modular, lossless, effort: 10] Compressed to 31409.2 kB (3.018 bpp). 8880 x 9376, 0.015 MP/s [0.02, 0.02], , 1 reps, 32 threads.

Hmm, good to know with enough time it still sorts itself out

hey i want to convert a set of jpg (lossless recompression) and png (lossless) images to jxl with many different parameters to find out how much each set of parameters influence the image size for my images. but even with the help description for each parameter i still don't really know what many of the parameters do and if there is even a point in testing these. can someone help me to narrow it down?

I'm by no mean expert, so this may be wrong or incomplete. For jpegs I use -e and --brotli_effort for jpegs with exif. For pngs these parameters affect compression: -e, -g, -E, -I and also probably --brotli_effort for pngs with metadata. Explanation what each parameter does is above my knowledge, sorry

the whole point is to find parameter combinations that are about as effective in terms of compression as effort 11 without having the insane computational effort that effort 11 that tests many different combinations

IIRC <@263300458888691714> did some work in this field

when i look at the help and see a parameter like this --codestream_level=K The codestream level. Either `-1`, `5` or `10`. i have still no idea if that is usefull for me because i have no idea what it does

Mostly you can ignore most things and just use --effort. At least that's the goal. We don't want to make it more complicated than that for end-users.

In other words, if there's a non-default set of options that consistently outperforms the default behavior, please make a pull request to improve the default 🙂

If you just want a best overall command, here are the results of Monad's extensive testing https://loathra.com/jxl/bench/20240819.html `cjxl -d 0 -e 10 -E 4 -I 100 -g 3 --patches=0 --brotli_effort=11` should give you the best overall density without wasting an extra month of your life on encoding

can i increase the -E parameter infinite or is there a limit?

At most you'll generally only have RGBA, so 4 channels for the parameter to use, although the maximum is 11

That's not the best overall command as far as density, it's the one that achieves the highest number of minimum results. Best one kept patches enabled, as seen in the [giant table](https://loathra.com/jxl/bench/20240819.html#data_or_data-3).

The 3 tables in a row threw me off which one to look at xD

the biggest

it shows density of command

density of command = most compressed end result?

So, most people look at smallest total size. That's fair, but biases toward larger images. I sort my tables on bpp, which I _feel_ is more robust, but which biases toward smaller images. This is okay for something like e11, which is increasingly impractical the larger the image.

ah yeah -e 11 has been working on a 3760*2684 image for a while now on my pc

it is the money wasting effort level, for entertainment purposes only

when you are after the smallest result should you also add `-I 100` besides -e11 ?

Expect Christmas gift, not earlier

or is that already included?

e11 overwrites user settings of I, P, E, g, patches, modular_palette_colors, X, Y

mmh so e11 is the absolut limit of what you can do? or are the perameters that have aa chance could make it smaller?

it's not the limit

for example, in maybe 20% of cases, old e11 can find a smaller image than new e11, but new e11 is smaller on average

yeah but are there parameter that let me recreate these results without relying on the old version?

e11 utilizes 46 configurations (one is probably redundant for density), testing either 26 or 22 per image depending on content. Minimizing my test corpus would require ~115 configurations.

can i create a script that does true brute force that reach the best result in case it ever completes execution?

You can. True brute force won't ever complete. It just won't. So if you want output, you have to make some choices.

what are the parameters that i would need to consider for true brute force?

Well, there's all e11 overwrites which I mentioned above, those are the ones exposed to the cli.

There is no true brute force encoder for lossless jxl except a Kolmogorov search of all bitstreams.

But there's a lot more stuff possible that isn't exposed to CLI.

Even e11 is just doing multiple heuristics but very far from exhaustive. We only apply RCTs in a limited way, we only try one palette ordering heuristic, we do MA learning in a greedy way, etc etc.

e11 also tests the no weighted predictor path, which is not exposed to cli

The full search space is just way too huge to even consider doing anything exhaustively.

Probably with genetic algorithms and AI you could make an encoder that can explore a bigger chunk of the search space and beat e11 with the time/memory budget of e10. There is a lot of room for making more use of the expressivity of the bitstream, in a way what we have in libjxl is just a proof of concept that there exists a somewhat effective encoder.

creating a heuristic for such a giant search space sounds difficult.

I already know of a better (and possibly slower, or maybe not, who knows) heuristic for the tree search

just never had time to write it 😄

well, *probably* better

Why not write a rust encoder for lossless jxl? 🙂

eventually 🙂

can't wait to start at 0 again when it gets released 🙃

e11 only increased the time for lossless significant. jpg recompression didn't seem to be affected at all

but it also wasn't smaller

e11 doesn't touch lossless jpeg

that explains a lot

Of course, this depends on content. so, specifically, on a diverse set of 84 images, new found 43% mins which old did not find, and old found 26% which new did not find. on a subset of 22 photo/film, new found 45% mins which old did not find, and old found non which new did not find.

The goal was to improve it by an amount where people wouldn't think they should use both versions.

with 45 configurations from e11, we achieve 52478644 bytes across a 1245 image set. 139 out of 3840 tested can minimize this set to 52439674 bytes.

but recall e11 only tries half of those on each image. by trying one set of 36 on each image, I get 52467707 bytes. one set of 26 gives 52515793 bytes.

What is your strategy?

i dont have one yet

```JPEG XL encoder v0.11.0 850f6cdf [AVX2,SSE4,SSE2] Encoding [Modular, lossless, effort: 12] Trying 760320 configurations, please be patient ...```

e11: 0.492s, 1779 B e12: 18m10.482s, 1752 B

worth

It finished before Sun became red giant? I'm surprised

Only 30x30 pixels

e12 ?😍

I'm surprised it was that fast too

<@365440150785753088> you want this shiz?

I'll test it for sure

okay

how many configurations is e11 testing?

either 25(+1) or 22

i didn't know there is e12 the help description only mentions e11

I just made it

can you give me the exe?

I will push to GH in a bit

<@365440150785753088> <@238552565619359744> <https://github.com/monad0/libjxl/tree/cpu-heater>

For jonny, it outputs the selected settings at the end. But I didn't add a `--tree_mode` yet, so sometimes you can't actually utilize that.

A significant portion of this space I am almost certain is useless, because I've tested it. Most of this space, I've never tested.

But it does just about fulfill the "keep running and never stop" prompt

is there a compiled version of new e12 cjxl.exe that I'm missing?

no

I know one idea I had was a very rough time estimation extrapolating from average encode time per megapixels

you could do one encode ahead of time and do the math

but also this is the dumbest thing you could ever run, so don't use it

maybe GH would build it for you enabling workflows. but i don't think i want to enable all that on my end, i don't know if it's practical to avoid the unrelated stuff

I see I'm not the only want interested in burning my CPU <:KekDog:805390049033191445>

yup

Does it print a progress log?

nah i don't check the output

i just assume that it worked when the process is done and start the next image

I kinda want to rent one of those 64 core servers for 1 hour to see how slow this is

Does it spawn new processes?

cjxl doesn't by itself but my java code does

Oh it’s a custom Java script?

Not JavaScript script, Java script

Geez they need Better names

i can change the number of paraallel conversion with this txt

maybe i should just my a gui but i'm too lazy for that so far

Is that your configuration file?

yeah just a file with a number that my programm reads every 5 seconds

mfw not using CLI tool as simple as `parallel cjxl <params> {} {.}.jxl ::: *png` and imagine writing Java code to do this <:NotLikeThis:805132742819053610>

and i agree it's confusing that there is java and javascript that are totally different laguages

For the longest time I actually thought they were related in some way

turns out they have nothing to do with each other ¯\_(ツ)_/¯

i already wrote the code for webp conversion so changing it to jxl was just editing the exe path and the parameters i want

JavaScript started as a scripting language that was created back when Java was very hyped, so I guess they're related in that way 🙂

reminds me of this: https://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html > 1995 - Brendan Eich reads up on every mistake ever made in designing a programming language, invents a few more, and creates LiveScript. Later, in an effort to cash in on the popularity of Java the language is renamed JavaScript. Later still, in an effort to cash in on the popularity of skin diseases the language is renamed ECMAScript.

Next time I visit my friend I can try and remember to plug in their old Google datacentre server, think it was 64 core 192 GB of memory

They just have a data centre server?

They used to work at Google and were friends with one of the datacentre techs. Old servers were getting retired one day, so he bought one of them off of the guy for £120 or something stupid

<@167354761270525953> I'll carry on here

Good idea

context: https://discord.com/channels/794206087879852103/822105409312653333/1283560514735177831

97.3 MB GIF to 77.6 MB APNG, so at least I was right for the first half

Now the issue is the total animation is 300 Megapixels... And I was already nearing my limit at half of that, so you might have to try it yourself. On the plus side, the APNG tool runs per frame, so the default settings should be fine without blowing up your RAM https://gif2apng.sourceforge.net/

I have a lot of RAM, so it'll be fine xd

But even 32 threads take a whole while to encode smh

Well, not that I'm surprised

Frames are small and it only encodes 1 at a time, so probably only using 2 threads at best

Thats why I am encoding webp, avif, apng and jxl at the same time lol

That kind of GIF is probably more suited to video codecs, does AVIF do any good?

AVIF conversion is still running

I'll post after it finished

Given the slight camera movements it would be hard to find patches of pixels that haven’t moved

Although AVIF’s horrid lossless performance may ruin that advantage

Indeed

AVIF is especially bad at encoding GIFs in my experience

Maybe the palette screws with it

It just does best with clean lines

What about lossy?

But we'll see how it does with this contender

Lossy AVIF just smears the result, even at crf1

Oh yeah, I forgot AVIF is AVIF

I have found it to be pretty useless for GIF encoding, especially if the GIFs aren't using palettes

And yet it is still often better than lossless WebP

Depending on the content of course

But with a few hundred animations I encoded lossless AVIF was often very competitive if not better than lossless WebP

``` 76M ZhEb2N3.apng.e10.jxl 78M ZhEb2N3.apng 81M ZhEb2N3_z9.webp 84M ZhEb2N3.gif.e10.jxl 89M ZhEb2N3_s4_crf10.avif 90M ZhEb2N3.apng.e7.jxl 98M ZhEb2N3.gif 106M ZhEb2N3.gif.e7.jxl 127M ZhEb2N3_s4_crf5.avif 261M ZhEb2N3_s0_crf0.avif ```

AVIF is indeed really bad for GIF encoding, as I said lol

Geez how is it worse than the original GOG

GIF *

By a factor of almost 3 nonetheless

Kinda an achievement tbh

Lossy AVIF larger than GIF, imagine

Is AVIF the only one that wasn’t lossless?

Or was JXL lossy?

All lossless except for the two AVIFs

Lossy AVIF beaten by lossless WebP 🤣

Yup

What were the encore times?

A few minutes for everything except for the e10, those were around 50 minutes each

The lossless AVIF also took around 10-15 minutes

Still, e7 JXL beat AVIF crf0 and crf5 so just use JXL

unless you have 50 minutes to do an e10

Agreed

Tbh WebP, not bad

Sometimes lossless AVIF beats lossless WebP, but yes, very much depending on the content

Speed?

WebP is much faster, but for me storage is more important

The WebP was btw also encoded at the highest compression

WebP also has the big disadvantage that it cannot be played by media players with FFmpeg backend because its libwebp integration is broken since years ago

Probably because GIF, PNG and (Kinda) JXL use an 8 bit palette, AVIF would've been turning it into 24 bit

I see 3 AVIFs though?

Yes, two lossy AVIFs and one lossless AVIF

CRF0 is lossless at the bottom

CRF 0 isn't lossless though <:Thonk:805904896879493180>

It wasn't due to a bug in FFmpeg, formerly requiring -aom-params lossless 1, but this has been fixed, crf 0 is lossless nowadays

Just for fun I tried using <@274048677851430913>'s Frame Stitching tool for some more results. GIF with e1 or e7 was always larger than the APNG. Encoding at e10 from the apng resulted in a filesize of just 75M, being 1MiB smaller than the previous best xd

oh, this is in ffmpeg...

``` 75M ZhEb2N3.apng.framestitching.e10.jxl 76M ZhEb2N3.apng.e10.jxl 84M ZhEb2N3.gif.e10.jxl 90M ZhEb2N3.apng.e7.jxl 106M ZhEb2N3.gif.e7.jxl ```

Are you sure it isn't just because AVIF's compression for content like this is bad?

Oh it's still awful, considering the total pixel count is around 300 Megapixels, and the lossless AVIF is 261 MB...

hmm my tool didn't have auto-cropping ability like ffmpeg's apng, wonder if that can make a big difference too~

in my testing at low efforts, the jxl was quite a bit smaller if compressed from a gifsicle-optimised version of the gif; I’ll try e10 now

ah, or perhaps the apng results in a similar effect

if you didn't flexiGIF, you didn't GIF hard enough

Does anyone know of a dataset with very large, possibly lossless images?

how large?

10-50 MB per image

even larger would also be fine

is that uncompressed?

doesn't really matter tbh, but png or similar would be prefered

I was thinking of creating one myself from images by NASA, but asking first may yield faster results

here's one <https://imagecompression.info/test_images/>

Thanks

You can also get the LPCB images here: <https://drive.google.com/drive/folders/1X_F_vhNwJFhPWSW3EeSa-gGhhikkOoYd>

Nice! Thank you very much

I was about to say isn't that lossy? Then realised I'm thinking of Gifski

yeah, as far as I know, it’s just about optimising palettes and “[storing] only the changed portion of each frame”

which `cjxl` can then take advantage of

(well, not the palettes, it will find its own)

it doesn’t try to detect such subrectangles itself in animations, but it does reuse them from input GIFs

The APNG tools use the same transparency trick, but also change the actual frame dimensions to the minimum change, which cjxl can then use too. So a twinkling star will only need a 3x3 frame instead of 720x580 for example

can you tell cjxl to move the pane? like if you have an image scrolling by 2px each frame, can you say "last frame but translate down 2px"?

obviously requiring extra data for the quite literal "edge cases"

Maybe with Kampidh's editing tool they posted a while ago

As in does the code stream support it?

I think at least patches would make this theoretically possible

by having one big patch that you translate progressively

provided that the image is static

or efficiently delta coded? you can use patches to move stuff in a duration-0 frame and then blend on top, no?

How big can a patch be?

not sure we have a limit

Can blending only blend certain pixels?

alpha blending for sure, yes

Like if I set the pixel to transparent it skips over?

patch width and height are just hybriduint encoded so can be anything as long as they stay within the bounds of the referenced frame

just wondering, how does the whole hybriduint thing work?

that's the part of the spec I really don't get

the entropy coding is really advanced stuff

so you could definitely making an animation that is based on some scrolling background with some sprites moving around on it, like an oldschool 2D platformer game — you just make an invisible patch frame that contains the full background and all the sprites, and then in each frame take a moving window out of the background as one big patch plus a bunch of patches for the sprites. Basically all the visible frames would be patches-only so very tiny.

sounds really fun

someone should make a full-blown JXL patches / animation / layers tool

Hybriduint is an encoding for unsigned integers that consists of reading one entropy-coded token followed by a variable number of raw bits. How to interpret it depends on the configuration (which is signaled) but generally the first few tokens are directly representing small numbers, and then there are tokens which only represent the number of bits and some of the most significant bits (optionally also some of the least significant bits), and the remaining bits are just read as raw bits. There can also be tokens that represent an lz77 match (then the token+raw bits represents the length of the match, and a next token+raw bits will be read to know the distance). The entropy coding for the tokens can be either ANS or Huffman.

Oh, so it’s like entropy coding the first byte in a UTF-8 stream?

Then storing the next bytes raw?

Also since ANS has fractional bits, how does it know when to send the raw bits?

Basically the assumption is that usually (e.g. when encoding quantized DCT coefficients or prediction residuals), only low-amplitude numbers and the most significant bits of higher-amplitude numbers are worth using entropy coding for; the least significant bits will be basically like noise so you can just as well not bother with entropy coding and use raw bits. (it is possible to include one or more lsb in the token, this is useful because often we turn signed ints into unsigned ints by putting the sign bit at the end, and sometimes the sign bit does benefit from entropy coding)

the final bitstream is a mix of "update the ANS state" bits (for which we always read 16 bits at a time) and just raw bits

So a token can mean “0110 (read 4 bits) 1” or “101 (read 9 bits)” or just “100”?

Does it signal when it’s Update ANS?

no this does not need to be signaled explicitly, it just gets updated whenever it runs out of state bits — encoder and decoder just have to do this in the same way

How do they make sure they’re doing it the same?

the ANS state is an uint32 and after each read the decoder updates the state, checks if it became smaller than 1 << 16, and if it is, reads 16 more bits. The encoder just has to make sure it writes those 16 bits at the right spot.

Isn’t ANS read backwards though ?

What form of ANS is JXL? uANS/ tANS / rANS?

rANS

it's written backwards so it can be read forwards — it's a bit annoying for the encoder since it has to buffer all symbols, then write them end-to-beginning, and then reverse the resulting bitstream again, or something like that

(this is why we also have the option to just do Huffman — it's not as good, but a lot easier for the encoder)

I have tested a small GIF dataset with 70 items from images I had lying around. JXL, WebP, AVIF and APNG, all with lossless compression of course. e8 for JXL, speed 2 for AVIF, max compression for WebP. There were some GIFS that cjxl could not compress, failing the encode. I have attached them ``` GIF 103M total JXL 96M total WebP 97M total AVIF 313M total APNG 95M total ```

libjxl version?

Oh sorry, forgot to mention that. v0.10.2 36e05143

I expect the issues go back to earliest releases

Would've been nice to have JXL'd APNG too since it gives a rough idea of what the format can do

I thought of doing that. Can still do it if you'd like

We have really pretty much neglected animation (since usually, video codecs will be a better choice anyway). Maybe we should at least add some basic encode option in libjxl that does auto frame cropping and/or auto converting kReplace frames to kAdd ones.

Video codecs are definitely the better choice for longer content, but many artists still deliver GIFs or very short animations with the intention of them looping

Especially in the case of Discord that disallows any sensible looping format... But then there's also pixel art too

Threaded frame encoding, difference masking/frame cropping (Likely in the same step, and calling it that for simplicity) and streamed input (Only load up to the current encoding frame) would solve pretty much every issue currently. Beat the others in speed, use the obvious optimization techniques and likely lower memory usage by a decent chunk for longer animations (If streamed GIF is feasable) 'Rolling Patches' could be another idea, only comparing the current frame to the previous, and then searching for old patches in new frames, although I've not checked the spec yet so that could be similar to how it currently works

the frame by frame loading is not really a libjxl problem but just cjxl being too simplistic and assuming it's fine to first load the whole input and then start encoding it. Libjxl does already support encoding one frame at a time, so it's mostly just a matter of code plumbing to change "first load the whole gif/apng, then encode all frames" into "load gif/apng frame, encode it, load next frame, encode it, etc"

Yeah, just thought I'd write down all the ideas I could come up with

`cjxl` seems to slowly amplify the DCT coefficients

gradually infecting the image with black and white lines

as the file size slowly creeps up

probably due to the hybriduints having more raw bits

currently generating a video

200 iterations per second ran until the encoder started repeating itself

`-d 1 -e 7`

can you try with `--gaborish 0`?

sure

now it's making things more and more yellow

after 700 iterations

(the previous went to 7188 iterations)

https://embed.moe/https://cdn.discordapp.com/attachments/803645746661425173/1283986089559982173/0700.jxl?ex=66e4fcbb&is=66e3ab3b&hm=44b5afd27dc8a0b33229691f08f3145f66aab695bab8d4b99eb0b3a6bfc021e0&

10k iters @ 200 iters/s

`cjxl -d 1 -e 7 --gaborish 0`

https://github.com/libjxl/libjxl/pull/3563 https://github.com/libjxl/libjxl/pull/3586

Not sure what libjxl version you're using, but those might help

i'm using release 0.10.3

i'll retest when 0.11.0 releases

Apparently that might be tomorrow, or today depending on timezones

nice

Since the AI boom started all searches regarding datasets mainly show AI focussed datasets and websites smh

JPEG AI?

No, in general

All these datasets are now intended for training AI models

``` 1,5M OpenTTD_8K.jxl 4,1M OpenTTD_8K.png 85M OpenTTD_8K.avif ```

This may seem like a joke, but it is not

To give some important context, the AVIF was captured using Valve's gamescope, which uses AVIF for screenshots, so it likely is encoded at the fastest possible speed

Ok nevermind ``` 1,5M OpenTTD_8K.jxl 4,1M OpenTTD_8K.png 85M OpenTTD_8K.avif 96M OpenTTD_8K_s0_reencode.avif ```

Encoding times: ``` JXL 0:00.92 seconds AVIF 0:32.40 seconds ```

Lossless avif is basically useless. It's worse than PNG in basically all ways: it has lower limits on bit depth and image dimensions, is slower, compresses worse, and has less software support. There is not a single reason to use it.

it exists !

Sadly there is no choice in the matter for gamescope. It will always capture AVIF if lossless capture is enabled.

I'll try to get a screenshot at 16K and higher and see how it compares lmao

basically the only competition for lossless is between JXL and WebP, but the latter is far more limited, and rarely better than JXL

though even xz beats JXL in some cases so it's very content dependent

I was actually thinking about OpenTTD recently, after my friend took a map screenshot of our last game... 5 Gigapixels large... The screenshot function already does chunked encoding, so it *miiight?* be possible to make a JXL patch with *relatively* little effort, although using patches from the game tiles would be another very advanced, time consuming, extremely efficent way

I doubt you're using HDR by any chance?

Sadly not

No HDR display available

Huh... Because AVIF should only enable when HDR is in use, both in Steam and the gamescope code I just looked at

AVIF capture is enabled if lossless capture is enabled

Ah, just checked and it was HDR screenshots only being enabled if AVIF is also enabled on gamescope

I was thinking of opening a feature request on the gamescope github to ask for libjxl support

`rgbAvifImage.format = AVIF_RGB_FORMAT_RGB` Well, at least they are actually lossless for once `pEncoder->speed = AVIF_SPEED_FASTEST;` And it seems like you were right, maybe just different versions?

Show the compression results and I doubt they'll have a reason to say no :P