JPEG XL

very very likely JPEG XL will be able to do much better with decent quality targets, but it is not clear to me yet that the palette modes and all options that JPEG XL has are as applicable to low quality anime compression as AVIF

I'm a bit suspicious if users actually want bad quality anime -- probably they are using it as a proxy to evaluate how efficient it will be in higher quality

🎨

I found it interesting that they use the term color cache -- I probably introduced that term for palettization related optimization in WebP lossless -- but then they use it for a single channel color

I don't think most people want and keep bad quality art images (although there are such people too, and for someone unnoticeable artifacts = good quality). But for resized images or previews on various services (when there is also a full image in better or lossless quality) it's fine, especially with the quality that AVIF gets for not very extreme low bpp (but still below mid bpp)

And for someone else, such as some studios, these are high-quality images of classic animation that have been given away for free use:

<https://www.reddit.com/r/DataHoarder/comments/lj00uv/studio_ghibli_released_400_high_quality_images/>

But, it's something like jpeg `-q 60` converted to PNG

And this is AVIF at low bpp https://discord.com/channels/794206087879852103/803645746661425173/817893091008184442 So the term quality is very wide and differs from person to person

Very true

A little curious, I notice some site use libjpeg q80~q85 jpeg image, In jpeg xl vardct -q 80(-d 1.900) and -q 85(-d 1.450), on this distance quality should be ok(not look so bad)(medium bbp)?, or on bad side(low bbp)?

-d 2 is definitely not low bpp

I'd call it medium-high (correct me if I'm wrong)

Everyone has their own taste in these things. My taste is like this: - cjxl -q 95 (-d 0.55): very high fidelity, good for archival if lossless is not needed - cjxl -q 90 (-d 1): high fidelity, can be used on the web if fidelity matters more than usually, e.g. product images of a webshop selling clothes with subtle textile textures - cjxl -q 80 (-d 1.9): medium-high fidelity, 'good' for the web (default web quality) - cjxl -q 70 (-d 2.8): medium fidelity, 'ok' for the web (when lower bpp is needed for whatever reason, e.g. bandwidth is an issue for client and/or server) - cjxl -q 60 (-d 3.7): medium-low fidelity, can be used on the web if fidelity doesn't matter much, e.g. preview thumbnails - cjxl -q 50 (-d 4.6): low fidelity, roughly the lowest fidelity target I consider 'normal use' for still image codecs - cjxl -q 30 (-d 6.4): very low fidelity, not really useful in any 'normal' use cases - cjxl -q 10 (-d 12.65): ultra low fidelity, nobody wants to do that to an image <-- this is what people tend to look at to compare codecs

<@456226577798135808> <@!794205442175402004> Thank you very much, those advice is very useful 🙂

What is the formula for the mapping between -q and -d? It looks linear (0.9 d/q), except below 30 q.

``` if (quality >= 30) { params.butteraugli_distance = 0.1 + (100 - quality) * 0.09; } else { params.butteraugli_distance = 6.4 + pow(2.5, (30 - quality) / 5.0f) / 6.25f; } ```

at least down to q7, after that it switches to modular and that doesn't define a distance at all

(it probably should use the distance too though at some point)

<@!179701849576833024> is that correct?

The Y-scale could be better, but at least the plots should be right.

For me 0.3.3 is a big step in -d 6 range, all strange colorful rigging is vanish in my test images

This quality -> distance mapping roughly corresponds to trying to match the average Butteraugli pnorm distance that libjpeg produces for a given `-quality`. So on average, roughly speaking, `cjxl -q 80` and `cjpeg -quality 80` should produce more or less similar-visual-quality images, with the caveat that in the case of cjxl, there will be way less image-dependent (or even image-region-dependent) fluctuation in actual visual quality than in the case of cjpeg (where `-quality 80` can be very good for, say, grass and trees, but very poor for, say, subtle red textures).

left -d 6, right -d 2 with more rigging to me

-d 2 has more details on the other hand, but indeed it has more ringing

d 2 is clearly better (and more then double size) but make this strange multicolor texture on slow gradient that is sorta visible also from no zoom if you know where see

seems correct, yes

probably less filtering, choosing the best balance is a bit of an art

left s 9 right s 7

s 7 seam better to me

hard to say for me which looks better, they are mostly just different (have problematic artifacts in different parts)

in general, I would not assume that speed 9 is always better than speed 7

speed 7 gets more attention, that's what always happens with default speeds

I can't see -s 7 -d 2 rigging from no zoom but I can -s 9 -d 2 rigging because it is in square shape

0.3.3 on anime at -d 6 VARdct is better then lossy-modular (Q45)

but at -d 1 I fell modular -Q 90 be better on anime

