JPEG XL

with jpeg i fatigue to compress almost zero image compressed but is made in this way

is more secure as jyri said

you have less risk or ruining image

also the encoder is test

mine was 100 kb jpeg to 20 kb jxl

80% reduction

your image sent i don't know the original file size

i guess is a png

with few webp icon

Don't worry, he used 8.03!

with photographic it does suprisly good

i expected the opposite

like it would be better suited for modular

now i'm using d 1 -s 7

no way

But i prefer options that works with different type synthetic etc

synthetic?

Like the contrary of photographic

i deleted the re encoding options on the doc file

i also tried

for %i in (C:\Users\User\Documents\a\*.png) do cjxl "%i" "%i.jxl" -q 93.10 -I 0.908 -X 8.222 -Y 13.44 --intensity_target=205 -g 2 -s 9 -m --num_threads=2

but it doesn't decode the modular file

it decodes an invalid file

i didn't tried without g2

or with g3

but i don't want to

i prefer waiting until the encoder makes butteraugli decisions

deleted my original

i tried with c2 but it changed colour it becomes violet

so i won't try anymore

Photomosaics generated by https://www.complang.tuwien.ac.at/schani/metapixel classical, no cheating, constituent image size of 32x32 ```encoder size B mem KB time s pingo -s9 -nostrip 29443130 766392 220.38 cwebp -z 9 -metadata all 8208784 1141764 99.42 cjxl -d 0 -s 7 34868365 3730400 189.53 pingo -s9 -nostrip 55490015 1040116 126.52 cwebp -z 9 -metadata all 20657804 1114144 111.69 cjxl -d 0 -s 7 50222491 3447760 214.21 pingo -s9 -nostrip 27867016 612748 56.23 cwebp -z 9 -metadata all 6994508 530856 40.39 cjxl -d 0 -s 7 25834021 1637624 84.85 cjxl -d 0 -s 9 -E 3 -I 1 -g 3 13691659 3794756 2544.06```

interesting, webp is doing great on these!

Is there that much overhead on JXL or is it something else?

maybe the color cache feature of lossless webp is particularly useful on these particular kinds of images

oh wait, this is a mosaic, so it's looking at the overall image and not the compression of each 32x32

<@263300458888691714> can you share an original png?

perhaps `-g 0` could give better results for these particular kinds of images

Yes, `-g 0` does better in what I've tested.

Can't share these images, but I can see about generating new ones if that would help.

<@!794205442175402004> <https://mega.nz/file/fNk2TaYS#7Ihu2HyAFIBPYbWRznvW_pAvCxRXuHQUIh1JaIRqg_U> ```encoder size B mem KB time s pingo -s9 -nostrip 31930150 576664 52.03 cwebp -z 9 -metadata all 9830406 539308 49.59 cjxl -d 0 -s 7 28134264 1619660 91.75 cjxl -d 0 -s 7 -g 0 26748947 1619916 123.80```

oh, I see what is going on here

a lot of the subimages are repeated

webp will catch that

jxl currently doesn't really

patches could do it more efficiently than webp probably, but the current encoder is not going to find those patches here

and we could get some savings with lz77 but that's only going to help within a group and it will not be as effective

Can symmetries be encoded with patches?

no, only translations, no flips/rotations

if you would first encode a spritesheet that contains every unique subimage once, then use patches to make the composite image, I think webp could probably be beaten here

Are we talking about libjxl or the jxl spec?

webp and png have the advantage here that all they know how to do is lz77 distance matching, so they will kind of automatically find these repeated subimages as long as they're within the lz77 window

spec

you can of course just encode all the variations w.r.t. flipping/rotation that you need

just you don't get "take this patch and flip it" for free

we at some point thought about adding that but it's basically more signaling cost for questionable gain

(and also more implementation complexity to do blitting of oriented patches)

few people do the mosaic thing any more, it seems like a fad from the early 00's

Which translations are allowed?

I mean translation just in the sense of moving it to whatever x0,y0 offset

do you can mantain another lossless algorithm that don't use patch

but the traditional way

You can just turn off patches and just use modular standalone I believe

There's no point to turn off patches though

Patches actually save space

not *always*

If they don't save space then they shouldn't be used right?

I mean the encoder should decide to not use them

Not *always* .

You need very good heuristics to determine if they are useful or not.

If you had the time you could check the difference with and without

But only if you had the time to do the equivalent of two encodes

my code generally assumes they do save space if they occur at least ... twice? three times? 😛

but I'm pretty sure we could do better

Probably patch on test save space also on one occurrence, modular encode test smaller than vardct

I think

you had a image in lossless modular smaller than vardct

pixelart? anime?

a lot

Not surprising. You can make PNGs that are much lower than JPEGs when the graphic is simplistic and a vector-type, unless you set JPG to rather low quality. Depends on the content of the image.

original

- d 1

-m

10 times smaller

Yep, pixel art generally will work better with modular.

as text

Text?

Even the PNG you posted is 18 KB, even smaller than the jxl.

yep, this is a good case for png, modular need some other tweaks on some pixelart

