JPEG XL

Here you can discuss cjxl options and the results you get with them

<@416586441058025472>

Maybe Fabian can make a size/quality graph with all his different options he tries

He sure tries different options a lot so why not make a graph

(and then encode the graph with various options)

Yeah lol

Dedicated Fabian channel!

Well not just Fabian

you'd run out of storage

actually no if you deleted the resulting file after

You don't need to give cjxl an output file.

can it still calculate a ssimulacra score?

Benchmark_xl is made for that kind of thing

ah

Does in-memory encode/decode and computes metrics

Basically a duplicate of benchmarks

But still i prefer this

Obviously i wont publish nothing as i dont have pc

Here are for example some results for the default encode params (just varying the distance and speed)

https://old.lucaversari.it/jxl_results/sdr_plots_html/

(this is for the encoder as it was in October 2020)

We ll See if jxl will do at least this

In Next two commits

And in 4 month we ll know if jpeg xl is fake wp2 or a Very good codec

04052021 has good Quality

What do you want jxl to do in two commits?

One good best ever Quality at d 1.053 s3

Even with modular re encoding

Second commit quantization in the style of wp2

3 commits and up ability to compress a sharper than original image done with 04052021 build

Without blurring as you said

Then i want to ask a question what gaborish=1 do in modular?

An image sharper than original you can already do

But an image with d 1.053 at low effort even with modular processing and an even new encoder still i doubt it will lead to good visual quality

Is the current -s 3 -d 1 not good enough visual quality?

It makes modular do the 3x3 convolution called gaborish, might help a bit for lossy modular though I have no idea if it really helps

Lossy modular is not a great idea in general, it works but VarDCT tends to be better

But obviously you have a schedule

And if jpeg tells to improve butteraugli you should do

But the image should also have a bit of contrast even re encoded at d 1.053 s 3

Washed out image makes bad impression

Even if You initially sacrify higher distances tiny modular improvements are apprecciated

.....

Avif q18 and wp2 should be obsolete in july

🤨

I propose to elect <@416586441058025472> the new project manager of jxl project <:PepeOK:805388754545934396>

He'll change the default font 5x a day...

You may have tested reencoding far more than anyone else, but I can't imagine it's generally efficient to encode to lossy modular, then VarDCT, etc, etc. Just encoding once to a suitable size/quality should preserve the most detail at that size most of the time.

here's how it looks with those

the first one wa with the re encoding

second one not

latest build

original

Does the USAC standard supports as metadata and covert art/thumbnail a Jpeg XL faster decoding 4 file? Do you think they will support new JPEG? -d 1.541 -s 7 --epf=3 --gaborish=1 --noise=1 --intensity_target=210 --dots=0 --faster_decoding=4 the 50° commit: jpeg xl a1248445

vs new commit that will be out at -d 1 or

-d 1.756 -s 7 --dots=1 --patches=0 --gaborish=0

on ytm screenshot it will improve

but i'm looking how it compares with real jpg album art

what parameter or commits is better to use

raysar is prefering to not risk

and he's right

nobody that has experience in metrics

has made measurement

i'm testing some upscaling with new heuristics

do not know if i should use reshade first

for %i in (C:\Users\User\Documents\bil\*.jpg) do cjxl -j -q 98.36 -s 7 --progressive --faster_decoding=1 --use_new_heuristics --epf=2 %i %i.jxl

jpeg xl is bad at blurring

but the file is suprisingly low

20 mpx only 2 mb

we are to test encoders

not to share images (upscaled ones)

