JPEG XL

Logically shouldn't cjxl be able to at least recognize that the two halves of this image are the same but mirrored?

In both ways

Can you do translation with patches?

Logically you could reduce this to 2M if patches could translate

Patches cannot flip, no

Hm

Could make thin patches for every column on the left and copy them to corresponding columns on the right, I guess

https://i.redd.it/9l003u3ltkq31.png ``` 471,000 - WebP 1,569,575 - PNG 2,093,942 - JXL (s9 E3 I1) 1,431,469 - JXL (-g 3) ```

gee

I mean, I get why

but...

I'll add something to my list for large, not text-like patches 😛

Also about patches https://i.imgur.com/H98sH.png ``` 8,404 - WebP 6,999 - PNG 1,954 - FLIF 20,447 - JXL (s9 E3 I1) 14,608 - JXL (patches 0) 20,285 - JXL (-g 3) ```

I guess this also counts as tree learning not doing a great job here...

although: `./tools/cjxl H98sH.png -g 3 -I 0 -s 9 -P 9 -m --patches=0` Compressed to 14197 bytes (0.109 bpp).

(has the advantage of being fast to decompress)

I mean, it should be possible to do better

How large is the image?

1023x1023

Then the FLIF size should be achievable

Or better

In a single group, for grayscale, there is literally nothing FLIF can do that jxl cannot do at least as well, I think

But it can happen that FLIF's tree learning finds a better tree than cjxl's

yeah, the tree learning in FLIF has very very little in common with the one in cjxl

It is almost completely different

mostly they both learn trees, but that's it xD

Well they are both greedy, one split at a time

So that kind of suboptimality they have in common

true

But other than that, very different methods

well, good to know we can do better 😛

Yes, I think a PhD or two could be written just on better MA tree learning

Let alone the interactions with lz77 and with modular transforms

However https://i.redd.it/nikixial60s21.png ``` 1,166 - WebP 805 - FLIF 184 - JXL (s9 E3 I1) 148 - BMF ```

That one could probably also be done in 40 bytes or so

I showed this example before, but https://i.imgur.com/UL1fXgB.png ``` 14,410 - WebP 77,610 - FLIF 44,165 - JXL (s9 E3 I1) 54,605 - JXL (patches 0) 36,721 - JXL (X0 Y0) 27,319 - JXL (g 3) 12,940 - BMF```

Here the group limit comes at a cost compared to non-tiled codecs

can you try -g 3 -I 0 -s 9 -P 0 --patches 0?

Would `-E 3` help, too?

I'd assume this would get palette'd

Not on grayscale images or other effectively 1 channel images

ah, but I think this has subpixel rendering

```28 665 (-g 3 -I 0 -s 9 -P 0) 33 154 (-g 3 -I 0 -s 9 -P 0 --patches 0)```

I hate subpixel rendering with a passion

not too bad... other values of P might be interesting too 😄 (up to 13 IIRC)

fair enough 😛

``` $ ./cjxl UL1fXgB.png t.jxl -m -g 3 -I 0 -s 9 -P 0 --patches 0 J P E G \/ | /\ |_ e n c o d e r [v0.3.7 | SIMD supported: Neon] ../lib/extras/codec_png.cc:505: PNG: no color_space/icc_pathname given, assuming sRGB Read 1167x865 image, 23.2 MP/s Encoding [Modular, lossless, tortoise], 8 threads. Compressed to 33164 bytes (0.263 bpp). 1167 x 865, 0.03 MP/s [0.03, 0.03], 1 reps, 8 threads. ```

I get a weirdly different result

Fortunately at least it's a text console, the font is monospace and aligned so the letters are pixel-exact matches

Patches actually help a bit

But probably most of them are not detected here

yup, but -I 0 decodes a lot faster so...

A bit? The whole thing can be encoded with patches!

Yes, here are the final results https://discord.com/channels/794206087879852103/803645746661425173/845639153549836359

I don't think patch detection works so well with subpixel rendering

but lz77 also does a good job 😛

Are there any universal options for the lz77 that I could add to the comparison without knowing the image type (to see where the lz77 might be better)? Like `-P 15` (15=mix everything) works with -i 0?

Looks like A,B,C,D are not detected as patches, and the rest somewhat is

So the biggest opportunities for patches are actually missed

Likely because there is no solid background nearby those

it doesn't

I'll try to get something like that working, but probably not earlier than in a month

what's that? background?

Ok, I need to finish encoding the other options anyway, since it takes a very long time

It's the result of djxl -s 8

Looks kind of bad because there is no DC :)

Something modular global still happens

Causing the bg not to be black, maybe palette or channel palette, I dunno