yes, modular is better on text then vardct

Oh, I thought you meant that image was text.

original

d1

d1 nopatches

m

i was expecting smalller m, but is lossless after all

If it where just the console window it would probably be quite a bit smaller. That photographic background around the edge is likely what increases the size.

probably

Patches with vardct does quantized colors so somewhat lossy modular (it subtracts the patches and the residuals do still get vardct encoded, but likely get quantized away there)

text file to try

What is the point of all these screenshots?

It is kind of spammy

ok

this is the png

https://discord.com/channels/794206087879852103/803645746661425173/839203840935198740

there are paint blocking artifacts

i did not generation loss tests

also low quality mozjpeg has smoothing enabled

ok new settings

q78 firefox browser jpg

canvas is wp2 image

i used lower possible settings

and worst possible settings

not comparable one

Here's the lossless image:

Recompress that at -d 1 and look at the lines on the bottom of the gun <@!424295816929345538>

oh no xcom 2 no!

now i can't on my computer

i haven't the ram

with firefox open the max i can is 1,6 gb of ram

on my screen i don.t see any difference

even the display of the image lasted more then 14 seconds

Oh <:PepeSad:815718285877444619>

you see differences in my png?

definitely, though I'm not sure why yours looks so much lighter on the right

I've been decoding with djxl to avoid any decoding issues with viewers

I try with djxl

whitch image viewer you use for pngs?

I'm using nomacs

you see divverences from the png opened in nomacs and in google chrome? (chrome as a good color managment)

I don't have chrome installed

edge?

Not running Windows

chromium?

Just Firefox

firefox not have a good color managment

not out of the box anyway

nomacs has some issues but as long as you stick to the common formats (png) it's fine

png can have may issue in color managment, I say that becouse a lot of bugs report (color shft) on jxl was due bad png viewer

example

well, opening it in GIMP it looks identical

we need a more expert opinion

random <@!799692065771749416> ping

Here is a good gradient (16 bpc) for testing dithering since the human eye is more susceptible to green:

```197 048 - new build 210 847 - old build```

But this is one of the few images where patches win

I am surprised it even finds patches there - probably misses many potential patches still

```21 223 - new build 16 505 - old build```

There's text, but that doesn't improve efficiency

Is this a 1-bit image?

(on phone, hard to check)

It looks 2-bit or so

Possibly the image itself is so cheap without patches that the signaling cost of patches is worse than just not doing patches

```q1bHrZ3.png PNG 1920x1080 1920x1080+0+0 8-bit sRGB 7c 18513B 0.000u 0:00.017```

7 colors, so 3-bit I guess

It could be that patches is trying to do those dithering dots

```19 665 - new 17 125 - old```

<@179701849576833024> what is the minimum patch size? Could be useful to bump it up when doing lossless...

Scope are you comparing at slowest settings? Things might be different at faster speeds...

Yes, first all sets on the slowest, then I'll try the others, btw, from what speeds are the paths enabled by default?

I think hare and slower

At slowest speed, the encoder also tries to do lz77 matching, which competes with patches in a way

yes, very likely

probably 1x1, and you're probably right

<@!111445179587624960> can you try this patch on the images that became worse? (and possibly also on those that became better :P) It makes things worse in some cases, but it should prevent dithering patterns to be encoded as patches - I don't know if that's going to improve things, and before I submit something like this it would be useful to know if it actually works 🙂 ``` if (!found_border || !all_similar || max_x - min_x >= kMaxPatchSize || - max_y - min_y >= kMaxPatchSize) { + max_y - min_y >= kMaxPatchSize || + (max_x - min_x) * (max_y - min_y) < 2) { continue; } ```

Yes, but I won't be able to do it right now, I'll be able to access my PC in about 10-12 hours (to compile changes and stuff), but sample images are above (with different results) if this is needed faster

I'm technically on vacation, so no hurry 😛

Then I will do it after I encode all the sets completely, also then there will be more examples of best and worst results or maybe someone else can compile and check these changes on the examples above

I guess that the best heuristic would be something like "if there's only x distinct colors, patches need to be at least y big, and they shouldn't create too many new colors"

or some simple estimate of bits of encoding a patch (~`k + h*log(image size)`) vs bits of encoding the pixels (~`size*log(distinct colors)`)

cjxl -m -s 9 -E 3 -I 1 ... zHEkAUH.png ``` 210 805 --patches 0 198 067 --patches 1 197 227 patched --patches 1 ``` q1bHrZ3.png ``` 16 522 --patches 0 21 869 --patches 1 18 595 patched --patches 1 ``` 4LF2tCj.png ``` 17 140 --patches 0 20 139 --patches 1 20 139 patched --patches 1 ```

mhhh so this mostly mitigates the problem but doesn't really solve it

good to know, but probably I should do the smarter thing

I might do this on Monday or so 🙂

🤔 So, yes, a more complex heuristic is needed to determine the benefit for paths, the encoding is still in progress, from what I've noticed, all the sets have been larger in size except the photographic type (they're the same)

yeah not many patches to find there 😛