also i used reshade image enlarger v 3.0 portable to at max jpeg quality (it doesn't offer png) and i first scaled resolution to x4. the original images were from instagram 160 kb one

still a few more artifacts, but in light they looks right

I don't think wp2 is aiming for standardization, at least webp isn't standardized.

it needs at least 6-8 upscaling for 50 kb jpg images

problem is that i don't know a script

and there isn't a GUI to do new heuristics

orum talked about megapixel qt but it can't do re encoding

only encoding

xnview doesn't read currently new heuristics file

it says convert 10 bit or something

i don't understand

on sasha plugin it works

i have installed it

Maybe, but atm it is only saying the media type is image/webp and here are some URLs that informatively contain some information that may be describing the bitstream in some amount of detail.

That's not quite the same thing as a standardized bitstream.

that's for webp1

and it's not "standartized", it's only for media type registration

https://datatracker.ietf.org/doc/html/draft-zern-webp-01

Yes, it's for webp1, and doesn't really talk about the bitstream itself

https://developers.google.com/speed/webp/docs/riff_container unsure if this is detailed enough and in the right format but maybe this can be called standard? tbh i dunno exact definition what makes something standard as opposed to documentation

These days you just make up new names. We'll call it... docustandard.

The main thing is that a standard is normative, completely specifies a decoder, and cannot just unilaterally be changed by someone.

jpeg xl is compressing good at

for %i in (C:\Users\User\Documents\xs3\*.png) do cjxl -s 6 -q 63.52 --epf=2 -p --gaborish=1 --patches=0 --dots=1 --use_new_heuristics %i %i.jxl

what speed use for lossless

to test parameters

with which commands?

40 kb

visually similar to original

0.348 bpp and very fast speed, super low ram consumption

<@!179701849576833024> what bpp gives usually this settings with the image dev use to test the codec?

you said in reddit typical setting without new heuristics is 0.7 bpp

and up to medium quality

i got images in 0.170 bpp 0.370 bpp and 0.710 bpp

so what is the average?

i'm confused

we usually go from ~1.5 to ~0.3 I think

for the setting i used or in general when testing the codec?

In general

usually 720x540 33,2 kb is low quality and 87,1 kb medium quality and 600 kb great

well 5 days after this channel was opened

wp2

-ps 5 -partition_snapping -uv_mode=3 -pass=7 -q 72.302 -effort 5

original

jxl old

for %i in (C:\Users\User\Documents\bn2\*.jpg) do cjxl -j -s 6 -q 63.52 --epf=2 -p --gaborish=1 --patches=0 --dots=1 --use_new_heuristics %i %i.jxl

new jxl

new wp2 default

this random comparison not a good one like the one scope does

is not a benchmark

......

what does it change between av1enc and avifenc

av1enc at q 81.9 should be very good

What's a flicker test?

maybe switch between images

in a flash

you can search on google

too generic

or -vbr 19300 -rav1e preset 9

holy shit what is that font 🤮

It has a late 1980s vibe

miriam libre is good enough

noto sans lisu is good enough

minaeff ect is bad

https://github.com/fabiorug/Suduwe-font

what fonts do you use

for web browsing

system default

idk why i would use anything else

maybe Ubuntu, it's really nice, not sure what the Windows default system font is

probably Segoe UI

Yes segoe ui

Guess this font <@416586441058025472>

product sans

are you in a phone

don't root the phone

you damage it

I'm using rooted Android for 11 years. No problems

how do you added the wallpaper?

do you use a discord mod

Yes

on android

Yes

does it requires root?

No

how is called

Bluecord

do you have the wallpaper

Yeah.

was the original png?

No. I made the blur and frosty effect

with an app or on pc

With gimp or photoshop

how you edited the font

this is system settings

No

bluecord settings

so discord don't support this

discord don't support this

Yes

can you choose a custom font in suduwe

like a ttf

Yes

do you need root for that

No

or google drive

Just ttf file

because on my galaxy s4 i can't see font without google drive

if i open file manager ttf and otf are blocked

they don't show

by default

Use mixplorer (file manager)

i used on kiwi browser

crx google web fonts

can open miexplorer with that

on a newer phone

but to edit system font on all your system is possible

or at least in the home

do it needs root installed?

My custom rom has inbuilt feature to change fonts

do you have a xiaomi

oppo

I have 3 phones. One iphone, one redmi and one plus

so this what model is

xiaomi

K30

only 6 gb ram

is good to decode jxl

like jpeg xl is superslow

to load a lossless vardct it takes 8 seconds

with newer builds is way better

but still slow

like 2019 this phone

before 2021 6 gb of ram we hadn't in italy

we have a redmi note 10 pro

https://www.hdblog.it/schede-tecniche/redmi-k30_i4248/

https://www.hdblog.it/smartphone/recensioni/n534800/redmi-note-10-redmi-10-specifiche-prezzi-prova/

could you say exact specs of your phone

maybe your isn't redmi note 10 pro

is yours 120 hz? 6,67 display 6 gb ram

No. Not that slow

superfast

like my computer is nothing compared to that

yes but the ram used

if you have a phone with 3 gb 3,5 gb of ram used

you open youtube chrome or firefox

and then gallery and you start scrolling jxl photos

how it will act?

like 8 gb aren't better?

then you have 5 gb free

or 4,6 gb free

310mb to decode 1080*2400 image

what

310 mb

of ram

to decode full hd image

Yes

why so much

IDK

you should decode 18 mpx at that ram

ah lossless modular

still a bit strange

maybe say it to wb

is there a benchmark tool to know ram usage

.....

Probably I have used wrong method to find memory usage (◠‿◕)

john sans lite pro font

good for photon interface

like with corporate s in the bar is amazing

working on it

but djxl decodes to floats, that doesn't help

What's the right procedure to find memory usage

In terminal

You can do /usr/bin/time

I previously used time command to measure memory. So it's okay I guess

Using valgrind valgrind --tool=massif --pages-as-heap=yes --massif-out-file=massif.out cjxl -d 1 PXL_20210530_125021048.jpg ; grep mem_heap_B massif.out | sed -e 's/mem_heap_B=\(.*\)/\1/' | sort -g | tail -n 1

Got the value - 4400201728 for encoding 16mp vardct d 1.

that seems a bit high overhead way to measure memory consumption 🙂

massif is not *too* bad

SCRIPTS FOR HIGH QUALITY FOR JPEG XL v0.3.7-31bbdcd7

s 6 isn't high quality but at least you have epf 2 so less filtering

i'd say

-d 3,02577 -s 4 --faster_decoding=3 --use_new_heuristics

this settings should be already better than webp

for quality

87,2 MB to 9,06 MB (9.501.135 byte) all with high compression 0,227 bpp at a quality better than webp jpeg xl is very efficient

<@!416586441058025472> stop spamming stupid params: --faster_decoding=3 --use_new_heuristics

YES they are stupid maybe for compressing some screenshots of a phone

but there is no use in such a bigger and long distance

in other codecs i said codecs are improving

let's try to treat all approaches to improve compression with respect

I don't agree with Fabian about benefits of --use_new_heuristics or the need for a distance value with many decimal points -- but I'd like to keep getting all signals and all critical voices, too, and opinions of those people who express the thinking that goes against our group-think

IIRC, while I have not always been able to follow the written text, Fabian has brought up examples of chromacity issues that have caused me to change the format or at least the encoder

The weight-lifting bells having grainy intensity losing saturation was an impressive and impactful example -- it could be that it was from Scope, Lee or Fabian, not quite sure whom it was from

i filed only an issue and it was about medium qualities

there was a slightly chromatic aberattion

that discussion was on encode.su

in the new heuristics

12052021

that one I haven't looked at

the image was a bit different from normal heuristic we have today

new_heuristics is a WIP, i.e., not yet implemented as I envison it

I think it needs 2-3 engineering months to reach parity with the old heuristics

anyway it was solved two weeks ago and i closed it

it can make the coding faster and less memory intensive

cool

I understand, it's cool to test and discuss here, the problem is: he doesn't make the effort to writing sentences and ponctuation and we don't understand what he say. It's not very respectful for us.

Are additional channels implemented? (in the latest reference lib)

My usual settings for high quality encoding in avif using aomenc for photographic images (SVT-AV1 below CPU-7 is not really useful) `avifenc -s X -j X --min 0 --max 63 -a end-usage=q -a cq-level=XX -a color:sharpness=2 -a tune=butteraugli -a color:enable-chroma-deltaq=1 -a color:qm-min=0 -a color:deltaq-mode=3 i.png o.avif` This necessitates a very recent version of aomenc, so might as well compile from source when compiling avifenc as well. 1. `-s X` = encoder speed. 99% of the time, lower is slower, but higher efficiency. My recommendation is 6 for speed, 3 for optimal quality. Anything lower is not very useful. 2. `-j X` = how many threads you let the encoder use. Above 1, this will activate row threading, with a small efficiency loss. 3. `--min 0 --max 63` is the minimum and maximum Q range used for the encoder per SB. Lets the encoder breath as much as possible. A smaller search space is faster, but lowers peak efficiency and quality. 4. `-a end-usage=q -a cq-level=XX` Chooses the "Quality" toggle, using quantizer modulation, with a certain quality level set by `cq-level` 5. `-a color:sharpness=2` Sets how much detail retention you want vs artifacts. 0 is the default, and a bit blurry. 1 deactivates some RD optimizations regarding artifact prevention. 2 is the highest I'd go, as going higher doesn't change much of anything, but provides the most detail/bpp. .6. `-a tune=butteraugli` changes the RD tune from psnr to butteraugli. You need to have a recent version of aomenc compiled with butteraugli support. Provides good detail retention and best color. A bit slower than PSNR tuning. Only works with 8b images(so no `-d 10`). 7. `-a color:enable-chroma-deltaq=1` Enables chroma Q variation per SB. Free quality increase. Not activated by default. 8. `-a color:qm-min=0` The default min quantization matrix flatness is 8, which is too high in my opinion: it restricts how low the quantizer can go per SB. May be less efficient, but provides a higher quality ceiling.

9. `color:deltaq-mode=3` Default is objective Q variation per superblock(1), which is not optimal for intra-only psychov-visual quality. Very recently, a intra quality Q variation mode made for psycho-visual quality has been introduced, and it actuallys works well. **Extra**: for banding prevention without using grain synthesis, you can add in `-d 10`. Prevents the use of `-a tune=butteraugli` though. Combined with `-d 10` and grain synthesis(`-a color:enable-dnl-denoising=0 -a color:denoise-noise-level=5`), it makes it a strong encoder, even in challenging scenarios.

Thanks, this is very useful. I don't get why they don't enable most of these things by default. You need to be a Fabian-level commandline parameter tweaker to get the best results, it seems...

Ah yes. The man page we need.

Some of these settings require additional compile times options(such as the butteraugli tune) and recent versions of aomenc(such as the tune butteraugli itself and the new deltaq mode: https://aomedia.googlesource.com/aom/+/c74dc0c588fd28b499d5bbb9230614cfc70d6a34)

I think they are not enabled by default because AVIF (both libaom and rav1e) has no developer (or team) relating and improving exclusively still images, the main changes come from AV1 encoders In addition not all of these options have a significant impact on quality (at least according to my own tests on art and photos), with some I did not notice any difference or they were insignificant, some are not always better for a certain type of content or strong compression But for example I use these options quite often and their impact is quite noticeable: `-a sharpness=2 -a enable-chroma-deltaq=1 -a deltaq-mode=3` Also I encode mostly in 10bit (since the decoding speed was significantly improved in dav1d and it's supported by hardware decoders): `-d 10` and also `-a enable-dnl-denoising=0 -a denoise-noise-level=5`

It also doesn't help that some settings come to preference. `--tune=ssim` for examples preserves detail better, but can butcher color performance, particularly in non-photographic images vs `--tune=butteraugli`, or the fact that the butteraugli tune only works in 8bpp. `--sharpness>0` biases the encoder towards better detail retention at the cost of artifacts. At super low-low bpp performance, that can actually hurt performance in some scenarios.

Also, `-j 1` according to my tests is not always the best for quality, sometimes more threads can be better, for example I had this happen with `-j 4`, visually and by metrics and it also applies to lossless

Although `-j 1` is safer for all images (especially if there is always something to encode in parallel), still `-j` with larger values is not necessarily worse

It is very inconvenient imo that it makes a difference to begin with

I mean also for the pixels you get, not just for the filesize

I can imagine that quality can improve in some cases, or get worse, and filesize probably always goes slightly up

For lossless I imagine it's a bit like -g 1 vs -g 3 in cjxl: doing it sequentially is like -g 3 where prediction can go over longer ranges, while doing it in parallel is like -g 1 where more localized entropy coding can make it more locally adaptive, in a way

Yep, I just mean that more threads does not always result in lower quality

Makes me wonder if they should add an option to emulate multithreaded encode in single-threaded encoding

try to re encode avif

........

To have similar bitrates of AVIF with JPEG XL try those commands

libjxl v0.3.7-169-g1f7445a win_x64 2021.06.26

this should be good

.......

second pack of settings

1920x1440 -q 54.14 -s 9 --epf=3 --use_new_heuristics --gaborish=0 1920x1080 -q 43.281 -s 6 -I 0.608 --epf=1 --dots=1 --gaborish=0 --patches=1 -p --use_new_heuristics 3840x2160 --faster_decoding=1 --intensity_target=293 -s 9 -q 45.943 --gaborish=1 ---patches=0 1280x720 -q 31.73 --faster_decoding=3 -I 0.89 -s 7 --use_new_heuristics -q 39.19 --faster_decoding=1 -s 6 --epf=3 --dots=0 1366x768 2560x1440 -q 32.888 -s 9 --faster_decoding=1 --epf=2 --dots=1 --gaborish=0 -q 46.96 -s 9 --faster_decoding=4 --720x540 resolution

.....

exclusive

after -d 2.8 -I 1.5 --epf=0

trying to encode chiara ferragni photo

libjxl v0.3.7-171-gc12aec2 win_x64 2021.06.28

https://eddiezato.github.io/bin/

should i also use noise 1

yes why not

maybe add new heuristics

it doesn't work with noise

help me

did

for %i in (C:\Users\User\Documents\9293\*.jpg) do cjxl -j -I 0.881 -s 1 -q 91.732 --gaborish=0 --use_new_heuristics %i %i.jxl

file size is the same

the jxl photo looks like restored

has lot less blocking

maybe you could use libjxl v0.3.7-171-gc12aec2 win_x64 2021.06.28 with that exact settings and ditch knusperli

but old things don't need to die

facebook likely will use the most faster decoding it can get

and want lower file size even on jpg input

is a social

social don't care if you see blocking or your eye sight or your images

What are your experiences about the deltaq mode?

encode this at -d 0.901

when the new commit is added

that’s a bit small, here is a larger version: https://images-na.ssl-images-amazon.com/images/I/81RynTwX7VL._SL1425_.jpg

deltaq-mode=1(default objective) works fairly well, but is not perceptually aware really. deltaq-mode=2(perceptual, but currently in placeholder since it is buggy) detalq-mode=3(perceptual for intra) works really well for intra images, and makes the rate control decisions based on block variance by doing a wiener filter pass to then decided to then allocate the bits in a well done psycho-visual manner.

how does it compare with JPEG XL ?

(I'm mostly interested around d1 - d2.5)

i want to try butteraugli with the version i captured

i want to try butteraugli with the version i captured

butteraugli exe

how to read the parameter

i read it on a https://www.youtube.com/watch?v=r_LpCi6DQME

that if the parameter is 2 it means is good

and it should be less than 1

could anyone send butteruagli.exe command

``` butteraugli_main original.png compressed_and_decoded.png ```

and what value i should watch

how to know if

https://discord.com/channels/794206087879852103/840831132009365514/859476503275634728

encoded at -d 0.901 -s 9

is bad or not?

if there is artifacts or not?

i will use latest compile

which is the best

i think butteraugli main because is a recent date

can we know or we need the source?

i would try also -q 79.49 -s 7 -p --epf=2 --dots=1 --gaborish=1

i'd say jpeg xl is already 41% less than jpg

tomorrow i will do

deblocked one

is this extra ringing worth it?

he can google ms-ssim and psnrhvs-m, but not butteraugli 😦

no he talks about butteruagli

ah the pronunciation

there is a small reversal there -- "buttergauli"

i say it butta-ragli

butta r ay gli

is not how dev said

is too italian as pronunciation

in english is different

(-:

he is a developer advocate, not a 'dev'

ok

he wouldn't actually develop or even integrate compression algorithms, just talk about them and how and where to use them

i know is a chromium talk

developer talk

talking is also important of course

wait... why he choose buttergauli distance 2.0? I think 2.0 is too risk, 1.6 probably more stable. > https://youtu.be/r_LpCi6DQME?t=1885

scope sent me a -d 0.901 -s 9 jxl

maybe i will continue to watch the video

butteraugli 2.0 used to be about 1.8 nowadays

there has been inflation 🙂

there is a b and a s

what is p norm

the b or the s

0.9621142149 3-norm: 0.579190

the difference is s is 60k

what is s in that video

is that SSIM

I try to align all butteraugli distance, probably butteraugli (pik,guetzli) distance need plus 0.2 to align butteraugli_jxl distance? > Butteraugli, Butteraugli_pik, Butteraugli_guetzli > d0.19 q110 > d0.2 q101~q105 > d0.5 q95~q100 > d1.0 q94~q95 > d1.45 q90 > d1.6 q85 > d1.8 > d1.9 q80 > // minimal quality value for guetzli is q84 > // The scores above quality level 100 are just linearly decreased so that score > // for 110 is 90% of the score for 100. > > Butteraugli_jxl > d0.1 q99 > d0.3 q97 > d0.5 q95 > d1.0 q90 > d1.45 q85 > d1.6 q82.5 > d1.9 q80 > d2.0 > // Positive quality values roughly match libjpeg quality.

even the deblocked cover art looks awful

to me don't look good

I think divide by 1.1 or so

I believe that in guetzli we calibrated guetzli and libjpeg with butteraugli scores

also “`butteragule.exe`” in the slide

In jxl someone came up with some values -- I don't think there was a calibration procedure, at least I don't remember us having one

It was slightly disappointing that they got the name wrong

but they are busy people, they can only invest so much time in each effort

he is 'senior staff' person, i.e., someone who could manage 10-25 people

he did provide a lot of energy for the audience

So butteraugli_old distance and butteraugli_jxl distance have some different quality(just noticeable errors) define?

I would say the difficulty of remembering and pronouncing such names for many other languages and countries is also heavily impacted, it's fun to have unique and unusual names, but they may not always be convenient for most people Let's say a person wants to name his compressor or metric as Llanfairpwllgwyngyll (since he was born there, yes, it's not as ordinary and trivial as Zstandard for example, but it's much harder to remember, write and pronounce correctly)

VMAF and av1 also have some psychovisual optimize like butteraugli just noticeable errors. > VMAF just-noticeable-difference > https://streaminglearningcenter.com/learning/mapping-ssim-vmaf-scores-subjective-ratings.html > https://streaminglearningcenter.com/codecs/finding-the-just-noticeable-difference-with-netflix-vmaf.html > av1 Just Noticeable Distortion (JND) > https://discord.com/channels/794206087879852103/805176455658733570/854652861442031616

What is a "just noticeable difference" when watching two videos in a row is not the same thing as a JND in still images

VMAF is based on MOS scores for 23 video clips

That's all the data that was used to make that metric

Only 23 video clips<:NotLikeThis:805132742819053610> I think I need use 3-norm on my av1 encoder test.

So, less ringing, more other errors (like smoothing)?

There was a time when I forgot a 5 % normalization that I usually did, and the metric slip by 5 %

I decided not to recover it to keep jpeg xl's internal testing values roughly in line

also, 'how many pixels is the viewing distance' is what matters in the end

screens are gaining pixel density, internet is getting faster, cameras are spitting out more pixels etc.

so, I thought it was not that big of a sin and never corrected

but I do believe the old guetzli-butteraugli is stricter

the encoded one is in benchmarks and scope did at -d 0.901 -s 9 and is written the p norm

p norm doesn't really indicate the ringing errors

In photographic/realistic images: At low bpp, AVIF still wins, as while JXL has improved significantly at low bpp as well, AVIF using aomenc has improved a lot as well. Grain synthesis proves to be extremely powerful. AVIF is still recommended to use there. At mid-bpp, JXL still eeks out a small win, but AVIF has improved nicely in this regard and now has a lot more consistent performance, and puts up an excellent fight. However, it has one weakness: in 8bpc, banding in challenging blue-black skies for example is unavoidable unless you do stuff in 10bpc(16bpc processing). It even wins in some synthetic images. I'd recommend JXL, but if you only have access to AVIF for some reason, I now feel comfortable to say to use it. At high-bpp, JXL wins, but AVIF has improved there even more, although its weaknesses still apply, and the speed delta starts to get rather large at the image sizes I tested it... In drawn images: Low-mid bpp: AVIF using aomenc wins, hands down. JXL has improved a lot there, and its lack of chroma subsampling from RGB sources means it can eek out some small wins in low complexity images, but in higher complexity drawings, the ringing and blocking artifacts hurt it, and aomenc-av1's improvement in intra means it got stronger there as well. High bpp: There, the difference gets so small between AVIF and JXL that you're better off just using CJXL over any AVIF encoder. Lossless: **Don't**. Slow decode speed, and on-par/worse performance than WebP. Encode speed is mediocre-ok, especially with the SIMD improvements brought over to aomenc recently. A more detailed analysis of this will be coming in the article next week.

Copy of bluesword comment

thank you fabian

you're welcome

Is the article going to compare JPEG XL and AVIF? Which versions are going to be used -- there is a substantial improvement between the 1.7. and 8.6. versions of JPEG XL

Yes. However, do not worry. The written article is already done. The image and metric comparison part is the one that can be more easily modified. Basically, I've put off publishing the article multiple times because of both encoders improving nicely. Since I can't keep delaying stuff however, the latest aomenc and CJXL versions as of Friday will be the ones to take the cake.

which organization do you work for?

I do not work for an organization specifically, but I am a technical writer at a website called Chips and Cheese: https://chipsandcheese.com/author/blueswordm/

that's cool

I like your writing style, it is with your own opinions with justification and explanations on how you reached the conclusions, also I find it energizing to read

then again, it is my favorite topic, so I'm probably easy audience

the JPEG committee calls JPEG XL just JPEG XL, without a dash

the devs call libjxl "libjxl"

none of the 'inner circle', at least that I know, calls JPEG XL 'JPEG-XL', but I see it used by Google's developer advocates and the AVIF team

for engineers there is some discomfort in names with spaces in them 🙂

ISO itself calls JPEG XL by its full name "JPEG XL Image Coding System (ISO/IEC 18181)", which is a bit too long for engineers' taste 😄

I mix JPEG XL and jxl

Spaces are indeed uncomfortable

yes, we have libjxl, jxl, image/jxl (I wanted to propose image/j -- but it was too much (too little) for the rest of the team), JPEG XL, and JPEG XL Image Coding System (ISO/IEC 18181)

last Friday versions (from the head) are a good choice

in some of the slowpic examples the original has darker shades than the rest -- do you know what is happening there?

in WebP team's testing I saw that AVIF and WebP become lighter, but JXL is kept the same as the original in darker shades

I suspect it may be different in different browsers, too

I think the reason is that at the time, the ICC profiles weren't being transfered with cjxl for some stupid reason. It has since been fixed

aah

that would explain it

I don't know if it would improve the low bpp performance when an ICC profile is not transferred

I don't know if we just enumerate the ICC profiles in those test images, or if we actually brotli encode the ICC profile into the JXL stream

if we do, and WebP and AVIF just don't, then we take a big hit in low bpp

(probably not the case)

CJXL 0.3.2 encoder

basically even at s 9 q 94.1 it introduced a lot of desaturation

like i encoded screenshots with -s 4 -q 99.2 in 0.3.1 and it was only decent

image have a lot of blocking

cjxl 0.3.3 is when it starts to be decent even if butteraugli and psnr are worse it can get

Uhh Fabian, I don't think any image encoded at q99/d 0.1, will look bad <:kekw:808717074305122316>

that was 0.3.1

you weren't in this server

Fabian, I was here when 0.2.0 rolled out <:kekw:808717074305122316>

yes

even at 10/02/2021 5th there is german

many surrounding systems had bugs, too, like browsers have had ICC interpretation issues

depending how the testing was done, the same image may look quite different for person A and B

supposedly even today there can be desaturation issues on desktop firefox that go away with chrome -- one of my twitter followers reported today

<@!532010383041363969> i don't find what is the default epf and gaborish value according to the distance quality. Can you help me?

gaborish: always on

EPF: see https://github.com/libjxl/libjxl/blob/main/lib/jxl/enc_frame.cc#L243 - 0 below 0.7, 1 between 0.7 and 1.5, 2 between 1.5 and 4, 3 above 4

Thank you 🙂

I compressed the dog

for %i in (C:\Users\User\Documents\imf3\*.png) do cjxl -q 71.459 -s 9 --epf=1 --dots=0 --use_new_heuristics --faster_decoding=6 -I 0.933 %i %i.jxl

libjxl v0.3.7-202-gc8b0bf3 win_x64 2021.07.03

here's poor results

black totally crushed

pixelations and blurring everywhere

curious what would happen if i choose q 57.71 e 5 in next wp2 commit

jon probably not very curious

to not kill your eyes

for %i in (C:\Users\User\Documents\imf4\*.png) do cjxl -d 4.38 -s 4 --use_new_heuristics --faster_decoding=1 -I 1.4 %i %i.jxl

2

the image look natural now

not very artificial or blurred quality

ringing is visible in 29,39 43,48

of the image what you expect is lossy

lossy the aim is that not high fidelity images

What do those numbers mean?

like i tried 3 encoding those two and i had more ringing

the first of those new 2 is blocked

the second i increased I and the blocked hided in this sample

poor doggo

58,5 KB (59.999 byte)