JPEG XL

I tried encoding an anime image with has many complex features (noise ) Avif looks smooth/less detailed even with --max 5 --min 5 but file size is very small compared to jxl.

Maybe add some parameter can get better result? > // from blue > avifenc --min 0 --max 15 --minalpha 0 --maxalpha 0 -d 10 -s 4 -j 12 -a end-usage=q -a cq-level=15 -a color:enable-dnl-denoising=0 -a color:denoise-noise-level=5 -a color:sharpness=2 -a color:qm-min=0

I will check it tomorrow

I change some parameter from blue version. > // original blue version > https://discord.com/channels/794206087879852103/794206170445119489/873604405491019786

Yes, jxl for keep grain and detail is very well, I really hope I can use jxl on my drawing content, but for now I still can't get great quality flat areas from jxl.😢

Color is Not perfect and contrast

Butter sacrificies that it only look for details

Also in cjxl we dont have deringing

Save in lossless

Lossless is great, but I want high quality lossy(near-lossless).

What is the min quality of jxl visually lossless for you?

Yeah. This looks good

Default avif aom encoding is bad

I used this image https://www.pixiv.net/en/artworks/77033762

For now I need jxl -d 0.1~0.3 -e 8~9 to reach visually lossless for specific drawing image, I hope jxl -d 0.5 -e 8~9 can reach visually lossless for any drawing image, jxl -d 0.8~1.0 -e 8~9 I hope on this distance, I can get still look good quality, lost some detail is fine, I using webp near-lossless 40 and 60 compare jxl d 1.0 and 0.5 quality.

Avif looks very good with this setting. It's visually lossless even on noisy artworks. I can even see some extra grain than original image when zoomed at 500% lol.

Jxl will always sacrifice something

Jxl is good for photographs and avif is good for artworks.

I heard extra grain issue before, but I haven't find issue sample, Could you share more information about this issue? That extra grain issue is very notable? extra grain will let drawing look really bad?

For RGB content ycocg it might help. > --cicp 2/2/8 And for dark area. > -a color:aq-mode=1

I really hope jxl can get good quality for artworks.😢

No. It doesn't look bad. Extra grain is not visible on normal viewing distance.

Extra grain looks bad on using --min 0 --max 63. I am using --min 0 --max 5 But file size bigger than jxl. On --max 15 loss of noise detail.

<@461421345302118401> https://wallhaven.cc/w/r71m9q

<@!263309374775230465> Thank you for your help 🙂, I think avif is strong but not easy to use for image contents... Hope Jyrki Alakuijala can bring some good news for drawing contents.

<https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_08_10/index.html>

