JPEG XL

Why do you say too early to use?

all modern codecs take years to mature

Sure but mature old codecs are still worse than immature new ones, and new ones are not going to mature if everyone waits to use them until they are mature

Depends on what you're trying to achieve. For archival purposes, I'd only consider mature lossless codecs, which is why I haven't yet converted my pngs/webps over to jxls yet

Lossless jpeg xl is what needs to improve only 42 percent reduction with s 9 -e 3

and 21 minute of encoding for 6 mpx

did only single core of i3 330m

i could do with five minute a image

The maturity of codecs without their mass use is impossible, there are codecs/encoders that are 20-30 years old, but just the years of existence does not mean anything

> which is why I haven't yet converted my pngs/webps over to jxls yet I haven't done that yet only because: 1. Neither Google Photos not Samsung Gallery on Android support JXL. 2. Lots of my recent screenshots are two-layer and `cjxl` doesn't support separate Modular layers yet.

Two-layer screenshots? I didn't know that exists

How does that work?

I'm actually taking two screenshots. Here's the "desired output" screenshot:

And here's the "helper" screenshot:

encode with libjxl v0.3.7-169-g1f7445a win_x64 2021.06.26 and do -s 9 -d 1 --use_new_heuristics

is perfectly visually lossless

it gives 0.636 bpp files

you could use normal mode who has less quality and compression but more resistant to generation loss

although they aren't test for that

and jon didn't say if cloudinary has the commit newer than that

You don't know what I mean

i can't use photoshop

Sometimes I'm not as lucky because the username (marked red) and Stories' status bar (marked blue) are laid over meaningful content.

I want `cjxl` to create a difference layer (like this):

And make an overlay over the "helper" image in `kAdd` mode, thus creating multi-layered end result:

(simulated with GIMP)

Comparison on -d3 on dslr face portrait 900px: PNG>jxl3.7>jxl new It's i bit better.

JXL old:

JXL new:

Well, some ringing was eliminated, but so was part of that hair...

Any ideas for spline detection? 😉

which build

arguably hair in old is so distorted that i wouldnt say it's worse

also, you didn't post filesizes

The same comparison @d 1.5 (resolution 1440*960px) It's a great denoiser like avif 😄

Why not download the original image rather than taking a screenshot?

GIMP somehow can't import APNG animation as separate layers (it can do that with GIF and WebP).

I mean download from the image host (looks like Instagram).

Instagram app doesn't support downloading images afaik

Not in the UI, but the URL is in the page source. You can use a browser extension to download them for you.

Wait, mobile app? never used it myself.

> browsing Instagram stories from a laptop

xiaomi android browser can one clic download instagram picture 😉 But it's rarely easy to download fast an picture in a webservice. Screenshot is very often use for users. That's why recompression is very important.

Lossy-palette test (`-s 9`), then the same size with VarDCT (with new changes), but as I said the size with Lossy-palette is quite large, much larger than past comparisons and the same VarDCT results from `-d 0.4` to about `-d 0.9`, so pretty high quality 1. Source 2. Lossy-palette 3. VarDCT

For Lossy-palette there is noticeable dithering/banding in some places and for VarDCT even at this quality there are still ringing artifacts (but with a very careful comparison or zooming)

We can see "posterisation" on lossy-palette, the dct version is amazing :p

Yes, but some things can be fixed in the LP

looks like it got better in the new (but not a day-and-night difference) -- the difference seems to be bigger in anime than in photographs

Yes there are only better decision on some area, but it's visually better 🙂

We need to improve on gradients of the lossy palette. Possibly also sharp transitions are slightly pixelized -- perhaps 'gaborish' would help there 😛

downloadgram.com for downloading in instagram

or this https://ingramer.com/it/downloader/instagram/stories/

obviously i recommend 4kstogram 3.4.2

but you need to a have a crack/patch

https://discord.com/channels/794206087879852103/803645746661425173/858379219444432906 Continue this issue, How to call this situation?(artifact, blocking, ringing?)