Something difficult even for FLIF and JXL does better, but according to BMF, there is still compression potential for this image https://files.catbox.moe/a480l8.png ```307,485 - FLIF 216,228 - JXL (s9 E3 I1) 215,824 - JXL (patches 0) 209,918 - JXL (X0 Y0) 211,211 - JXL (g 3) 148,940 - BMF```

https://i.redd.it/016nuealcl341.png ```6,198,924 - FLIF 7,843,213 - JXL (s9 E3 I1) 6,210,965 - JXL (palette 0) 7,666,728 - JXL (g 3) 5,756,530 - EMMA```

- https://i.redd.it/5qmh3c3fben01.png ```11,704,800 - FLIF 12,891,658 - JXL (s9 E3 I1) 10,949,990 - JXL (palette 0) 11,952,531 - JXL (g 3) 9,048,551 - EMMA```

- https://i.redd.it/59rr49wh1qo31.png ```2,014,202 - FLIF 2,248,884 - JXL (s9 E3 I1) 1,944,748 - JXL (palette 0) 1,928,298 - JXL (g 3) 1,798,641 - EMMA```

I would be pretty surprised if jxl could do consistently better than EMMA

pleasantly surprised, but surprised nonetheless xD

What does EMMA do?

I think it would be quite difficult, at least without the kind of storage mode where the decompression speed would not be important

Some discussion was here: <https://encode.su/threads/3589-GDCC-port-mortem?p=69000&viewfull=1#post69000>

`stat -c "%s %n" *.jxl 39255 test-dct.jxl 32350 test-modular.jxl` Is this normal for non-photographic content?

So Emma good for compressing for raw dngs.

not entirely surprising at least

Okay

For many things, except Pixel Art

And this experimental non-optimized for speed encoder is faster than lossless JXL with default settings (effort/speed 7), but the drawback is that the decoding speed is the same as the encoding speed

From where can I get emma?

The one from Google drive? https://drive.google.com/drive/u/0/mobile/folders/0B_X1BeQ2TuWibTBmVG90S0k1bVE?usp=drive_open

https://globalcompetition.compression.ru/assets/files/compressors/EMMA.7z

I think this is another EMMA, a more complex encoder that is no longer developing

And EMMA only accepts PPM files, for example I convert images with ImageMagick: `convert Image.png Image.ppm`

In my opinion, For current version avif lossless implement(libaom) can't compare other lossless encoder, ```--cicp 2/2/0, pack the RGB values directly into the planes (in the order GBR)```

Yes, but I had to compare it as well (because so far many people think AVIF is also very good in lossless), although lossless improvements are planned for AVIF

If jpeg xl have high fidelity lossy for any type image(photographic and non-photographic), And have better lossless mode(modular lossless and jpeg lossless), maybe we can defeat avif on this github discuss. https://github.com/mozilla/standards-positions/issues/522

The binary size is just 37kb. Is it okay?? I tired to run it with wine but it doesn't.

Also not working in windows 10

Yes, it's ok, because this competition takes into account the size of encoders/decoders, but this EXE should work, something like this: `emma_c.exe Image.ppm Image.emma`

what happened between speed 3 and 7 lol

some optimization that we NEED for pixel art isn't applied at some level between 7 and 3

3 doesn't even try to do anything but photographic-only 😛

ah

Yes, I've done experiments with fast modes <https://docs.google.com/spreadsheets/d/1ugFqODnDnyeHbww9g4kKsqk--VKvosMQ2YYd1YN5KLA/edit#gid=1077758646>

Possibly something like -s 3 -P 4 might work a bit better for pixel art

https://i.redd.it/6wcb3n2w2uc31.png ```18,842 - FLIF 23,670 - JXL (s9 E3 I1) 23,539 - JXL (palette 0) 23,419 - JXL (g 3) 17,240 - BMF```

- https://i.redd.it/ixnqw29s2li31.png ```84,049 - FLIF 45,657 - JXL (s9 E3 I1) 42,988 - JXL (patch 0) 47,176 - JXL (g 3) 25,796 - BMF```

FLIF big fail in this

Lossless is a funny game

Big fail is a relative thing. FLIF compresses it losslessly at 0.25 bpp...

A lossy jpeg could easily be ten times as large

But yes, jxl does even better, and bmf even better than that

It's amazing how much structure some images have, so they can be losslessly compressed to a bitrate that would be very poor lossy quality

See <#824000991891554375> for some examples.

Haha yes. Finding the hidden structure in an image is tricky though.. probably if you try compressing those jxl art images with cjxl, it will be quite a bit bigger

0.000 bpp asymptotically is hard to beat

Hmm, didn't find options when JXL was close to WebP https://i.redd.it/kepfxbji1ru31.png ```346,632 - WebP 429,355 - JXL (s9 E3 I1) 421,094 - JXL (palette 0) 417,652 - JXL (g 3) 328,192 - EMMA```

not even `-s 9 -I 0 -P 0 -g 3` and/or `-s 9 -I 0 -P 4 -g 3`?

