JPEG XL

Well if you create such a comparison and put it online, I think it's quite clear that the person is ignorant and over-confident. I mean, of course things don't have to be perfect, but why write about lossy compression if you don't even understand that encoders have a configurable quality setting and can obtain various trade-offs between filesize and quality.

With jpegtran you can do that. But I assume they were talking about decoding to pixels and recompressing from that?

yes

they do not know about things such as jpegtran and where telling people to open their JPEGs in photoshop and then export them again

Ouch.

I forgot where the article/blogpost for that is but it was something that was showing on the first page of search results

I found it: https://medium.com/hd-pro/jpeg-formats-progressive-vs-baseline-73b3938c2339

the first result just advertises a CDN when it gets the the part about converting while the second one is the one I mentioned before

ran my entire emoji set (~8000 images, mostly flat colour) through my exporter (just edited it so it can use libjxl), and compared Lossless JXL to Lossless WebP, PNG and crushed PNG

at normal effort it loses to WebP but at max effort it beats it

If you have plenty of time you could try e10 😅

looool, I think e9 was long enough

was experimenting to see if a size increase in progressive could weigh up potential benefits with how browsers could just choose to download only a bit of a JXL depending on resolution, for me the answer seems to be 'no', but also on the e7 512px output the filesize massively spiked :S

Progressive lossless is a bit iffy at the moment

ahhh okay

<@162568168693432320> for lossless webp you should try ```cwebp -mt -lossless -z 9 -alpha_filter best -metadata icc``` which will result in max effort and also make sure icc profiles are properly copied over

ooo thank you

I'm unsure if "-z 9" also includes what "alpha_filter best" does but I included both just in case

okay ^^, I'll probably avoid the -mt flag for my export application because it already multithreads export operations