correct.

blocking

jxl is all blocking

I only see blocking in lossy modular. In vardct I mostly see ringing.

In avif I mostly see blur, smearing and banding.

<https://github.com/libjxl/libjxl/pull/231>

Ringing artifacts are not much different overall, rather they have moved to other areas, but in my opinion the quality has become a little closer to the original with less distortion

with which ones these can be compared against

I do quotes on past comparisons at the beginning

oh.

I create a reddit post to show the upgrade since 0.3.7 It's a 400% zoom on -d 1.1 jxl 225kB, but to have the same file size on 0.3.7 i need to use -d 1.2 You need to open apng in browser. (I do the same comparison on half the size, ak -d 4, and at this quality it's not better than 0.3.7 on manga style)

significantly better tbh

❤️

In the mean time I made three more changes

at least the last one tries to address ringing in anime

https://github.com/libjxl/libjxl/pull/246

I consider it a very very small improvement, but I have more ideas...

<https://github.com/libjxl/libjxl/pull/246>

Slightly less ringing and less distorted outlines

the last girl looks better in whole image

how many butteraugli has this on -d 0.901 -s 9

scope can do a test?

just to see if it small images changed

can you just encode the image

But, I do not recommend using `-s 9`

is really -d 0.901

or are you joking

what speed is that?

`-s 9 -d 0.901`

now i can't absolutely see anything because there is night

can you send the jxl

the one you encoded

are you joking

only 6 kb

ok i will measure the butteraugli

0.9621142149 3-norm: 0.579190

how to interpret this data?

should i compress more?

is the output too many colours?

i believe if the first value is <= 1 then it is (supposed to be) visually lossless

Yes

Well 1 means you might just barely see it when flipping between the two and watching from 900 pixels distance

I built `cjxl` with the old commit before Jyrki's improvements and ran tests. The target file size is taken from `avifenc`.

```Powershell PS > avifenc 0.png 1.avif -j 4 -r f -y 444 --min 12 --max 12 -s 4; avifdec 1.avif 1.png PS > (ls 1.avif).Length 57875 PS > .\cjxl_4a4782e 0.png 2.jxl -e 8 --epf=3 --target_size=57875; djxl 2.jxl 2.png Encoding [VarDCT, d1.298, kitten], 4 threads. Compressed to 57950 bytes (0.615 bpp). PS > cjxl 0.png 3.jxl -e 8 --epf=3 --target_size=57875; djxl 3.jxl 3.png Encoding [VarDCT, d1.201, kitten], 4 threads. Compressed to 57764 bytes (0.613 bpp). PS > butteraugli 0.png 1.png; butteraugli 0.png 2.png; butteraugli 0.png 3.png 2.1854407787 3-norm: 0.612597 1.4679248333 3-norm: 0.601586 1.4060662985 3-norm: 0.580481 PS > ssimulacra 0.png 1.png; ssimulacra 0.png 2.png; ssimulacra 0.png 3.png 0.00605603 0.01000992 0.00989381 ```

Enlarged crop from original PNG

from AVIF

from JXL before improvements

from JXL with last commit

Dark area anime image test, avif look like image still look good, but some background detail is lost. jxl also look good, and can keep more background detail. // not latest libjxl commits > jpeg q92 444 142KB to avif q15 444 50.9KB, > avifenc --min 0 --max 63 -d 10 -s 4 -j 12 -a end-usage=q -a cq-level=15 -a color:aq-mode=1 -a color:enable-chroma-deltaq=1 -a color:enable-dnl-denoising=0 -a color:denoise-noise-level=5 // not latest libavif commits > jpeg q92 444 142KB to jxl d1.0 51.1KB, > cjxl -j -d 1.0 -s 8

original

avif-q15

jxl-d1.0

what are exact file sizes

50.9KB for avif and 51.1KB for jxl if im reading them right

tbh i usually take screenshots w png

which version/commit of jxl? theres been quite a bit of changes for anime kind of stuff lately