[initially posted on AV1 server by mistake, haha] Wow! I think the progress of JXL at lowest bitrates is very noticable! Where was this comparison that allowed one to compare different releases in this same interface? [EDIT: answered there by Scope: https://eclipseo.github.io/image-comparison-web/]

And the author's even here! <@493871605408071681>, time to make 0.5.0 I guess? 😉

Yep, also Shift is now broken in Chrome (after the latest slider changes)

> I think the progress of JXL at lowest bitrates is very noticable! Oh, I know what gave me this impression. `Tiny` got bitrate bump in newest version compared to previous… (I agree the new higher value may be more realistic, but there goes my initial excitement…). Makes comparisons between versions harder too.

Old > Methodology > Large images were first encoded with BPG at q24 filesizes. Medium is 60% of Large. Small is 60% of Medium. Tiny is 60% of Small. All other codecs were matched to +/- 5% filesize. New > Methodology > Large images were first encoded with Mozjpeg at q85 filesizes. Big is 125% of Large. Medium is 60% of Large. Small is 60% of Medium. Tiny is 60% of Small. Everything else was matched to +/- 5% filesize.

I tested this drawing image on jxl -d 0.5 -e 8, > https://wallhaven.cc/w/r71m9q jxl really powerful for complex structure and simulate real style drawing, but for now when drawing content have some flat areas, jxl can't work very well. Jyrki Alakuijala mention smooth areas and visual masking have some problem for current jxl. > https://encode.su/threads/3397-JPEG-XL-vs-AVIF?p=69868&viewfull=1#post69868

not sure i will do another so soon as it was done very close to the 0.5 release

<@!493871605408071681> https://discord.com/channels/794206087879852103/803645746661425173/875034356098433086

How so?

It like switches once and doesn't work anymore

On all chromium-based browsers on Windows

I can't reproduce on Chromium or Vivalde

I will be trying on a Windows when i have access to one

Strange, I tested it on Edge, Chrome, Opera and some others and it's the same, but FF works fine

does the size info change when you press shift?

Only bpp is shifted a bit

if you use the same codec both side this won't work

does the info text change with different codec?

Yep

can you tell me if there is an error message in the console when you shift switch?

```splitimage2.js:96 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'getAttribute') at getSelValue (splitimage2.js:96) at setFile (splitimage2.js:239) at splitimage2.js:459```

the message repeat when you switch?

No

that is weird

whats your chrome version?

Dev 94.0.4603.0 But if this happens only in my browsers, perhaps some scripts are blocked (although I have tried disabling all plug-ins and extensions) Also, the previous version worked fine

the script is not blocked, the images load, but somehow the size of the canvas or opacity is not changed

does it happens also on Chrome stable browser?

if you escape switch mode, does the moving split works?

Yes, as and when I switch to another image, but once, stable I will check

Hmm, stable Chrome works, so it's something on my side or something happened in this Dev version <:Thonk:805904896879493180>

damn 😩

i'm grabbing a chrome canary to see what's happening in the debugger

<@!493871605408071681> So perhaps everything is fine on stable versions, btw, I also had a suggestion to add a set of some art or UI images, though we need to find some free to use

With large flat color areas and clear lines

I tested Chrome Version 94.0.4603.0 (Official Build) dev (64-bit) and it works too?

I'd like too but I don't know where to find some with a CC license, also I already at max capacity on Github

It's the same on my version, but maybe it's only a problem on my side Also maybe do WebP and AVIF as real images instead of PNGs to reduce the size (although this might be a problem for Safari for AVIF)

Avif needs bigger file size to retain grain compared to jxl no matter how your tune encoder parameters

Could you try on a fresh profile wiyj no custom config?

I think sometimes people don't see the subtle change in the background. I notice JXL isn't always the best on the main focus of thr image but is better at keeping texture details on backgroud elements

You can perhaps host the images on a free Cloudinary account (or somewhere else)? Btw you can also use Cloudinary conversion to see what the Aurora avif encoder does

I tried it, but maybe it's not completely fresh, and I also tried Incognito mode, since it also disables extensions

I use to do that but I changed to PNG to avoid problems with color profile detection on various browser

I'll look into Google Cloud storage or DigitalOcean

Also on pixel art or drawing, sometimes lossless is more efficient than lossy but I don't know how to select the best options on a pr image basis

I think av1 is a good video encoder, but for still image jxl is better, so I really look forward jxl can fix flat areas weak point. 🙂

Yes for video good enough

Yes, but often needs much more compression than lossless, especially if the images are quite complex also with sharp lines and flat areas And for comparison I think 2-3 such images will be enough

For example: https://www.deviantart.com/kaiseto/art/With-a-Staff-I-Guess-136421766 On default lossy, it weight 65KB, on lossless only 16KB. How does the layman will know when lossless is a better choice than lossy? this is not easy to tell

Yep, but not lossy pixel art, btw JXL also needs improvement in pixel art compression in lossless mode

lossy compression being worse than lossless in cases is a problem in some cases, but in general for pixel art i dont think you should be using lossy compression anyways

the fun of dual formats

I'm revisiting GitLab issues and here's one that might be related to the problem: https://gitlab.com/wg1/jpeg-xl/-/issues/188

I don't know exactly how `cjxl` works, but it could count colors in an image **regardless of the mode** and if there's more than *threshold* (1024 by default), abort color counting immediately and switch to VarDCT like if nothing happened. But if there are less colors than that in the whole image (or just the testing area, like e.g. first row of pixels, depends on the color counting algorithm's implementation), try lossless Modular encoding first.

That's another question... how is color counting performed in Modular? Does it do O(n^2) sweep through the whole image? Is there any premature aborting if it detects threshold overshoot earlier?

Counting colors is a bit expensive to do

Yes, modular palette transforms abort as soon as there are too many colors

As a heuristic, on a limited number of pixels (aka "testing area")? I don't think so... 🤔

There's still room to make it faster though, current encoder uses std::set on std::vector (so it works for arbitrary number of channels) to do the counting, so that's probably not very optimal, lol

We could certainly add some heuristics to detect cases where lossless is likely better, and at slow enough speeds try both lossy and lossless

I'm already thinking about edge cases (e.g. be cautious around 100% white pixels because that could mean either some art background, a document or clipped sky in a photo)

well if you only check if lossless is better than lossy and not the opposite way around then that shouldnt be a problem right?

It's mostly a matter of speed - you don't want to waste a lot of time trying a high-effort lossless to then discard it because lossy was smaller after all.

You can try both lossy and lossless on the very slowest speed (or on other speeds by using a new `cjxl` switch), but medium speeds could probably use some sort of neural network to quickly detect the best settings, like the one used in Opus to switch between music and speech coding? https://jmvalin.ca/opus/opus-1.3/

If jxl have some heuristic to switch between photography(steep) and drawing(flat) coding, that will be very useful.

It'd have to switch not only between VarDCT and lossless Modular, but also lossy Modular.

And detect if patches/dots option is usefull or not 😄

There are many choices 😄

That'd be a lot harder

As if VarDCT / lossless Modular / lossy Modular heuristics already weren't hard

BRUTEFORCE rule them all ! 😆

Veluca is working on improving patches, so they will be better (someday)

I guess pull requests 403 also work in process, maybe we can get better drawing quality on next quality improvement. 🙂 > https://github.com/libjxl/libjxl/pull/403

I think after 19082021 it will change more

https://github.com/libjxl/libjxl/pull/434 I'm not so convinced...

This commits also can fix some vardct file size inflate issue?

Did some tests, but no time yet to code the whole set, so it mostly helped where the patches worked worse, but there are exceptions

Examples where the new build equals `--patches=0` and it helps: https://i.imgur.com/H98sH.png

https://i.redd.it/ixnqw29s2li31.png

https://i.redd.it/w5fls6lwpcp31.png

https://i.redd.it/zdyvupnbeam41.png

<@!179701849576833024> But: ```111 086 - s9 E3 I1 (master build) 111 086 - s9 E3 I1 (improved patches) 109 413 - s9 E3 I1 patches=0``` https://files.catbox.moe/kkug21.png

- ```658 553 - s9 E3 I1 (master build) 645 747 - s9 E3 I1 (improved patches) 594 170 - s9 E3 I1 patches=0``` https://i.redd.it/ps0qma6rixf41.png

- ```489 632 - s9 E3 I1 (master build) 489 854 - s9 E3 I1 (improved patches) 474 441 - s9 E3 I1 patches=0``` https://i.redd.it/x58a481h2xe31.png

We'll see on 19082021 how it evolves

So far so good

- ```82 458 - s9 E3 I1 (master build) 77 061 - s9 E3 I1 (improved patches) 68 592 - s9 E3 I1 patches=0``` https://i.redd.it/xmtoihicvlj41.png

Good at high distance

Maybe use this for high distance

Better than expected

Maybe delete i1

Is lossless or lossy

<@111445179587624960>

Is it exception pictures where patches is not good? Or it's common?

That's all I've found so far where the patches have been worse

Scope is lossy or lossless

Lossless

●<:Poggers:805392625934663710>

So it's rare in lossless mode?

With improved patches, yes But here, for example, the size is larger after the changes https://discord.com/channels/794206087879852103/803645746661425173/875409538457669682

yeah, I guess the question is whether overall it helps more than it hurts 😄

<@!179701849576833024> But, it's VarDCT

Good

I want a build

Color are amazing

that's an interesting result xD

mhhh, this one I'm pretty sure is a bad idea 😄

What distance is it

Last image

Seems like d10

<@111445179587624960>

It looks detailed on my samsung galaxy s4

Can you also Say file sizes and send a build

I think I have some constants I can tweak for this, I'll try and see what happens

This is a "debug" image to see how the patches work, it is not intended for normal encoding, there is no difference between the builds except for the patches

Distance and file size on Last image

These are the default settings, I have not changed anything for the encoding

S 7 d 1?

Yes

File sizes versus lossy with old patches

In Last image

Vs png

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

I want the lossy file size

Not lossless

Scope

Send s 7 d1 s7 d1 new and png

I want to view latest image

In my image viewer

Jxl file please

I don't know, I deleted images after encoding because it doesn't matter, I just needed to know how the patches work, on this image we have to wait for improved patches

So was it smaller

Like 10% less

I compared only lossless, if the patches will be improved it will also affect lossy, that's why I search and show "bad" examples

Scope Thank you for your work 🙂

https://i.imgur.com/UL1fXgB.png

Not all are detected as patches, but perhaps because the letters are not exactly the same (and the new changes don't make it worse or better)

that one is worth investigating

my bet would be the "is this a flat area" heuristic

I updated the code, would you be willing to give it another go? 😄

> perhaps because the letters are not exactly the same Nope, they're the same. I've just made a quick check in GIMP, with "Difference" layer mode.

It's monospace font, the subpixel rendering pattern should be consistent across the whole screen.

```enc_patch_dictionary.cc:316:1: error: version control conflict marker in file <<<<<<< HEAD ^ 1 error generated.``` I'll try to re-download 🤔

Yep, but sometimes the image may not be completely lossless with some distortions

so there are ways to change the parameters of the heuristic to detect ~all the patches there, but I suspect it horribly breaks other images then xD (or even the same image in a different mode...) `jxl:m 52873`

those heuristics definitely need a good old rewrite xD

```diff diff --git a/lib/jxl/enc_patch_dictionary.cc b/lib/jxl/enc_patch_dictionary.cc index 035b842e..d5de772e 100644 --- a/lib/jxl/enc_patch_dictionary.cc +++ b/lib/jxl/enc_patch_dictionary.cc @@ -208,7 +208,7 @@ std::vector<PatchInfo> FindTextLikePatches( if (state->cparams.patches == Override::kOff) return {}; PatchColorspaceInfo pci(is_xyb); - float kSimilarThreshold = 0.8f; + float kSimilarThreshold = 5.0f; auto is_similar_impl = [&pci](std::pair<uint32_t, uint32_t> p1, std::pair<uint32_t, uint32_t> p2, @@ -346,7 +346,7 @@ std::vector<PatchInfo> FindTextLikePatches( ZeroFillImage(&is_background); Image3F background(opsin.xsize(), opsin.ysize()); ZeroFillImage(&background); - constexpr size_t kDistanceLimit = 50; + constexpr size_t kDistanceLimit = 1000; float* JXL_RESTRICT background_rows[3] = { background.PlaneRow(0, 0), background.PlaneRow(1, 0), @@ -378,8 +378,8 @@ std::vector<PatchInfo> FindTextLikePatches( background_rows[c][cur.second * background_stride + cur.first] = opsin_rows[c][src.second * opsin_stride + src.first]; } - for (int dx = -kSearchRadius; dx <= kSearchRadius; dx++) { - for (int dy = -kSearchRadius; dy <= kSearchRadius; dy++) { + for (int dx = -4; dx <= 4; dx++) { + for (int dy = -4; dy <= 4; dy++) { if (dx == 0 && dy == 0) continue; int next_first = cur.first + dx; int next_second = cur.second + dy; ``` this works in lossless mode on this image (and likely on this image only)

I know, ClearType is a bitch. But in *this* particular case that's not the issue, fortunately.

Same

Same

69 726

ah nice 😄

<@!179701849576833024> So, there are still some patches/dots(?) left, also not sure if they are effective

You can change \`\`\` to \`\`\`diff to enable syntax highlighting for diffs 🙂

I didn't know, thanks 😄

likely they aren't, but I'm afraid I'll end up turning them off in too many places if I try to get rid of them

and I consider the reduction large enough as it is

hopefully this didn't end up disabling patches in places where they're important...

Yep, and the overall result is pretty good on this image (not that much difference vs the disabled patches)

There's a bunch of syntax highlighting (for C and C++ too), Discord uses Markdown 🙂

What about this image with Luca's patch? I'm really curious, literally the whole image can be <:JXL:805850130203934781>-patched...

not going to change

I thought this was the size https://discord.com/channels/794206087879852103/803645746661425173/875440300355633184

unless you apply the patch in the message manually and use lossless - in that case you do get something

yep

it's about 33% the size without the patch

```2 412 - s9 E3 I1 (master build) 2 639 - s9 E3 I1 (improved patches) 2 639 - s9 E3 I1 patches=0```

<:PepeOK:805388754545934396> ``` 9 214 - s9 E3 I1 (master build) 8 979 - s9 E3 I1 (improved patches) 10 071 - s9 E3 I1 patches=0```

- ```36 887 - s9 E3 I1 (master build) 36 305 - s9 E3 I1 (improved patches) 28 728 - s9 E3 I1 patches=0```

- ```11 895 - s9 E3 I1 (master build) 10 124 - s9 E3 I1 (improved patches) 9 631 - s9 E3 I1 patches=0```

ahhhh, dithering patterns... there's one way to fix it which will likely make other things even worse 😛 (also -- what happens at -s 7)

<:PepeOK:805388754545934396> ```957 114 - s9 E3 I1 (master build) 955 418 - s9 E3 I1 (improved patches) 977 919 - s9 E3 I1 patches=0```

46 793

I mean before/after 🙂

Lossless Speed 7 before patch changes and after? Also VarDCT

yup

```47 501 - s7 (master build) 46 793 - s7 (improved patches)```

ok, thought so

and no patches?

`432 451` 🤔

hah

I guess our lossless mode with no lz77 really doesn't like dithering

(by the way, if you have a `benchmark_xl` somewhere, you can get more info on patches by passing a `--debug_image_dir` option)

Ah, no, something unwanted got into the options, the real size: `40 068`

ah 😦 oh well

But, overall, these changes mostly do better than worse

However, for something like pixel art it would be nice to have a mode similar to WebP and maybe with a larger default group size and probably without patches at all

ehhh, later 😄

improvements to lossless mode for me are mostly in the "doing it when I'm waiting for other stuff" category

But, yes, it's not the highest priority right now, even for lossless, in my opinion for now it's more important to improve patches, then better palette selection work, then maybe automatic group selection up to `-g 3` Btw, now I'm encoding a larger set to compare patch improvements

So, after encoding a larger set, there are still many images where patches are ineffective, especially on not very large images, I will show the results later

ok, thanks 😄

I think I'll make some sets like GoodPatches and BadPatches, for a more convenient comparison of where patches help and where they are bad

Eh, but since there are very few images where the patches work and help, at least on my test corpus, and where they are ineffective quite a lot, most likely I will make one combined set 🤔

I think I also need some sort of set with UI, screenshots containing text and repeating elements, but a good sampling of different random relevant images is not so easy to compile

**Patches Tuning Corpus** <https://docs.google.com/spreadsheets/d/14dIfETkUkocEuDOhGQI24tiKnnpTMKSp1qlTtmXOD74/> `PatchesCorpus.7z` <https://drive.google.com/file/d/1o48eAuEaGn-EO5kiTJvJ-iFzHQ8KcqRd/>

makes me proud to see WebP still competitive for some image sets -- but then again, my explicit design guidance for JPEG XL lossless as well as some architectural/project team headcount allocation choices I made were to prioritize lossless photography compression this time (and for WebP lossless I prioritized explicitly the other way around). Also, WebP lossless is a more light-weight construction for decoding resource use.

for WebP lossless I decided to take a 10 % density hit for photograhs by leaving out larger filters -- I just considered photography compression out of scope of that effort

Yes, but if we focus on Web usage, it's very rare to use lossless photos and it will mostly be art, UI/design elements and the like As I wrote before, the need for lossless even at very good quality or visual/near lossless modes will not disappear, maybe even grow, because there are a lot of sites that use even less efficient PNG and bandwidth or traffic is not a big problem for them and for most of their users, also with lossless modes no need to worry that the image may have any artifacts or other visual losses (which can not always be seen or closely compared even at very high quality)

yes, that was my thinking for WebP lossless

for JPEG XL I considered a world where WebP lossless exists and does a pretty good job in that corner -- i.e., winning over it is not the priority, but it is more important to fill the gaps

and from raw photography we know that some people are keen on lossless photo compression

Yep, but still, JXL would also be nice to have some more practical mode that could be a competitor to WebP in similar content, but fast enough for Web use (prioritized for decoding), but maybe a little better overall and at the expense of slower speed, but within comfortable practical use

With fuif I wanted something universal, but it needed pik to be really good at photo. I think the end result is quite universal though.

Bitstream-wise I think jxl is an improvement over lossless webp. Encoder-wise there is still work to be done to make jxl get more consistent gains.

And for patches, I think for lossless they are very hard to use correctly so where they start to work, quite often the compression gets worse and this can be a problem especially for small images (which are also very common on the Web) where the size increase is most noticeable

For small images it would probably be good to have a more exhaustive encode mode that actually tries things with and without and takes the best.

For lossy, there can be a problem on images with text or UI when there is significant compression, because some letters or elements will be much crisper and cleaner than others and it sometimes looks worse than the same quality degradation across the image or it may even appear that the encoding or the image itself is broken (but with better patch detection and less ringing artifacts it will be becoming less noticeable)

For lossy I want to try doing patches (or an extra layer) also for non-repeated but just not-dct-friendly stuff

Yes, that might be a good idea

E.g. a text part would then be extracted completely, quantized a bit, and done with lossless modular (some of it with patches, some of it without, but consistent quality anyway)

Last day of holiday for me today

I'll give it a try tomorrow

`-d 8` 1. Old `--resampling=2` 2. New `--resampling=2`

------- `-d 4` 1. Old `--resampling=2` 2. New `--resampling=2`

<@!532010383041363969> ^

Sometimes better, sometimes not sure, and it seems that yes, more useful would be an implementation with partial upscaling, but not the whole image

<@!111445179587624960> which commits did you compare? `631c862` and `7193782`?

Yep, with <https://github.com/libjxl/libjxl/pull/445> and without For `-d 4` mostly better, but for `-d 8` the artifacts are more noticeable

d8 with 2x resampling is _very_ lossy though, I think at that point you're maybe at the 1x equivalent of d20 (just inventing a number) and you might be better off doing d3 with 4x resampling or something...

for very low bitrates, try resampling + photon noise...

I'm not sure if it works, I haven't noticed any difference

it does work 😛 just to be clear, I don't mean `--noise`

`--photon_noise=ISO250` ... `--photon_noise=ISO1500` + `--resampling=2`

weird... <@!604964375924834314> what did you try?

a 2021×1586 image with `--photon_noise=ISO8000 --resampling=2 -d 2.2` (that’s what matched the bitrate of d8 without resampling on that image if I recall correctly)

but it’s a rather noisy image

ok, so a *lot* more noise

Yes, perhaps my numbers were too low

It somewhat masks artifacts, but it is not suitable for every image

yes, of course - on synthetic content especially I doubt it will do anything sensible

I've just tested it and the new resampling method indeed works better. I used Windows executables from GitHub artifacts (I've been able to download them because I've been logged in to GitHub). Options: `--target_size=170000 --resampling=2`

**Before** (commit `Fix docs (#448)`, hash `631c862`)

**After** (commit `Implement sharper 2x2 downsampling kernel`, hash `7193782`)

settings?

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

https://artifacts.lucaversari.it/libjxl/libjxl/latest 😛

try adding photon noise too

for %i in (C:\Users\Utente\Documents\wqe\Camera*.png) do cjxl -s 8 -I 0.953 --gaborish=1 -q 97.056 --photon_noise=ISO44 %i %i.jxl

i did and it was s..

like better than the two deltas

Too much time, I just wanted to test the resampling itself 😛

but the blurring of a normal shape not good

Low bitrate comparison, same size (e.g. what could be better as the default setting for low quality): ```1. AVIF (*.avif.png) - also for comparison 2. Modular (*.JXL_m.png) 3. No resampling (*.JXL_nr.png) 4. Old `resampling=2 --photon_noise=ISO2000` (*.JXL_r2.png) 5. New `resampling=2 --photon_noise=ISO2000` (*.JXL_r2n.png)```

https://twitter.com/jyzg/status/1427338090658607112

we have a few more resampling improvements in the pipeline -- possibly roughly the same amount of improvement that is available in the 445 PR

I'd like to remind that with 2x2 resampling the bitrates are roughly 4x lower -- this means that jxl:resampling=2:d2 is roughly the same bitrate as jxl:d8

Perhaps 2x2 resampling is good enough that we could degrade to that for extremely high distances rather than the modular mode

Today the modular/VarDCT flip creates a strange discontinuity in quality: https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_08_10/plots.html

also a link to the images https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_08_10/index.html#seikima-ii-20100704-japan-expo-32*3:1&JXL=m&HEIF=m&subset1 -- can be difficulty to find from the objective plots link

thank you everyone for posting the results on 2x downsampling, this is helping us to prioritize things

Thanks for the feedback! We're working on further downsampling methods to improve it further: This was the original resampling:

This is after yesterday's patch:

And this is what's possible with optimal downsampling:

And also this, which has more ringing but is sharper:

What is this --resampling parameter? Is it supposed to downscale/resize input by 50%? It doesn't do anything when I use it.

try --resampling=2

Yeah I used that

it downscales when encoding, but upscales when decoding, so it encodes 1/4th of the pixels, but you still get the original resolution

Oh. Yeah. I get original resolution that's why I got confused

I have used it on a full gradient image. So I couldn't see any difference

Same size <https://github.com/libjxl/libjxl/pull/445> vs <https://github.com/libjxl/libjxl/pull/458>

Sharper, but the ringing artifacts on flat areas have become much more noticeable

Updated <https://github.com/libjxl/libjxl/pull/458>

do you have exe for windows, can you send build

<@!111445179587624960>

would be extremely good

<@!111445179587624960>

-d 0.838 -s 8 --epf=1 -I 0.373

this is really impressive

if you have build please send cjxl

I only have AVX2 build and there are changes just for --`resampling=` and if don't use this option, there is no changes for quality

ah

yes on third try i notice improvement

32979 photos in jpeg. Resolution from 1372x2000 to 11064x14006. Transcoded lossless with `-e 8` to jxl. 100,24 GiB - jpegs. 80,68 GiB - jxls.

looks like the ~20% gain estimate is about right 🙂

🤔

lol that looks messy

it kind of makes sense in a way, I would say it selected the "most nonphotographic" parts of the image

but looks like the thresholds could use improvement, and also if you have many borders like in this example, it is likely going to be counterproductive because those borders add entropy too

`-d 2`

`-d 2 --separate=1`

And with almost the same size

hmm, the quantization is really bad in that example, you can see the banding the modular image introduces in those long gradients

and then vardct has to undo that banding, which is way more work than not introducing it in the first place

Yep, it appears when converting from XYB?

well if you do the modular part with too high quality, you're basically losslessly encoding a ~12-bit version of the image, so the size will blow up

so like in other patches, I quantize the (XYB) colors to make it more compressible - and since vardct will still encode the residuals, it can still correct any quantization error that was introduced

`-d 2`

`-d 2 --separate=1`

`djxl -d 8`

And further for all images: `-d 2` `-d 2 --separate=1` `djxl -d 8`

Yep, there are some noticeable artifacts even at the border between modes, but still, a very promising option

it’s an interesting effect, though

probably deserving of some space in <#805007255061790730>

it’s like having enhancing glass on certain parts of the image

However, the size is larger here, perhaps because the blocks on the large single-color area are not combined and there is no benefit in compression

I should probably add something to ignore solid-color regions - for those it doesn't really matter what mode is used, and it would be silly to separate just because there's a solid background

did you say it replaced the modular part with black in the vardct image?

maybe it could replace with an average of the surrounding or something like that instead

Also if the images will be encoded in lossless with VarDCT lossy patches? <:Thonk:805904896879493180>

Larger size, but no ringing artifacts (if not counting artifacts between different modes)

Hmm, I think it would be useful to encode in modular mode also the crossings between solid color backgrounds and sharp lines/edges, even if it is not so beneficial for compression (because artifacts or blurry/jagged lines are most noticeable there) It would be even better if all the sharp lines were compressed in modular mode and then overlaid on top of VarDCT, but I'm not sure if it is possible, and using splines for that would be quite difficult

Like this (modular mode only works on the background and mostly does not touch the lines): Source

And also to be much closer to lossless at higher quality settings, like `-d 1`, at least visually

Some upscalers comparison (960x540 >> 1920x1080) 1. AMD FidelityFX Super Resolution 2. ImageMagick Lanczos 3. `-d 0.1 --resampling=2` 4. Cropped 1920x1080 source

Not very correct comparison, but I had this idea after AMD FidelityFX Super Resolution was open source <https://github.com/GPUOpen-Effects/FidelityFX-CLI>, it is very fast GPU upscaler (except I'm not sure about mobile GPU, but it is implemented on shaders), it is intended for upscaling mainly in games and in real time, but in general suitable for any content, its main advantage speed, good quality, openness and it should run on any relatively modern GPU So maybe in the future it will be possible to use something like this upscaler implementation on GPU

For `--resampling=2` there are noticeable problems with lines and some more blurring, although I understand that it is also intended for highly compressed images and better hiding various artifacts

just use nnedi

Nnedi is very much slower, FSR is extremely fast (it is intended for 1000+ fps in real time at 4k+ resolution)

how did you *down*sample?

Also ImageMagick Lanczos (but also tried other methods, not seeing much difference)

for %i in (C:\Users\Utente\Documents\wfwe\*.png) do cjxlsharpness -q 98.36 -s 7 --progressive --faster_decoding=1 --use_new_heuristics --epf=2 %i %i.jxl for %i in (C:\Users\Utente\Documents\wfwe\d\*.jxl) do djxl %i %i.png

sharpness 06052021 BUILD