JPEG XL

Holiday mode 😛

https://discord.com/channels/794206087879852103/803645746661425173/860925867550310462 Some supplement information Artist: ゆたまろ > https://www.pixiv.net/users/1566535 Touhou Project-Hata no Kokoro (秦 こころ) > https://www.pixiv.net/artworks/54764555

Cute

-s 9 seem to be always visually better. For same file size -s 7 d2.2 or d2.3 == -s 9 d2

decision are not always perfect :p color variation is visible here. 800% zoom and d1 is 1/10 the png file size.

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

It's overall better and less of the most noticeable ringing artifacts

cool, I only try s7 and s8, I never thought s9 can get better quality.

when it gets really better compression quality everything else is

for %i in (C:\Users\User\Documents\imf5*.png) do cjxl -q 97.6 --epf=1 --faster_decoding=4 -p -s 7 --use_new_heuristics %i %i.jxl

about -d 4.38 i was joking

quite decent blurring

but jxl isn't designed to get here

webp like does better

`-s 9` may give better quality, especially on art content and after recent changes in VarDCT, but I would say that it is not always very consistent and sometimes there can be unexpected strange artifacts (so for me for now `-s 8` remains the safer choice)

The same images but with `-s 9`, for example

A little better overall, but there are strange things, like in this area

jpeg xl is optimized for the highest bitrate possible

not for webp comparison

yes, I can see some strange area on s9.

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

Slightly less ringing artifacts, maybe I need some examples with bigger distances on which the difference would be more noticeable

What are the distance of you image compression?

Various, from 0.2 bpp to 0.9 bpp (~`-d 2` ... `-d 5`), depending on the size of AVIF images

But we can compare all iteration of same picture you upload?

All images are the same size, I leave a quote for past comparisons with past builds, the sources and AVIF images was in the very first message So it's possible to see the progress and compare different changes to each other

not _quite_, as that would mean it doesn’t compress

Can jxl compress pictures with low artifacts at low bpp when used with avif source? Like use avif as texture denoiser.

you could try downloading those thumbnails

https://music.youtube.com/playlist?list=PLic8c70Da8qigm7NXv6a5w7D2uLRkTxCy&feature=share

are 100 songs

but you won't get original webp

i guess you can download only jpg

and is a limit

You can download webp. It's there. But I don't understand why is it needed

https://i.ytimg.com/vi_webp/dgxwEmU2_Oc/maxresdefault. webp

you know all

how to download all 100 thumbnails in webp with youtube-dl

is there a script you can do

No script is needed. You can just use shell commands.

no with browser, i want to do in cmd

I know only Linux commands. I don't know about windows cmd.

so you know how to download the one hundred webp in a second

can send a compressed file

is the command that long

it's not a good idea. jxl "denoise" also when you compress more. Using a real denoiser tuned with eye is a good solution if you want to reduce file size.

But avif blurs textures and keeps lines sharp, making pictures look good at low bpp. A denoiser denoises everything.

A good denoiser doesn't

I'm not sure how valuable that is, but...

I took random art and photo images and encoded them to avif/jxl. I dunno how to get the "same quality", so I targeted for the same file size. Encode to avif: `avifenc -j 4 -r f -y 444 --min 0 --max 63 -a cq-level=12 -a end-usage=q in.jpg out.avif` then encode to jxl: `cjxl -j --num_threads=4 --target_size=<avif_size> in.jpg out.jxl`

Then I did decoding to pixels 10 times for each image and took the average time. Commands: `avifdec -j 4 -c dav1d -i in.avif` `djxl --num_threads=4 in.jxl`

Here's what I got:

``` Name Time_sec ---- -------- art1.avif 0,089 art1.jxl 0,1614 art2.avif 0,0799 art2.jxl 0,132 art3.avif 0,0566 art3.jxl 0,098 photo1.avif 0,2241 photo1.jxl 0,2133 photo2.avif 0,1191 photo2.jxl 0,1258 photo3.avif 0,2781 photo3.jxl 0,3467 ```

The archive with the original images and powershell script is here (17,1 MiB): https://github.com/eddiezato/eddiezato.github.io/releases/download/bin/test_dspeed.7z

A more accurate way to measure is to do `--num_reps=50` (no idea if avifdec has something similar)

Also single-core decode probably still matters most for browsers, so you might want to compare that too.

Unfortunately, `avifdec` has no `--num_reps`.

With `avifdec -j 1` and `djxl --num_threads=1`, 50 tries for each image:

``` Name Time_sec ---- -------- art1.avif 0,1236 art1.jxl 0,3415 art2.avif 0,0914 art2.jxl 0,2465 art3.avif 0,0619 art3.jxl 0,1446 photo1.avif 0,426 photo1.jxl 0,5318 photo2.avif 0,1278 photo2.jxl 0,2243 photo3.avif 0,8158 photo3.jxl 0,9727 ```

How are the numbers for 10-bit avif?

Also might be interesting to see what happens when you add `--faster_decoding=4` when encoding with cjxl

Is this x86 or ARM?

i5 3570k

I'll try `--faster_decoding` later.

With `cjxl --faster_decoding=4`, `avifdec -j 1` and `djxl --num_threads=1`, 50 tries for each image:

``` Name Time_sec ---- -------- art1.avif 0,1239 art1.jxl 0,2396 art2.avif 0,092 art2.jxl 0,1656 art3.avif 0,062 art3.jxl 0,1262 photo1.avif 0,4293 photo1.jxl 0,4835 photo2.avif 0,129 photo2.jxl 0,1943 photo3.avif 0,8188 photo3.jxl 0,9249 ```

Btw num_threads=0 might be better, not sure if it still makes a difference

Yeah, the differences are within the margin of error

how big are the images?

the first decode in a process has some significant setup time in djxl

``` art1.jpg 790206 bytes 2387x3000 art2.jpg 1101110 bytes 2560x1600 art3.jpg 504564 bytes 1920x1080 photo1.jpg 6866353 bytes 4296x2709 photo2.jpg 1261580 bytes 2560x1600 photo3.jpg 7365131 bytes 6000x4000 ```

--num_reps=50 will give different results from starting 50 processes and taking the average

trying to run a benchmark on like 10000 jpegs but the process just gets killed, i assume its trying to load them all in mem - is there a different way to do this?

also is there a faster way to transcode a massive set of jpeg files than just launching a new cjxl process per image?

I think I would personally just do it in parallel with https://github.com/gittup/tup, it’s meant to be a build system but I find that it can have many more uses

```tup : foreach jpegs/*.jpeg jpegs/*.jpg |> cjxl %f %o |> jxl/%B.jxl ```

if the images are large then doing it in parallel may not be the best idea

you could use benchmark_xl with --save_compressed and --num_threads=[some low enough number]

awesome thanks both of you