jxl preserves background grain better, but has much more ringing around black lines on red dress

> libjxl 17fc76048a9bf237513c8a01bcdd952b2cdf823d > libavif Version: 0.9.0 (aom [enc/dec]:3.1.0-13-g3bd281799)

not latest libjxl commits

it would be interesting to test with up to date encoder. there's been a lot of ringing-related changes after that commit

ill try encoding it

56K (53563)

Kate Shadow is so cute 😛

hmm it ended up bigger

either that or we are using different K units

could you give exact byte counts for your images, K is a bit confusing. but looks a bit bigger either way

KB = kilobyte = 1000 byte KiB = kibibyte = 1024 byte

I don't know in what world 53563 bytes can be 56 K though

except that K is often done with 1024 bytes anyway...

wait did `du -sh` report disk allocated size..?

``` --apparent-size print apparent sizes, rather than disk usage; although the apparent size is usually smaller, it may be larger due to holes in ('sparse') files, internal fragmentation, indirect blocks, and the like ``` ughh why do they make everything complicated

53K

// not latest libjxl commits > jxl 52,371 // not latest libavif commits > avif 52,213

yeah so a bit bigger. thx

and i also don't really see much improvement in ringing :<

maybe my stuff for viewing is not precise enough or im expecting too much

I think probably have more vardct imporve for anime in next few week.🙂

Which quality you have visual ringing? -d 1.2 have near zero ringing. The picture with red girl is a jpg with so many ringing ...

I'm comparing both my and lee's encode against original

and I see more noise around black lines in both of them than in original

arguably, original shouldve been png and it would be more fair comparision then, as I suspect original has a bit of noise there too and re-encoding makes it worse

i'll send a deblocked image

here's you wasted space only on visual blocking

basically you sent a super blocked image

try to compress the deblocked one

i'll decode to png with jxl

here's the image

raysar we know it loses quality the same

Test with a manga picture without artifact, or a picture with a real noise.

but at least the source is better in this way

though 80% blocking i would delete this image

not giving any space in my disk

if you focus on the roses on the head you can still see blocking on my image

59222

not my source, it's Lee's

test with your favorite pictures, or i can send you pictures if you want.

d 1.0 has too much blurring

the deblocked i did with that s 1 and old encoder

is more truthful

green red brown

I was just curious to expand a bit on Lee's benchmark so yeah. I'm way too lazy to do full testing against avif as I have no clue about usage of its options, and I'm way too lazy to compare jxl revisions as I use aur package

look at the colors

but the image is bad point

Ok, it's just than avif is a denoiser, so encoding a ringing jpg in avif will enhence the file XD

i'd say the blocked i did is acceptable

but not the best you can do with 54 kb

indeed lol

it need a better png

pngs i have are more fitting for lossless encoding tbh. should i try anyway?

or should i just downsize some super resolution jpegs and consider them suitable at that point idk idk

To be honestly, It's hard request every source image is lossless png... this sample from japanese official site. > https://shadowshouse-anime.com/story/?id=01

yeah but screenshots should be .png if you want to use them for benchmarking later

the d 1 is not bad

what encoder it was

i see ringing in her shirt

up-to-date cjxl

but i think that noise was because jpeg was a bit noisy there and jxl re-encoding made it worse i already said all of this plz keep context in ur head

Example on an other dark picture, defauld jxl -d 1

original

I believe jxl can make better quality on contrast sharp edges(black sharp lines) and smooth have gradient area.

Yes it's good on very high contrast with modular encoding 😄

this worsened with deblocking

plz upload jxl->png too for comparision reasons

i think is a png

chrome read jxl you only need to open it ...

I don't use chrome

and it'd result in download first anyway

because I think discord wont recognize it as image and wont set mime right

jxl -d 1

in this case the deblocked image looks bad because the original source is a q 100 image

in lossless png

or is a jpg either?

i expected better from jxl

image look similar

not too added details

do s9 please when encoding

keep in mind that i encoded with s 1

proof