What do you think the issue with this one was?

Yes, also combinations with `-I 0` almost never give better results than some other options I have even tried bruteforcing `-P`, like `-P 0-13`

curious

might be a case of bad tree learning

`--palette 10000000` helps somewhat (~1.5%)

Yep, some options are better, but not by much

I wonder what webp does

anyway, I'll be playing with lossless in a couple months I think

<@!532010383041363969> should know a thing about that...

from what I understand, most of the things that webp does should also be possible in jpeg xl, and at similar speeds

it's just a question of implementing appropriate special paths xD

well, more or less, webp-ll is hard-coded for 4 channels, jxl is not, and that changes a thing or two

Also, i made another spreadsheet for tuning when some of the other formats are noticeably better, but have not yet uploaded the images from this set and some other little things

no hurry

very likely I won't have any amount of time until the chrome 93 branch cut

It's good that often the compression is improved with `palette` or `-g 0/3` options, but sometimes this doesn't help either

Unless, for some Pixel Art, `-I 0` can be better (but still worse than WebP) https://files.catbox.moe/5jx4oh.png ``` 95,490 - WebP 123,090 - JXL (s9 E3 I1) 121,016 - JXL (palette 10000) 125,828 - JXL (g 3) 113,156 - JXL (s9 E3 I0 P0 g3) 71,884 - BMF```

What magic is BMF doing?

and back in 1999 too o.O

I think nobody know, but it's a context mixing based model, right?

anyway IIRC it's a lot slower than JXL at decoding

I *believe* that it ought to be possible to basically copy the webp encoder in JXL, but I'm not absolutely sure 😄

EMMA yes, but BMF as far as I know uses several different models with good hand tuning for many years

did you perhaps measure decompression performance?

No, but on slow mode it's only slightly faster than encoding

how fast is encoding then? 😛

But on normal modes, the decoding speed is quite sufficient for practical use, I no longer have my own tests, but there are, for example GDC: https://globalcompetition.compression.ru/#leaderboards

But this is purely photo content, EMMA does not work well on Pixel Art (unlike BMF)

I see that the jxl encoder is a tad slow xD

anyway, about 10x slower than jxl is very slow

For decoding, yes, except for the Balanced test, where BMF is fast in both encoding and decoding while still having good efficiency for these speeds (this test only has photographic images, but it is also good on other types)

yup, indeed

For example PIK is also very good, but on other sets it performs worse than BMF

btw pik-lossless should be neither faster nor denser than JXL, we'll have to fix that at some point...

Same for Gralic (It has been well tuned for LPCB, but on other sets it is worse than BMF and some other encoders) http://qlic.altervista.org/LPCB.html

yeah, all the insanely high compression formats tend to have very slow decompression

`-I 0` helps, but WebP still better https://files.catbox.moe/dn0i9a.png ```465,218 - WebP 827,465 - JXL (s9 E3 I1) 827,483 - JXL (patch 0) 733,108 - JXL (X0 Y0) 592,772 - JXL (g 3) 515,937 - JXL (s9 I0 P0 g3)```

Slightly better than WebP, but BMF has a decent gap https://i.redd.it/fabub8fetx441.png ```35,330 - WebP 45,319 - JXL (s9 E3 I1) 45,224 - JXL (patch 0) 34,342 - JXL (s9 I0 P0 g3) 26,900 - BMF```

- This image has been posted before, but still an interesting result https://files.catbox.moe/kkug21.png ``` 53,674 - WebP 111,086 - JXL (s9 E3 I1) 109,413 - JXL (patch 0) 97,091 - JXL (palette 10000) 106,322 - JXL (s9 I0 P0 g3) 37,852 - BMF```

yup, very interesting

png to jxl. Non synthetic image. `Q 97 s 9 - 411kb Q 97 s 7 - 275kb`

amazing!

tree learning must be doing something very wrong here 😛

Same image `d 1 - s 7 - 128kb d 1 - s 9 - 126kb`

ah wait, that's lossy, nvm

I don't remember what q97 maps to - but I'm not surprised that very very high qualities do weird stuff at -s 8 or -s 9

don't use -s 8 and -s 9 for VarDCT lossy if you're not prepared to have very weird results 😄

jxl modular tortoise - 1.64 mb squirrel - 1.68mb emma - 1.56mb

jxl s9 took more time than emma 😞

To decode?

Encode

Ah

Yes, tortoise encode is kind of "not even trying to optimize"

Faster modular encode should be possible for s4+, but it's not trivial

Also better densities should be possible, but also not trivial

It's not really a priority atm to work on better lossless encoding, there are more urgent things to do right now (faster/lower memory decoding, improving browser integrations, decoder conformance, fuzzing, subjective evals, improving lossy encoding)