Some lossy and near lossless comparisons: ``` avif (q19) 183 856 avif (q26) 143 557 jxl (lossy-palette -s 9) 217 250 jxl (lossy-palette -s 9 -P 0) 215 841 jxl (lossless -s 9) 442 330 jxl (--epf=0 -d 0.3 -s 8) 376 604 jxl (--epf=0 -d 0.5 -s 8) 279 388 jxl (-d 1 -s 8) 186 040 webp (-near_lossless 60) 460 104 ```

Source

AVIF (q19)

AVIF (q26)

WebP (nl 60)

JXL (lp P0)

JXL (d 1)

JXL (d 0.3)

jxl -d 0.3 size?

thanks

to me jxl -d 1 do a good work in this, only the small rigging near the line at 300% size

Lossy palette is quite noticeable when zoomed in, but in normal viewing it is not so obvious JXL (lp -P 0)

WebP NL60 (much less visual differences)

And -d 1 still has some ringing artifacts

AVIF (q19)

And they are noticeable even with -d 0.3/0.5 when comparing with flipping

However, AVIF also loses detail and smoothes at higher bitrates, as well as at lower ones

PixelArt ``` avif (q19) 76 127 avif (q26) 66 854 jxl (lossy-palette -s 9) 260 571 jxl (lossy-palette -s 9 -P 0) 256 106 jxl (lossless -s 9) 82 098 jxl (--epf=0 -d 0.3 -s 8) 350 503 jxl (--epf=0 -d 0.5 -s 8) 258 603 jxl (-d 1 -s 8) 167 342 webp (-near_lossless 60) 198 610 ```

Source

AVIF (q19)

AVIF (q26)

WebP (NL40)

JXL (LP -P 0)

JXL (-d 1)

JXL (-d 0.5)

JXL (-d 0.3)

Lossy palette

WebP (NL)

JXL lossy palette - there are visible differences AVIF has less pixel smoothing than JXL -d 1, also less size And lossless is more effective than all lossy modes (which also have a noticeable visual difference), except AVIF (but it is also visually different and smooths out pixels even when the bitrate is increased)

So even for the Web for this kind of content I would prefer lossless, maybe in the future JXL will have other near lossless modes, but at the moment lossy palette is not very suitable for this

jxl -d 1.0 s 7 will increase file size (119KB => 182KB).

For PixelArt content probably need local palette?

Probably something like WebP NL, but it also sometimes has noticeable differences and is not always more efficient

It should be possible to do just regular lossless but make it behave a bit lossy

If it will be possible with minimal visual loss for any content, then yes, although this can be checked afterwards with some metrics and only then make a decision (but as far as I know usually near lossless methods are not very good for metrics)

I found good testing material

https://upload.wikimedia.org/wikipedia/commons/9/96/The_Garden_of_earthly_delights.jpg

`JPEG Image, 39137 × 22279 pixels`