> avifenc --min 0 --max 63 -d 10 -s 4 -j 12 -a end-usage=q -a cq-level=15 -a color:aq-mode=1 -a color:enable-chroma-deltaq=1 -a color:enable-dnl-denoising=0 -a color:denoise-noise-level=5 uhh is that anime-optimized avifenc settings or what

lossy modular Q95 can get good quality, but sometime can't get better file size, I think vardct also can make it, just need wait some quality improve.

can you add some avif

at lower file sizes

i know avif way too little to benchmark against it if it needs that many flags

maybe you could use libjxl v0.3.7-171-gc12aec2 win_x64 2021.06.28

for %i in (C:\Users\User\Documents\deblocking5\*.png) do cjxldeblocking -I 0.881 -s 1 -q 91.732 --gaborish=0 --use_new_heuristics %i %i.jxl

exact command

i did not use target size

it just setted the size you choose

only casual, it happened for no reason.

yea totally looks like casual clear and developper-endorsed flags right here /s

deblocking isn't a new command

is that i renamed cjxl

because i need to copy newer builds

i test only at s 9 -d 1

An picture with very sharp edge original:

jxl -d 1 (458ko)

jxl -d2 (300ko) ringing is very low, look at the scale.

which build raysar

s 1 encoded

what size did you have

jxl -d 3 (225 ko) it's half the size of d1 and it's amazing the ringing is very low !

I think some quality issue is happen on non-photographic image, I didn't test photographic image, but I think for current jxl have stable quality on photographic image.

yes you wright but on lossless modular file size is very low size on "powerpoint" style image 😄

raysar which build

and which speed

Agree, basically if image have less color and structure simple, without dct probably a best method.

whether i try on my images with -d 1 it looks just ok idgi

ah nvm haven't zoomed on this one

^ orig

^ jxl `-d 1` 169910 bytes

wait source is messed up even tho its .png aaaaaaaaa

we need "lossless certified" or something for images, formats alone don't do justice

i tried a settings

for %i in (C:\Users\User\Documents\deblocking7\*.png) do cjxl -q 33.983 -s 8 -p -I 1 --use_new_heuristics %i %i.jxl

libjxl v0.3.7-184-g67fa874 win_x64 2021.06.30

basically i tried the max i could try

"new heuristics"

new heuristic pro

Perro

Source image lossless is great, but I think in real scenario, some image probably only have lossy source.

what do you think

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

Use lossless jpeg compression?

lossless jpeg compression is great, but can't compress too much, for jpeg q90+ 444 image I guess use d1.0~0.5 probably still can get stable quality?

tfw still searching and cannot find truly lossless image where `-d 1` would make any visible artifacts

maybe my downloads folder is not diverse enough

should try my animu screenshots or something maybe

Yes that's why jxl dev are genius and create jpeg recompression for 20% file size reduction 😍 And in real life visual recompression of jpeg is good in jxl, there is only even more artifacts and smoother noise. Jpeg 90% quality (pretty huge file size) is a HUGE problem, they have ALSO HORRIBLE ringing everywhere !

i mean if i zoom in 200% I can see stuff but otherwise it's really hard to find anything

other jpeg lossless recompression implement > lepton and packjpg

every lossy codecs have their own artifacts. You can't just expect good quality without removing those artifacts.

Or you could do like this. Open the jpg, save it on lower quality and use jxl's lossless jpeg recompression mode.

Look at here an horrible internet jpeg file 491 ko

-d 2.3 (0.15bpp!) 70% file size reduction and it keep a good visual quality, only noise and artifact noise is removed.

Lossless recompression is 33% file size reduction !

I understand jpg to jxl still a lossy way, so I just expect d 1.0 can keep good quality and include all jpg artifacts or lossy error. Some CDN service will lossy recompress jpg file to other format, so I guess high quality(q90~95) jpg lossy compress to jxl(d1.0~0.5) is acceptable? Use jpg lossy recompress is a good idea? I not sure. > jpg q92 444 (ycbcr, dct 8x8)=> jpg q90 444 => lossless jpg jxl > jpg q92 444 (XYB, vardct)=> jxl d1.0 s8