And as already discussed, it would be nice to have a fast speed with relatively universal compression for photos, artificial content and pixel art, like something with a fixed tree/predictors that would be suitable for this

Yes, when I get the time I will make an s2 modular that is faster than s3, and an s4 that is faster and better than current s4

anime preset 😜

use neural net to divine the most suitable preset tbh

eh, we can do faster than a NN I believe 😛

So `thunder` is something like this? https://discord.com/channels/794206087879852103/803645746661425173/813732246804234260

-s 2 *might* be a bit better than -s 3 for nonphoto

I dunno though

Hmm, I guess I'll do the tests then

It might be better for nonphoto than -s 3, yes

I was thinking for -e 4 to maybe do just both -e 2 and -e 3 encodes of each group, and take the best one. WDYT, <@179701849576833024> ?

That should be faster than twice as slow as -e 3, which is a lot faster than current -e 4

And likely better

why not - but we should probably avoid complicating our lossless encoder further and just do a good redesign of it 😛 we should also try -I 0 in each group...

Yes, it is starting to become a bit of a complicated thing

Good redesign might be a better approach

Also figuring out how to combine lz77 and trees. It's currently too much one or the other...

It's complicated though, combining them

lz77 doesn't match pixel values, it matches encoded symbols, which will end up doing different things depending on the predictor, which depends on the tree and on the neighboring pixels.

But, as I said before, it would be nice to have an option to remove the invisible alpha, at least, if it is not very difficult to implement (for further correct comparisons with FLIF/WebPn)

Ah yes, I keep forgetting about that, and it should be easy enough

should being the keyword here

Better on Pixel Art, but not on the other sets 🤔

not entirely surprising

one relatively easy thing to try is to see if we can lz77 each group instead of globally... the next idea would be to pick predictor in some way (possibly per-group), then LZ77, then learn a tree on lz77 symbols

Yep, but I thought maybe it would be better on some non-photographic sets

wow, speed 1 is pretty bad on pixel art 😄 then again, I guess that's no context modeling, so...

Yep, also a little more efficiency and `-s 2` would be the same or slightly better as the optimized PNG

how fast (and how good) is, say, `-g 3 -s 7 -I 0 -P 5` for you?

and/or -P 4

it should be pretty similar (in density) to a fast PNG encoder

(perhaps a fast PNG encoder would try all of -P 0 / -P 4 / -P 5)

This is hard to measure accurately, or rather I would need to write scripts and measure the time on some set on an unused CPU, but I remember doing this once with something like `-g 3 -s 8 -I 0 -P n` and `-s 4 -P n` was faster

And also this https://cdn.discordapp.com/attachments/803645746661425173/813732244711669810/unknown.png

-s 8 is slow yes, IIRC it does zopfli-like matching

(I mean, I wrote that, but I don't remember if it's at -s 8)

And perhaps with a faster/optimized lz77 implementation, combinations with `-i 0` will be faster

yeah the current code is not *too* optimized

However, I will check results with `-g 3 -s 7 -I 0 -P 5/4`

not bad

Hmm, looks like QLIC2 and ZPNG are faster than JXL `-s 1` with better efficiency

<https://github.com/catid/Zpng>

QLIC2 is faster than Kvick, and here is a comparison between Kvick and JXL `-s 3` (and on my sets Kvick is worse in efficiency than QLIC2)

-s 1 is not worth much, I need to find something better to do there

-s 2 might be somewhat useful though, it should be quite a bit faster than -s 3 both in encode and decode

Yep, `-s 2` is also in the table, I did not compare speeds, but ZPNG and QLIC2 are very fast, almost instantaneous

It's a 75mpx 14 real bits 6mB jxl file, it's a bit slow to decode 😄 (12cores pc) You can see my beautifull browser collection :p

ouch 😄 is that modular or vardct?

