JPEG XL

slower? yeah ... xD like 100x slower xD

And the name of that speed could be "snail".

If s9 is the "Tortoise", then s10 should be "Achilles" <:CatSmile:805382488293244929>

i'm trying avif with custom options

this the best i got

quality 15

extra chroma compression

subsample chroma off

sharpness 1

noise synthesis 5

tune for psnr

effort 10

avif has really improved

https://github.com/GoogleChromeLabs/squoosh/pull/987/commits/831c27ad5ad1cac8e38b197f4cc11b2e4a1f9935

could you find what version it is

speed is not bad 2 minutes and 30 for a 526x526 image

at effort 10 with only 300 geekbench only 2 threads only 1 core i3 330m 2,1 ghz 32 nm

likely even in a phone you could get 7x 8x times faster

why? Phones are many times slower than desktop CPUs, even i3. Unless they have specialized hardware of course.

Haha.

If it's a pentium 3 era 300 MHz celeron, I believe you.

stronger pentium 3s went up to like 550MHz iirc

x86 didn't actually have SIMD initially so depends on what you mean by "x86"

and ARM have NEON too

Higher ILP, generally.

fatter caches, more prediction magick

But also, most ARM (until recently...) was targetting power minimization (per computation), not throughput.

also, more software optimizations since x86 things are more popular

Yeah, from what I read, Apple M1 is actually competitive with all but high-end x86 chips.

Single-core decode speed of jxl is between 8 and 18 MP/s (depending on encode settings) on a typical mid-range ARM phone

On a high-end x86 single-core decode speed is 50+ MP/s

For browsers single-core speed matters because they don't parallelize single image decoding afaik

so are you saying that geekbench is b..

you're right

mostly because geekbench measures also gpu

so phones have weak cpu weak architecture

basically what you're saying that a snapdragon 780g 765g 732g can't compete even with 32nm processor

even if geekbench is 1900-2900 and not 300/600

Multi-core speeds things up by roughly 3x for 4 cores. Of course only if the cores are as fast as the main core - often on ARM you have big cores and little cores...

geekbench is stupid?

Main difference between ARM and x86 is that x86 has wider simd and faster floats

clock speed isn't the relevant metric. My phone is an 8 core, with clock speeds in range 1.8 GHz to 2.4 GHz. That's not much lower than my 16-core desktop cpu that does 3.5 GHz. But my desktop can do way more per clock cycle in terms of actual work.

so geekbench is stupid

snapdragon serie 7 is bad

x86 has 256-bit or even 512-bit simd, while most ARM has only 128-bit simd

to encode anything in jpeg xl

Hardly any common CPUs have 512-bit SIMD.

Yeah, very uncommon afaik. AVX2 (256 bit) is pretty common.

why?

like is more like a gpu tool for phones

likely it won't do 5,6 mpx of encoding squirrell

also phones can't use all eight cores normally

as sipa said

maybe only in games

Ah yes, GPU speeds of mobile phones are often relatively powerful compared to their CPU.

do you have experience in that

to me i guess i need 8 gb of ram

only consumer cpus with avx512 are (ice|tiger|rocket) lake. intel server (and maaaaybe workstation?) cpus have had it for a bit but amd doesn't have it at all.

because anyway it would be less

how many ram has your phone

plus how really it is

like if you have a 6 gb ram phone android

what is really true

5,5/3,0

or even less

mine has 6 GiB, apparently

6 gb really

check task manager

how is the max

5,4 gb?

mine (oneplus 6) says 5.9 GB with 4.1 GB used

i know i model specify

I don't know where I can see that.

with all closed?

Just 256 bs 128 bit simd does make a difference

nah lots of stuff open

developer settings

did you bought the 6 gb ram model

or the 8 gb ram model

190n

6gb

you're lucky 5,9 gb of 6

do anyone have less

more than 0,1 difference

4.5 out of 5.7 GB used

htop reports 3.43/5.50 GB used <:Thonk:805904896879493180>

with all closed how is

that was with all closed except termux

all multitasking closed

yeah

thanks

evidently there's still a ton of shit going on in the background tho <:kekw:808717074305122316>

so android 10 uses 3 gb at least

6 gb ram is not that much

to have 200 mb free for decode a 12 mpx jxl image

i'm curious what dev think

if there are any improvements

a lot of the ram that's used could probably be freed if it had to be

android has lots of java which is garbage collected

and various processes probably keep stuff in cache