there is no jxl encoder that can reduce more than 42% in lossless -s 9 -E 3 -q 100

Example on infographic image: varDCT suck against lossless modular Original PNG 307 kB -s 9 (and -s 9 -E 3) modular 89.9 kB

The lower varDCT -d 16 (with target_size) = 102 kB ! (0.08bpp) But you can see there is NO ringing on text ! It's AMAZING !

cjxl patches function probably very useful for this case(text content).

You wright with patches=0 there are artefacts.

With modular and patches=0 file size increase to 112 kB, it's good too.

I'm sure, with PNG encoder need to encode image in modular when we use -s 10 (for example) in varDCT mode and encoder takes the lower size automaticaly. People don't want to think about using modular for specific file ...

I want -s 11 !

Another warning need to refuse encoding output file if it's bigger than the original file. If this file is in my batch encoding (-d 1) jxl is bigger than the png and lossy :/

Agree, Hope cjxl can use better heuristic choose right method.

Bruteforce for now is a good initial solution ^^ for -s 10 :p

why s11? s10 does not exist now

speed Sloth 🙂

gotta turn it up to eleven

-s glacier and -s tectonic_plate have been suggested at some point for -e 10 and 11

I still like amoeba.

I like sponge

Isn't sloth slower than tortoise? If it is, then it should be assigned to speed 10 IMHO

what about snails

slightly slower

Leech

can't they actually swim pretty fast

Let's not use yucky animals

yucky is subjective

so are animal names though

i personally think that snails and leeches are p cool

evidence for snails in popular culture:

alternative for French speakers

the presenter mentions a previous record of “3 weeks, 27 days and 6 hours” (yeah, that’s three more weeks) for a distance of 18" (US) / 40 cm (FR)

libjxl-7896a7e

use -d 1 -s 9

can you send source image

needs exact file sizes

avif is ringing more

the hair looiks totally ringing

without file sizes we can't know

based on my test it reduces file size by 30% without anyone noticing anything

very less distorsion, good noise redistribution

photo can look like they were shoot on galaxy s4 so it worsen image

avif focuses more on appeal, hiding ringing as much as possible in parts of image, blocking is less visible, but jxl is not bad

just not ready for general use

i'm 286 of 1043 encoded 1080x1080 images

> original-full 682,462 > libjxl-d0.5-s8 118,341 > libavif-q7-s4 110,672 > libavif-q7-s3 108,708

I understand compare encoder exact file size is very important, but according to jxl distance design intention, d0.5 and d1.0 should output stable(not look so bad) quality image?

i understand you want -d 0.88 at -s 8 and still good looking images

you don't want compromises

i don't think this image should look bad at -d 0.767 -s 9

with the build you said

send the source image

libjxl-7896a7e, original_cut

-d 0.5 -s 7 looks a good in this

or do -q 71.095 --faster_decoding=3 --use_new_heuristics -s 9 -I 0.4

if you want less precision and more oblique faces

I don't want use lower quality distance, I favor d1.0, d0.8(q90, q92) and d0.5(q95).

then you should wait improvements of heuristics

for anime is not great you're right

i see a lot wi horizontal lines and slightly artifacts, heavy ringing

perceived quality is like 73.518 73.185 of old jpeg

i don't know if old jpeg can be so specific

i guess is not the latest heuristics

SO YOU CAN'T LIKE IT

No, I don't think avif is winner, avif just get little little bit quality advantage for this content, I believe jxl can make better quality. 🙂

jxl needs a 12,6% improvement just be transparent at q 81.576 -s 4 --use_new_heuristics

https://twitter.com/jonsneyers/status/1410921825077501954?s=19

another thing i don't agree is aggressively aiming for example a 30% reduction

because of not understanding which bitrate is best for the encoder

i posted an article in coverage is basically what i wrote today