That map of Threed is helped pretty significantly by `-g 3`. I know you aren't testing it (you're using `-s 9 -E 3 -I 1`), but the amount of savings impressed me, since `-g 3` usually doesn't work that well.

`167 455 cjxl -q 100 -s 9 -E 3 -I 1 -g 3 threed_map.png threed_map.jxl`

Yes, by individual settings for each image it is possible to significantly improve the efficiency and even this image we have already discussed https://discord.com/channels/794206087879852103/803645746661425173/812097373438214205 But, when encoding many images (thousands, millions, billions) it is impossible to choose individual settings for each image (except brute force, but it will extremely increase the encoding time, which is already slow)

Unless, as I once suggested, for example for -s 11 add an automatic selection for -g 3 where it will be better, perhaps there are some methods to identify it faster than brute force

that's likely lz77...

the bigger problem with -g 3 is that it reduces parellizability of decoding, but otherwise I do have a couple of ideas on how one could try to figure out if it would help (without doing full tree learning...)

Yes, that's why it should only be enabled for something like -s 11 (modes where for maximum compression the sacrifices are worth)

And perhaps some small images that fit entirely in the tile

I'd prefer to not tie *compression* speed to *decompression* speed

maybe I'll repurpose `--faster_decoding` for that and have `--faster_decoding=-1` do this kind of search

That's why you should make a hidden -s 12 that's only available if you compile with a specific option that does everything in the encoder's power to compress as much as possible no matter the cost during decoding <:kekw:808717074305122316>

Yes, but there are other cases where maximum compression is most important and it's good to have a choice for that

zstd generally has limited requirements for the decoder, unless you specify --long, which enables higher compression settings which need more decompression memory

this feels similar

<@179701849576833024> Does the 5 or 10 profile restrict the use of this?

I think I'll make a `--faster_decoding=-1` for automatic `-E 3`, `--faster_decoding=-2` to also try to find the best group size, and maybe let `-s 9` also try the equivalent of `-I 0` and pick the best

nope!

Maybe it should?

I don't think our encoder today does anything that is not covered in L5

ah, perhaps some higher bit depths

well, browsers won't be very likely to decode images in parallel I believe, so not sure the restriction should be there

Yes, it might be worth doing this with an extra setting than `-s`, so that people don't select it without much knowledge of what they're doing

q: should `-s 9` default to `-I 1`?

why do you prefer an extra `-s` setting rather than using a flag that is there explicitly to control decoding speed? 🙂

I have not tested how much slower `-I 1` is for encoding and decoding But, usually the effectiveness of `-I 1` is not that big (if there is any)

decoding: shouldn't change

encoding: probably 2x

(I could also make a `--speed glacier` / `-s 10` ...)

<@!794205442175402004> thoughts?

Glacier is a terrible reference for speed. The fastest is way faster than some slugs, and the slowests are arbitrarily close to 0 speed.

I think this kind of setting would be good, my thoughts are that `-s` option is optimal enough to be used by everyone, but it is nice to have additional settings for better compression or vice versa - faster decompression speed

And that it was not like in some articles, when people use `-s 9` for VarDCT and conclude that JXL is very slow and not very efficient

any proposals of an animal that doesn't have negative connotations? 😛

I'm half joking of course. The only concern about having something that spans an entire range from n>0 speed and 0 speed, is that you later can't add anything that's even slower, unless it has negative speed ;)

Jon proposed tectonic_plate once 😛