remember unused ram is wasted ram

android especially is designed to let the OS kill apps at will and revive them later based on memory pressure

my galaxy s4 don't do that

it simply reboot

and sometimes it don't do even that

because is too old as android v?

the behaviour of killing apps on samsung phones when it was introduced

from android 6.0 and up?

ah ok i understood

iirc from the statt

like android 2.x had that, if i remember correctly

you generally don't notice

but when is the way is now

they don't disappear from the list of running apps

like it changes every version of android?

but when in a xiaomi it was the way is now?

i have no clue

there are probably often tweaks to this

like from a galaxy s4 when it improved

and become standardized

Stock Android keeps many apps in memory but miui don't

ok offrtopic

jpeg xl will get good at -s 9 -d 2.21

will have good performance at -d 0.5 -s 9 -d 2.21

and up to -s 8 -d 4.45

i try to predict the future

now the safe value is up to d 1.261 custom settings s9 and -s 6 -d 2.3 stock

this would convince users to compress more; unfortunately

also this image is black on original

yellow on xnview

why

this is the jildo image

https://discord.com/channels/794206087879852103/824000991891554375/837601278531207198

nomacs and imageglass display it well

should someone reproduce the issue?

there is the jxl art link surma technology

I suppose the bitdepth 12 is not properly handled in xnview?

I would not be so sure.

Modern phone SOCs are quite strong.

seam the best cpu android is similiar to i7 laptop or i5 desktop

https://www.cpubenchmark.net/cross-platform.html

this is definitely readable

it actually kind of is if you click “Open original”

but yeah, best to open the link anyway

Oh

yeah good point

Ugh annoying - is there a way to use openexr with both the latest and an older openexr? Will we need to explicitly check the openexr version or what?

welcome to the wonderful world of dependencies

It's just a bit silly that they have to break things for this

Well you can build without exr support of course

Not if it's already compiled, afaik

The annoying thing is they replaced a uint64_t with a uin64_t in a way that breaks compilation

Luca suggested that we use something like `using Int64 = decltype(OpenEXR::…)`

which I think should work

yeah, or ``` decltype(baseclass::tellg()) tellg() override { return pos_; } ```

or something like that

kinda hacky, but...

random question: why theres no global pallette support? it was probably discussed but I can't remember. do apng and webp support global pallette stuff or that was only gif?

Frames are quite independent things in jxl, besides blending / patches / dcframe there is no dependency between frames.

Palette is a transform in the modular sub-bitstream, not some kind of metadata property of the image

Conceptually it is just a coding tool

<@!260412131034267649> I hope you'll find this discussion useful, at first I also was confused about palettes in JXL. https://discord.com/channels/794206087879852103/794206170445119489/827533448318418945

You mean lossless or lossy?

Lossy encoding has been quite well-optimized for speed

Lossless not so much

There are quite a few things in the encoder for lossless that haven't been parallelized yet

For this image, -s 3 is probably quite bad, but that kind of speed gives an indication of how fast it could be (and it could be faster than that too if needed)

This size limit, the limit to 8-bit, the obligatory 4:2:0 in lossy mode, and no progressive decode are the 4 things where webp is not just strictly better than the formats it aimed to replace (JPEG and PNG)

If you want to replace an existing format, you need to be as good on all fronts and strictly better on enough fronts. Otherwise there will still be reasons to use the old thing.

This happened when PNG attempted to replace GIF (no animation support kept GIF alive)

This happened when J2K attempted to replace JPEG (speed being significantly slower being the main issue there at the time)

Yes

Well GIF has the advantage of being supported by anything that exists, being 32 years old.

Most things that support APNG will also support a video codec, which is much better for animation on the web than intra-only approaches like gif/apng/awebp.

or animated JPEG-XL...

Yes

I think animated jxl is only good for things like a photo with a blinking text overlay (ugh), a slideshow of different images, an animated geographic map, or things like that. For anything with 'natural' movement, video codecs will be better.

depends on the codec used in the mp4 but probably not. if the codec is hevc or av1, and the frames in question are intra frames, you could extract them as heic or avif.

oh sorry part of the video

yeah you can trim without recompression. `ffmpeg -ss start_time -i input_file -to end_time -c copy out_file`

You can generally trim a video as long as you start from a keyframe

if you don't start from a keyframe, you can still sorta trim it, but the resulting file includes the keyframe and any more frames before where you actually want it to start. those get decoded but not displayed until it reaches where you wanted it to actually start