people take the 30% number for guaranteed

honestly i don't care about more sharpness and lose of quality, about more compression, about more transparency, that's too early to judge

Getting predictable/reliable results in the range of fidelity targets that matters, that's imo the most important thing. I think in the -q 60 to -q 95 range, cjxl does that — maybe for 'ligne claire' some more work is needed, but roughly speaking, you know that -q 90 should be safe for most images, -q 80 should be OK, etc.

with avifenc, cwebp, and cjpeg you don't have that: sometimes cjpeg -q 80 is perfect, sometimes it is artifacted.

with avifenc it's really hard to know what settings will give a good result on an image

for jpeg, many programs have a "save" dialog that lets you control a slider and see what happens to the image so you can adjust the slider to your taste. It is unfortunate that this is needed, but it kind of works.

with avif that will not work though, encoding is too slow to make such a slider usable

even though it's probably more needed, because while you can go to lower sizes, you really need to check what the encoder is doing

with jxl you just don't need the slider, you can just set it and forget it

I using libjxl -d 1.0 or -d 0.5 file size to find a reasonable libavif -cq-level=N. 🙂

https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_07_01/index.html#clovisfest*3:1&JXL=l&JXL=l&subset1

is the latest comparison from webp team

https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#clovisfest*3:1&JXL=l&JXL=l&subset1

a month ago, before the acs tree reversal

we have some improvement in this comparison, too

if someone observes significant degradations from 2021-06-08 to 2021-07-01, I'd like to learn about it and how to see it

To me it looks worse in every image

lots of ringing in high frequency details

sloth is not considered a careful animal -- it has many things living in its fur -- let's not call our best compression options 'sloth'

is because you are lefting alien artifacts

even on big the artifacts are annoyign

i wouldn't go any higher than

-q 71.095 --faster_decoding=3 --use_new_heuristics -s 9 -I 0.4

could you find the image where that is most easily visible

with libjxl v0.3.7-192-g7896a7e

and give zooms or similar to show what you mean

i looked only at clovisfest

which bitrates did you focus on?

mostly large is annoying

0.48 bpp

this is -q 71.095 --faster_decoding=3 --use_new_heuristics -s 9 -I 0.4

less areas

so bigger noise

and more pixelization

now that i looked at the one with custom settings large looks good to me

it depends how you look at it

i see issues with small

I like median better than what you showed

significantly better, muchos muchos less ringing

so you prefer medium 31.9 kb

compared to the settings i use

yes, better than the settings you showed

and if I comprare 8.6. vs. 1.7., 1.7 looks much better

i don't hav a good screen

not day and night, but substantially less ringing

the gui allows you to 3x zoom

then you can move back 3x to compensate for it

yes i see way more sharpness in xnview

probably more than jpeg normal heuristic limits

probably is bad

but better at wasting 80 kb or q 90 especially with low resolution photo

i should retry lossless jpg transcode

<https://github.com/libjxl/libjxl/pull/262>

In some areas a little better, some I'm not sure (ringing artifacts may appear in other areas and sometimes there may be more blurring)