one last q.. to find transcoding compression speed in terms of megabytes/sec, it is sufficient to multiply (MP/s) x (# input file megabytes)/(# megapixels) right?

Usually when speeds are expressed in megabytes/s, it's uncompressed megabytes, which in case of 8-bit RGB means just x3: 1 MP/s = 3 MB/s

(when it's higher bit depth I don't know what the convention is, since e.g. 10 bit can either be 6 bytes per pixel like in ppm, 4 bytes per pixel if you pack 30 bits in 32 bits, or 3.75 bytes per pixel if you really pack the uncompressed bits tightly)

ah ok cool thanks 😄

I'm finding that lepton is about 10% faster at compressing JPEG files than cjxl - does that line up w ur expectations/experience?

Haven't compared recently but that sounds plausible

Different use case though - Lepton is not an image codec, you need the whole file and decode to jpeg before you can show the image

<@!604964375924834314> --noise=1 still bugs out in some weird cases :/

top: JXL, bottom: original

yes, to be clear, `--noise=1` on its own is still the old behavior

for now, to get the new model, one must choose a parameter manually with `--photon_noise=`

okay, I was just thinking that you maybe fixed that as a little bonus. But no problem, I just tested photon_noise and think I have to rename myself now!

I think we hope to do that eventually, and thank you for the feedback 😄

my expectation is that finding the noise level from an image is a too hard problem -- I have seen three people trying to solve it and the result has always been 90 % good, 10 % surprising

my anticipation is that when we find the best solution possible, it will be 99.5 % working, 0.5 % surprising -- i.e., still not ok

depends on how bad the surprise is, I guess

certainly a first condition is to have good detection of photo vs nonphoto, so we don't add noise to a screenshot or something silly like that

(photo vs nonphoto would be useful more generally to choose between modular and vardct, possibly also to segment the image and do a combination)

yes, but that kind of thinking will add to the surprise -- because the screenshot can be 75 % photo, 90 % photo or 20 % photo

if adding one more pixel of photography surface will flip the noise on/off, then weird things are bound to happen

and this relates to having large areas of noisy textures

trees vs. noise for example, with a small patch of non-noisy sky in between

agreed - segmenting the image in photo/vardct regions (with noise) and nonphoto/modular parts (without noise) would be needed, and that's not so easy if it has to be done accurately

(the regions don't have to be rectangular in general, etc)

If our noise is per layer, then that could be done, yes.

layers will likely complicate and slow down decoding, so they are not an option right now

our noise is per frame so it can be done

do we add single-channel noise if the layer is single channel ?

two layers should be fine for decode speed, especially if they are used for what they're good at (doing nonphoto stuff like text with modular is likely not really slower than doing it with vardct, and we already kind of do it anyway with Patches)

layers all have the same number of channels, grayscale vs color is an image level thing

ok

what was the final decision on the blending colorspace?

both xyb and linear sRGBish ? source colorspace?

I remember there being complications of doing good things there

XYB can be used for blending patches, source colorspace for blending frames

ok, thanks

but xyb could the source colorspace?

yes, xyb is possible source colorspace (though we don't do that atm, we signal the actual original colorspace atm)

we only allow enum colorspaces for frame blending though, not arbitrary ICC profiles

(because we want the decoder to not have to depend on lcms/skcms just to figure out what the decoded pixels are)

that makes sense

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

I understand zoom in image not a fair compare, this sample only use for jxl quality improve, not compare different encoder. jxl-2db3204 have some quality improve, I think use -s8 can reduce more ringing, maybe implement slower but strong ringing reduce in -s8 or -s9 is worth it?

rework

I see all the images the same because i wake up but at night i see more differences

I update a rework version, use same jxl commits (2db3204), I still feel red and blue area have some strange behavior, maybe vardct too radical on red and blue area?

I do add 20 % more bits for blue areas in delta palette matching

I could add a similar heuristic to VarDCT

blue diffs cannot be see when they are below the red and green values

however, when they are above, they become visible

in usual compression it is all superposition and the normal formalism cannot capture that

in XYB it is more complicated, but still superposition and quantization is going to go wrong

need to think about it and experiment, looks like a great possibility

does it happen on both red and blue or only on blue?

green is always ok?

Lee, Thank You for keeping this topic alive, it gives more motivation and guidance to deal with it from all angles...

d 0.5 -s 8 looks ok

I don't test too much green color image sample, so I not sure green is safety.

could you take your image and swap the color channels in gimp

decompose to RGB, and then recompose in another way

separate to single color channels?

I try to use photoshop make this.

jxl-d0.5-s9-green and blue_png 200% in photoshop

probably like this?

jxl-d0.5-s9-blue-only_png 200% in photoshop

jxl-d0.5-s9-green-only_png 200% in photoshop

I'd be most interested if you can swap B<->G channels, compress with -s7 -d1, swap B<->R channels, compress with -s7 -d1

ok

that would help me to explore the channels -- if I use B only for additional bits like in delta palette, or if I need to do that for R, too

wait a minute, I need find how to swap color channels.

perhaps rotate hue by 120 degrees (I don't know photoshop)

like this order? RBG BGR

I don't mind any order

as long as B goes to R in one, and into G in another

Irfanview swap color_1.0_s7_BGR

Irfanview swap color_1.0_s7_RBG

ok, so it is blue that is the problem

I using cjxl 0.3.7-2db3204

just checking -- you swapped the colors in the originals and then compressed with s7 d1?

could you run them with s9 d1, too -- does that mitigate the problem or make it worse?

oh, I use jxl s7 d1 => png => swap

original_RBG_to_1.0_s7

original_BGR_to_1.0_s7

original_RBG_to_1.0_s9

original_BGR_to_1.0_s9

I can't say s9 is better than s7, still have some problem.

yes, looks the same, and blue is more of a problem than others (when you didn't swap)

then the blue hair gets the terrible artefacts

I should try other color channel swap?

Why blue color will affect red color in XYB?

perhaps run the without swap here, too with those two -s7 and -s9

with d1

ok

just to have a calibration reference on how bad it looks then

original_to_1.0_s7_no-swap

original_to_1.0_s9_no-swap

red ribbon have some tiny error(like ringing), blue hair is look better than older jxl version.

great, I have an idea now how to reflect this on VarDCT

very likely the same idea that I used in delta palettization works there, too, for a better initial guess (to make s7 behaviour closer to s9, and possibly improve both a tiny bit)

Thank you for your work 🙂

blue hair is still terrible and I can improve on this

Another approach is to look at generation loss after lots of d1 encodes, it can give an indication of where things can be improved

Last time I did that was a long time ago but then it was blue-yellow discolorations that were the biggest problem

Input file: green-original.png -1,823,722 Image: 1920x1080 pixels | 8 bits/sample | RGB | 385379 color(s) cjxl-0.3.7-2db3204 Look like green color area doesn't have issue in this sample?

green-original_1.0_s7-213,762

green-original_1.0_s8-202,128

green-original_1.0_s9-201,989

Comparison of 0.3.7 versus latest GIT https://eclipseo.github.io/image-comparison-web/jxl_results.html Significant improvement noticed

do you have the images too? 😄

https://eclipseo.github.io/image-comparison-web/#abandonned-factory&JXL_0.3.7=s&JXL_20210715=s&subset1

thanks!

Venti!

Lee, do you play Genshin Impact?

I haven't play Genshin Impact yet, but I like game soundtrack, story and character 🙂

About this image, I find a tiny issue on d1.0 s7, venti green pants have a tiny issue point(upper area).

I got a bitter bamboo flute because of the soundtrack :-]

cool, can you play a bitter bamboo flute?

<@!493871605408071681> for lossless, you might also want to try `-e 3` and `-e 2` for faster encode/decode, and `-e 9 -E 3 -I 1` for very slow but dense compression

we still need to work on better speed for lossless encode

I have a -e 9 -E 3 -I 1 locally that I didn't publish or plot yet

I'll try with -e 3, it seems heif has a better Weissman score due to the speed at which it encodes, the compression rate being very similar otherwise

is q100 rgb jpeg actually lossless btw? I assume it's still slightly lossy

not sure if Weissman score with the mean of encode and decode time is that useful in practice

it depends on the use case imo - for encode-once, decode-very-often use cases, you basically care only about decode speed

and for authoring workflows and archival use cases - i.e. encode-very-often, decode-rarely, you basically care only about encode speed

so it might be useful to also have an "encode Weissman score" and "decode Weissman score"

Maybe PNG (say whatever default imagemagick does) is a more useful reference codec for lossless than rgb mozjpeg

its near lossless for jpg, i only use it as a reference for time

i use to have png as a reference

but png is already the source file

did you check if heif-enc is actually lossless? it seems to have quite good density, better than what I expected - but then again, the images are all photographic so that might help

I used the parameters explained in the help: -L -p chroma=444 --matrix_coefficients=0

well you could also just take 24 bpp ppm as the source file and have compression ratios in the usual way, comparing to uncompressed

probably yes, I haven't tried yet, but in general I can play the flutes -- the flutes are still on their way (I will get an C and A key)

Yep `lossless: heif-enc -L -p chroma=444 --matrix_coefficients=0 -o [output] [input(PNG)]` it looks like lossless, but in my tests on various sets HEVC-HEIF (x265) was not good and could not compete with WebP and sometimes even optimized PNG (although it may make more sense on photos)

``` $ compare -metric pae ClassA_8bit_BIKE_2048x2560_8b_RGB.ppm.png ClassA_8bit_BIKE_2048x2560_8b_RGB.ppm.png.heif.png null: 257 (0.00392157) ```

looks like it does still get off-by-ones even with those options

off by 0.25 on average

it is strange because bpg used to be the worse performing yet heif is better

``` Channel distortion: MAE red: 81.3112 (0.00124073) green: 49.7283 (0.000758805) blue: 106.136 (0.00161953) all: 79.0585 (0.00120636) ```

well if it allows the lsb to not be quite lossless, as seems to be the case, then it's easy to be better

because then basically you win 3 bpp

less error on green than on red and blue suggests that it is either still doing YCbCr internally anyway (despite the --matrix_coefficients=0), or it is doing something like YCoCg but with the lsb of CoCg dropped, so they remain 8-bit

i'm not familiar with these tools

point is: best not to believe encoders when they call something "lossless", best check on at least one image that you can decode it to something so that when you do `compare -metric pae orig.png decoded.png null:`, the result is 0 (no error)

Apple Preview has an "Export..." option to HEIC and you can select "Lossless" there, but what it actually does is a YCbCr 4:2:0 HEIC encode at some high quality

so it's not even visually lossless, since on some images you can see chroma subsampling artifacts

(also for some bizarre reason it also subsamples the alpha channel if there is one, even at the 'lossless' setting)

ah yes this is bad

what the flag on compare -metric to get the channel separated?

`compare -metric pae -verbose orig.png decoded.png null:`

pae is the max error per pixel

mae is the mean error per pixel

(peak absolute error, mean absolute error)

ok

I'll see with heif upstream for what they consider "lossless"

the numbers are in 16-bit if you have a default imagemagickq16, so 256 means "off by one in 8-bit"

maybe it's just a bug in the decoder and the heif is actually lossless, but I'll only believe that when I see it

I remember reading this https://github.com/strukturag/libheif/issues/62#issuecomment-758674528 but thought the option fixed it

BPG should have true lossless, but it has a very old version of x265 so it could theoretically be a little less effective, also Avifenc has true lossless

checked Wep@, it's true lossless too

*webp2

if it looks right then it is lossless, right? 😛

Some people found the commit whcich regressed heif lossless mode https://github.com/strukturag/libheif/issues/533 I'm reencoding now and the files are now significantly larger

Cool

Looking forward to the updated results 😁

It's a bit of a pity that there's not more competition in lossless, I think there's room for jxl improvement in lossless too but we're already the densest of the practical codecs so it's not really a priority to work on improvements there

But, I think the speed/density competition is still there and it would be nice to have a JXL mode that would be only slightly slower than WebP (especially in decoding) but at a higher density, which could be used as a full replacement for WebP, JXL is better in maximum compression but not consistently better in speed/efficiency ratio on all types of content and in the current implementation there is a big difference in decoding speed

I've try -e 3 it's fast but compresses no better than webp (losslessly)

yes, we need lossless -e 4 to -e 9 to get better speed/density trade-offs

heif went from the best compressed to the worse with now true lossless, JXL is now king with the fastest decode after mozjpeg too https://eclipseo.github.io/image-comparison-web/speed_results.html

nice - i'm not a big fan of that patent mess of a codec, so the more it can be shown to suck, the better 🙂

if you have results for faster and slower lossless jxl, I think that could be interesting to add

and also the speed of png encode/decode (e.g. measure how long it takes imagemagick to convert between ppm and png - which is not the best thing you can do, but it is a commonly used implementation)

also webp1 can probably get better weissman scores with different `-z` values

it makes heif looks way worse in lossy too, before it was appearing to keep more details but now it looks very bad with colors being kept correctly

wait what? in lossy nothing should change, I would assume?

the `--matrix_coefficients=0` you shouldn't use for lossy

even forcing 444 might not be the best idea

typically for heic and avif, 420 is better at low bpp (but you always need 444 at high bpp because otherwise you can't get rid of the subsampling artifacts)

for lossy, doing things in RGB and not in some luma-chroma-chroma space is a bad idea

imagemagick jpeg encoding and mozjpeg by default do ycbcr 4:2:0 on quality < 90 and ycbcr 4:4:4 on quality >= 90

aren't the other codecs keeping 444?

i think avif defaults to 420, not sure

webp can only do 420

webp2 can do 444 but I assume it also defaults to 420

ah but webp2 you do set to 444

yes

jxl is doing 444 no?

i've tried to keep everyone at the same level

avifenc defaults to 444, so that's ok too

jxl cannot really do 420

it can do ycbcr 420 when recompressing jpeg but you cannot use variable block sizes, only fixed block sizes when doing 420

only webp is 420 and jpeg too

yep

jpeg below quality 90

ok so doing heic in 444 is fine, but you have to drop the `--matrix_coefficients=0`

only for lossless YCbCr should be skipped

Wait

Jxl doesn't do 420 well?

444 by default is pretty cool

in varDCT and modular mode chroma subsampling doesn't exist. It use better solution for reducing file size. chroma subsampling is for noob file format 😜 (and ultra low visual quality like video)

I have an HDR screen on my phone and chroma subsampling makes jpeg look gross on it, so jxl not using subsampling is good

On all images?

I don't understand why 8 bit jpeg might look bad on HDR display than a non HDR display.

It's not the 8 bit

It's the chroma subsampling

Either that or my screenshot app

Difference between 420 jpeg from snapseed and 444 png from my phone screenshot manager

Open original

But I think phone's HDR mode work only when viewing HDR videos and pictures( depends on gallery app)

UI always run on 8bit mode

It's always easier to see chrome subsampling artifacts on text screenshots and on 🌴 images.

420 in screenshots is a Very Bad Idea, but that's not what is going wrong here 😄

looks like gamut issues

420 <:Hsss:806131225278152756>

Could other <:JXL:805850130203934781> inventions be used (EPF, noise, gaborish) when using YCbCr 4:2:0? (Not like I'm a fan of YCbCr 4:2:0, I'm just curious lmao)

not sure what is allowed, some things are 444 only

<@!179701849576833024> do you remember the restrictions? in 420, can you do epf, gaborish, noise, splines, patches?

yes to all

you can't do adaptive DC smoothing

you can't do it because we specced it that way? (in principle it could be done though, right? just for chroma DC it would be annoying to implement — or am I missing something?)

the things you can do, they are all done after the chroma upsampling I assume?

yup

also yup (I am not sure how to do it either - adaptive DC smoothing works on all the channels at the same time)

ah right, it's not a per-channel thing

JXL looks particularly good on paintings at very low BPP (0.30) compared to AVIF and HEIF: https://eclipseo.github.io/image-comparison-web/#kryer*2:1&AOM_20210715=t&JXL_20210715=t&subset1

I suppose it depends on the painting style: avif/heif tend to blur/smudge/vectorize, which is bad for brush strokes and charcoal-like highly textured styles, but it is perfect for ligne claire manga-like material.

😆 Now: how do I write a format-choosing logic that depends on historical art style…? 😜

I think probably disable denoising can get better result for this case? > -a color:enable-dnl-denoising=0 -a color:denoise-noise-level=5 or 8 and for high quality optimize > -a color:sharpness=2 -a color:aq-mode=1 -a color:qm-min=0 or 2 original > https://eclipseo.github.io/image-comparison-web/report.html > between q=4 and q=63: avifenc -a end-usage=q -a tune=butteraugli -a sharpness=3 --min 0 --max 63 -a cq-level=$quality -o [output] [input(PNG)]

I hope jxl can improve quality for ligne claire manga-like material(anime), still can't get transparency quality result on -d 0.5 -s 9.

The bitstream itself can certainly do it - it can directly represent Splines and mix DCT-based with non-DCT-based methods, which theoretically makes it great for ligne claire / manga. It's just extremely hard to make an encoder that fully uses the bitstream, detecting splines etc, so for now we (mostly Jyrki) are trying to do generic improvements like being better at VarDCT block selection (which will help for any kind of image).

I'm really looking forward to seeing next jxl quality improvement. 🙂

in these cases I wonder whether support could be added, eventually, to specific authoring tools (like, say, inkscape, or whatever), as those would be able to exploit that kind of features far better

There are still noticeable differences <https://github.com/libjxl/libjxl/pull/385> `-s 9 --lossy-palette --palette=0 -P 0`

WebP NL40

- But, there is a visible improvement, images are closer to the source Source:

`-s 9 --lossy-palette --palette=0 -P 0` (before 385)

`-s 9 --lossy-palette --palette=0 -P 0` (after)

WebP NL40

(mostly background texture)

oh wow, there's definitely some noticeable extra dithering going on there

it did improve though 🙂 IIRC there's still some work that needs doing on improving the clustering, both for colors and for deltas, but I am not really sure

It's a more interesting/tricky thing to optimize when it's not just about selecting colors but also about selecting deltas and deciding when to use implicit colors/deltas and when to make them explicit

Plus there's way more powerful context modeling to exploit which makes things even harder to optimize for

does delta offer higher compression of images of aut people

is useful for that

please be honest

`-s 9 --lossy-palette --palette=0 -P 0` (385)

WebP NL40

it can't be compared, jxl way better

the artifacts in the sun

heavy blocking banding and dithering

can you share those files in a zstandard preset 3 or zip file?

ah true they are jxl so already compressed

share in zip for compatibilty

the clear lines in jxl

so subtle

NL40 is the winner here -- but we will get the delta palettization eventually to it's quality level, also the NL40 approach is possible within the non-palettized JPEG XL lossless, it is just a lot of effort to build

simple for non-predicted images, but somewhat complicated for predicted

Yep, I'm only pointing to images where the differences with the source are very noticeable, these are not real comparisons because JXL in these examples are much smaller

guetzli goes to quality 110, and it is still lossy

my experience is that most often custom delta's don't change much since the dithering coming from slack in stock deltas is masked by the noise in a photograph

however, for fully noiseless images with gradients the slack in stock deltas manifest as weird dithering patterns (not particularly beautiful)

the smallest non-zero delta there is 4, 4, 4

and if only one color component is changing (for example green) the smallest delta is 12 steps or so

that is not cool

it works for photographs, but not for smooth graphics

custom delta generation can identify when the image has a lot of small deltas and choose deltas that fill the gaps in stock deltas

when those gaps are filled, then in respective areas there are no dithering patterns to observe

----

in webp near lossless I have another approach -- there, I change only those pixels that are in a visually active area

it is easier to get right visually, but is pretty complicated to implement because every pixel change changes the prediction residuals and the quantization of prediction residuals is what matters

the palettization is inherently more powerful for quantization -- it is vector quantization after all -- but requires more care to get right

I believe that eventually we will have a palette solution that compresses ~35 % more than webp near lossless with roughly similar quality

<:kekw:808717074305122316> ``` PS > cjxl 0.jpg 7.jxl -j -e 7 JPEG XL encoder v0.5.0 [SSE4] Read 1988x3056 image, 53.6 MP/s Encoding [VarDCT, d1.000, squirrel], 4 threads. Compressed to 1300653 bytes (1.713 bpp). 1988 x 3056, 4.36 MP/s [4.36, 4.36], 1 reps, 4 threads. PS > cjxl 0.jpg 8.jxl -j -e 8 JPEG XL encoder v0.5.0 [SSE4] Read 1988x3056 image, 53.2 MP/s Encoding [VarDCT, d1.000, kitten], 4 threads. Compressed to 4397281 bytes (5.790 bpp). 1988 x 3056, 0.52 MP/s [0.52, 0.52], 1 reps, 4 threads. PS > ls -File | Format-Table Name,Length Name Length ---- ------ 0.jpg 2097141 7.jxl 1300653 8.jxl 4397281 ```

<:PepeOK:805388754545934396> ``` PS > cjxl 0.jpg 8p.jxl -j -e 8 --patches=0 JPEG XL encoder v0.5.0 [SSE4] Read 1988x3056 image, 52.9 MP/s Encoding [VarDCT, d1.000, kitten], 4 threads. Compressed to 1298130 bytes (1.709 bpp). 1988 x 3056, 0.55 MP/s [0.55, 0.55], 1 reps, 4 threads. PS > ls -File | Format-Table Name,Length Name Length ---- ------ 0.jpg 2097141 7.jxl 1300653 8.jxl 4397281 8p.jxl 1298130 ```

what about -e 9? 😄

I'm trying, but it's quite long 😄

``` Name Length ---- ------ 0.jpg 2097141 7.jxl 1300653 8.jxl 4397281 8p.jxl 1298130 9.jxl 4387353 9p.jxl 1306128 ```

i'm testing with some jpeg, i have not the same issue.

Some kind of images can produce amusing results.

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

There is less ringing as well at not very high distances, but sometimes the differences are not so big and the artifacts have just moved to other areas

i use speed 2 but with a optimal settings, the images are 75-80 kb small ones, those images are more than 3 mpx and they weight 60 kb. Is completly different

it's x2,5 more compression

do not be fooled

this is what medium compression is today

Thank you for your work 🙂 Test on libjxl_0debc57, hope jxl can reduce those tiny artifacts in red circle(red area), on normal (no zoom in) status still can notice those tiny artifacts.

Can you share the image? Looks like a spectacular patches encode heuristics fail...

Page from the comic book

n my opinion in 5 improvements after 0.5.0 will become good at q 70.08 s 9 epf 1 faster decoding 1

just wait for it

how to delta palette? what changed to normal palette? is simply adding l0 p1 or this types of commands? should i write palette 0 palette 1024 -m -s 8

what is correct command for normal use

could someone create a page like pingo encoder optimizer? same layout?

in html format, like it was before, in february 2021 and february 2020

and findable by everyone not by a cmd command that could fail

why complicate things?

also s 2 N 3 or what are possible options and speed for near lossless?

Interesting case for patches, <@179701849576833024> . We don't do dots when we do patches, right? Maybe that's the issue?

https://discord.com/channels/794206087879852103/794206170445119489/821763695772041236 What's the difference between dots and patches, by the way?

Decode-side it is the same thing. Encode-side there are two different detection heuristics.

pretty sure it's not dots

would love to see the image with patches removed...

We can see patch with djxl -s 8 There are one pixel patches? i don't understand the aim <:ugly:805106754668068868>

Those small patches are likely very counterproductive

Also a bit disappointing how little text it detects

I think we need a large corpus of images to refine the patch heuristics, avoiding counterproductive patches but also improving detection of productive patches.

Yep, something similar happens on black and white lossless images, where disabling patches improves efficiency

The current heuristics are likely to detect counterproductive patches in monochrome regions

Is 1 2 and 3 pixels patches useful on picture? Disabling small patch on jpeg input could be an easy solution? 😄

Or more precisely, not only b&w, but others where there are only a few colors https://discord.com/channels/794206087879852103/803645746661425173/843591188866793503

Maybe minimum/recommended patch size as a fraction of image dimensions?

You know, bigger images usually require bigger patches...

Small patches _can_ be useful: something like the dot on an i or a comma (,) is expensive to do without ringing with the DCT and if it can be replaced by a patch it can be very productive.

But here they just seem to increase the entropy of the residual image instead of decreasing it

This quality improve commits not merge to main libjxl branches yet, > https://github.com/libjxl/libjxl/pull/403 look like my testing not include this commits...😢 > https://discord.com/channels/794206087879852103/803645746661425173/872470336329895977

And I notice some grayscale comic image also have some file size inflate issue.

Are you testing with high distance

No, I only test lower distance, > cjxl -d 0.5 and -d 1.0 -e7~-e9

Then you don't need that ringing commit I think

very likely it does nothing at d0.5 and d1

(and I'm still unsure on whether it is an improvement at d7+...)

<@!179701849576833024> In these art images the ringing improvements are noticeable (quality between `d2` and `d5.7`)

From what I can see in photographic content it's generally worse, so I'm not really sure if it is overall better...

Worse

-s 7 -d 1.24 --epf=0 --use_new_heuristics

Only good with an added new heuristics

Lets veluca decide

needs --anime switch

Yes yes. With best settings for anime.

I have 2 visual problem in -d 1 -e 8 in this synthetic picture The details in the highlight center of the flower disapear. And the are little color shift in the stars. There is green desaturation and little yellow desaturation, in the top of the picture. I understant that it's because it's simple to encode this hard part of the picture but in -d 1 i expect a little bit visual transparency. Maybe it's linked to the color shift in a previous scope image (full noise image)? What do you think?

Maybe try cjxl -d 0.8 and -d 0.5 -e 8~e 9 can get better result? I guess some synthetic image(anime) use -d 1.0 still too risk...

Hope vardct can improve quality for synthetic image(anime) 😢

I don't see any issue <:kekw:808717074305122316>

I add that at -d0.5 the center of the flower is also blur 😕

I can search in real picture, sky detail could have the same problem. As a photographer blue highlight is very important.

-d0.2 is ok 😄 , but it's not a bug because detail in blue high light is not at all very visible in humain vision.

but for synthetic image, blue still very important.

Maybe we need cjxl parameter like this? > --ImageContent=content (Photo, Screenshot(anime))

Look like graphical images quality improve have some conflict on photo images? > https://github.com/libjxl/libjxl/pull/403

or some heuristic can detect content type?

Just my opinion, for now I still think synthetic image quality is vardct weak point...

It is more convenient to do it like x264, but this can complicate both development and use, and it is better to improve the quality that will be universal for different types of images

or webp, but, images are rarely encoded with individual settings for each

Encoder tuning presets can rarely be used in automated workflows.

They also don't help in case of mixed contents, like a screenshot containing icons, text, photos, and illustrations.

That make sense, mixed contents is a problem.

I honestly do not see the issue at all in my viewers.

I remember aomenc have some heuristic to detect screenshot content, but I can't find source...

if you need many parameters there is this https://css-ig.net/pingo

still don't know this is other codecs

how to download all images in that site

This is the default avif, similar size to -d1 Detail in high light is less good than jxl. But there is no desaturation on stars in the top of the picture (but noise reduction in dark area) And there are a bizarre color shift in the yellow. I prefer jxl 😄

Same comparison with jpeg, massive desaturation and blur, but no visible artifact (no blocking no ringing wow). Mozjpeg is very good !

Are you sure you are not having image viewer issues <:Thonk:805904896879493180>

https://github.com/Blobfolio/refract

> All conversion takes place at Pixel Level and is intended for displays with an sRGB color space (e.g. web browsers). Gamma correction, color profiles, and other metadata are ignored and stripped out when saving next-gen copies. <:SadOrange:806131742636507177>

I see it as a workaround for web browsers without having good color management ( Firefox)

Firefox has ok color management, it just doesn't do the right thing by default on untagged images

gfx.color_management.mode needs to be set to 1

Yes. I don't understand why it isn't the default.

i dont even know if color management is even enabled by default

i remember having to turn it on but im always on nightly now

ICC profiles are handled correctly by default

It's untagged images that are a problem, and maybe also partially tagged images like png without icc but with gamma

also ICCv4 iirc

right: `gfx.color_management.enablev4`

^ what Jon and Sami wrote. My workaround for Firefox having (still, hopefully not for much longer: https://bugzilla.mozilla.org/show_bug.cgi?id=455077) a wrong default is to embed a small 500b sRGB equivalent profile in all images. Bit wasteful, but the only way (DCF EXIF in JPEG would be smaller, but isn’t supported).

This test isn't my test, A little curious, in this case why jxl blue color different original blue color? https://encode.su/attachment.php?attachmentid=8579&d=1625392452 > https://encode.su/threads/3397-JPEG-XL-vs-AVIF?p=70124&viewfull=1#post70124

For drawing, screenshot, anime, manga contents, I notice avif can get more stable and balance quality, even original source not lossless, flat quantization, blurry, strong filter those features can let result more stable, but for photography contents, avif need some parameter optimize to preserve detail, jxl vardct is very powerful on photography contents, but for drawing or screenshot contents, I think still need some quality improvement.

if you use -d 0.681 -s 8 --use_new_heuristics -I 0.25

It's like placebo

for the build luca versari released

~~I think avif will always look better than jxl on synthetic images.~~ Edit: I was wrong. It fails on anime which have complex brush strokes.

Which encoder do you use for avif? aom or rav1e or svt?

libavif aomenc

For now jxl have butteraugli and very strong, but avif also a strong option, It's very difficult to say which encoder is better...

For images with many flat areas AVIF is often better, but for more complex synthetic images I would not say so