(# of cores doesn't really matter atm)

I guess modular, vardct should decode in about 2 s...

dct

uh, weird

how long does it take in practice?

it's realtime 60fps

so ~30s?

that's... bad

It's fast for small images

75 mpx should take about 2-4s on a modern PC

12s

that's clearly more

ok, I'll have to look into it perhaps next week

if you can file a bug...

you can see it's only one core, it's not a fast monocore with no avx2.

well, if you can decode it from CLI first

still, should be about 4s I think

ideally, at least

how long does a JPG of the same size take?

i need to decode it with djxl?

ah i need to add it's a file with hdr profile and p3 color 😄

oups :p

It's from darktable png, the png is opening very fast on xnview, but it crash xnview after few seconds 😄

In fact, original png decoding is a joke on all chromium browsers 😄 In summary 16 bits HGL+P3 75mpx 😄

i never undestand why so many part of chrome are not multicore :/

Firefox is way faster for this png 😄

It's ultraslow in jpeg too, so it's chrome the problem. Decode fast with imagemagick viewer. Jpeg HLG + P3

ah, ok 😄

that's a relief

15 seconds on 1.5mB srgb (14bit input) that's slow too, plus slow zoom.

pretty sure JXL has nothing to do with the zooming 😄

Yes

I hope progressive decode become ultrafast for huge files 😄

we'll see 😄

I consider that eventually -- with 5-10 years of maturing (hopefully earlier) -- lot of the computation is transferred to a GPU, and we will be able to use animation to mitigate the introduction of spatially scattered visual activity in JPEG XL

compressing every png texture in factorio with lossless jxl made the textures 25.37% smaller (1108 → 827 MiB)

<https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/edit#gid=1523015175> I added Game Assets, it would be better to take these sets directly from the resources of the 100 top mobile games or something, but I was limited to free public sets, however I tried to choose examples that are frequently used and varied. <https://github.com/catid/gcif> I also added GCIF, which claims to be optimized specifically for Game Assets and decodes images faster than WebP with better compression (but this is not always true when using a variety of other sets) Also in practice, mobile and other games are not always using PNG or WebP, it is often some other specialized or GPU formats, but still not uncommon and it would be nice to have optimizations for this use case (and since there are most images with alpha channel, it is good to have different options for it)

Also a video about WebP and games (although quite old, but still) https://youtu.be/1pkKMiDWwpM

I don't see any popular mobile games using webp. They are using gpu formats like ktx

They use, especially if it is 2D games or various hyper casual, also for logos, icons, UI, loading screens, etc., but not for 3d textures and stuff

For example, this is from Gardenscapes

Or Homescapes

However, I'm not sure that modern formats with lossless mode should be intended primarily for Game Assets and this is their typical use, it's not bad to have good efficiency for that as well, but... 🤔 https://twitter.com/PascalMassimino/status/1390536793855086593

"typical" can typically mean many things to many people 🙂

At least now there is a set with Game Assets and mostly transparent images, also this use case requires very fast decoding with moderate memory consumption and also I think some optimizations for this content which are well described in the Specification of GCIF: <https://github.com/catid/gcif#specification>

Probably can use vardct lossy on Game Assets? on lower distance(-d 0.5~1.0) quality still good.

lossy

Like this pixel art case, lossy -d 1.0 -s 8 still can keep good quality.

original

jxl-d1.0-s8

Yes, games use lossy as well, both WebP and Jpeg where it would be more efficient and artifacts wouldn't be noticeable, for pixel art it often happens that sprites are shown at very high zooming and they show very noticeable blurring, banding and artifacts, so they mostly use lossless, as well as UI elements and some other things

I don't see blurring

right is the original

140 KB vs 480 KB

I see the difference and for pixel art it is important to keep every pixel as it is (they are also drawn pixel by pixel), also their zooming does not use any smoothing algorithms, as it happens in viewers or browsers, it is very risky to get any distortions or artifacts from lossy algorithms, but lossy formats can be used for some large images or for example loading screens

pixel art case2, lossy -d 1.0 -s 8, Can see some error on dark red and dark purple area, I think need wait Jyrki Alakuijala fix integral transform selection. > https://gitlab.com/wg1/jpeg-xl/-/issues/147 > I guess dark red, blue, purple color have smooth and specific gradient area, > have chance happen this issue, this issus probably like an edge case.

original

d1.0-s8

Yep, and for example this

Probably fix integral transform selection, can fix some issue?

if you're going to look at it as pixel art that gets upsampled to the point that you see actual pixels as little squares, then I think lossless is a better choice than lossy. Lossy cannot really do much if it cannot assume some minimal viewing distance... imho

Yes, sprites can be stored in their 1x1 form, but in games they can be even x10 times larger, sometimes some lossy techniques are used in their own formats, but they are not like Jpeg losses, also such games look like this on the screen (and not in a very small resolution as their real sprites):

don't use medium bitrate

use d1 s 9

or -q 78,97356 -s 7 --use_new_heuristics --dots=1 --gaborish=0 if you are really desperate but it will disable blurring and also new heuristics

so you will get s... performance

so you can only use d 1 s 9

<@!794205442175402004> <@!111445179587624960> If want do some lossy thing on pixel art, probably lossy modular can make better result? > cjxl -m -Q 90 -s 9

not worth using lower bitrates if medium bitrates give blurry results

like don't consider any lower than q 65 and q 63.52

jpeg xl is very good on them

i tested it on squoosh

lossy pixel art might be hard to do effectively

but without optimization of medium bitrates

lower bitrates can't look good

e.g. usually pixel art only uses a small number of colors, so palette works well... but lossy and palette don't mix that well

Maybe, but it can also cause the loss of some pixels Lossy-palette may be better for some cases

i posted in on <#804324493420920833>

and i also filed an issue on github

one week ago

we did in <#794206170445119489> compress a nasa image

4 people participated

operationally, for pixel art, the effort spent in manually checking if lossy is OK or not is too expensive for the potential gain you could get by doing lossy.

imo

result

webp is still ok

However, I do not know games that would use lossy formats for this kind of sprites (and not even for pixel art), textures are another thing, there is not so noticeable losses because it uses a lot of post-processing, different perspective, lighting and other things

anyway also -d 0 -s 1 is smaller then png on the first image, it is also faster to dec?

damn, -s 2 is a lot smaller than -s 7

mmh someting sus

When I have time I would like to compare the decoding speed for different modes, also now it is better to compare mostly with WebP since it is already quite common in games (at least on Android)

``` s1 162 148 s2 148 873 s3 150 026 s4 134 958 s5 174 345 s6 174 404 s7 171 100 s8 169 377 s9 163 032 s9 E3 I1 135 371 ```

something going bad after `-s 4`

Yep, especially for something like pixel art this is a common thing

I didn't expect s4 can be best then s9 E3 I1 on some images

Must be tree learning or RCT selection really messing up

I'd bet tree learning

we should make a "webp mode"...

ah, could also be patches 😄

Also https://files.catbox.moe/6sxvc6.png ```1,048 - WebP 1,215 - JXL (s9 E3 I1) 336 - GCIF```

GCIF, what's that?

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

As far as I understand, it's kind of a continuation of BCIF ideas and some other formats that would be better suited for Game Assets

🤔 https://github.com/play-co/gcif/issues/2

is old

why i should star this repo

i removed the star

It doesn't matter how old the format is, if it is effective and especially if it has sources and where there may be some interesting ideas ```It typically produces files that are 60% the size of PNGCRUSH output and about 85% the size of WebP output, while decoding faster than both. The format is released under the BSD license as forever patent-free, monetarily free, and open-source software. Contributions, discussions, and a healthy dose of criticism are all welcome.```

no, s7 patch 0 171 240

<@!794205442175402004> bad memory I see xD

hah, lol

wb should you or me close the issue about less perceived quality in mid range compared to new heuristic

is not valid anymore

the detail is the same in s9 q 65

is exactly the same

more info about build used in <#794206170445119489>

if your issue is resolved you can close it yourself

an user called <@!387462082418704387> sent the build

and this build solves the issue

at 100%

so i can

ok

issue closed

made a low fidelity version of that image

-q 48.23 --use_new_heuristics --epf=2 -p --dots=1

another image

ezziedato build

not sure if users will be happy of seeing images in this quality

this image is getting larger and larger

first it was a crop, then the full image, and now there's Windows stuff in it too?

no is same resolution

this original

the crop i did with paint

those version i have at -q 45.858 -s 9 and new heuristic is 2

How to compare --lossy-palette --palette=0 result quality? (compare -d 1.0 -s8 and -m -Q 90 -s9)

look like --lossy-palette is very suitable lossy pixel art.

but lossy-palette get large maxButteraugli_jxl score on some case.

I don't think it can be compared by metrics like this, it needs a visual comparison

original

lossy-pal0

look like still great.

Yep, except for some brightly colored modified pixels

<@!794205442175402004> For current version cjxl -m --lossy-palette --palette=0 is implement lossless alpha channel?

yes, the alpha is lossless, and I think it also doesn't do anything special with the invisible pixels (it does the same lossy palette thing on them as on the visible pixels)

ok thank you 🙂

I think if color less than 15000, lossy-palette can't get best result,

For such content, efficiency could also be improved with options for premultiplied alpha and invisible pixels <https://github.com/libjxl/libjxl/issues/76>

And some complex drawing (anime, manga), vardct is suitable those content.

pixel art content > png pal 8 => -m -q 100 -s 9 -g 2 -E 3 -I 1 --num_threads=12 > color large than 15000 => -m -s 9 --lossy-palette --palette=0 -g 2 -E 3 -I 1 --num_threads=12 > color less than 15000 => -m -q 100 -s 9 --palette=15000 -g 2 -E 3 -I 1 --num_threads=12

special case

This case is very special, only --palette=15000 can effective compress,

vardct, lossy modular, --lossy-palette will increase file size.

try `--palette=20000 -I 0 -s 9 -g 3`

or maybe -g 2 works too

I using this, slow but can effective compress. > cjxl -m -q 100 -s 9 --palette=15000 -g 2 -E 3 -I 1 --num_threads=12 Input file: w9feLzj.png | 122829 bytes Image: 1920x1080 pixels | 8 bits/sample | RGB | 10105 color(s) Delta filter: Mixed

-I 0 will will increase much file size. 119KB =>721KB

> -m -q 100 -s 9 -g 3 -I 1 --palette=20000 --num_threads=12 => 99.3KB > -m -q 100 -s 9 -g 2 -E 3 -I 1 --palette=15000 --num_threads=12 => 87.5KB

ah, sorry, `-I 0 -P 0`

I always forget those two go together

> -m -q 100 -s 9 -g 3 -I 0 -P 0 --palette=20000 --num_threads=12 => 117KB

> -m -s 9 --num_threads=12 --lossy-palette --palette=0 -g 2 -E 3 -I 1 =>252KB

Can't understand why lossy palette can't compress pixel art...

<@!461421345302118401> , сan you give advice on lossy compression of manga w/ screentone?

For now I don't recommend vardct mode, some fix not implement on current version, If you want try, -d 0.5 -s 8 for color content and -d 0.8~1.0 -s 8 for black and white content(manga).

-d 1.3~1.45 still good, -d 1.6~1.9 have some risk.

Manga and anime content have much entropy, I don't think large target distance can keep good quality.

<@!736666062879195236> I think integral transform selection fix probably will implement on this mouth. > I hope that will change in the next few weeks. > https://gitlab.com/wg1/jpeg-xl/-/issues/147

my eyes are bleeding

it looks like random banding and sky mirror

New -s 1, -s 2 (some sets have changed, but still)

after https://github.com/libjxl/libjxl/pull/47 lands it will be a bit different again

After today's and future changes? This is `-s 1/2` with this patch, but I compiled this build yesterday

And the previous comparison is `-s 1/2` from the main branch

Ah you added the patch before it was merged?

Yep

PNG is optimized PNG in that table, right?

Yes, Pingo+ECT

It would be interesting to compare with a reasonably good fast png encoder too

> Lightning is now consistently at least slightly faster than thunder. I am now curious whether a medium exists in which sound is faster than light.

IIRC yes but I'm not a physicist

For authoring workflows, you just need a weakly compressed fast encode option, you're not going to do a very optimized encode each time you hit 'save' in gimp or photoshop

Yes, but I don't know any good PNG encoders and they are often optimized afterwards with at least something like Oxipng Even IM or LibVips produce rather bloated images, which even with the fastest optimizations will be smaller

Before delivery or packaging, sure, but for authoring workflows people now use XCF or PSD which is basically very weakly compressed, more important to save quickly than to compress well.

But it might be worth re-converting with some popular PNG encoder to compare the results 🤔

amazing that zopfli is not even the slowest xD

random thought : uncompressed PNG + Brotli is actually reasonable for web delivery, if you use brotli as a content encoding...

Yes, but the problem is that if someone wants to save a PNG, it will be very large (or it will be Brotli compressed and then it will not work in applications), I have not tested this in practice

Which encoder is mostly used in production: libpng/lodepng/stb_image/...?

probably libpng

Btw, it's strange when there are many PNG optimizers, but almost no one makes or compares PNG encoders by their efficiency, mostly comparing decoding speed

**PNG** - Optimized PNG **IM-PNG** - ImageMagick with default settings (there is an option to enable stronger compression), also there are probably faster and more efficient PNG encoders, but I found this to be the most optimal and used solution (IM also uses libpng)

Perhaps I found the fastest PNG encoder (as well as decoder), but I couldn't compile it properly on Windows <https://www.reddit.com/r/programming/comments/mld1ob/the_fastest_safest_png_decoder_in_the_world/gtnbv50/>

Also (same encoder/decoder): <https://www.reddit.com/r/programming/comments/lpzxnc/time_to_dethrone_jpeg_a_comparison_of_nextgen/goidxws/>

I highly doubt you can write a JPEG decoder that is 15x faster than libjpeg-turbo

if I had to trust their numbers, it would be decoding 3 gigapixels/second - that's not going to happen on a CPU

They do parallel encode/decode of JPEG using some trickery - doing things in stripes, with restart markers in the beginning of every strip, and adding a TOC in an app marker, or something like that.

https://www.reddit.com/r/programming/comments/lpzxnc/time_to_dethrone_jpeg_a_comparison_of_nextgen/goiaks1?utm_source=share&utm_medium=web2x&context=3

not even using the TOC, just hoping there to be restart markers

if you do jpeg encoding/decoding in parallel like that, it probably scales almost linearly with number of threads

since the stripes are literally independent

of course the decoding is only fast 1) if you encoded in that way (which probably does hurt compression slightly and is not what normal jpeg encoders do), and 2) if you can use many cores