(well, the operations themselves aren't multithreaded, but it runs multiple export operations on individual threads)

okay, maxing out WebP quality was not worth it but it was interesting to see lol

jxl works really well it seems 😄

well we could improve speed/density trade-offs, e1-e3 are OK but e4+ is slow and could be faster

(and possibly there's also room for better heuristics to improve density without losing speed)

I have an image that jxl struggles with. With `cjxl -e 9 -q 100 ` I get a 195KB output

the original (GIF) is 94 KB and an optipng-optimized png is 123KB

adding `-g 3` results in the output getting down to 165KB

also I did a max effort lossless WebP and it ended up being 114KB

Hmm, thanks, I didn't know about that flag. Apparently, it isn't documented.

I did some googling, I found this thread https://github.com/libjxl/libjxl/issues/426

and I played with some of the flags mentioned there

and now my best result is 119933 bytes: ` -I 0.3 -P 0 -e 9 -q 100 -g 3`

If you have time, try --allow_expert_options -e 10

Interestingly, effort 10 provides far better compression than effort 9, but still larger than GIF - effort 10: 118799 bytes, 4153.316 seconds of compression `cjxl -e 9 -d 0 --brotli_effort=11 --num_threads=0 -I 100 -g 3 -E 11` - effort 9: 165153 bytes, 14.802 seconds `cjxl -e 10 -d 0 --brotli_effort=11 --allow_expert_options --num_threads=0 -I 100 -g 3 -E 11`

Don't use other flags with e10 (other than d0) - it will try everything 😛

Also brotli effort doesn't matter here

<:frogstudy:872898333239279666> and since I specified the different params, is the result different from the "vanilla" -e 10 ? also, will cjxl bruteforce settings using parallelization ?

oh yeah, full cpu load <:2_pepeShy:721833660457943151> But I wonder if using multiple threads with JXL could increase output size ? <:Hmmm:654081052108652544>

no no

it might be, I don't actually remember 😆

That's really nice to read, I really thought it would somewhat split the input image in (let's say) 4 rectangles and then compress them independently (at any level of effort)

I got the exact same output size with only `cjxl -e 10 --allow_expert_options` Compressed in 659.222 seconds using 16 threads

huh not as slow as I thought 😆

Is this with current git version or with 0.8.x?

0.8.2

I guess with https://github.com/libjxl/libjxl/pull/2523 it might produce smaller output now ?

Maybe, maybe not

eh before compressing I always forgot that I use the latest version from my package manager <:dogelol:867794291652558888> and not the nightly builds

gonna try it then <:thinkies:895863009820414004>

It will certainly be different, if it's an ex-gif

I hope better but there's no guarantee

oh no nevermind, latest nightly build is from 10th June, while your PR was merged 13rd

is it easy to build ourselves cjxl ?

Yes it's easy

On linux*

ofc on Linux <:chad:862625638238257183>

gonna try it then

https://github.com/libjxl/libjxl/blob/main/BUILDING.md

``` sudo apt install cmake pkg-config libbrotli-dev clang ninja-build export CC=clang CXX=clang++ git clone https://github.com/libjxl/libjxl.git --recursive --shallow-submodules cd libjxl ./ci.sh opt ```

That should do the trick on debian or ubuntu

thanks, I already saw that "how to build" file I was mostly worried about finding the equivalent packages in Arch, but it appears I had already everything installed <:thinkies:895863009820414004>

Just use makepkg from aur if you're on arch

Ahem <@794205442175402004> I think you'll be disappointed <:dogelol:867794291652558888> Current git produces bigger file (0.1%) <:kekw:758892021191934033> 118938 bytes, in 562.977s 16 threads (this time compiled by me) 118799 bytes from 0.8.2

`jxlinfo` showing the exact same stuff for the 2 files

well that size increase is quite negligible

but I wonder where it comes from <:Hmmm:654081052108652544>

verbose version of `jxlinfo` still the same

What does it do at default effort or at e9?

The size difference comes from using a different palette order

I'll do that in a few hours, need to leave my place sorry

If I use `-fprofile-generate` when compiling, is it a problem to also use `-O3 -flto -static -mtune=generic` when doing that (and use them also with `-fprofile-use`) ?

current git at default and -e 9 provides 1~2% smaller output than 0.8.2, while being 1.46x faster ``` 96651 16 jun 16:06 dilbert.gif 254624 16 jun 19:19 dilbertDef.jxl 252811 16 jun 19:20 dilbertDefGit.jxl 200550 16 jun 19:19 dilbertE9.jxl 195689 16 jun 19:20 dilbertE9Git.jxl ```

so on this side it's a really good improvement

only -e 10 has the problem <:Hmmm:654081052108652544> Should I try -e 10 on another file?

Meh, I mostly want to make e1-e7 get good trade-offs. If speed is not a concern, we can even make an e11 that is even more exhaustive than e10, but I think in practice you generally want something that is fast enough to be convenient.

Really depends on how many times each image might get served

I can imagine some very large scale web sites being interested in ultra slow encoding

But they'll probably tell you that themselves if they ever need it 🙂

Yeah if something will be served a lot it can be worth it, but many lossless workflows are basically save-once load-once...

and some nerds like me too <:2_pepeShy:721833660457943151>

effort 11 ? <:woag:852007419474608208> I thought effor 10 already bruteforced all the settings, what effort 11 would bring in more ?

Also, I am wondering: if I manually bruteforce all the different arguments given to cjxl, could I reach -e 10 size ? If I read correctly, the most "random" things is the function `-I`

e10 tries many things, but as you can see it is not exhaustive, otherwise how could it get worse?

e10 is basically trying lots of combinations of e9 options

Truly exhaustive jxl is not feasible, the bitstream is just too expressive

Well, with -e 10 it took hours in the worst case for me (Ryzen 7 3700X) when I tested on screenshots and smaller graphics

And seconds in the best cases

I would be open for something that could take days or weeks on my hardware

Was having a look on here and noticed the benchmark image took quite a while to load, decided to check how a JXL would fare <https://www.cpuagent.com/cpu-compare/amd-ryzen-7-1700-vs-amd-ryzen-7-5800x3d/benchmarks/passmark-cpu-single-mark/nvidia-geforce-gtx-1070-ti?res=1&quality=ultra> 721 KB to 59.3 KB Not bad for a 12x lossless size reduction Also, wouldn't recommend running `-e 10` on a 10K image... Let's just say I now have over half my RAM free after Ctrl + C

wouldn't even recommand `-e 10` on 1080p <:dogelol:867794291652558888>

The original filesize has a big impact on total memory usage, so I thought 700KB might not be too bad.... Yeahhhhhh, nah

yep that would take a while

Not file size, _image_ size, measured in pixels.

Did two tests, both 4096x4096 PNG files from Krita, one with just a simple scribble on and the other a texture for a 3d model 234KB was 750MB (2GB peak) of RAM 34.4MB was 4.4GB (4.9GB peak) of RAM (Didn't finish due to taking so long)

likely, the original filesize is not the direct factor, but correlates with it, downstream of it causally

This demonstrates memory usage is related to complexity of image content (which, yes, correlates with _compressed_ file size).

Kind of depends on the kind of encoder heuristics

At e1-3 I am pretty sure memory is just linear in the number of pixels

But when things get more complicated, e.g. patches are used, memory usage also starts depending on image content

Yeah, I know there was an issue open about large filesize PNGs using up dozens of gigs of memory too <https://github.com/libjxl/libjxl/issues/464>

But yeah, resolution, complexity and filesize all have an effect on the memory usage, although they are all generally intertwined too

Should be okay with 64 GB. When I use -e 10 on screenshots of two monitors I have seen RAM usage of up to 21.5 GiB for cjxl

With e10 you probably want to limit the number of threads if you use it on larger images

I mean, the problem is not really the RAM usage but rather the time to encode <:dogelol:867794291652558888>

sure, but generally there is a hard cap on available RAM while time is only limited by patience 🙂

Ah, so it does influence how much RAM is taken?

More threads = more RAM usage?

If I recall e10 is essentially just brute forcing e9 options, so each thread could be trying combinations in parallel

Ah, that could be what is going on

yeah, e10 just does one thread per setting, as opposed to e9 and below which do just one setting where some steps in the process are multithreaded (but most of the high-effort modular encode stuff is still sequential)

Here's a test for filesize using images with same content: ```v0.9.0 141c48f5 [AVX2,SSE4,SSSE3,SSE2] cjxl -d 0 -e 9 --num_threads 0 --disable_output cjxl memory usage, median of 5 trials pixels file(b) mem(kb) sv.00.png 3840x2160 24925484 710972 sv.11.png 3840x2160 959928 687412 succ.00.png 600x900 1623567 84132 succ.11.png 600x900 756728 83500``` The difference in memory is less than the difference in filesize. Not dramatic.

Surely this is not related to the actual encoding process.

I assume you just used worse PNG compression to get the larger size?

guessing it's not freeing zlib stuff aggressively enough

Can I trust ssimulacra2.1 scores with avif? Usually score around 85 is hard to distinguish without a zoom, but it's different in case of avif and sometimes there are easily perceivable differences. If I compare 2 pictures of something like 85 jxl and 85 avif, it can be completely different.

I feel like jxl has smoother scoring, in the meaning that if we split whole image on 100-1000 fragments, all fragments would be close to each other in quality. But in case of avif sometimes it might score at lot on majority of such fragments, then have several bad fragments, that are easily perceivable, but at the same time barely affect overall score. Does this make sense?

You can't trust it absolutely, but it is one of the least bad perceptual metrics. butteraugli max-norm might be more discriminative about local error.

I've tried to check specific picture, and I was wrong. Fragmenting doesn't help much. Here is 3x zoom of problematic place. Avif completely blurs it, while jpeg xl tries to preserve even the shape of that artifact in the corner. Banding probably can be solved with different settings, but those check-like patterns are important. It's not artifacts, but dot-like transition. While these lower quality settings do not preserve it properly, jpeg xl tries to create something similar and it works at normal viewing distance, while in case of avif it's easily perceiavable that dot-like shadowing turned into gradient. This is 82.2 score for a showcase, but the problem stays the same until 89-90 score. Score of smaller 150x200 pixels fragment is also similar, so I suppose from metrics point of view, both encodings are lacking, but psychovisually jpeg produced more fidelity. This is why I was pondering if it's even accurate to compare. While at 90 both pictures are similar, I feel that there are probably more situations when jpeg xl 80-85 is more accaptable than 80-85 avif. https://i.imgur.com/pTxjBKq.gif

Btw, the size of avif in this case was 30% smaller, that's why I've decided to check in details.

That's the point of AVIF - it's a video codec. When frames are wizzing by at 30-60 per second, you're not likely to even notice the finer details. So it gets blurred out to save bandwidth. For a still image that needs the finer detail, it's more of a problem than a solution.

at the end of the day, the only accurate way to evaluate image quality is to use human eyes 😉

and brain

people sometimes forget that part

Assuming they have one these days

Hmm. A very unrealistic use case... hmm.. personally, if I see that my original image has jpeg artifacts, I use the "cunet" in waifu2x-caffe — neural network that is specially trained to destroy jpeg artifacts https://discord.com/channels/794206087879852103/794206087879852106/1104649413831438376 , which is also suitable for photos. But do same thing on the image codec... This is strange

want it from codecs that are designed to convey the details of the picture as much as possible... Logically, JXL is better here because it really preserves the details that were there.

That's the point

this is not this case, the AVIF is based on a keyframe, the frame to which there is no movement

And which is still displayed for 12ms

now it makes sense why AVIF is bad for science and medical use... would be bad if it decided to blur tumor or something

It's bad for any use outside of video or tiny filesize, you loose all the fine detail

science and medical use typically is lossless, so it's only inferior to JXL in that lossless JXL outperforms it in speed and compression density

quality is identical, cause lossless

And that it can only do 12bit or whatever it was

What your avifenc settings?

By default I use " -s 2 --min 0 --max 63 -a tune=ssim -a end-usage=q -a cq-level=24" and simply adjust cq to get specific ssimulacra score. Sometimes I play around with d 10-12, --sharpyuv or aq-mode, but haven't decided on final result yet.

Also that blurring is quite common. Here is another example with skin color. Bottom-left is crop, and the right side is 2x zoom. Avif has 84.8 score, while jpeg xl 81.8 with slightly smaller size, but in my opinion it retains overall idea better here. Avif not only blurs, but also adds something of it's own and this visibility slightly depends on color profile. For example, there are 2 slightly lighter lines a bit below center, so it looks like a kind of m wave. https://i.imgur.com/HePZf32.png Ok, discord seems doesn't like animations. It's actually apng and animated at the link.

At equal 85 ssimu score jxl is just better at retaining all details here. So I'm not so sure about it. Avif is decent at 90. Also such kind of blurring should be good for something like 60-70 score, when people want very small size and are fine with some kinds of distortions. But I'm not sure about this in between place. At least it's obvious that we can't simply take a pack of images, encode with both and directly compare just based on metrics alone. Out of ~30 different images, I've seen several when avif had easily perceivable changes and these changes often stayed until ~88 ssimulacra score, while for jpeg xl it was hard to distinguish after ~84.

Heh, JXL even conserves the original jpeg group borders

avm is better than that

update your jxl for having less issues

also

for %i in (C:\Users\Use\Documents\a\*.png) do cjxl -e 8 -d 0.647 -I 0.154 --lossless_jpeg=0 "%i" "%i.jxl"

use this

don't go to blocking

anyway with enine d one

if you're palermitan and there is a fat woman with you, your face will be noticeability puffier

s 8 d 0.805 i 0.758 would be better suited to your use case like a lot

and won't cause the puffier effect

but screenshot will have only an acceptable quality, not good for print

<:PepeGlasses:878298516965982308>

you want a copasion

avm i don't have it now

because cpu 5 crashed

warp rachel barker

No I won't do absolutely nothing

that's the new jxl

a bit of blocking and undesatuation

The topic is not clear to me in general. JXL saves details better than avif. Proof was shown in gif. Well, that's it, closed the topic....

this webp3

<:PepeGlasses:878298516965982308> 3

avm

125,1kb

old build no warp

real who

thanks it'useful

anyway i have a old blog of jxl

https://discord.com/channels/794206087879852103/794206170445119489/1080900107278504038

plus the lemmy.wold of bitflag

cpu seven woks with wap

i need only six

the file is supe big

like supe

But you say your words uselessly. The main developer of jxl does not know what the fuck avm you are saying all the time, but even after that you continue to do it. Enough, say the full name every time so that I could at least Google it!

i'n not that advanced in english

cpu six is sane as seven

aomenc.exe C:\Users\Use\Pictures\a\lo.y4m --cpu-used=6 --threads=4 --min-qp=30 --width=1366 --height=768 --max-qp=68 -o C:\Users\Use\Videos\single.ivf -

i will do highe

i did this aomenc.exe C:\Users\Use\Pictures\a\lo.y4m --cpu-used=6 --threads=4 --min-qp=60 --width=1366 --height=768 --max-qp=136 -o C:\Users\Use\Videos\single.ivf -

aomdec C:\Users\Use\Videos\single.ivf -o C:\Users\Use\Videos\csao.y4m

ffmpegold.exe -i C:\Users\Use\Videos\csao.y4m C:\Users\Use\Videos\sqfa.png

a bit contrasty

accoding to yiang wu av2 cons this yea

and it's aleady at 25 gains

the intev published in livevideostack.cn on twentynine of june

distotions modelling of the noise

this has taken 5.1s on i3 330m

it was even bef fast then webp2

like 198s fo cpufou

and quality is not bette than jpeg xl

The photo is clipped on my phone

And doesn't look better

Anyway it has the best font retention

Out of all photos

AVM retains the saturation without being too reflective

Even at High speed

Is not a codec yet JPEG XL is

Any particular reason to use non-default -I parameter?

This is the best

For font retention and avoid blocking and puffing issues

Generally I just try `-I 1, -I 50 (Default) and -I 100`

Those are nt new settings I just invented now

fabian invents the most precise settings for each context

Yes

I got curious about upscaling. Quite often there is no difference between different modes on a normal viewing distance, but if we look at pixels, we can see small changes. And it's not even so rare, we can zoom pictures or view 480-720p video in fullscreen. Here is a small comparison between jxl and avif. I took 88-89 ssimulacra score pictures and losslessly upscaled x2 and x3 to check how much ssimulacra score would change. Average scores are similar. Median for jxl at x2 was 0.9327 and for avif 0.9305, at x3 0.8995 and 0.8971, thus typically 89 score becomes around 80 at x3 zoom. But we can see some differences in 95 percentile, jxl quite constantly provides slightly higher values. Avif jiggyness is due to sorting values by jxl for easier comparison, on practice both vary due to picture's content.

Odd timing with the video I put in <#806898911091753051> about scaling methods. Although at first I thought you were benchmarking cjxl's `--resampling`

I will check that. My scaling was done simply by repeating values 2-3 times in both axis. I had seen that how avif and jxl approaches lossy differ quite significantly, similarly -e6 and -e9 for jxl apply different strategies, which differ on individual pixels, but not always visible on a normal viewing distance. This scaled approach was an attempt to automate comparison a bit. Like what if both pictures would have a similar score on a normal viewing distance, but differ significantly after zooming a bit.

Yeah, photos you're almost expected to zoom in, videos it's almost impossible without specific software

Is there any way we can add `ssimulacra2` to the installed CLI tools when debug tools are disabled?

I feel like that one is worth installing even without jxl_from_tree and hgl_to_pq or whatever

Hi 👋 ... what's the status of `cjxl` for small (<200 bytes), lossless images? I was surprised that WebP comes close, and is beaten by WebPv2 ... Is there still some tuning planned for lossless with the core encoder?

Right now bit packing (two 4 bit pixels per byte) and pallete ordering (webp is currently much better) are two pitfalls JXL has, if/once those are implimented/improved there should be a larger gap between webp especially for small images

So bitdepths 1,2 & 4 (from png) are not currently supported by `cjxl`?

They are supported, but they can be larger than the original png due to using 8 bits with the other 4 zeroed out (If I recall, feel free to correct me). Usually the zeros are compressed down in the final file so it has less of an impact though

Wow. Ok. So there's definitely some low hanging fruit 🙂

If I recall wb said they might be able to do bitpacking using some modular encoding wizardry, but it'll take some work

Here's an old explination on how it could work https://discord.com/channels/794206087879852103/794206170445119489/935096155354832906

<https://encode.su/threads/4025-HALIC-(High-Availability-Lossless-Image-Compression)?p=80326&viewfull=1#post80326>

is jxl e1 decoding still the same after the recent improvements? although as far as i remember it's a slower version of jxl with msvc compiler, without avx2 jxl can be much faster with clang

> Test Machine: i7 3770K and 3770K doesn't support avx2 😔

I have the impression he did it on purpose...

e1 encode should be way faster than that I think

yeah but what about halic with avx2

i don't think there will be any noticeable difference, at least until some other entropy encoders are used or implementations optimized for avx2+ > SIMD was not used. FSE was preferred as entropy encoder considering the old systems. > > The results are the same as the compression ratio as V.0.6. In my tests, good results can be obtained with various alternatives such as rANS -o1, Deflate and Error Correction. However, because the process speed fell slightly, I left it later. And AVX2 alternatives.

good speed without using SIMD is great, but I think for a future-proof codec maximizing speed with SIMD is something that should be a highest priority

e1 usually takes less than a second, must have some pretty big bottlenecks to hit 13 (seconds?)

I don't think this is the fast_lossless e1 codepath that ends up being used. Maybe he's calling libjxl with input in the wrong pixel format so it doesn't trigger the fast_lossless codepath, or something like that

fast lossless encoding is an order of magnitude faster than decoding so this the generic fallback e1 codepath (the one that is used whenever the fast path cannot be used, like for > 16-bit, > 4 channels, etc)

i don't think it's that slow, because as i understand it's not a single image, but 16 large 46 megapixel photos but still e1 should be faster, it seems to be an issue with the git binary version (with msvc) and testing without avx2

is it possible to make at least e2 consume less memory or is it strictly required, maybe only for single threaded mode? and again lots of people make benchmarks based on official github binary versions for windows, which are much slower than they could be and make wrong statements about jxl speed

Streaming encoder should help with memory use, but since e1 runs a specific 'fast lossless' mode optimizing e2 may not be as easy as it sounds

Currently e2+ is doing global histograms which means it's buffering all entropy coded tokens, then making histograms and doing context clustering, and only then writing bitstream. Likely with local histograms, compression would not be too different (<@179701849576833024> have you tried this at some point?). There would be more signaling cost since histograms would have to be signaled per group instead of globally, but possibly compression could still be better since the histograms are tuned to each group. It would reduce the memory consumption to a fixed amount per thread (one group worth of tokens) and remove the sequential bottleneck in encoding (since each group can be encoded independently).

I mean for lossless. For lossy, I suppose signaling the histograms+clustering for every group is too much signaling overhead and the effect on compression would be bad. For lossless, especially with small fixed MA trees like we have in e2/e3, the histograms+clustering signaling should be small compared to the data itself

We're working on making a (more) streaming encoder right now 😄

for lossless as well? and it would be nice to have some modes for cli encoder

my quick comparison `8192x5456 image, 134086673 bytes` ```md # clang v0.9.0 [cjxl e1 lossless MT 8T] 134,086,673 -> 60,600,350: real 586 mb/s (0.218 sec) = 221%. ram 439084 KB, vmem 626304 KB # clang v0.9.0 [cjxl e1 lossless] 134,086,673 -> 60,600,350: real 304 mb/s (0.420 sec) = 92%. ram 438872 KB, vmem 625960 KB # Git release build v0.8.1 [cjxl e1 lossless] 134,086,673 -> 60,590,767: real 73 mb/s (1.746 sec) = 98%. ram 440368 KB, vmem 626292 KB # Halic 0.7 134,086,673 -> 42,934,087: real 207 mb/s (0.615 sec) = 99%. ram 14668 KB, vmem 17704 KB # Halic 0.7 MT 134,086,673 -> 42,934,087: real 455 mb/s (0.281 sec) = 171%. ram 203820 KB, vmem 667420 KB # QLIC2 134,086,673 -> 55,560,218: real 133 mb/s (0.956 sec) = 99%. ram 309988 KB, vmem 307196 KB # KVICK 134,086,673 -> 50,718,469: real 95 mb/s (1.333 sec) = 99%. ram 184640 KB, vmem 289856 KB # QIC 134,086,673 -> 59,306,145: real 223 mb/s (0.573 sec) = 97%. ram 235868 KB, vmem 328976 KB # WEBP -z 0 134,381,603 -> 61,230,557: real 49 mb/s (2.596 sec) = 97%. ram 939072 KB, vmem 1029708 KB # clang v0.9.0 [cjxl e2 lossless] 134,086,673 -> 57,074,430: real 33 mb/s (3.826 sec) = 97%. ram 3082080 KB, vmem 3578156 KB # clang v0.9.0 [cjxl e3 lossless] 134,086,673 -> 54,192,098: real 17 mb/s (7.516 sec) = 95%. ram 3076816 KB, vmem 3575676 KB # clang v0.9.0 [cjxl e4 lossless] 134,086,673 -> 53,533,646: real 5 mb/s (25.388 sec) = 98%. ram 3076456 KB, vmem 3575728 KB```

yep

Can't find HALIC source code

That's because there isn't any so far

<:FeelsReadingMan:808827102278451241>

I was looking for a documentation of benchmark_xl ? doc/benchmarking.md seems outdated. And I'm specifically looking for the syntax of the --codec parameter ? do you have some tips for me ? 😅

It's poorly documented

I check the code when in doubt lol

--codec=jxl:d1:6,jxl:d2:3 will do a distance 1 encode at effort 6 and a distance 2 encode at effort 3

ok 😄 like here tools/benchmark/benchmark_args.h ?

nice, which letter could I use to set quality instead of distance (if possible ?)

your example should be enough for what I want to do 😄 thanks

I don't think quality is implemented in benchmark_xl, you can use cjxl to translate q to d since it says what d it uses

oki, perfect, that's why it didn't worked 😄 i'll do with d

the formula found in cjxl_main should be the right one, isn't it ? ``` double distance = args->quality >= 100 ? 0.0 : args->quality >= 30 ? 0.1 + (100 - args->quality) * 0.09 : 53.0 / 3000.0 * args->quality * args->quality - 23.0 / 20.0 * args->quality + 25.0;```

https://www.desmos.com/calculator/5onywrdyau

Yeah. There is no real right or wrong here though, it's just a parameter where higher d or lower q means more distortion

yep, I just wanted something similar to what's used, but I understand your point, only distance is used internally

funny, the 30 -> 100 part crosses distance 0 à quality = 101 is seems 😄

depends on what you mean by "correct"

pretty sure FFmpeg has a slightly different method

```c /** * Map a quality setting for -qscale roughly from libjpeg * quality numbers to libjxl's butteraugli distance for * photographic content. * * Setting distance explicitly is preferred, but this will * allow qscale to be used as a fallback. * * This function is continuous and injective on [0, 100] which * makes it monotonic. * * @param quality 0.0 to 100.0 quality setting, libjpeg quality * @return Butteraugli distance between 0.0 and 15.0 */ static float quality_to_distance(float quality) { if (quality >= 100.0) return 0.0; else if (quality >= 90.0) return (100.0 - quality) * 0.10; else if (quality >= 30.0) return 0.1 + (100.0 - quality) * 0.09; else if (quality > 0.0) return 15.0 + (59.0 * quality - 4350.0) * quality / 9000.0; else return 15.0; } ```

This is what FFmpeg uses

Damned! I'll compare the two

tbf FFmpeg's relies on the -qscale feature

it's not documented that it does this and it's strongly recommended that -distance be used instead

which gives the following graph (red for cjxl and blue for ffmpeg) https://www.desmos.com/calculator/budsvf2qkz. They are almost identical above q30 (the jpeg xl version cross d=0 at q=101 instead of q=100 for the ffmpeg one) and really different below q30

`BPP*pnorm` is the result given by benchmark_xl which seems closer to a score of "best quality / size tradeoff" but why pnorm instead of ssimulacra2 score is used ? And what is QABPP ?

QABPP is same as BPP*pnorm but with 4-norm ?

qabpp is pretty much `bpp * max(1, butteraugli max-norm)` IIRC

oki

if libjxl isn't mapping q=100 to d=0 that's probably a bug

maybe yes 😄 affine functions are tricky beasts

even if it is mapping >=100 to 0, it's still a discontinuity

when I chose the FFmpeg mapping, I tried to map q=0 to distance=15

as distances above 15 aren't sane

however, I strongly recommend against setting -qscale for ffmpeg at all

and instead just use -distance

oki, you did the ffmpeg integration of jxl ?

right now, I'm just playing with benchmark_xl

that was me, yes

guetzli goes to quality 110

"110 is more than 100"

https://www.youtube.com/watch?v=4xgx4k83zzc

I tried to shave some bytes off this image : https://www.reddit.com/media?url=https%3A%2F%2Fi.redd.it%2F0xda9546x6g61.png (for which webp outperform a bit jxl)

```cjxl -d 0 -e 9 -I 100 -E 3 --container=0 0xda9546x6g61.png 0xda9546x6g61.jxl JPEG XL encoder v0.9.0 4caa4209 [AVX2] Encoding [Modular, lossless, effort: 9] Compressed to 577 bytes (0.018 bpp). 512 x 512, 0.140 MP/s [0.14, 0.14], 1 reps, 4 threads.```

(not bad, but a bit behind the 520 bytes of the previous lossless encoding attempt shown line 56 of the tab PixelArt of https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/edit?pli=1#gid=0)

So I wondered if it was better (since each pixel is made of 64 pixels) to compress the same image downscaled by a ratio of 8... but by default, it uses a container, and the result is bad

```cjxl -d 0 -e 9 -I 100 -E 3 0xda9546x6g61_1px.png 0xda9546x6g61_1px.jxl JPEG XL encoder v0.9.0 4caa4209 [AVX2] Encoding [Container | Modular, lossless, effort: 9 | 208-byte Exif | 3426-byte XMP] Compressed to 1363 bytes including container (2.662 bpp). 64 x 64, 0.054 MP/s [0.05, 0.05], 1 reps, 4 threads.```

without the container it is better though:

```cjxl -d 0 -e 9 -I 100 -E 3 --container=0 0xda9546x6g61_1px.png 0xda9546x6g61_1px.jxl JPEG XL encoder v0.9.0 4caa4209 [AVX2] Encoding [Modular, lossless, effort: 9] Compressed to 463 bytes (0.904 bpp). 64 x 64, 0.043 MP/s [0.04, 0.04], 1 reps, 4 threads.```

but I don't know if the jxl format could upscale the reduced image by a factor 8 at the decoding ?!

yes it can, see also https://github.com/libjxl/libjxl/pull/2571

nice ! I played a bit, is the container required to store all the relevant informations ? ```cjxl -d 0 -e 9 -I 100 -E 3 --already_downsampled --resampling 8 --upsampling_mode 0 0xda9546x6g61_1px.png 0xda9546x6g61_1px.jxl JPEG XL encoder v0.9.0 4caa4209 [AVX2] Encoding [Container | Modular, lossless, effort: 9 | 208-byte Exif | 3426-byte XMP] Compressed to 1784 bytes including container (3.484 bpp). 64 x 64, 0.049 MP/s [0.05, 0.05], 1 reps, 4 threads.```

(the containerized version crash on my viewer... and without the container, there is no upsampling, I'm digging)

it work perfectly under gimp ! thank you !

but I don't gain any byte compared to the original, compressed with cjxl at 577 bytes

It seems to work without container, for 884 bytes

That Exif and XMP metadata is taking a lot of bytes

Custom upsampling weights for doing 8x NN upsample do add too many bytes if the image is small like that

It would be worth it if it's a larger sprite or say a full screenshot of an old game or something

2x and 4x also have less signaling cost than 8x for the custom weights

maybe 8x NN upsampling can be done using modular LF frame and vardct frame with empty HF coeffs

Ah yes that would also be a way to do it

For downsized pixel art (around 256x256 or under) you can actually use `-e 10 --allow_expert_options` without the `-I` or `-E 3` to have it find the best settings automatically. Much bigger than that and you'll likely run out of RAM or it'll take too long to compress 179 bytes (Unfortunately wb is right about the upsampling bloating the size, it's 600 bytes then)

thank you ! with -e 10 I miss the knowledge of which setting where used to compress best ! but 179 bytes is neat !

damn ! ```cjxl -d 0 -e 10 --allow_expert_options --container=0 0xda9546x6g61_1px.png 0xda9546x6g61_1px_e10.jxl JPEG XL encoder v0.9.0 4caa4209 [AVX2] Encoding [Modular, lossless, effort: 10] Compressed to 433 bytes (0.846 bpp). 64 x 64, 0.001 MP/s [0.00, 0.00], 1 reps, 4 threads.``` it gives me 433 bytes... I'm jealous

0xda9546x6g61_1px.png is the downscaled version (with 1px per pixel)

Huh, what's the filesize of your 1 pixel input image?

Here's what I've got

weird, I reopened the downscaled png under gimp to rewrite it again (without the metadatas, or the color profile) and the new png is 350 bytes, compressed to ```cjxl -d 0 -e 10 --allow_expert_options --container=0 0xda9546x6g61_1px.png 0xda9546x6g61_1px_e10.jxl JPEG XL encoder v0.9.0 4caa4209 [AVX2] Encoding [Modular, lossless, effort: 10] Compressed to 186 bytes (0.363 bpp). 64 x 64, 0.001 MP/s [0.00, 0.00], 1 reps, 4 threads.```

Not exactly what you got but much closer

(the png I used just before was this one 4.7kb of png with metadatas, which compress to 433 bytes in jxl)

The large one was at full 32 bitdepth and had a lot of GIMP metadata inside listing the original file, version, OS, ect The one near mine has the correct 4 bit pallete, although it totalled 8 colors and mine 7 weirdly

😄

is there an argument for jxl to discard ALL medatata ? except container=0 ?

I note that I have to be careful with the original image...

`-x strip=exif` was added fairly recently, might work with `-x strip=all` but not sure, could try exif and xmp at the same time too

ok

I might be on a newer version than you, but container doesn't quite do what you'd expect either ```--container=0|1 0 = Avoid the container format unless it is needed (default) 1 = Force using the container format even if it is not needed.```

It's either sometimes on, or always on

Yep, I noticed the subtleties of container... Indeed, it look like there is not way to discard it at all times. I'm pulling the last version and compiling, then I'll test once more 🙂

If you are just testing I've got a script that strips the container. https://github.com/Fraetor/jxl_decode/blob/main/src/jxl-strip.py

Just use `-e 9 -I 0 -P 0 --patches 0` for pixel art. e10 is a terrible waste of cycles, it's unjustifiable.

`-I 0` isn't always best, it was a month or two ago so I don't recall specifics, but I was testing on pixel art and stepping up the tree percentage in steps of 5 to see what worked best, it ended up being `-I 75`. 74 and 76 were even worse than just 0, but for some reason 75 took off about a quater of the filesize as far as I recall

And that's why I specifically said 256x256 or under, when you're in the realm of 'raw' pixel art it only takes a second even on `-e 10`, as soon as you hit anything at a regular size the time and compute increase exponentially

If it only takes a second, then you've wasted an entire second.

And saved many more if you plan to actually distribute the file

Have an example?

I imagine high efforts are not touched in practical cases, e9 is insanely resource intensive itself.

If you're distributing a lot of pixel art, better go with WebP.

I am curious how much the WebP pallete ordering will improve JXL when it's ported over, it seems like that's the main reason JXL doesn't win every time

I'll have a look at your feedbacks and do some more tests on this pixelart sword 🙂

``` e10_phone_home.txt B s 0xda9546x6g61.png 2503 (various PNG) 720 cjxl d0e9I100E3g3 497 0.33 cjxl d0e8I0P0g3 412 0.04 cjxl d0e10 388 690.27 cjxl d0e9I0P0g3 388 0.44 cwebp z2 374 0.00 *```

I'm pretty sure e10 sends the file to Jon to encode by hand.

what is g3 ?

group size of 1024x1024

much of the encoding context applies to groups so things can be parallelized. larger groups allow more context, possibly yielding smaller output

ok

g2 should be enough then, given the fact the original pic is 512x512

yes, and sometimes g2 is simply better than g3, but as image dimensions increase that tends to happen less

I don't understand why -I 0 works better than I 100... ```Higher values use more encoder memory and can result in better compression```

I think in general the context modeling is implemented in a way which performs well on photographic content. Here, the point is to avoid a high-error/large tree and utilize other tools (LZ77).

this plot shows the resulting file size for `-d 0 -e 9 -I xxx -P 0 --patches 0 -g 2` for each values of xxx from 0 to 100

the size is not very well correlated 😄

that's heuristics for you 😛

could this mode be forced with the existing options of cjxl ?

nope

also not sure if it would be less signaling overhead than custom upsampling weights

IMHO, pixel art should be only 1 pixel per pixel, and only rendered upsampled in the display... but it's not what pixel art does, most of the time

1 pixel per pixel is perfect, NN upsampling beforehand is okay in most cases, but then occasionally you find NN upsampling which has either been resized incorrectly so it can't be downsampled to 1:1 again, or... They save it as a jpeg....

``` irresponsible_computing.txt input count 1:1 pixel art 109 (optimized and stripped PNG) mean mean B user s wins best of 17755.60 .04 0 cjxl d0e7 * 17149.56 .00 4 cwebp z3 * 16748.95 .04 1 cwebp z8 16379.49 1.02 5 cwebp z9 * 15913.63 .24 11 cjxl d0e9P0I0g3patches0 * 14846.37 .63 9 cjxl d0e9E3I100g3 14414.88 .87 20 cjxl d0e9E3I100g3, d0e9P0I0g3patches0 * 14413.90 .85 18 cjxl d0e9E3I94g3, d0e9P0I0g3patches0 * 14383.66 6.95 61 all cjxl except e10 * 14332.60 8.05 74 all except e10 * 14154.25 501.16 55 cjxl d0e10 * 14116.77 509.21 109 all 'all' commands (wins): cjxl --disable_output -d 0 -e 9 -E 3 -I 100 -g 3 cjxl --disable_output -d 0 -e 9 -E 3 -I 99 -g 3 cjxl --disable_output -d 0 -e 9 -E 3 -I 98 -g 3 cjxl --disable_output -d 0 -e 9 -E 3 -I 97 -g 3 cjxl --disable_output -d 0 -e 9 -E 3 -I 96 -g 3 cjxl --disable_output -d 0 -e 9 -E 3 -I 95 -g 3 cjxl --disable_output -d 0 -e 9 -E 3 -I 94 -g 3 cjxl --disable_output -d 0 -e 9 -E 3 -I 93 -g 3 cjxl --disable_output -d 0 -e 9 -E 3 -I 92 -g 3 cjxl --disable_output -d 0 -e 9 -E 3 -I 91 -g 3 cjxl --disable_output -d 0 -e 9 -E 3 -I 90 -g 3 cjxl --disable_output -d 0 -e 9 -P 0 -I 0 -g 3 --patches 0 cjxl --disable_output --allow_expert_options -d 0 -e 10 cwebp -mt -z 9 cwebp -mt -z 8 cwebp -mt -z 7 cwebp -mt -z 6 cwebp -mt -z 5 cwebp -mt -z 4 cwebp -mt -z 3 cwebp -mt -z 2 reference (no wins): cjxl --disable_output -d 0 -e 7 environment: cjxl v0.9.0 97e5ab09 (clang 15.0.7 x86_64-pc-linux-gnu) cwebp 1.2.4 (1.2.4-0.1ubuntu0.23.04.2 amd64) i5-13600K, 16GBx2 RAM, SSD timings were median of 3 or 5 runs, 1 run for e10```

I did it to free the rest of you.

The numbers don't seem to add up, 123 wins total instead of the 109 listed as all (Ignoring the 'all except' entries)

That can happen when summing random numbers. Notice you don't have individual results for every command, and the results for some commands are represented multiple times.

Differently, if you consider the wins for **cjxl d0e10** and **all except e10** sum to 129, you'll find there are 20 cases where both strategies found the same solution; thus, e10 found 35 better solutions than everything else, and everything else found 54 better solutions than e10.

Even just the cjxl strategies found more wins than e10. One might speculate that a curated selection of cjxl strategies would outperform e10 quite comfortably.

I see what you mean now, curate a selection of e9 parameters to run successively and select the best result, rather than brute forcing all option with e10

Agreed. Do you think e10 can sometimes activate some options which are not directly available via the command line in e9?

I doubt it, even e10 doesn't brute force every option, it's why a few want an e11 for maximum savings for mass distribution

I don't know, I glanced at the code when the e10 commit was made but didn't understand it.

Nobody wants that.

We'll ask the chef

if an option that tries literally everything is ever added, it should be e99, not something like e11

Surely it should be e42

When numbers fail to inspire

I'm convinced a limited number of settings should be searched for, depending on the type of source. For screenshot, mangas, pixel art etc. in every case, an experimented jxler pull a string of options which works well. We should just aggregate this knowledge

According to my calculations, it is time for JXL to achieve world domination.

16 September 2023: pick up car from garage 18 September 2023: world domination 19 September 2023: buy potatoes for raclette

unlimited breadsticks

Mmm raclette yummy

raclette in september ! are you crazy ! what will you eat in the winter !?

Where I live, it is winter from September to June.

also raclette

I’ve had raclette in August (2018, I believe)

why not, right?

What is the traditional cheese for raclette?

raclette cheese https://www.raclette-suisse.ch/en/raclette/our-cheese https://www.raclette-du-valais.ch/fr-ch/raclette-du-valais/fabrication https://en.wikipedia.org/wiki/Raclette_du_Valais

Are you using avx2 cpu

> JPEG XL encoder v0.8.2 954b4607 [AVX2,SSE4,SSSE3,SSE2] Looks like it (Unless I've been misunderstanding that printout the entire time)

Lossless above effort 1 is not going to benefit much from avx2...

Oh I thought it was showing instructions sets it would support based on build options. 😄

Do you use avx2 optimized Firefox or the regular one?

could be optimized more, but it took me long enough to compile this as-is

ok, optimized a bit

Ran a few different Butteraugli norms on the CID22 validation set Butteraugli scores obtained using butteraugli_main.exe from GH Actions artefacts of a few days ago, correlations with MCOS scores calculated using SciPy's implementation ``` Norm Kendall Spearman Pearson 6 -0.5894 -0.7729 -0.7044 5 -0.5966 -0.7795 -0.7128 4 -0.6057 -0.7880 -0.7260 3 -0.6162 -0.7985 -0.7472 2.5 -0.6218 -0.8048 -0.7623 2 -0.6273 -0.8120 -0.7809 1.5 -0.6328 -0.8211 -0.8015 1.25 -0.6360 -0.8269 -0.8111 1 -0.6399 -0.8335 -0.8182 4/5 -0.6419 -0.8373 -0.8203 3/4 -0.6419 -0.8376 -0.8201 2/3 -0.6406 -0.8368 -0.8188 1/2 -0.6327 -0.8297 -0.8125 ``` Norms tested = the usual 2-6 range, + half and quarter those, + 4/5-norm and 2/3-norm because I saw 3/4-norm scored well so picked 2 nice fractions slightly above and below it

interesting that 0.75-norm seems to be optimal here — I should check if that's also true for the full set

I did note the 3-norm result is different from the one listed in the validation set table on github (mine is lower by -0.060, -0.020, -0.022). Not sure whether that's due to a change in Butteraugli, ~~reduced precision (the command line tool only prints 6 digits after the dot for pnorm)~~ (tested w patched tool to print full precision, not it), or a difference in SciPy's implementation of the correlation metrics

Some silly norms ``` Norm Kendall Spearman Pearson π -0.6147 -0.7969 -0.7436 π/2 -0.6319 -0.8196 -0.7986 π/4 -0.6419 -0.8374 -0.8203 e -0.6193 -0.8020 -0.7553 e/2 -0.6345 -0.8243 -0.8071 e/4 -0.6409 -0.8370 -0.8191 φ -0.6313 -0.8187 -0.7966 φ/2 -0.6419 -0.8372 -0.8203 φ/4 -0.6240 -0.8213 -0.8060 ```

"3-norm" likely means a mix of 3, 6 and 9 norm

yes, the listed norm is the argument to --pnorm, and from looking at the code butteraugli uses an even mix of pnorm, 2pnorm, and 4pnorm

that's why i picked pnorm arguments ½ and ¼ the usual ones

3-norm = 3 norm + 6 norm + 12 norm 1.5-norm = 1.5 norm + 3 norm + 6 norm 0.75-norm = 0.75 norm + 1.5 norm + 3 norm

Ssimulacra2 used a mix of 1-norm and 4-norm

4-norm is closer to max-norm?

don't quite understand what this whole thing means mathematically...

Wikipedia link would be appreciated <:dorime:1075610532620541952> so I can learn <:frogstudy:1077511463264071701>

found it https://en.wikipedia.org/wiki/Norm_(mathematics) <:frogstudy:1077511463264071701>

higher norm is closer to max, yes.

1-norm is the same as average, 2-norm is root mean square

basically, you take the conponents of a vector, absolute value them. then you raise each to the power of `p`, add up the results, and then take the sum to the power of `1/p` which is the pth-root

If p is 2, then you have the standard distance formula

but 2 is not always ideal

run a big simplex search on it to find the optimal norm ;P

don't need simplex search, it's 1d 😛

you could determine the 3 norms to use rather than just using p 2p and 4p

then itd be 3d

fair

here's a few using actually a single norm (no blending of 3 norms) ``` Norm Kendall Spearman Pearson 1.833 -0.6435 -0.8388 -0.8213 # Found via search 2 -0.6430 -0.8378 -0.8210 1.5 -0.6416 -0.8378 -0.8195 2.5 -0.6393 -0.8318 -0.8163 1.25 -0.6367 -0.8335 -0.8157 3 -0.6354 -0.8250 -0.8076 1 -0.6283 -0.8255 -0.8094 4 -0.6299 -0.8148 -0.7849 0.75 -0.6163 -0.8134 -0.7999 5 -0.6257 -0.8078 -0.7624 0.5 -0.6012 -0.7969 -0.7860 6 -0.6211 -0.8015 -0.7433 0.25 -0.5830 -0.7754 -0.7647 ```

Alas, I have not found how to beat e10 on digital paintings.

do you have a tool (or a methodology) to do subjective assessment (especially to compare 2 settings, not 1 encoded vs the original)

You're asking if there's a double blind ABX test program for images

maybe

yep, kind of 😄 except abx attempt to assess the capacity to tell apart the original and the encoded version (when they are almost impossible to tell apart) here I would like to compare A (encoded with one setting) vs B (encoded with another setting) with the reference R available

I do have some subjective evaluation software, internal only unfortunately ☹️

I'll do something some quick n dirty stuff for my needs 🙂 no worries

for quick viewing, libjxl’s “compare_images” can do that

``` $ compare_images a.png b.png ref.png ```

it will split the view into `a.png` on the left, `b.png` on the right, and `ref.png` in the middle, following the mouse cursor, with configurable width for the middle

one can also use the arrow keys to display just one of the images at a time

(left arrow: `a.png`, right arrow: `b.png`, up or down arrow: `ref.png`)

so you can quickly switch between all three of them

to have that tool, libjxl must be built with `cmake -DJPEGXL_ENABLE_VIEWERS=ON`, and with Qt6 available

we haven’t quite made it compatible with macOS, though (the most straightforward way to do that would restrict colour gamut to sRGB)

thank you for the info, I'll recompile with the flag to test this

`8192x5456 image, 134086673 bytes` ```md # clang [cjxl e1 lossless MT 8T] 134,086,673 -> 60,600,350: real 513 mb/s (0.249 sec) = 175%. ram 425332 KB, vmem 586100 KB # clang [cjxl e1 lossless] 134,086,673 -> 60,600,350: real 303 mb/s (0.422 sec) = 92%. ram 424580 KB, vmem 585744 KB # clang [cjxl e1 streaming lossless MT 8T] 357,838,336 -> 60,601,114: real 179 mb/s (1.906 sec) = 52%. ram 7836 KB, vmem 9972 KB # clang [cjxl e1 streaming lossless] 357,838,336 -> 60,601,114: real 165 mb/s (2.063 sec) = 77%. ram 6348 KB, vmem 7836 KB # Halic 0.6.4 134,086,673 -> 42,927,166: real 199 mb/s (0.640 sec) = 87%. ram 10840 KB, vmem 8236 KB # Halic 0.7.1 134,086,673 -> 42,934,087: real 234 mb/s (0.546 sec) = 82%. ram 18900 KB, vmem 17356 KB # Halic 0.7.1 ST 134,086,673 -> 42,934,087: real 215 mb/s (0.593 sec) = 76%. ram 181564 KB, vmem 419452 KB # Halic 0.7.1 MT 134,086,673 -> 42,934,087: real 747 mb/s (0.171 sec) = 566%. ram 185896 KB, vmem 524380 KB # QLIC2 134,086,673 -> 55,560,218: real 136 mb/s (0.939 sec) = 81%. ram 310036 KB, vmem 307192 KB # KVICK 134,086,673 -> 50,718,469: real 95 mb/s (1.343 sec) = 86%. ram 184668 KB, vmem 289828 KB # QIC 134,086,673 -> 59,306,145: real 221 mb/s (0.578 sec) = 80%. ram 235932 KB, vmem 329008 KB```

is the % CPU time over real time?

basically only total time is matter and correct, percentages can be ignored

regardless this definitely needs some extra profiling

```[cjxl e1 lossless] Compressed to 60600.1 kB (10.847 bpp). 8192 x 5456, 145.595 MP/s [145.59, 145.59], 1 reps, 0 threads. [cjxl e1 streaming lossless] Compressed to 60601.0 kB (10.847 bpp). 8192 x 5456, 21.669 MP/s [21.67, 21.67], 1 reps, 0 threads.```

what disk are you reading data from?

NVMe SSD ~3 GB/s

I saw the same slowdown too

I'll try to figure it out tomorrow

```[cjxl e1 lossless] ram 424304 KB, vmem 585720 KB 8192 x 5456, 141.233 MP/s [141.23, 141.23], 1 reps, 0 threads. [cjxl e1 streaming lossless] ram 135896 KB, vmem 7980 KB 8192 x 5456, 143.065 MP/s [143.07, 143.07], 1 reps, 0 threads. [cjxl e1 lossless 8t] ram 425024 KB, vmem 586168 KB 8192 x 5456, 364.837 MP/s [364.84, 364.84], 1 reps, 8 threads. [cjxl e1 streaming lossless 8t] ram 136144 KB, vmem 8268 KB 8192 x 5456, 398.885 MP/s [398.89, 398.89], 1 reps, 8 threads.```

**500 reps 1t** ```[cjxl e1 lossless] 8192 x 5456, geomean: 156.968 MP/s [135.47, 161.38], 500 reps, 0 threads. [cjxl e1 streaming lossless] 8192 x 5456, geomean: 180.074 MP/s [141.18, 183.05], 500 reps, 0 threads. ```

136 MB of ram is still pretty high

Though if you need ultra low hydrium still works

in previous version it was 6-8 mb (but slower) and that's for lossless https://discord.com/channels/794206087879852103/803645746661425173/1177006237913718944 or does hydrium already support lossless? i wonder if now (with mmap changes) it will work faster for the smallest blocks

meh, it's memory mapped memory, it's not "true" memory usage

(input file is 130mb, afaiu - encoder memory usage excluding the mmapped input is not affected by this change)

hydrium's VarDCT and lossy only atm

So, depending on content, you can outperform d0e10 at 90-330x efficiency running a few commands.

mhhh weird, e10 should explicitly try those flags...

I still love how this came from me trying to defend e10's existence for low res pixel art

how do you get this detailled prompt ?

Please elaborate, I'm not sure what you're asking about specifically.

I was wondering what is this tools which seems to plot the size and bpp of different options of cjxl and plot such a beautiful benchmark

It's some glue code I wrote, interfacing with `cjxl`, `time` and `identify`. That's why it has that stupid mem bpp column giving the max memory allocated divided by total pixels for all images. <:YEP:808828808127971399>

this type of investigation would be useful to improve the speed/density curve for e2-e9 by setting defaults differently — but you need a representative corpus for that, and I still don't really know how to make a representative test corpus for lossless image compression...

RE: https://discord.com/channels/794206087879852103/848189884614705192/1188264295323156511 🦐🌬️

what’s (u) vs. (r)?

user/real, I guess

yeah

I'm guilty of this (3, 6, and 12 norm IIRC) -- it seemed to me that a mix of norms worked better than one, and it felt too complicated to be exposed to usual users

unsplash png sqz progressive lossless jxl (center-first, -p, e9)

truncated to 272557 sqz and jxl

<@179701849576833024> <@794205442175402004> <@532010383041363969> maybe this codec will be interesting and author welcomes any suggestions and possible improvements (if someone will have free time and interest for this, maybe something useful for research) also xyb may have some advantages over Oklab (or logl1) for faster/better compression with the same subjective quality? or maybe something can be performed better for lossless for the same concept of scalability? <https://encode.su/threads/4183-SQZ-Low-complexity-scalable-lossless-and-lossy-image-compression-library> i find the results of this experiment are pretty interesting for fairly simple implementation and flexibility, also it's open source (with MIT license) <https://github.com/MarcioPais/SQZ>

normal compression for jpeg (jpegli) and vardct jxl (e8) and truncated for sqz (target size ~172557 bytes)

sqz is worse than jxl subjectively, but not by much, given the infinite byte by byte scaling and lossless-lossy concept

I know progressive lossless JXL currently has a massive size penalty (if I recall worse at higher efforts), so if that weren't a factor I think the results would be a lot closer

but then they are very different contexts and the second comparison is the normal lossy jxl if there are no requirements for progressive compression, then it will be different formats, from the same author there is a non progressive lossless codec with very strong compression (but not open source)

I wonder how it compares to just a lossy vardct frame followed by a lossless frame

for photos lossless sqz has almost the same sizes as lossless jxl (e7) but worse for non-photos though I need more tests

maybe also i need to compare fuif as lossless-lossy or jxl lossy modular is the same but improved?

it's at least very similar

Note that progressive lossless is not something we have been seriously trying to make a great encoder for. We have been assuming that usually when you want progressive, you also want lossy. It is possible that better compression is possible.

Interesting to read the rationale behind the design choice. For me progressiveness is also a way to display thumbnail from partially loaded files, and in this case, lossless files could benefit from this. Yet perfect progressivity is not required for this usecase

I use lossless files whenever I have images that compress well using lossless algorithms, which definitely isn't exclusive with getting lower quality previews while on a slow connection or something.

If the design of JXL doesn't preclude efficient progressive lossless files, maybe I'll try to look in to it. Are there any modular encoders other than the one in libjxl?

as a web format or for some previews, using just some stages is completely enough but, lossless format which can be encoded only once and used as lossy with truncation to the needed compression level is also interesting while still having decent compression and scalable quality (up to lossless for the same file) e.g. j2k was used as a format for textures in some games because it has flexible quality scaling (although not used currently because there are more specialized formats for gpus)

i think the problem with this type of scalability is the very constant quality changes across the entire image when the other normal codecs can prioritize some of the higher perceptually important areas and give them more bits

at such low bitrates, which jxl is not optimized for, sqz performs better

what does ssimulacra says ?

is your assessment based on fidelity or appeal ? https://cloudinary.com/blog/what_to_focus_on_in_image_compression_fidelity_or_appeal

with the comparison posted in [here](https://discord.com/channels/794206087879852103/803645746661425173/1193577411267272834) it's obvious to see that sqz does better then jxl just by looking at the images from any viewing distance however this kinda makes since because libjxl is known to currently not perform that well at low bitrates

i've also tested at very low bitrates and sqz mostly wins there, but basically jxl lower than d4 is not very good in general in the current implementation low bitrates are mostly avif field

sqz is similar to other wavelet codecs and has smoother quality degradation at very low bitrates more appealing quality at very low bitrates for normal codecs is not that useful feature, but for progressive quality scaling it would make sense

Great like 0.293 14,41 0,256 0,239 19.24 improvements

Yes I agree with every single yours commented.

Fidelity is how close it matches the original

Appeal can be cheated by increasing brightness or saturation

which causes people to say something "looks better"

JXL will always be at a disadvantage compared to video formats at low bitrates, although eventually the larger VarDCT block sizes and overlapping blocks could help close the gap

I have more encoding ideas to improve jpeg xl at lower distance, but likely will not be magical -- I expect these to surface in mid 2024

perhaps 5-10 % improvement

it is to have less heuristic approach to edge preserving smoothing, more quantitative/disciplined approach

Jyrki

This is HD now