To anyone using VMAF as a still image metric, this is what Netflix (who made the metric in the first place) said about that: > VMAF, as of today, is a metric trained and developed to judge encoded videos rather than static images. The range of distortions associated with the range of image codecs in our tests is broader than what was considered in the VMAF development process and to that end, it may not be an accurate measure of image quality for those codecs. Further, today’s VMAF model is not designed to capture chroma artifacts and hence would be unable to distinguish between 420 and 444 subsampling, for instance, apart from other chroma artifacts (this is also true of some other measures we’ve used, but given the lack of alternatives, we’ve leaned on the side of using the most well tested and documented image quality metrics). This is not to say that VMAF is grossly inaccurate for image quality, but to say that we would not use it in our evaluation of image compression algorithms with such a wide diversity of codecs at this time. (source: https://netflixtechblog.com/avif-for-next-generation-image-coding-b1d75675fe4)

However, their framework can calculate VMAF and its documentation is often referred to as an example of a metric that can be used <https://github.com/Netflix/image_compression_comparison>

I completely agree with "we would not use it in our evaluation of image compression algorithms with such a wide diversity of codecs"

I don't trust any metric, but at least DSSIM, SSIMULACRA and Butteraugli are actually looking at all the color and in a perceptually relevant color space.

We need better metrics though

And exactly DSSIM, SSIMULACRA and Butteraugli are not in their framework and I even asked to add them a long time ago: <https://github.com/Netflix/image_compression_comparison/issues/2>

Maybe we need to create an image metric using neural network tuned by eye of thousands of humans 😄 I see this cool paper about neural network metric 😄

this is the boss of JPEG AND JPEG XL

who wrote that

tourij ebrahim

read first page

http://compression.cc/leaderboard/perceptual/test/

PSNR accuracy: 0.507

What's the accuracy of coin tossing here? 0.5?

Yes, accuracy is just correctly predicted pairs / total pairs, and the choice is binary, A > B or A < B

So PSNR is slightly better than coin tossing

50.7% correct instead of 50%

Likely not even statistically significant

orig

before PR 273

after

``` sizes: 76712 54764555_p0.png.new.jxl 76886 54764555_p0.png.old.jxl ```

so new is both smaller and visually better

it's `-d 2 -e 8` for both of these encodes

i dont know exact version of old encodes but it's like day old

(I really should write some scripts or something like that to fetch exact commits and build encoder for these, so I can be sure that it's not some other commits doing that)

THANKS for this useful comparison.

old version is actually 2 days old, and had revision r189 and commit g653358d

so it does include Don't favor 4x4 locality in visual masking (#262) merge too

(i mean old version didn't have that, and this comparision ends up evaluating multiple improvements)

ill try building just one commit before locally, since this wasn't exactly really clean benchmark

c8b0bf3, 76765 bytes

this is one commit before `Less ringing, more fidelity through 'info loss'`

changes are much more subtle

but still quite visible in few areas

so yeah basically it's improving :--DDD

in _some_ places it's a little bit worse though

like in both versions there's artifact, but it's different and incidentally it somehow gets less noticeable in old one, but there are more good ones than bad

old2 ver

new ver

but yeah in general there are more improvements than downsides

and in more reasonable (for anime content) than `-d 2` levels it shouldn't be visible, there would just be improvement in general, and maybe reduced file size too

I'm only testing -e 7 in my work, thank you for checking with -e 8

I measured only a 0.006 % improvement in filesize in my testing

but 2.5 % improvement in max error

and I observed a fidelity improvement of complex textures

in 273

(and less locations of anime drawings ringing, but often in different places)

all such analysis requires a lot of subtlety -- I'm amazed that we agree about the results

are there any Genshin Impact players here (in the anime fans)?

i tried it on my phone but got bored after a bit, can't into games much nowadays

I like the music in it 😄

I played quite a lot and I'm at AR 54 now

i remember music being pretty nice, yeah

im just bad at keeping my attention unless game really hits my spots. yume nikki (old version, haven't tried new 3d thing) was awesome

I haven't play Genshin Impact, but I like game soundtrack 🙂 , > https://www.youtube.com/watch?v=h_wb3LfOMw4 > https://www.youtube.com/watch?v=-LZxk09LNaM And I also like war of warcraft soundtrack, > https://www.youtube.com/watch?v=UuSON351IyY

I will play it after few months. Currently I'm playing - sky: children of the light.

these ost vids are great

my daughter plays sky a lot

I like the atmosphere in the sky game

it feels more 'spiritual' or elegant than most games

Yeah.

she is just five, but she makes friends all around the planet and she is excited that they keep her hand when showing the game world

my UID in Genshin Impact is 716656652 if someone wants to connect

I'm a war of warcraft player before, but for now only game soundtrack can attract me.

I never tried WoW, I considered it too addictive 😄

I played nethack 2.3e

perhaps this is getting offtopicy ...