yeah

Hmm, sometimes premultiplied alpha gives worse results on very small files like Emoji

I suppose it can both add and remove entropy

Like an image that is all white and transparent, could be just constant color RGB and all info in A when doing non-premultiplied

An option for "don't care about invisible pixels" would be good, not sure yet though what would be the best thing to replace the invisible pixels with (ideally they are ignored when learning an MA tree and get their residual set to 0 in whatever MA leaf they end up in, but that's a bit tricky to do)

#comparison

-q 49.23377 -s 9 --use_new_heuristics 26.jxl

-q 49.23377 -s 9 25.jxl

in <#794206170445119489> there is the avif you can download and also the firefox bug

is difficult to detect a difference between those two images

with night is slightly

``` 263 - WebP2 288 - JXL (s9 E3 I1) 16,377 - JXL (s9 E3 I1 Premultiply)```

WebP2 as far as I know uses premultiply and removing invisible alpha by default

But overall (Emoji set)

WebP2 is still a bit better

- https://files.catbox.moe/i0s15w.png ``` 52,952 - WebP 155,017 - WebP2 154,651 - JXL (s9 E3 I1) 185,833 - JXL (s9 E3 I1 Premultiply)```

Game Assets

I wonder what's up with that, smells weird

Something must be going horribly wrong on that one, I wonder what

No time to investigate now, might help if you show cjxl --verbose output

Yes, those were examples from a quick test, I will have to re-check, maybe some of the file names have shifted in the spreadsheet

While the Emoji set is being re-encoded, a few more examples from Game Assets https://files.catbox.moe/ei0ft6.png ```222,196 - WebP 218,919 - WebP2 150,705 - JXL (s9 E3 I1) 222,274 - JXL (s9 E3 I1 Premultiply)```

- https://files.catbox.moe/73phzp.png ```4,204 - WebP 4,055 - WebP2 4,045 - JXL (s9 E3 I1) 5,864 - JXL (s9 E3 I1 Premultiply)```

What encode settings for jxl are this?

modular speed 7

Using cjxl

Pictures are web page screenshots

Ah, screenshots

Might get better results with -g 3 on those

And with -I 0 -P 0 -s 9

this one I cannot reproduce, could be a spreadsheet misalignment?

This one does indeed somehow suffer quite a bit from premultiplying, my guess is that too much entropy from the alpha channel gets introduced in the RGB by doing premultiply here

Probably, because I was adding and modifying images to the set (now doing a complete re-encoding) But this applies to Emoji, for Game Assets the results should be correct

Interesting that WebP2 doesn't have the option to disable premultiplying and removing invisible alpha (so the devs are sure that this is always necessary and more effective?)

inb4 it doesn't have option for removing invisible alpha because it's always removed

(just speculating)

When you do premultiply, invisible pixels inherently become black

And no, it isn't always effective, counterexample being white text on a transparent background where premultiplying doubles the entropy.

So in the future, for denser compression, is it better to do something like auto mode and apply only where it will be more effective?

Emoji

- ``` 618 - WebP 581 - WebP2 575 - JXL (s9 E3 I1) 1,150 - JXL (s9 E3 I1 Premultiply)```

- ``` 70,406 - WebP 61,548 - WebP2 55,964 - JXL (s9 E3 I1) 108,391 - JXL (s9 E3 I1 Premultiply)```

- ```1,310 - WebP 1,213 - WebP2 1,251 - JXL (s9 E3 I1) 2,216 - JXL (s9 E3 I1 Premultiply)```

After re-encoding there is not such a big difference, but there are still some examples with a noticeable increase in size, also WebP2 is still more efficient on Emoji set

- ```139,772 - WebP 133,482 - WebP2 73,162 - JXL (s9 E3 I1) 116,525 - JXL (s9 E3 I1 Premultiply)```

> **skal** > It is lossless (because of the -q 100 option indeed, which means 'lossless' in cwp2)... but in premultiplied world! > Means: cwp2 is discarding everything under the alpha=0 area, and pre-multiplying the other area, which could explain the difference you're seeing with 'pngdiff' if this tool is not doing the measurement in pre-multiplied space.

Btw, it would be nice to have support for these modes in comparison tools

Decoding to null-file (although I'm not sure if all decoders do all their work this way)

Because with the actual decoding to the ppm file, the result is slightly different, but I did not want to add the impact of disk speed For Jpeg XL it is images encoded with the new fast `-s 2`

this is for lossless, right?

Yep

seems about right

you have no idea how much useless stuff is being done now in the lossless decode path 😛

lossless decode speed in webp/png is probably quite image-dependent: if you have many long lz77 matches (like in that diagram) it should be a lot faster than on e.g. a photo

Yes, so I made a mix set for this test with about ~500 images/1.5 GB

However, here Qlic2 is a bit faster than WebP (but perhaps because this is a rather old comparison and WebP has become more optimized) http://qlic.altervista.org/LPCB.html

> Linear prediction based on a block-wise LSM(OLS)-optimized prediction model + ANS coding So, it's something very fast?

However, on the overall result on my sets Kvick does not show such good results (perhaps it was tuned only for this test set?)

Hmm, since WP2 also uses tiles (although I'm not sure about lossless) and ANS, but still better than premultiplied JXL on Emoji, it must be something else 🤔