Sloth (but it's not always about the movement speed)/Snail? The names should rather be memorable and well-known, than a more accurate match to the encoder speed Although, personally, I prefer just numbers, because I do not need to remember what names are used and they are not always obvious (except like for turtle = slow)

Slowest tortoise: 70000 μm/s Slowest slug: 23 μm/s Fastest glacier: 520 μm/s Amoeba speed: 0.5-3 μm/s

If you would have given me slug/glacier/amoeba, I don't think I'd even be able to order them in speed...

Fastest tectonic plate: 0.005 μm/s

slug does have some negative connotations though

I expected glacier and slug > amoeba and tectonic plate, but I wasn't sure about (glacier, slug) and (amoeba, tectonic_plate)

don't worry, we'd keep numbers too 😄

There is a sea slug that swims like a fish, so it's a lot faster.

Yep, but just names are less practical in general, for example more understandable for x264 like `-preset slow`/`-preset veryslow` etc. are not so slow nowadays when fast CPUs and much slower formats like AV1/VVC and encoders appeared (and such presets can only relate to each other but not in comparison with something outside encoder)

tardigrade = 200 μm/s

https://twitter.com/pwuille/status/1393022684221431812

Oops, my number for the slug is wrong by a factor 1000.

Also about single image decoding parallelization, does it work or planned in browsers? Since if it's not used, `-g 3` for web won't be slower to decode, but it would be nice to have a smarter use of resources, like using one thread per image if there are many, and multi-threading for one very large image

I like `snail`, it's somewhat less yucky than slug, it has a hard shell like a tortoise, and it's a simple animal that everyone knows is slow.

Makes sense to me. Could also do E 3 by default and disable it with faster decoding = 1, but that does make default decode speed possibly slower (though at default encode speed it probably doesn't use the extraprops). IIRC the effect on decode speed was not that dramatic though...

Art set with new build and patched patches `(JXL Patches)`: <https://docs.google.com/spreadsheets/d/1rZJFsAm65Da-z30-yrphjfTWptGltjML6QkhLqPDkvY/edit#gid=2120588660>

There are some interesting results 🤔

Were there any other changes in lossless modes besides patches in the latest builds?

https://i.redd.it/09ti861d66j41.png ```6 230 966 - patches 6 774 178 - old ```

It looks like this grain is better compressed by the patches

https://i.redd.it/4hkchu3ft7841.png ```3,623,432 - patches 3,095,190 - old ```

We'll have to make better heuristics to avoid such worst-case stuff, and use patches only when they actually help.

It's a powerful coding tool and we're just scratching the surface of understanding how best to use it.

https://i.redd.it/dgfpiwvmghh41.png ```10,385 - patches 12,552 - old ```

<:WhatThe:806133036059197491>

I wonder how patches help on that image

Yep, it's strange, patches for solid color areas/lines? <:Thonk:805904896879493180> Or maybe I need to compare the same build with `--patches=0`

<@179701849576833024> it would be fun to have a debug image that shows little rectangles around the patches, or something

Ah yes, could be we somehow improved something regardless of patches

Yes, this is the result of some other improvements, with `--patches=0` the size is the same in the new build (10,385)

<:Thonk:805904896879493180> ``` cjxl -m -s 9 -E 3 -I 1 ... 10 286 --patches 0 10 286 --patches 1 10 286 patched --patches 1 ```

On commit 30ea86ab (2021-05-12) [v0.3.7 | SIMD supported: AVX2,SSE4,Scalar]

Maybe because I'm encoding an already optimized PNG or maybe it's the compiler, different SIMD?

^ Optimized PNG

Gotta make it even smaller <a:DogeEvil:821038587176419381>

Yep, `10 385` on optimized PNG and `10 286` on unoptimized one <:NotLikeThis:805132742819053610>

We have that :P compress with benchmark_xl and use --debug_dir

It is weirdly enough compiler/platform dependent what exact encode result you get. Some heuristics use float arithmetic which has compiler/platform-dependent behavior. Of course the result is always a bitstream that losslessly represents the image, but it might be using a different MA tree, for example.

That is a bit weird, other than maybe a different color profile signaling, if the input pixels are the same then there shouldn't be a difference, afaik

might be that one has an ICC and the other one doesn't

Pingo optimizes to 8 bits per channel (this is most likely the reason for the different size), but it also creates equal conditions with lossless WebP

Not sure if this was worth a 10 minutes wait, but have a PNG of 🍋 that's slightly better optimized I guess ~~yes, I'm this bored~~

2**6,66**8 bytes now <a:ElmoHELL:593434575146057728>

~~only 304 bytes smaller <:kekw:808717074305122316>~~

not that I recall making any change to lossless recently 😛

🤔

Maybe the better choice between prefix and ANS helps here?

ah, maybe, but shouldn't help *this* much...

(the thing you did to trim off some bytes for jxl art 😂 )

Well that image does have some very low entropy groups, but yes shouldn't help that much

<@!111445179587624960> since you've made this huge comparison, could you perhaps send me a corpus of a few images that you know behave surprisingly (in some way) in jxl? 😄

I want to play with improving our heuristics and it would be useful to have such testcases

say: - bad cases for patch detection - cases where lz77-based codecs (or `-s 9 -I 0`) do better than JXL - cases where `-g 3` or `-g 0` do a lot better than defaults - cases where using palettes has surprising results ( <@!794205442175402004> for the flags for checking that) - other things that just seem weird 🙂

Yep, `-g 0`/`-g 3` for best compression settings? But first I need to finish the current encoding, which will take some time

I don't plan to do anything about this until *at least* Monday, likely more anyway 😛

(I didn't understand the `-g 0`/`-g 3` question)

Like for `-s 9 -E 3 -I 1` or just for default settings/speed

ah, yes

no need to try it for *all* images of course, just a few examples where each option does better would be good 🙂

it's hard to find outliers unless you look at results of all image encodes and compare them, no?

not necessarily, you can also run a script 'til it finds something significantly smaller than the results you already have, say

well yeah, but you won't know if there's something even more significantly smaller

(yes this is pointless)

I just need examples, not complete information 😛

It's strange, but the new build is worse than the older one (on which I did the last comparison): <https://docs.google.com/spreadsheets/d/1rZJFsAm65Da-z30-yrphjfTWptGltjML6QkhLqPDkvY/edit#gid=2120588660>

JXL Patches (new build with a patch for patches) `-s 9 -E 3 -I 1` JXL Patch 0 (same, but with --patches=0) `-s 9 -E 3 -I 1 --patches=0` JXL (s9 E3 I1) (old build) `-s 9 -E 3 -I 1`

... weird

any idea why?

or a few example files

there might have been regressions, I guess

Also strange that I tested several recent builds (but I do not remember which ones) and the result did not change, it happened on some of the most recent

I wouldn't be sure why...

https://i.redd.it/j6dypx3jha841.png ```5,635,876 - JXL Patches 4,959,727 - JXL (s9 E3 I1) ```

one random guess is that we might preserve more metadata now (i.e. exif) but that seems too big of a difference for that

what does it do with --patches=0?

5,635,876 - same

not *too* surprising

if you have both builds around - can you run cjxl with `--print-details`?

`Unknown argument: --print-details`

sorry, --print_details

I think

nah

it's just -v

Apart from the version and SIMD there is nothing there

could you create a drive folder / email / whatever with these weird files and send it to me by DM (or even better email), so that I won't forget to look into it when I have time? 🙂

ok, let me figure out how to trigger that

`[v0.3.7 | SIMD supported: AVX2]`

``` luca@desktop ~ $ ./jpeg-xlm/build/tools/cjxl /data/jpeg_xl_data/jyrki31/stp.png -m -v J P E G \/ | /\ |_ e n c o d e r [v0.3.7 | SIMD supported: AVX2,SSE4,Scalar] ../lib/extras/codec_png.cc:505: PNG: no color_space/icc_pathname given, assuming sRGB No output file specified. Encoding will be performed, but the result will be discarded. Read 1024x683 image, 41.8 MP/s Encoding [Modular, lossless, squirrel], 32 threads. Compressed to 625248 bytes (7.152 bpp). 1024 x 683, 0.70 MP/s [0.70, 0.70], 1 reps, 32 threads. Average butteraugli iters: 0.00 Total layer bits headers 0.001499% 75 Total layer bits TOC 0.006658% 333 Total layer bits quant tables 0.000020% 1 Total layer bits modularGlobal 0.404769% 20246 [c/i:107.00 | hst: 2486 | ex: 0 | h+c+e: 618886.455] Total layer bits modularAcGroup 99.392926% 4971499 Total layer bits modularTree 0.194128% 9710 [c/i: 4.00 | hst: 39 | ex: 109 | h+c+e: 1205.837] Total image size 5001864 [c/i:111.00 | hst: 2526 | ex: 7121 | h+c+e: 627103.792] Allocations: 429 (max bytes in use: 3.662562E+07) ```

Yes, but I was going to finish at least one more set first (maybe there will be a different result)

For this image?

```cjxl.exe "j6dypx3jha841.png" "j6dypx3jha841.png.ls9.jxl" -q 100 --num_threads 8 -v J P E G \/ | /\ |_ e n c o d e r [v0.3.7 | SIMD supported: AVX2] Read 2097x4781 image, 40.8 MP/s Encoding [Modular, lossless, squirrel], 8 threads. Compressed to 6078780 bytes (4.851 bpp). 2097 x 4781, 0.83 MP/s [0.83, 0.83], 1 reps, 8 threads. Average butteraugli iters: 0.00 Total layer bits headers 0.000185% 90 Total layer bits TOC 0.007973% 3877 Total layer bits quant tables 0.000002% 1 Total layer bits modularGlobal 0.196613% 95612 [c/i:128.00 | hst: 11946 | ex: 0 | h+c+e: 4707763.904] Total layer bits modularAcGroup 99.559425% 48415207 Total layer bits modularTree 0.235802% 114669 [c/i: 4.00 | hst: 54 | ex: 2438 | h+c+e: 13983.063] Total image size 48629456 [c/i:132.00 | hst: 12001 | ex: 1316104 | h+c+e: 6035412.717] Allocations: 1428 (max bytes in use: 4.588365E+08)```

that's on the new or on the old build?

New

ah, also I meant with the same other flags

so -s 9 -E 3 -I 1

could you also do it on the old? 🙂

Ok, but I don't remember which was the old build, I'll try some

And it's a big image, so it's going to take a while at these settings

thanks!

Hmm, I tried all the builds from 0.2 and higher and the result was the same, maybe it was some even older version, I think I'll update all the other sets with the new version and see the results

Aw set <https://docs.google.com/spreadsheets/d/1rZJFsAm65Da-z30-yrphjfTWptGltjML6QkhLqPDkvY/edit#gid=1734182694>

The difference is very small

Manga set <https://docs.google.com/spreadsheets/d/1rZJFsAm65Da-z30-yrphjfTWptGltjML6QkhLqPDkvY/edit#gid=1181869618>

Some interesting examples https://i.redd.it/xptmu1db53o31.png

```41,741 - JXL (patches 0) new build 50,175 - JXL (defaults) new build```

- https://i.redd.it/95syrffycdj51.png

```436,377 - JXL (patches 0) new build 429,883 - JXL (defaults) new build```

But in general the result does not change much on this set

PixelArt set <https://docs.google.com/spreadsheets/d/1rZJFsAm65Da-z30-yrphjfTWptGltjML6QkhLqPDkvY/edit#gid=0>

- https://i.redd.it/myvhtme8abi41.png ```9,819 - JXL (patches 0) new build 8,774 - JXL (defaults) new build```

- https://i.redd.it/jm2ri825s9851.png ```5,541 - JXL (patches 0) new build 5,374 - JXL (defaults) new build```

But it seems that on very small images or where there are few colors, patches are ineffective https://i.redd.it/qu0dqaxauoh41.png ```4,204 - JXL (patches 0) new build 5,987 - JXL (defaults) new build```

- https://i.redd.it/b0meqib48zf61.png ```249 - JXL (patches 0) new build 353 - JXL (defaults) new build```

- https://i.redd.it/v0o3h0uc1j961.png ```9,631 - JXL (patches 0) new build 11,895 - JXL (defaults) new build```

- https://i.redd.it/uo9u57i7opj41.png ```28,726 - JXL (patches 0) new build 36,885 - JXL (defaults) new build```

tuning for pixel art could be improved, I'm pretty sure one of the devs said that on small images a lot more tuning could be done

Some -gX examples (-s 9 -E 3 -I 1): https://i.redd.it/815jlxknl5o51.png ```352,540 -g 0 385,640 -g 3 371,122 -g 1-2 (defaults) ```

- https://i.redd.it/1xbcfb7b49h51.png ```212,026 -g 0 153,379 -g 3 205,573 -g 1-2 (defaults) ```

- Interesting that both `-g 0` and `-g 3` are better than the defaults https://i.redd.it/xptmu1db53o31.png ```46,794 -g 0 41,856 -g 3 50,175 -g 1-2 (defaults) ```

- https://i.redd.it/5yqvn7szhhy51.png ```1,510,864 -g 0 1,360,890 -g 3 1,565,266 -g 1-2 (defaults) ```

So for something like black and white images, the smallest and largest group sizes are better?

- https://i.redd.it/o0ilan3v7fy51.png ```283,415 -g 0 391,175 -g 3 277,937 -g 1-2 (defaults) ```

<:Thonk:805904896879493180> Hmm, although this is not always the case, perhaps it also depends on the image complexity in the tiles

Thanks for finding these examples!

Figuring out a good heuristic for -g will be tricky, there are several things that interplay there...

I think for patches my heuristic on "some formula on #pixels and #colors" should work

I guess if the patch is duplicated only within the same group, using lz77 matches will probably end up being cheaper to signal (unless it's a very tall patch, small width and big height is not good for lz77)

So maybe could also give a heuristic weight boost to patches that have copies in multiple groups, or something, and based on aspect ratio (a 100x2 patch is probably better done with lz77 while a 2x100 patch is not good for lz77)

mhhh, that might be useful, but I think we have bigger problems

like we shouldn't create patches at all for 1x1 pixels in a black-white image, that's just silly

Yes, probably not for 2x2 pixels either

- https://i.redd.it/6obx988is5h61.png ```13,000 -g 0 2,246 -g 3 4,930 -g 1-2 (defaults) ```

For this kind of content there is a big difference for `-g 3`

yeah, that image is very lz77 friendly

big groups help there, a lot

https://i.redd.it/eftrizs1uf941.png ```495,654 -g 0 296,654 -g 3 452,338 -g 1-2 (defaults) ```

- For pixel art or tile patterns -g 3 helps, but not always https://i.redd.it/49ox0pmrf6c61.png ``` 97,839 -g 0 105,746 -g 3 66,357 -g 1-2 (defaults) ```

- It seems to be worse for very complex images or with large color areas https://i.redd.it/d2emovbjx5861.png ```188,634 -g 0 312,502 -g 3 196,182 -g 1-2 (defaults) ```

- -g 0 ```165,025 -g 0 225,345 -g 3 216,175 -g 1-2 (defaults) ```

- https://i.redd.it/0dw3cmjdh9b61.png ```110,633 -g 0 129,171 -g 3 127,735 -g 1-2 (defaults) ```

Small groups make local palette more effective, big groups make prediction and lz77 more effective

https://i.redd.it/ps0qma6rixf41.png ```590,982 - JXL (patches 0) new build 638,522 - JXL (defaults) new build```

- https://i.redd.it/xmtoihicvlj41.png ```68,569 - JXL (patches 0) new build 73,291 - JXL (defaults) new build```

38 kilobytes is a large delta

I'm talking about the wave image

Do you think detecting dithering would help

maybe not dithering specifically

but small patches on low-color images, definitely yes

<https://i.redd.it/9s13kkm53mc41.png> ``` 874,098 - JXL (palette=0) 1,148,710 - JXL (defaults)```

- https://i.redd.it/c4o4edl7zli41.png ```533,895 - JXL (palette=0) 645,720 - JXL (defaults)```

- https://i.redd.it/mcjesaqusa141.png ```1,293,982 - JXL (palette=0) 1,540,206 - JXL (defaults)```

- https://i.redd.it/msakckaxtyt41.png ```3,750,292 - JXL (palette=0) 4,385,213 - JXL (defaults)```

- Manga set with added `palette=0` and other options, I have not yet selected images that highly differ in size with some options, first I want to finish encoding other sets, but if such examples are needed, it will be easier to copy the spreadsheet and sort the efficiency in percentages by the desired options <https://docs.google.com/spreadsheets/d/1rZJFsAm65Da-z30-yrphjfTWptGltjML6QkhLqPDkvY/edit#gid=1181869618> - All image sets from this comparison (if it's more convenient or some have a broken link) <https://drive.google.com/drive/u/1/folders/1X_F_vhNwJFhPWSW3EeSa-gGhhikkOoYd> -

Btw, `palette=0` for the Manga set is more efficient in general (except `-g 3`), so the palette needs some tuning

those palette=0 numbers are kinda odd xD

I think it's because Manga are mostly black and white images

For example for something like this, it's not good: https://i.redd.it/815jlxknl5o51.png ```731,619 - JXL (palette=0) 371,122 - JXL (defaults)```

sure, but we do have heuristics for palette for 1c...

they might not be good though 🙂

Maybe because it's not pure black and white, it's usually some kind of shade

https://i.redd.it/dghx5h93l8k41.png ```316,862 - EMMA 433,042 - WebP 426,770 - JXL (palette=0) 414,566 - JXL (-g 0) 408,716 - JXL (-g 3) 447,090 - JXL (defaults)```

<@!111445179587624960> would you be able to collect all the images you sent here in a drive folder / zipfile and send them by email/dm/whatever? (even better if you can divide them by what is the weird thing, or add the text that you sent here with them :D)

Yes, but I will finish at least one more set because encoding at these settings is very slow and I will not add `--palette 0` for other sets (because it is mainly useful for black and white images), btw, I think that `--palette 0` consumes more memory <:Thonk:805904896879493180> , although I have not done a comparison, but overall RAM consumption has increased for the same set

Later I will make a spreadsheet only with strange images and upload them to gdrive, it will be difficult to describe or separate them, because one image can fit into several categories at once and it will be easier to see what the problem is in the spreadsheet

that's great already 🙂

Hmm, for some big images with `--palette 0` I didn't even have enough RAM to encode them, yes, several images in parallel, but still, with other settings everything encoded fine So can `--palette 0` consume significantly more RAM in certain cases?

Some examples:

I don't think --palette 0 is needed for these images, but still

Strange that it uses more memory, I would expect less

probably not creating a palette ends up with more pixels in total

Also interesting example https://i.imgur.com/qAiPdtp.png ```668,269 - JXL (palette=0) 850,291 - JXL (patches 0) 915,479 - JXL (-g 0) 672,755 - JXL (-g 3) 849,578 - JXL (defaults)```

Not a black and white image, unless there are not many colors

- https://i.imgur.com/j84wOJe.png ```175,771 - JXL (palette=0) 218,843 - JXL (patches 0) 243,080 - JXL (-g 0) 171,226 - JXL (-g 3) 220,018 - JXL (defaults)```

So the palette needs tuning, because on certain images `palette=0` or `-g 3` gives a significant difference

<@!179701849576833024><@!794205442175402004>**Tuning Corpus** <https://docs.google.com/spreadsheets/d/1Ne3sFznHIMAUn-QQJR9UnQDRwKNarcvuFxeAvQDSHw8/edit#gid=2120588660> **Tuning Corpus Images** <https://drive.google.com/drive/folders/14zu7SUT1CYGvsCbqnrfDejWNcfQO6gwB>

The selected sets look like this, the rest are not ready yet

I picked the biggest difference in some options or WebP and if BMF or EMMA is 40% better (since it is most likely that such images can also compress better) The biggest and most problematic set is still Pixel Art, WebP and BMF are kings there

thanks a lot! I don't know *exactly* when I'll be able to look at tweaking the encoder for this (the *decoder* still needs quite a bit of love :D) but those will be very useful 🙂

<https://i.redd.it/p2x28aq8uxc41.png> ```2,175,032 - JXL (Palette 0) 2,091,901 - JXL (Palette 10000) 2,085,348 - JXL (-X 0 -Y 0) 2,085,348 - JXL (s9 E3 I1) 2,085,371 - JXL (Patch 0) 2,070,774 - JXL (-g 0) 2,287,156 - JXL (-g 3) 1,741,899 - FLIF 1,484,366 - EMMA ``` I'm doing another corpus with different options on images where JXL was worse than other formats, is there anything else I can try for this image for better results?

Or just one more option that will be useful in the overall comparison and the result can be very different? So far, I've noticed that the biggest difference is more often with `g 3` and `palette 0`

`2153287 crop.png 2177387 crop-s3-modular.jxl 1757006 crop-s4-modular.jxl 1304737 crop-s6-d1.jxl 1387412 crop.zpng`

zpng compress very fast and has better compression than modular s3 , s4.

1312x30297 image dimensions.

For non-photographic images that doesn't surprise me

For photographic, `4.5 MB ref-m.jxl 6.0 MB ref.png 1.3 MB ref.zpng`

That is a nice result for zpng

Faster to encode too

What is zpng? Png with zstd?

Yes

Could you share that image?

Maybe try -s 3 -g 3 ?

Is it lossless?

I mean -m -s 3 -g 3

No change in file size

Should be at least some small change in file size

The image is the flower photo which I shared in photography channel

That's a jpeg?

It's a PNG

plu.jpg is a png?

May be discord changed it

I will share the png

May the zpng does lossy compression?

That sounds weird to me, but maybe?

What tool do you use to encode it?

I got encoder exe from their GitHub. And used wine to run it on Linux

https://github.com/catid/Zpng/blob/master/ZpngApp.exe?raw=true

I opened both reference PNG and zpng decoded PNG on gimp and set layer mode to difference. I don't see any difference.

use dssim

Do compare -metric pae orig.png decoded.png null:

Pae - 242

Not lossless then

Maybe converts 16-bit to 8-bit?

But on viewing on imageviewer, comparing both pixel by pixel, no change in color and there are no artifacts

Yes on an 8-bit display you wouldn't have any difference

I didn't realize I was using a 16bit PNG as input. I am stupid. 😆

``` $ stat -c "%s %n" ref* 521695 ref8bit.png 367726 ref8bit.png.jxl-m-s3 344042 ref8bit.png.jxl-m-s9 363371 ref8bit.png.jxl-m-s9-E3-g0-I1 339557 ref8bit.png.jxl-m-s9-E3-g1-I1 354125 ref8bit.png.jxl-m-s9-E3-g3-I1 1738349 ref.jxl 2280161 ref.png 521034 ref.zpng ```

zstd-png doesn't help much compared to regular gzip-png, on this image

Yeah

for stuff that is good with PNG, you should try `-s 9 -I 0 -g 3 -P 0` 🙂

(I promise I'll make a speed setting that tries that at some point...)

What about this file then? Even `-s 9 -g 3 -E 3 -I 1` JXL can't go below original PNG size...

did you try -I 0 and different values of -P ?

`-I 0` increased filesize from 383 to 811 bytes

mhhh, let's see what's going on here

Just bruteforced through all `-P` values both on `-I 1` and `-I 0` while keeping `-m -s 9 -g 3 -E 3` constant, never went lower than 383 bytes.

Also, I tried `-s 9 -I 0 -g 3 -P n` on images where WebP was better and the result was still worse than WebP or some other JXL option, perhaps JXL has a less efficient LZ77 implementation right now?

one thing webp does that jxl doesn't is change predictors with lz77

but in this specific case, by looking at the tree, I'd say this is a bad tree learning case

This file is from Wikipedia, btw

Perhaps sometimes the limited group size also affects, btw, would adding a size higher than 1024x1024 not add more efficiency or would it be difficult for the JXL structure, more designed to work with tiles rather than one solid image?

`-m -s 9 -I 1 -v --palette 0 -X 0 -Y 0`

palette and channel palette heuristics are too simplistic

-E 3 trims two more bytes, 130 bytes

a hand-written tree could probably bring it down further

Yes, `--palette 0` was often noticeably better in my tests, mostly `-g 3` or/and `--palette 0` gives significantly different results on problematic images, all other options are not that noticeable

basically currently the heuristic is just "if the image (or group) has less than 1024 different colors, make a palette and encode it like that"

that is certainly not always a good idea

sometimes palettes with more colors are effective, sometimes even a palette with just 100 colors is less effective than encoding the channels separately

it's just quite hard to estimate in advance when it will work well and when not

maybe we should just try both with and without palette and make a -s 10 that is twice as slow

or 4 times as slow, since this would have to be done both globally and locally

Yep, sometimes --palette 10000 https://i.redd.it/lmbvey8yymj41.png ```43,631 - Palette 10k 49,780 - Palette 0 48,923 - JXL (s9 E3 I1) 48,382 - JXL (-g 0) 55,370 - JXL (-g 3) ```

10k is just the upper bound, it could be a 1025-color palette 🙂

we can do better than that, we just need to find a good proxy for "how many bits will this take", no need to do full tree learning 😛

Big difference for `-g 3` https://i.redd.it/i6e4lbla4pv21.png ```576,412 - WebP 734,087 - Palette 0 769,994 - JXL (s9 E3 I1) 793,921 - JXL (-g 0) 528,436 - JXL (-g 3) ```

anime'ing

(du is bad for small sizes)

also jpeg's levels don't quite match up. for small images jxl makes them much smaller at equivalent jpeg levels

which is kinda expected but also these purple color shift on ribbon things make me think that its pushing a bit too far

I suspect the blue differences are not visible without a lot of zooming

when i make file sizes basically the same, it looks pretty much perfect, so it's not worse than jpeg

anyway ill stop playing with it ive been nerd sniped

no more

curiously, with modular color shift happens near border, while with vardct it's more like random drops

Interesting, but maybe not very practical example (since fractals are quite a narrow theme) https://i.redd.it/04gch7ezbdc41.png ```7,774,068 - WebP 8,513,022 - JXL (s9 E3 I1) 8,046,059 - JXL (-g 3) ```

Looks quite repetitive, that's where groups hurt (theoretically patches could help, but good luck detecting those in an image like this)