Yes, that's what I meant

(you still start from a keyframe then)

do common containers actually support doing this, with good software support?

I think I have encountered random audio desynchronization in the past when doing that

the video and audio were in sync when the file was played in mpv but not when sent via WhatsApp, or something like that

I don’t remember exactly

well, maybe having to trim lossy audio is an added complication

I suppose you can’t just trim that at arbitrary points either

Yeah, I trimmed once on a non-keyframe and the only platform it worked on without issues was Messenger... because FB is recompressing videos anyway <:kekw:808717074305122316> Everywhere else? Problems. Only VLC plays that thing properly, from a good starting point and with audio in sync.

I trim a lot of videos and have yet to find a satisfactory app for playback. VLC can have a particularly choppy start, Firefox a somewhat choppy end, and mpv can omit starting sound (I guess before start_time in the command 190n posted).

I'm actually surprised.

On the full image with default settings(other than lossless) on a 3700X, I get this: ```real 0m23.996s user 0m33.887s sys 0m1.246s ```

That's quite the large difference vs 2.36 minutes 🤔

Maybe not a build with full simd?

That is always a possibility.

Not that that should make much difference for lossless, not a lot of simd there

Same image? Same cjxl version?

Same image, but it's likely that we do not have the same version.

Nothing funny like swapping to disk or something?

With the encoding process consuming 2,8GB at S9 with the image he linked, that is possible.

Not sure what settings you are using. Here is default lossy: ``` J P E G \/ | /\ |_ e n c o d e r [v0.3.7 | SIMD supported: AVX2] Read 1271x16384 image, 54.9 MP/s Encoding [VarDCT, d1.000, squirrel], 4 threads. Compressed to 2358233 bytes (0.906 bpp). 1271 x 16384, 3.71 MP/s [3.71, 3.71], 1 reps, 4 threads. 00:00:06.0900956 ```

Modular: ``` J P E G \/ | /\ |_ e n c o d e r [v0.3.7 | SIMD supported: AVX2] Read 1271x16384 image, 55.1 MP/s Encoding [Modular, lossless, squirrel], 4 threads. Compressed to 3803557 bytes (1.461 bpp). 1271 x 16384, 0.77 MP/s [0.77, 0.77], 1 reps, 4 threads. 00:00:27.3445915 ```

Probably running `-s 8`. At that setting it took a little over a minute.

I figure the main point was the relative speed advantage of WebP. Notice WebP takes about 1/5th the time JXL takes. My system also runs faster than Hoshino_8869453's, but the relative difference remains about the same (8s user/real time for WebP, 42.7s user/33.3s real time for JXL).

Since there is discussion about settings, I interpreted default lossless to mean just `-d 0 -s 7`.

If you want to make such comparisons, better to try all speed settings of cjxl and all speed settings of cwebp

And then compare both density and speed

I saw a plot with results like that, forgot who made it though

maybe a script for it

It clearly isn't comprehensive, but comparing default settings seems fair enough.

They are default for a reason.

To clarify, when I said 'speed advantage of WebP', I didn't mean to suggest cwebp was faster than cjxl in all (or even most) permutations of settings and input. Just this case of default setting on this image.

What CPU do you use?

Me? i5-4670

It may be a threading issue

How might I investigate that?

I'm just talking about you know, a 4 core 4 thread processor from 2013 maybe being worse at threading than a 6 or 8 core 12/16 thread processor from 2017-present

As far as I've seen, cjxl modular encode is mostly single-core bound. And cwebp seems entirely single-core bound. I guess you're suggesting add more threads and cjxl's speed will increase relative to fewer threads, but I imagine it would never beat cwebp on this test assuming they're run on the same machine.

Modular at -s 3 should parallelize well

Default and slower speeds are for modular bottlenecked by encoder things (mostly tree learning) that aren't parallelized yet

It's probably a bit early to do encode speed comparisons for modular, since it is not yet fully optimized

Even the decode side of it hasn't been completely optimized yet

For people who don't know, **avidemux** can cut vidéo easily, h264 h265 vp9 (avi mp4 mkv) without reencoding. Limitation is to cut to i-frame. (ffmpeg can do better but in comand line)

FWIW:

Try -s 9 -E 3 <:megapog:816773962884972565>

This will take much longer than -s 9

But it's much better at compression

I might not have enough RAM, I only have 8 GB.