Yeah, also used them for testing. Sadly none go over ~32k~ pixels longer side [EDIT: or, maybe, it was 65k? https://commons.wikimedia.org/wiki/File:Portr%C3%A4t_des_Herzog_von_Mantua_Vincenzo_I_von_Gonzaga.jpg]: https://commons.wikimedia.org/wiki/Category:Gigapixel_images_from_the_Google_Art_Project

for %i in (C:\Users\User\Documents\f\*.png) do cjxl "%i" "%i.jxl" -s 3 -P 4 -I 0.334 -m --mquality=82.78 --num_threads=2

jpeg xl quality is still a bit low

the text is too zig zag

the original source is obviously a webp from youtube yt music

not sure if the orders of the cmd is right

i think is not too bad

Why do you use modular?

you can't compare compression artefacts between different codecs

whatever cjxl produces, it's probably going to look very different

Why did you use lossy format as source image

Because it's no fun and it takes very little time to compress a good quality image and get the result without visual differences using a minimum number of encoder options, it's much more interesting to choose from a billion different options while compressing a bad image and spend hours on choosing from different kinds of artifacts

https://c.tenor.com/3DeS-m1u6_AAAAAM/yoda-sarcasm.gif

Only half, but when there is a lot of time and enthusiasm people usually do something like this (sometimes it's just a waste of time, but sometimes it can lead to something) It would be better if it goes in a productive direction more often, but

i don't want to re encode

i want to encode all my png at this quality

taken from RAWs

which distance to use

0.7 to 1

And higher `--target_nits`, because you'll probably edit those RAWs and lower target_nits will mean worse quality in the shadows even at extreme VarDCT qualities.

ok

What help do you want.

I use esrgan (dejpeg or 2x scale) to upscale lossy images and downscale them again to original size and convert them to jxl. It gives better quality and compression.

-I 4.41 have no sense, also -g 2 it is not the default?

The q (lowercase) and Q (uppercase) are different. The lowercase q is for the quality of a VarDCT lossy while the uppercase Q is for making a modular output lossy.

honestly modular is for quali ty, vardct for fidelity but too options can cause future decoders to be broken with certain newer encoder versions

the bitstream is standardized so a decoder that fully implements the standard (which we will have with libjxl 0.4) can decode anything encoded by any encoder version

as for encoder options: our goal is to need as few of them as possible. Ideally, you only need to do `cjxl input.whatever output.jxl` and it does something good.

The options `--quality`/`--distance`, `--speed` and maybe `--progressive` are the only ones you should really need.

And even those should be "set it and forget it", not something you have to tune for every image.

My `cjxl_auto.sh` script is one *really small* step, but still: a step closer to full automation. The encoder is planned to be intelligent enough to know the best encoding parameters **better than us**. And Fabian, don't worry about decoders breaking down, there wouldn't be many options in new encoders (0.4+) that will break current decoders (≤0.3.x), the standard will get fully frozen soon 😃

for 4k

dct sometimes are less (never)

but is not worth it to me as i like quality, not fidelity

even if fidelity is better

and nor

`--num_threads=2.5` 😆

how to program a similar program?

scope can you write this program?

like without changing 0,3.6 code is it possible?

Choose how?

I can make a program that always chooses the first option you give it 😅

https://tenor.com/view/spin-spin-the-wheel-make-a-choice-random-selection-zerkaa-gif-13856034

Just write a shell script or something

the quality will be degraded too

also this is for 0.3.7 encoder, and it can't read JPG/JPEG (You should convert to png)

We should get some windows binaries out there, I suppose.

Indeed. Perhaps AppVeyor's build platform could be used?

-N is probably broken, that is an option from a long time ago

the problem with those options is that the image looks encoded good but it doesn't display well

av1 encoding is improving even videos with 50k views from 3 days ago are getting re encoded

Hello, is there a table benchmark between jpegxl and AVIF in lossy mode? I only see lossless benchmarks: https://www.reddit.com/r/AV1/comments/fjddcj/lossless_image_formats_comparison_webp_jpeg_xl/

<https://www.reddit.com/r/AV1/comments/k9kq5t/updated_my_image_formats_comparison_including/> <https://eclipseo.github.io/image-comparison-web/> <https://storage.googleapis.com/demos.webmproject.org/webp/cmp/index.html>

Because in lossy it is a very bad idea to base only on metrics, a visual comparison is required (which is also different from different people's perceptions)

For Lossless, the only thing that matters is compression efficiency, which can be compared in numbers, smaller size - better compression (and encoding/decoding speed), the image quality is always the same

lossy is basically impossible to evaluate automatically. whenever someone makes the best metric ever, someone will make an encoder that optimizes for it, and soon enough you'll get images that are great according to the metric but not so great when you look at them

it’s kind of related to the “streetlight effect”: https://www.discovermagazine.com/the-sciences/why-scientific-studies-are-so-often-wrong-the-streetlight-effect

> It is often extremely difficult or even impossible to cleanly measure what is really important, so scientists instead cleanly measure what they can, hoping it turns out to be relevant. After all, we expect scientists to quantify their observations precisely. As Lord Kelvin put it more than a century ago, “When you can measure what you are speaking about, and express it in numbers, you know something about it.” > > There is just one little problem. While these surrogate measurements yield clean numbers, they frequently throw off the results, sometimes dramatically so.

when you have clear and “objective” numbers, it’s very tempting to optimize for them

even if they turn out to be meaningless

> The fundamental error here is summed up in an old joke scientists love to tell. Late at night, a police officer finds a drunk man crawling around on his hands and knees under a streetlight. The drunk man tells the officer he’s looking for his wallet. When the officer asks if he’s sure this is where he dropped the wallet, the man replies that he thinks he more likely dropped it across the street. Then why are you looking over here? the befuddled officer asks. Because the light’s better here, explains the drunk man.

So how do you know jxl is better than avif in high bpp? Only watching it? Metrics can't be perfect but we need a math base for comparison. A butteraugly and psnr benchmark could be interesting. ( in video psnr is a useful metric in all reviews) Visually on photography i prefer avif even at "hight" bpp (>1) because there is no dct artifacts, but little noise filter. Maybe we need to create a big evaluation by people to know what is the average preference of people. How we can convince that people using jxl againt avif, thinking that avif have better compression efficiency? (apart from talking about advanced features of jxl)

subjective study on a lot of people

We do often look at metrics too (I mostly look at Butteraugli, HDR-VDP, DSSIM and SSIMULACRA), but you just have to understand that metrics are not the same as actual humans.

Relying on codecs to do noise filtering is like viewing sRGB images on a P3 screen without doing any color management because you like the extra saturation...

i need to reduce the number of colors --> gif

Here i can say that avif is better at tiny and small, medium i prefer avif (but it depend of picture, on the asian girl picture, jxl is way better) in large it's very similar, jxl have better small texture but dct artifacts if we zoom, in big jxl win against details. https://eclipseo.github.io/image-comparison-web/#japan-expo*2:1&AOM=m&JXL=m&subset1 What is about you? (for me the noise reduction in big avif is a bad tuning of the encoder)

To be fair, enable `-a aq-mode=1 -a enable-chroma-deltaq=1` in avifenc using libaom, and see the image coding performance improve considerably at medium bpp. At higher bpp though, JPEG-XL wins massively in terms of single threaded encoding and decoding.

This is the difference in human perception, I have not made comparisons with the latest versions, but usually by Butteraugli metric at bpp above 0.7-0.8 -- JXL almost always wins, also by my personal visual comparison with AVIF sometimes even at very high bpp can not get close to the original image quality, it washes and removes so many details, I do not want to use the encoder as an image filter for that there are other tools, I want to keep the original quality For low bitrates AVIF is better (although JXL will have improvements for that in the future), images also still remain far from the original, but it does not show artifacts and is more pleasant to view

For non-photographic images and anime-type images, AVIF also currently has a big advantage at low to medium bitrates

Personally, I am almost not interested in extreme lossy compression, when it comes to choosing who works better with filters and is good at hiding artifacts, I prefer a quality close to the original, almost without visual losses (without using zooming or pixel-hunting)

About the metrics (I didn't really look at them, also here are not the best source images for such a comparison) <https://eclipseo.github.io/image-comparison-web/lossy_results.html>

With increasing bpp, JXL has a significant gap (but keep in mind that it was tuned for Butteraugli)

Yes, Butteraugli is a good metric but comparing a codec that is tuned for it to one that isn't is not quite fair

Both SSIMULACRA and DSSIM show quite well the "intersection point" at higher bpp where JPEG XL starts being better than AVIF (AOM)

https://eclipseo.github.io/image-comparison-web/subset1.ssimulacra.(aom,bpg,jxl,mozjpeg,rav1e,svt-av1,webp,webp2).svg

https://eclipseo.github.io/image-comparison-web/subset1.dssim.(aom,bpg,jxl,mozjpeg,rav1e,svt-av1,webp,webp2).svg

Also making such aggregated plots can be a bit deceiving, it's usually better to look image by image

It is also possible to take the best features of the two formats, use AVIF for low bitrates and previews (especially art images with sharp lines) and JXL for higher

Btw, according to VMAF, JXL has the worst quality, worse even than all old formats on all bpps

Is VMAF stupid or something? Lmao

VMAF is not suitable as a metric for still images, even its name is **Video ** Multimethod Assessment Fusion

VMAF looks at YCbCr and PSNR, which is basically what old codecs work in and optimize for

vmaf seem to be a stupid metric, jxl is ALWAYS better than mozjpeg in any case in any image. Is there a psnr graphic?

psnr is also a stupid metric

<https://eclipseo.github.io/image-comparison-web/lossy_results.html>

But, for video, VMAF is considered by many people to be the most modern and good metric, at least of those that are freely available (unfortunately I also notice a lot of advice from different people to use VMAF for still images as well, because it is modern, advanced and Netflix is a big company) PSNR is also not suitable as a good metric for comparing quality (although I know it can be useful and is used to compare some of the encoder tools)

> a lot of advice from different people to use VMAF for still images as well, because it is modern, advanced and Netflix is a big company

<:ReeCat:806087208678588437>

Last time I saw a discussion about this article and that DSSIM is bad and old, but if the author had used a more modern VMAF, the results would have been more reliable and truthful (I can't quote directly since it was not a public discussion) <https://siipo.la/blog/is-webp-really-better-than-jpeg>

Wow ok i'm shocked about the result. Psnr is good when comparing video complexity algorithm, also in video there is tuning for better visual quality but psnr is a good math ref. There is no psnr tuning in image codec? https://eclipseo.github.io/image-comparison-web/subset1.psnr-hvs.(aom,bpg,jxl,mozjpeg,rav1e,svt-av1,webp,webp2).svg

psnr doesn't take any human perception into account

it's a metric for accuracy in the color space domain, but humans don't perceive all deviations there as equally important

if you're optimizing for anything else than psnr, psnr is going to suffer

ok, but mozjpeg better in psnr at low bpp is very strange, jpeg complexity is very low. Maybe i'm biased by codec video, with many tuned preset, nobody compare visual tuned preset in psnr 😄

one of the AV1 devs said: "If your optimizations don't damage PSNR, you do something wrong"

<https://web.archive.org/web/20141103202912/http://x264dev.multimedia.cx/archives/472>

<@231086792315633664> I think the point is that PSNR is a very *simple* metric, and that if you have two encoder settings that optimize for the same thing (even if not PSNR), but with different bitrates, PSNR will give you an idea of how much better one is than the other.

But if things optimize for different things, you can't compare PSNR across them.

It's like observing that cars with more cylinders in their engines go faster, and then concluding that semi trucks must be faster than cars.

Sure, within the same class of vehicle more cylinders in the engine is correlated with being faster. But it's still measuring something fundamentally different.

I'm studing this comparison test https://eclipseo.github.io/image-comparison-web The encoding params for jxl are not good ... it's the default, so it's -s 7 ... (i'm not benchmark avif time encoding). If we change to -s 9 -E 3 image is a better. https://github.com/eclipseo/image-comparison-sources/blob/master/recipes.json I do some manual test and i find a solution to upgrade quality to lower image quality, adding a little blur to the source image 😄 "magick.exe in.png -blur 0x0.3 out.png" for medium and small, (i'm shure if i denoise image we can be better than avif in small and tiny image :D) I need to generate my website version to show us results ^^

For the same size with blur, we switch to -d 5.1 to -d 4.9 in the small seikima picture.

All formats use the default settings (although this is also not entirely fair, for example AVIF encoding is much slower than other formats), but this at least compares their most common use case

yes but we need to compare avif and jxl to the max quality. And in an other time to the same time encoding. Never to the default setting, it's stupid, like comparing TV to the default color setting in store 😄

Yes, it would be more correct to compare with one encoding speed or maximum possible quality, but this is also not a bad test, a lot of people usually just use the default settings (since the maximum ones are usually much slower and the fast ones have worse quality)

Usually images are encoded once and viewed many times, so why wouldn't you encode with the best/slowest encode?

We know that all people looking for benchmark now are choosing a codec for quality not for speed. We need to defend jxl to be the best for the web at social media image bpp.

Because modern formats have become quite slow and very often required to get the encoding result as quickly as possible or not to unnecessarily waste computing power, because usually the default settings are the most optimal in terms of speed and quality Lossy Jpeg XL also mostly not tuned to other settings besides defaults and slower speed very rarely gives better result (and sometimes it is even worse)

This also applies to the encoding settings on the various services (they very rarely use the slowest ones, except for old formats like JPEG, but mostly use something more optimal)

Now we are in the step to convince people that jxl is the BEST image format (best than avif) fort all level of quality, nothing else matter 😄

if I can do it on github I will make a webpage with different jxl encoding parameters to verify it.

Not on low bitrates at the moment, especially on art/anime content (at any settings)

That's why we need to add an extra denoise filter before jxl encoding to beat avif :p (i want to test it :D)

In a fair comparison, the source image must not be changed or processed (because in this case it can also be "optimized" for AVIF or other formats)

we are in WAR 👺

It's not unfair, (if I had the skills) i can create an fork of the encoder and adding in the encoding process a denoiser proportionnal to the final image quality :p

Denoising doesn't help Jpeg XL as much and it will still be worse than AVIF at a low bitrate, besides such tricks bring more mistrust to such a comparison than something good

Also, with more advanced encoder tools, denoising would also make AVIF using aomenc-av1 perform worse.

And for blurring JXL has `--resampling`

the smaller value is so HUGE

But you see that av1 iframe have a "denoise filter" (i don't know how the code works) also at high bpp that's why jxl beat it.

It's more like it's tuned differently.

https://damiencarrier.github.io/image-comparison-web/#japan-expo&AOM=l&JXL=l&subset1

look at the large image

turbo denoiser 😄

But we need best avif tuning to fair comparison.

Is there a webpage explaining how av1 iframe works?

And also these are more recent comparisons (eclipseo is quite old) https://storage.googleapis.com/demos.webmproject.org/webp/cmp/index.html

Yes, you can see the big denoising here in big size: https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_03_16/index.html#eaglefairy-hst-big&AVIF-AOM=b&JXL=b&subset1

It's not really just denoising, it's more the work of some AVIF tools and also choosing which details are more important to save

Yes it's a very smart denoiser, but it denoise 😄 and then it remove details progressively, it's very smart !

But that might actually work in JPEG XL, to remove the "worst" noise (mostly in flat areas) with a natural-looking denoiser, estimate how much noise was removed and encode that value so the decoder reapplies that noise.

We need to wait for cjxl 0.4, core dev are working on blocks heuristics

_ Never to the default setting, it's stupid, like comparing TV to the default color setting in store_ FWIW, I agree the codecs should be pushed to the max in a useful comparison. I don’t even know what a _default setting_ is… That said, I also agree with _ the source image must not be changed or processed_ Otherwise, we would be comparing these TVs with only a specific movie we know looks best on one of them. Also, not sure _war_ is a useful metaphor. More like a dress rehearsal. I mean, I have utmost respect for all the skillful taylors and their revolutionary, flexible fabrics, but with all due respect, it’s not even about the actors, let alone about the costumes. It’s about the show.

An image codec should not be something many people have strong feelings about in some 'codec war'. It should just be something that doesn't get in your way, that is transparent, that just does its job of saving storage and bandwidth without any observable degradation. It's a good thing if it's something you don't have to care about.

Also, lastly, about denoising specifically. My main interest and huge excitement in new codecs (all of them!) is their use on the web. I get all the other use cases which are different and useful too, but I’m not at all excited about being able to reencode all my locally stored photographs to a new, more efficient, lossless format. Who cares: storage is cheap (check if I’m not Google). Web… that’s a different story! So for me, only one quality setting really matters: _take as much time as you want and then give me the pic at the quality where it only **just** starts to look shit. Maybe take one tiniest step back, maybe not._ Any other quality setting is a total waste of time. Also, I know it may not be a popular opinion, but I prefer artifacts that suggest there was detail there to a fake obliteration. So in this comparison, JXL wins with AVIF for me:

^ https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_03_16/index.html#2011-03-05-03-13-madeira-159-funchal-mercado-dos-lavradores&AVIF-AOM=t&JXL=t&subset1

Sadly I feel there likely will be a format war once they start being widely supported. The good thing is that I feel JXL is in the best position with the best set of features (speed, responsive/progressive encoding, JPG transcoding) and widest range of quality that work well will put it in a good position to be the primary replacement for JPG, PNG, and GIF. I feel the major downside is that many don't yet know about it or confuse it with one of the older JPEG editions.

> *I prefer artifacts that suggest there was detail there to a fake obliteration.* Fully agree, though I would probably never use tiny. I would always use medium and higher. I do like the progressive encoding of JXL so if speed queries ever become a thing I could use that to have the download stop at a tiny quality level would be great. https://css-tricks.com/bandwidth-media-queries/

Yes, there is some PR work needed, at least among web devs and image/photo professionals, to make sure everyone knows jxl exists

I like to call it jxl and not JPEG XL to reduce the confusion with the old jpeg

I've been suggesting it on Twitter to people who talk about different codecs or image formats in general. The biggest responses I get are that they either didn't know about XL or thought it was XR. I typically use both JXL and JPEG XL so they know the long and short names and let them know it's the successor to JPEG.

The confusion with XR is a thing indeed

Also the jokes about "extra large"...

The funny thing is, the name was chosen by those who made the call for proposals, not by those who actually made the codec

Not seen those, but I have seen people saying it means extra light.

i like also JXL

ji ex sell

jxl or JXL on internet? I prefer force all people writing JXL, it's more visual.

.jxl

is the right

at least is one

we don't want .jpg .jpeg

confusion

It's `image/jxl` and `.jxl`

When talking about it, it's JPEG XL or JXL (capital letters make more sense in a sentence imo, like GIF and PNG or HEIC and AVIF)

so are two

not only .jxl

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

There is only one filename extension

Question is: how to pronounce it

. jpg/.jpeg is always "jay peg"

How should we pronounce .jxl?

how is jyrki pronounced

yorki

jayksel

alaqùgliala

or alaqugliàla

https://forvo.com/word/jyrki_alakuijala/

That seems like the j is silent so it would just be excel.

he said yerki

right

is not jyrki

is yrki

not is not jayexcel

but excel

yeecksle

pickle

ji ex sell

g ex sell

ask IPA

I put it in Google Translate to see if it would give a pronunciation but it just spelled it 😆

In french we can say that, it sound great 😄

jeeksel is a good one

I still feel saying jeksel is faster, more modern, and sleek than saying "jay ex el"

nobody say J P E G, all people say jaypag

i'm thinking about in english if we say i like in the work "like" or as a "hey"

Ji X él

like this

or gi X elle

these sounds more phonetically correct to me

no jackson no

JAY EX SELL

is the right pronunciation

just don't worry

japan is great 😄

goood benchmarks<:SadOrange:806131742636507177>

how you made this, what you wrote it and where?

i thought the extension was jay èx èl and jèi-xsl

this is getting too confusing

we can stop

i'm writing in phonetic in google translate 😄 "jixel"

italian benchmark

how is my pronunciation

english was

no

then do the same in spanish

then spanish g x l is right

i wrote .jxl in english google translate

pronunciation is very clear compared to me

or is only a single word

punto gekisele punto jota - ekisele

dot da. jEiExEl

punto gei ix elle

The J like in spanish

It's jota

Hicksèl

this is polish

I think it should rhyme with pixel

so punto jota - ekisele

this confused me

Either djixel or yixel, I guess

Maybe move this discussion to <#794206087879852106>?

This is mostly how I pronounce it but with more of an "e" than an "i" after the j.

I denoise with camera raw (level 100) and the i encode in low quality 72kb target. You can see it's visual better than default encoder. I do the test in realistic quality, small target, not tiny as here. In medium jxl is better 😄

Denoise with camera raw level 25. at -d3.5 denoise before is visual better without artifacts.

To reduce image size denoising is better than reducing quality. It's for extreme reduction for website or for keeping the full resolution of 24mpx camera withour resizing.

do you remember the settings it looks good

how to install camera raw

it's free like adobe bridge, when you use their download installer. If not i'm using photoshop and lightroom, it's integrated in.

Yes i denoise before encoding.

i don't understand the need of denoising, applying filters after encoding, lowering brightness (nits) of image with filters

like i agree with scope

i never used ssimulacra, the last time was in september 2020 and i had 0.140 ssimulacra

too high

this is probably best settings to reduce music cover art

as you can see it didn't reduced the space of the male image

jpeg lossless recompression is more powerful

also this was because there located area encoding

that makes thing more blurrier

tomorrow i will measure ssimulacra of those pictures

look, for the same size different options

we need to change the default params

modular is better than -d=2.5 here ^^

I can't use -m with -d, only with -q or --target_size, is it a bug?

You need to use -Q

why i can't use -d? it's a choice of dev?

Because modular mode is not based on visual perception/quality and distance as VarDCT, it is just a linear mathematical value like `-Q` (quantizer) in Jpeg

`-q` is universal, it gets mapped to `-d` value in VarDCT and `-Q` value in Modular by simple formulas.

Ok thank you 🙂

I have many screenshot encoded in jpeg (with dct artifacts on text), to be smaller than lossless jpeg transcode, is there a lossy modular tweek? or varDCT is better? lossy modular seem to not be a good solution.

Your best bet is first to use JPEGtran to losslessly compress it then use JXL lossless transcode.

There is a gain?

Actually, yes.

Let me get you some test images.

Here is an example:

The benefit is small, but it does do better.

JPEGtran with JXL: `Compressed to 5990560 bytes (2.405 bpp).` Just JXL: `Compressed to 5990809 bytes (2.405 bpp).`

i test it with default jpegtran, i have 0byte gain ^^

but my original jpeg is xnviewMP with huffman optimisation ^^

I see.

The only gain jpegtran can give would be from stripping metadata and things like padding bits, but it should not affect the jxl codestream, only the metadata and jpeg bitstream reconstruction data

If you don't care about jpeg bitstream reconstruction (and if you can run jpegtran, you probably don't), you can also just do cjxl --strip and get something smaller

What is about lossy modular, modular with -q 80 is bigger than lossless. It's not easy like varDCT ^^

Lossy can always be larger than lossless

Try encoding any of those <#824000991891554375> images with lossy anything.

So i need to use --target_size to create smaller lossy modular? The aim is to reduce size of lossy jpeg screenshot, or vardcr is "near always" the good solution for jpeg screenshot?

I don't know why screenshots are being made in jpeg nowadays

Even my Android phone does that now, and I cannot seem to config it to use png instead

It used to be common sense to make screenshots in png

Neither of my previous mid-range Huaweis couldn't do that IIRC, but fortunately Samsung Galaxy Note 9 can 🙂

but is the default?

i have a galaxy s4 and it only offers png

Lol, that phone got released on my birthday <:Poggers:805392625934663710>

And yes, jpg is the default on many phones sadly <a:sadd:818856865231405117>

so higher resolutions smartphone use jpg

smartphone bigger than 16:9 use jpg

can oppo realme make screenshot in png without lossy compression?

I don't know if you can really get smaller size for JPEGs using modular - you can use varDCT with no JPEG recompression, likely it will work better

it fails with resampling

it can't recognize resolution

even with 29-03 build

just this i wanted to do

https://avif-blur-preview.glitch.me/

https://have-you-considered-jpeg.glitch.me/

new heuristics 0.2.0 is average but is fine for blurring

the images in all 2 sites are avif the source

i think you know if there is an higher quality original, those weight 420 kb

firefox nightly reads AVIF in all resolutions

but i want to discuss more in off topic

Unrecognized token IDENT (`P`) in expression

Which script it is?

https://discord.com/channels/794206087879852103/804324493420920833/824769691629125652

can work on windows 7?

https://discord.com/channels/794206087879852103/804324493420920833/824769691629125652

how to install bash and optipng

C:\PATH_Programs

basically wha it does?

Sorry, but no. You **must** use Linux (or WSL on Windows 10).

I don’t see anything that wouldn’t work in msys2?

what it means that?

It means you somehow reached an encoder codepath that isn't implemented. Randomly trying experimental/expert options can do that :)

In squoosh.app progressive option is always buggy in effort 5 and 6, seem to have an old jxl encoder.

All my Android phones take screenshots in PNG.

Stock Android / AOSP always take screenshots in PNG.

What Android version are you on?

I use lineageOS (derived from AOSP) and I get png

i get jpegs on oxygenos (oneplus) 10.3.9

Example of a screenshot

11

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

it looks very different

can you tell which is new version

is it evident to you

there is a slight color editing

done to compress more

even at d 1 jyri enabled something today

it looks like pinwheels

sometimes

when it failed to allocate noise

like they are exploring more lower bpp

How to download those images

https://github.com/eclipseo/eclipseo.github.io/tree/master/image-comparison-web/comparisonfiles/subset1/Original

Imagediff give litteraly no difference

cause this is not the source

those are captured screenshot from windows

no one can see a difference in this screenshots because there isn't

https://online-image-comparison.com/

i didn't use command line tool

i did as you to find a imagemagick Gui

i can't even generate the difference in png with dssim

is mainly patch improvement

is this true?

or i should compare by eye

doing with gimp or photoshop

is there any improvement on patch or quality or only more zip compression

Apparently, there's Brotli now 😛

i did ab x

test

Fabian maybe you should try using deepl sometimes for translation from your native language

The main problem is not even in English, but in a more clearly expressed thoughts and a basic understanding of some things

deepl translates meaning a lot better than gtranslate

I'm just assuming that the clearness of expression is being lost a little

And maybe his native language put through this AI would work better

As far as I know Fabian mostly does not use automatic translators, he writes in English, but instead of writing slower, more meaningful and clearer, he rushes to write separate not very connected words and jerky thoughts

also to these options i could have lossless jpg transcode

I don't support the idea that some random number on parameters can boost the output visual appealing over the original

also if it work you are faking the image

this is for graphic

this i use for photograph

indipendent of the original source png jpg

even if jpg graphic like anime/e usually i did only with modular

and i saved space max in 15 images

over 77+15 images

but i also think q 90.33 is useless just use distance 1

but i don't like the pinwheel effect and the vision of random patch

Conversion to png with xnview

is a good idea to do conversion to png with xnview or only imagemagick should be used

because you crixis said that color profile get edited with xnview or other players

is never a good idea to convert jpg on png becouse make bigger and more difficult to compress images

i know with modular i had this problem

on most images

but i don't think with those smaller distance i can save more than 20% space

perfect white background also

i do not sell the screenshots

Safe good encoding options: - for foto: - very high compression `cjxl -d 4` - high compression `cjxl -d 2` - medium compression `cjxl ` - low compression `cjxl -d 0.5` - for graphics: - standard compression `cjxl -m` or `cjxl -q 100` - slow compression `cjxl -m -s 9` or `cjxl -q 100 -s 9` - slower compression `cjxl -m -s 9 -E 3` or `cjxl -q 100 -s 9 -E 3`

Thanks

Im doing encoding

After i will compare modular lossy files and do some lossless test

Still im encoding 310 jpg with photographic option after i have 810 pngs

--lossy_palette -s 9 -q 83.3 -E 1 -s 8 -g 1 -c 1 -X 0.92 -I 0.913 -m -d 8.03 -s 6

is this good

i need help which quality is d 8.03

can some dev check

-s 6 -q 17.33 is d 8.031

-s 6 -q 17.335 is d 8.030

d8 is garbage

d 0.5, d 2, d 4, d 8

can you send the source

in png if is a png

only one image

in original quality

not jxl compressed

lowest jpeg xl quality

this is lower!

yes but ugly

mine was 0.170 bpp

also this

this not the source

this encoded version with all 3 parameters i specified

looks good

hahha

https://tenor.com/view/some-men-just-want-to-watch-the-world-burn-batman-alfred-quotes-gif-14054558

and only 795 b

i guess the older version now is obsolete

but i still need to check if modular size are the same

0.007 bpp

in lossy and modular (lossless)

but i think i will convert PNGs tomorrow