that may be true idk ( :

It might not scale up too much with just `-E 3`, but `-E 3 -I 1` can scale up significantly.

I was under the impression `-I 1` was of little significance to compression

like that it gave improvements

but that they were nowhere as drastic as `-E 3`

That may be generally true. Depends on the content to some extent. `-s 8` and `-s 9` can compress worse than `-s 7` on certain kinds of content.

even in modular?

Yes.

I saw that specifically on scans of anime style art.

<:monkaMega:809252622900789269> just compressed a lot of line art diagrams with `-d 0 -s 9 -E 3`

i wonder if I got bad compression

This kind of comparison is interesting. Some things are quite image-dependent so it might be worthwhile to try multiple images (and also maybe to show real time too)

Such a comparison could also be done for lossy, but there it would be time, size, and perceptual metric result.

Real time is represented in the table.

WebP is hardcoded for 8-bit RGBA

jxl is not

That means the encoder (currently) uses 32-bit per sample, not per pixel

In case it's not clear, this is maximum memory.

This is avoidable but not so easy code-wise (could make specialized code paths that work on 16-bit instead of 32-bit buffers, for example)

If we implement such optimizations, yes.

Jpeg xl standard setting are for general use, webp standard settings are for web use, I don't tink is fair go for "standard vs standard"

Jpeg xl lossy misure the distance from the original in the encoding, is very safe

jpeg xl lossy on photographic image is great, but on specific non-photographic image have some issue, some time standard setting is not enough keep high fidelity.

i'm sure the encoder can be tweaked in the future to alleviate this

probably is the distance metric that need some tweaks on not-photographic content

FYI the next sync should have this fix

(the EXR one)

Is edge preserving filter used in Modular? (Probably not, but I'd like to make sure.)

not by default, but the bitstream does allow it

Can current encoder do it?

Not sure, does it do anything when you manually set epf with modular?

it should do it yes

About vardct non-photographic image improvement statu, i can't find too much information about this, maybe i miss something important information?

I don't have any news

ok, I understand, just hope can get some good news 🙂

the good thing i think as jon has said is the bitstream has a lot of flexability so a lot of heuristics etc can be added to the encoder to improve image quality and possibly size.

Indeed.

Remember, it's only been 5 months since the standard was finalized.

We have 10 years to get the biggest gains, and another 10 years to squeeze everything out.

Even with jpeg we have recent things like mozjpeg that can give us very high quality results

For an almost 30 year old codec

I suspect most of the 'big' gains will happen in the first 3-5 years

It will all depend on adoption - mozjpeg happened because jpeg is extremely widely adopted. There is no mozJ2K or mozJXR, even though for those codecs there are likely also a lot of things possible...

so we need to get popular enough for mozJXL

On the right track

Or `cjxl` (and the library implementing its encoding logic) just has to good enough that there is no need for a MozJXL :)

https://tenor.com/view/it-has-to-be-perfect-the-first-time-flawless-no-mistakes-perfect-seeker-gif-14552788

Yes, well cjxl has guetzli in its ancestry so it is indeed already much more than what e.g. the original libjpeg was: it already does significant perceptual optimization (to the point that there's not even a way to do simple "naive" quantization, it's always at least somewhat tuned for butteraugli)

But the jxl bitstream also has way more potential than jpeg to do all kinds of advanced stuff, and there we're only scratching the surface at the moment. Things like splines, saliency progression, patches, delta palette, etc are not or only partially implemented in the encoder, basically mostly only as a kind of 'proof of concept' that it works and that it is useful, but the encoder is either not using it or very far from using the full potential of these coding tools.

There will probably be a libjxl-turbo but possibly not mozjxl. There will probably also be dozens of other libraries based on libjxl that target some specific industry - most will likely be much slower and highly specialized.

By the way: images with noise synth finally work in Chrome Canary, yaaaay!

<:Hypers:808826266060193874>

I'd be quite surprised if someone created a libjxl-turbo rather than sending speed improvement patches to the main libjxl...

(I'd also be rather surprised if, say, the vardct coding path could be *significantly* sped up without making some serious compromises - such as having limited range due to integer arithmetic...)

libjxl is already quite turbo - at least the vardct part

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

TURBO TURBO

🔥

not sure if anyone else besides <@!799692065771749416>, <@!768090355546587137> and me can make sense of the above video (not that there's much that makes sense in it to begin with)

Kabouter Wesley <:Poggers:805392625934663710>

I'm not sure there is enough non-absurd story content for it to need understanding of the words...

It's pretty simple to understand the basic plot

WOW IT ACTUALLY WORKS https://slow.pics/c/o3yFIfZ0

Modular is still blocky, but not as much as without EPF!

EPF 3 was way too strong and EPF 2 had extremely hard to notice differences (and only in some places) compared to EPF 1.

Which one of them do you prefer? Vote 1 for VarDCT and 2 for Modular.

*(yeah, I also prefer VarDCT)*

I ran both `butteraugli_main` and `ssimulacra_main` and while 🧈augli marked Modular version as better, SSIMULACRA picked VarDCT.

Hah, that's kind of funny that ssimulacra picks vardct and butteraugli picks modular. Are you sure it's not the other way around? (remember: lower score is better in both)

In theory you can make EPF 3 less strong, but I don't know if the command line can do it

how is the epf strength aux image created?

is it just a constant?

It's a constant in modular mode, yep :D

and in vardct mode?

the --epf cli option is the max but it can also go lower or something?

No, the cli option defined the number of steps, the strength of each step is defined by a value that the encoder computes

wow there are more things to optionally configure in epf than what I assumed

the strength is also signaled, right? there's a 1:8 aux image called `Sharpness` in the spec

that aux image encodes one 3-bit value per 8x8 block in the image that is the index into `epf_sharp_lut[8]`

(which by default is just `N/7`)

that aux image is modular encoded so if it's all the same value it compresses to nothing

In my test, jpeg xl 3.X(-d0.5) and libavif(q20) in high bbp and near file size(non-photographic image), maxButteraugli and P-Norm will choose vardct is better, dssim and ssimulacra will choose avif is better.

none of those metrics are really calibrated/validated for non-photographic images though, afaik

ah so for the epf, looking at the code it just sets the Sharpness to all 4 at speeds faster than wombat and it has some complicated heuristic to set it to either 4 or 0 at speed wombat or slower

but the current encoder never uses values 1,2,3,5,6,7 (I assume to reduce entropy in the signaling)

would be funny to make a jxlart tree for the Sharpness field and see what happens if you do something like `if W > 6 - Set 0 - W 1` in combination with epf 3 on a random image 🙂

(or do a sierpinski in the Sharpness and see if you can see it)

Have plan for let butteraugli calibrated or validated on non-photographic images? That improvement might let vardct and av1 get much benefit.

sharpness is not signaled in Modular mode, so...

Ah right, I meant in a vardct image (just some random photo, see what happens if you put a Sierpinski in the sharpness field)

ewout still hasn'0t build the new version

04052021

new jpeg xl authored 5 minutes ago!

butteraugli have some change in this sync

you can search if is true

if you know to compile

for images i'll start testing with screenshots or quality 77 mozjpeg photos

if i see some changes in heuristics

but anyway i would do

that with older version

is sufficient as quality for me

i don't need super compression

like to me a 52 kb jpeg over 80 is worth

i don't need 25 kb that look dusty

also i don't need full modular search

anyway is not very urgent to compress jpg

as all programs now can read lossless compressed jpgs

even sasha plugin was uploaded

sasha (Kagami mozilla)

main changes in this sync are the following afaik: - more blending was implemented, reducing the number of "not yet implemented" things in the decoder (bringing us closer to version 0.4 - fully complete, forwards-compatible decoder) - several fuzzerbug fixes (making decoder more robust against malicious inputs) - things related to the progressive decode api - some build issues fixed

Xnview is still at 0.2.98

.0.98.2

so it can't also 12 bit

but you use sasha plugin

you open by default with ImAGEGLASS

and is good

ok

ah i uploaded cwp2 and dwp2 in <#805176455658733570>

you can view hoshino command

for echo

(win 7,10, linux, don't know, ask him)

now i will try

with q 78 is not hard to get 44% file reduction

do not know i should test more

many have doubts because of too fast speed

It can happen. It depends on the input image and the encoder parameters. Share them if you need detailed comments from the community.

I know that lower is better 😉 **Butteraugli** ```VarDCT 6.7319784164 Modular 6.3625779152 (*)``` **SSIMULACRA** ```VarDCT 0.02510738 (*) Modular 0.02566513```

*(I used the previous version of JPEG XL, before today's sync)*

it's funny if you know that I made ssimulacra and most of my contributions in jxl were in modular, while the team that made butteraugli and the one that made vardct are mostly the same people 🙂

I was curious and re-did the tests for other EPF values. **Butteraugli** ```./butteraugli_main 1hxwd.png epf0.png 6.5329294205 3-norm: 1.852758 ./butteraugli_main 1hxwd.png epf1.png 6.3625779152 3-norm: 1.821999 ./butteraugli_main 1hxwd.png epf2.png 6.2895941734 3-norm: 1.849840 ./butteraugli_main 1hxwd.png epf3.png 8.0625114441 3-norm: 2.294456``` **SSIMULACRA** ```./ssimulacra_main 1hxwd.png epf0.png 0.02820122 ./ssimulacra_main 1hxwd.png epf1.png 0.02566513 ./ssimulacra_main 1hxwd.png epf2.png 0.02605319 ./ssimulacra_main 1hxwd.png epf3.png 0.03053731```

Both metrics agree on the 4th place (EPF 3) and 3rd place (EPF 0), but they disagree on the 2nd and 1st place.

not really if you look at the 3-norm (which is probably more interesting than the maxnorm)

it's somewhat surprising to me that epf 1/2 actually make things better than no epf - I would expect the metrics to just get worse with more epf

What's the difference between the "normal" 🧈augli and the 3-norm?

And the encoder parameters?

EPF 0 is quite blocky in an unpleasant way since it's line-art. EPF 1 and 2 blur it just enough to remove most of the blockiness, but not too much so details don't get nuked. And EPF 3 is just... ugh. It's so overblurred that even EPF 0 is better.

the first number is the maxnorm, basically the worst distortion anywhere in the image. The 3-norm is something closer to the average distortion over the whole image. Maxnorm is useful if you want to be sure that there is nothing happening like an easy background that has no artifacts but the interesting part of the image does have artifacts, but 3-norm is closer to what ssimulacra does and probably correlates better with the overall subjective quality assessment of the image.

the simple metrics like psnr/ssim/vmaf etc are based on just the average over the whole image, so they suffer from the "easy background compensates for artifacts in the foreground" problem

3-norm is better than just taking the average, but not as sensitive as max (inf-norm)

Visual comparison between different EPF values: https://slow.pics/c/0vpzkivz

yeah, that's a surprise for me too 😄

I've just compiled the latest JPEG XL build and redone **Butteraugli**. ```./butteraugli_main 1hxwd.png epf0.png 6.5188107491 3-norm: 1.861889 ./butteraugli_main 1hxwd.png epf1.png 6.3523821831 3-norm: 1.831513 ./butteraugli_main 1hxwd.png epf2.png 6.2814126015 3-norm: 1.859491 ./butteraugli_main 1hxwd.png epf3.png 8.0532217026 3-norm: 2.298350``` Despite the tweaks in the algorithm the relative ranking didn't change. **SSIMULACRA** remained completely intact.

how to correct read butteraugli 3-norm score? lower than 1.0 is good? bigger than 1.0 is bad?

lower is better, yes

in principle, a maxnorm score of 1 means that if you view the image from 1000 pixels distance and flip between the original and the distorted image, there is at least one spot where you can just barely see a small difference (a just-noticeable-difference).

if it's below 1 it should be no longer noticeable, above 1 easier to notice

of course not everyone has the same vision and it also depends on other factors like ambient lighting, the screen brightness, etc

(and of course if you zoom in or get closer to the screen, more becomes visible too)

My eye prefer epf 3, could you add an extra strenght epf 4-5 for smaller jxl file? 😄

Jyrki Alakuijala say different p-norm suitable different quality area, like 12-norm is suitable libjpeg q95~q99

what is 3-norm suitable quality area?

i'd say libjpeg q60-q90, but maybe <@!532010383041363969> has a different opinion. this is mostly gut feeling at this point, we need more subjective evals to calibrate/validate things

last time, Jyrki Alakuijala Suggest me to use 9-norm for jxl -d 0.5 and -d 1.0

do you have generic build jxl

I tested 3-norm, 6-norm, 12-norm and 9-norm, but I still confused how to correct use this score

basically larger norm means closer to "one problem ruins the whole image", smaller norm means closer to "as long as it's OK on average, it is OK"

like psnr compare butteraugli? I have a white wall, and have black point in this wall, in psnr and low p-norm, if black point is gone, they don't too much mind this issue, white wall keep white is fine. but maxButteraugli and high p-norm will very mind this issue.

exactly

someone has generic build for jxl?

the one from today

I understand, thank you very much <@!794205442175402004> 🙂

I see some encoder change in 9a8f5195 commit(butteraugli change), that change will improve image quality?

Maybe a little at speeds 8/9

the thing i did re encoding is bad

even with new build you can re encode in aom

-m -q 91.48 --epf=3 -Y 2.62 -X 99 -s 9 -q 77 wp2 01052021 jamaika doom9 build slower preset -q 58,4 cavif rs 0.6.7 preset 0

but that is an insane amount of resource

do you think is worth it

like for 43 mb of photos i used 1 hours and 35

but with those options i think i can't even try

what do you think wb

should i advertise this

cavif rs 0.6.7 don't exist

do you have a jpeg xl build from today thanks

<@!321486891079696385> do you have jpeg xl from today?

Yes.

can you send

here

also i need the link from the blog

because reddit don't load to me

did you deleted it

No, Reddit is just down 😛

Just a moment ago,I test cjxl v0.3.7-ab7c5e9b(not new commit) on my issue drawing image, in -d 0.5 have much quality improve in this commit, s7 can litte feel some very tiny noise(smooth), but is hard to see, s8 and s9 look very great, i think just only need litte optimization probably can fix this issue. I think i need test new commit, new commit probably have some new fix. and get unexpected ssimulacra score in ab7c5e9b, i need to fix this issue on my tools **cjxl -d 0.5 -s 7** ```bt_LLd_00a.png": "maxButteraugli": "0.809804", "maxButteraugli_jxl": "0.9525151849", "9Norm": " 0.525483", "dssim": "0.000288", "ssimulacra": "0.51175491" "iv01_07_29.png": "maxButteraugli": "1.104811", "maxButteraugli_jxl": "1.0105659962", "9Norm": " 0.588762", "dssim": "0.000792", "ssimulacra": "0.00754120" ``` **cjxl -d 0.5 -s 8** ```"bt_LLd_00a.png": "maxButteraugli": "0.821976", "maxButteraugli_jxl": "0.6731215119", "9Norm": " 0.402167", "dssim": "0.000229", "ssimulacra": "0.51101196" "iv01_07_29.png": "maxButteraugli": "0.912869", "maxButteraugli_jxl": "0.7721188068", "9Norm": " 0.474472", "dssim": "0.000703", "ssimulacra": "0.00674128" ``` **cjxl -d 0.5 -s 9** ```"bt_LLd_00a.png": "maxButteraugli": "0.841169", "maxButteraugli_jxl": "0.6185841560", "9Norm": " 0.377900", "dssim": "0.000217", "ssimulacra": "0.51096180" "iv01_07_29.png": "maxButteraugli": "0.905566", "maxButteraugli_jxl": "0.7593594790", "9Norm": " 0.464589", "dssim": "0.000686", "ssimulacra": "0.00664199" ``` **avif q7 ycocg** ``` "bt_LLd_00a.png": "maxButteraugli": "0.965656", "maxButteraugli_jxl": "0.8684271574", "9Norm": " 0.459998", "dssim": "0.000163", "ssimulacra": "0.00176666" "iv01_07_29.png": "maxButteraugli": "1.436351", "maxButteraugli_jxl": "1.0399889946", "9Norm": " 0.595515", "dssim": "0.000617", "ssimulacra": "0.00495691" ```

but discord is not down

you can send if you have cjxl exe from today

or the article link

ah squoosh has jxl

AGAIN? <:kekw:808717074305122316>

Easy help: Don't use speed 3. Use the default speed 7 and you get to 26 kB. Or even slower speed to make it even lighter.

cjxl v0.3.7 9a8f5195 on my issue drawing image(non-photographic image) **For drawing image** ***Great*** -d 0.5 s8 s9 ***Good recommend to s8 s9*** -d 0.5 s7 ***Okay but have risk*** -d 1.0 s7 s8 s9 ***Unacceptable*** -d 1.9|-q 80 In my test, -d 0.5 s7 is good, but smooth area still have tiny noise, not easy to see, -d 0.5 s8 and s9 tiny noise is gone, everything is great. -d 1.0 s7 smooth area tiny noise issue will increase, s8 and s9 can reduce, but still can see some issue. -d 1.9|-q 80 s7 smooth area have much noise, i think that is unacceptable. ssimulacra get unexpected score, i still don't know why.

**d0.5 s7** ```bt_LLd_00a.png": "maxButteraugli": "0.809787", "maxButteraugli_jxl": "0.9525215626", "9Norm": " 0.526194", "dssim": "0.000289", "ssimulacra": "0.51176302" "iv01_07_29.png": "maxButteraugli": "1.104811", "maxButteraugli_jxl": "0.9993979931", "9Norm": " 0.587139", "dssim": "0.000793", "ssimulacra": "0.00744962"``` **d0.5 s8** ```"bt_LLd_00a.png": "maxButteraugli": "0.822295", "maxButteraugli_jxl": "0.7336245775", "9Norm": " 0.406894", "dssim": "0.000222", "ssimulacra": "0.51099064" "iv01_07_29.png": "maxButteraugli": "0.902251", "maxButteraugli_jxl": "0.7896180153", "9Norm": " 0.479455", "dssim": "0.000680", "ssimulacra": "0.00636489"``` **d0.5 s9** ```"bt_LLd_00a.png": "maxButteraugli": "0.728147", "maxButteraugli_jxl": "0.7415617704", "9Norm": " 0.409213", "dssim": "0.000215", "ssimulacra": "0.51097473" "iv01_07_29.png": "maxButteraugli": "0.902173", "maxButteraugli_jxl": "0.7899788618", "9Norm": " 0.471273", "dssim": "0.000657", "ssimulacra": "0.00608337"``` **avif q7 ycocg** ```"bt_LLd_00a.png": "maxButteraugli": "0.965656", "maxButteraugli_jxl": "0.8684271574", "9Norm": " 0.459998", "dssim": "0.000163", "ssimulacra": "0.00176666" "iv01_07_29.png": "maxButteraugli": "1.436351", "maxButteraugli_jxl": "1.0399889946", "9Norm": " 0.595515", "dssim": "0.000617", "ssimulacra": "0.00495691"```

this is the quality i find acceptable

when the alien artifacts are hidden most

default 128 kb

with this 221 kb

i'd say this is the equilibrium vs avif

or just use d1 or d 0.5

at speed 9

do not use this

i've found better custom settings

this compares decent with webp

not bad!

I just need test s8 and s9 which one is best.

Drawing

but non-photographic include Drawing I think

but i think anime screenshots can't get lossless source, in best case you probably only can get yuv 444

wp2 i couldn't it crashed i don't remember the options

the test i did

q 72.5 autoedge fiter optimize for decoding speed 3 effort 5

wb deletes two of those images

one i repluoaded

because is useful

<#803645746661425173> is cleaned

That's a strange ssimulacra score, maybe caused by color space issues? The non-jxl ssimulacra assumes all input to be sRGB

deleted 6 images in it

(best to use the jxl ssimulacra, it doesn't ignore icc profiles like the non-jxl one)

Is there anyway to boost quality in dark areas relative to light(er) areas?

it still encodes too light and too information in the dark areas compared to the bitrate

q78 jpeg looks in the preview like a 52,2 kb wp2

no, he said most users don't need those

maybe you could use intensity

target

who is 'he'?

don't remember but wb said something about b and q values

something like that

that 99,9999% of users don't need

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

here's found

the message

that was in reference to a completely separate discussion

about color shift

maybe you are referring about intensity or noise

but i think wb understood what you said

I don't think there is

No, the problem is that -d 1 is obviously not visually lossless in dark areas of an image, while for lighter areas it's totally fine

use speed 9

i think depends on so many things (display, single image feature)

or one of those two options if you want lower quality

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

the best thing is go -d < 1 (0.6, .05)

72.5 q 76.7 with the settings i mentioned

no best thing in d 1 d 0.5 is use speed 9

it will encode less bits to the dark areas

so it wil boosts also visual quality

Yeah, I had to go down to -d 0.4 to get the dark areas looking good, but then (I assume) it also spends a lot more bits on the lighter areas which already looked fine

the encoder claims to be similar to jpg not mozjpeg

mozpeg quality 78 as you seen in benchmark looks like a 52,2 kb wp2

but with less banding

you get bad dark in all image?, it can by a too much luminosity on the screen

the encoder still don't match mozjpeg eno0ugh

because is very new

the modular quality and the galaxy s4 screenshots at d1 s7 were encoded good with old build

but if i need with this build i use speed 9

because of what you said

What happens is basically a blur around sharp details in dark areas. They become very poorly defined, almost like a gaussian blur was applied

and because speed 9 is super fast for hd even on squoosh. it encoded in 2 seconds

(effort 0-6)

maybe is the contrary

can send an example in bencmark?