JPEG XL

only this

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

and this

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

seem quite decent

the rest are blurred

Because it's not just normal encoding, all images have only half resolution

i know but first discord link is 1920x1080 to 1920x1080

resolution to same resolution

second you could say because i'm interested

This is an upscaling comparison (960x540 >> 1920x1080), not an encoding quality, so it makes no sense to compare JXL without using `--resampling=2`

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

Much better now, pretty close to ImageMagick Lanczos

you mean Lanczos downsampling + upsampling?

Yep

interesting...

I'd have thought it would be better tbh 😛

Lanczos has less outline artifacts with the same sharpness

Lanczos with some Fabianium magic (same for downsampling and upsampling) `-filter Lanczos -define filter:blur=.9891028367558475`

wow it's almost like jinc / ewa lanczos

I wish amd made an actual upscaler like nnedi3, or simply just took nnedi3 and made it faster. fidelityfx SR is quite disappointing compared to already existing realtime upscalers based on nnedi such as ngu and fsrcnnx and especially what you're doing here lmao.

FSR is pretty good, considering its speed, but it is more tuned for games, not for video or photos and it should not waste a lot of GPU resources, because the GPU will be busy not only with upscaling, but with all the other tasks for game rendering And realtime for video, where ~25 fps (sometimes 60) are usually enough, and games, where there are no limits, are different things (also games usually use higher bits of color data and FSR is also tuned for this)

I also wish what you say about games using higher bits of color is true

The final frame is rendered in the same bits as the user's display supports, but the internal processes, shaders, effects, textures, postprocessing and so on mostly work at higher bits <https://aschrein.github.io/2019/08/11/metro_breakdown.html>

Lanczos IM downsampling Gigapixel AI upscaling (standard model without tuning settings) <:Thonk:805904896879493180>

Scope, thank you for keeping us in check with this

For getting intended results from the JXL upscaling you need to use the downscaling in JXL

The current version is a work-in-progress and is about to take the next step today

The theoretical win that JXL's non-separable filtering should have is in oblique features -- not pixelizing them

JXL:

IM Lanczos:

but looks like we still have problems that eat the gains that we might eventually get from solving that

Yep, I used `--resampling=2` on the full image in this comparison ^ (but, without today's changes), downsampling was used only for the other resamplers And I started this comparison because the images after the JXL resampler (without the recent changes) looked strange

correct observation and very good guidance for us, thank you!!

I have four more small ideas that will improve the resampling a bit

naturally when upsampling is a linear filter of 25 pixels, it will not be as good as neural upsampling

particularly, it is not possible to gracefully interpolate all thing lines in different angles, and not even slowly developing edges in situations where the required subpixel ringing would be visible

I am hoping that we will eventually (soon) be able to produce better results than IM lanczos

with decent decoding speed -- and be able to layer them with 2x resampled VarDCT d2 for photos with d8 modular for a few shiny random pixels, text and graphics

the layering will require a lot of heuristics and will not happen soon

but the resampling is easier and we can make further improvements there

Yes, neural upsampling was just for comparison, good methods are quite slow and most create a very unnatural image And strange results with `--resampling=2` I noticed a long time ago, but was not sure how it works, thought that maybe it is something much smaller than x2 downsampling or maybe it works on different principles for higher speed and it is incorrect to compare it with normal resamplers

It is fair game to compare just like you are doing. Also very helpful for me to make further decisions about it.

the good news is that if Lanczos / bicubic produces better or equally results than our 5x5 non-separable upsampler, a user just stop doing the jpeg xl upsampling and leave it up to skia/Chrome to resample

my belief is that the 45 degree angles are the worst case behaviour for separable resamplers (lanczos/bicubic), and there we do a better job

unfortunately, at 20-30 degree angle, there is no similar big win any more, and our non-separable will also expose pixel grid in the rendering artefacts (neural methods with larger support can easily fix things there, too)

I like to put a lot of weight on the worst case behaviour and reduce the worst case error -- and there non-separable does have some success with the 45-degree edges

Yes, or in the future I think it would also be nice to use the development of some of the highest quality variations of upsamplers (today most likely using the GPU), which could be integrated into browsers and any other formats and applications would use them, and the quality of these upsamplers would develop independently And about using for quality improvement during encoding, I think that the best method would not be to reduce whole image (especially when encoder has full image and "knows" how it was in source, unlike usual upsamplers), but selective approach, some parts/details would be better to keep in original resolution, than to try to reconstruct them later

<https://github.com/libjxl/libjxl/commit/e00ac5788b769b14af8a543d6572aee615513649> 1. IM `-filter Cosine -resize 960x540` + IM `-filter Lanczos -define filter:blur=.9891028367558475 -resize 1920x1080` 2. JXL `-d 0.01 --resampling=2`

For me, I notice differences in these areas where JXL has slightly worse results (but in others it can be better), a screenshot just to indicate the area

JXL has more thickened and distorted lines

And also I like the text in the other images with Lanczos more, although this is only on high quality images, I'm not sure that it will be better with noticeable compression artifacts

Also, about AV1 Superres

However, it is not very effective for still images <:SadOrange:806131742636507177>

when I look at these images something strange has happened there in this post (not in the previous):

AVIF tends to do a great job on low bpp in any case, I believe that because of the "tool" choices in JPEG XL we will get a 10-15 % improvement in low bpp area due to 2x2 resampling.

Yes, because this is a scaling in the viewer, these images are not for comparison, only to point out the places I am talking about, it is better to compare in full images

do you happen to know the support length of lanczos used in IM ?

is it expressable by 5 pixel support?

No, I didn't go into details, I just used Lanczos because it is usually the most versatile and even by various metrics usually outperforms the other known upscalers (if exclude ML and other more computationally-heavy ones)

Perhaps there is something better, but my idea was to compare it with something fairly common

Does FSR works better than or worse lanczos? I have tried line art images with FSR. It looks good

Quite good, sometimes better, sometimes worse, it is also quite good at removing various artifacts and very fast (but unless it always needs to use the GPU) and it is also based on Lanczos

https://twitter.com/RyanSmithAT/status/1423012754718289923

But FSR is designed and optimized for games, not for normal image or video upscaling

I have seen people calling it a improved lanczos before it was released.

http://www.johncostella.com/magic/mks.pdf is also interesting

my personal interest in the sampling was for 4x4 and 8x8 upsampling, for DC previews

there, my focus was more on not having details (artifacts) present that disappear later when the full image arrives

the worst artefact in showing 8x8 or 4x4 dc (in experimentation in pik) as well as 8x8 in jpeg is the pixel structure surfacing from the 8x8 grid

lanczos or bicubic doesn't do a great job in removing it

there I noticed that a non-separable filter can do better than a separable filter

for 2x2 upsampling it is less of an issue, but still it matters a bit

the upsampling in jpeg xl has non-linearities that make it impossible to reach the finest line widths, but those may reduce ringing

we clamp the values within min/max ranges of original pixels

this is great for flat edges, but not so good for the thinnest lines

we added the decoding-side clamping before we had iterative downsampling so we don't know very well if the decoding-side clamping is an improvement or degradation right now

and if that will make it impossible to achieve lanczos like quality for the thinnest lines

in any case it should give less pixelization and likely less ringing at edges

Is there no way to take any clarifying data from the full image? Because it's not just upsampling when the source image is completely unknown, but JXL has access to the full image before downsampling (although lossy compression will be an issue here as well, because it's already a distorted image compared to the source)

jxl preserves good the hair with new heuristics s 5

if you want more preservation of banding and grey texts and less ringing s7 is way better

without new heuristics

to me would be good if the two heuristics were all the two good

Also https://news.ycombinator.com/item?id=26513518

https://arxiv.org/abs/1708.07029v3

PNG: ``` 146 718 - oxipng 124 692 - optimised with many programs (the uploaded file) ``` JXL (v0.5.0, MacOS): ``` 171 877 - -q 100 138 974 - -q 100 -e 9 133 996 - -q 100 -e 9 -E 3 -I 1 133 844 - -q 100 -e 9 -E 3 -I 1 -g 0 122 781 - -q 100 -e 9 --palette 1000000 -I 2.46 -g 3 118 651 - -q 100 -e 9 --palette 1000000 -I 1 -g 3 -P 0 ``` WebP: ``` 102 992 - -lossless 101 450 - -lossless -z 9 ``` Does anyone know why JPEG-XL struggles with this image, while WebP is able to perform better, or does anyone have some parameter suggestions which outperform WebP? -P 0 was a happy mistake, I meant to try something else but mistyped.

try -g 3 -I 0 -P 0 -e 9

or other small -P values

Ok, there is some progress: ``` cjxl 0.jpg 7.jxl -j -e 7 cjxl 0.jpg 8.jxl -j -e 8 cjxl 0.jpg 8p.jxl -j -e 8 --patches=0 JPEG XL encoder v0.6.0 688f915 [SSE4] Name Length ---- ------ 0.jpg 2097141 7.jxl 1291696 8.jxl 1297652 8p.jxl 1297029 ```

try with `-s 9 -I 0 --patches=0 -g 3 -P 0` 🙂 or -s 8 if you want that to be faster

nah, doesn't work

https://imagick-filters-comparison.netlify.app/

Is robidoux / robidouxsharp better than lanczos for downscaling?

I prefer Mitchell myself, but it's a matter of taste

Doing it in linear color is the most important thing (most things like default imagemagick and browsers do it in nonlinear space)

Does it work in linear scale if I use like this? `convert {input} -colorspace RGB \ -filter Lanczos -define filter:blur=.9891028367558475 \ -distort Resize 20% -colorspace sRGB {output}`

Yes

I don't particularly like Lanczos in linear space, I think it somehow looks better in nonlinear space

Most important is to do rescaling at a higher bit depth and then dither to the original depth.

<@!263309374775230465> `magick {input} -colorspace RGB +sigmoidal-contrast 6.5,50% -filter Lanczos -distort resize 20% -sigmoidal-contrast 6.5,50% -colorspace sRGB -ordered-dither o8x8,256 {output}`

Yes, I consider it a given in image processing that processing is done with more precision (ImageMagick typically uses uint16 internally, though you can also compile it to use float instead). But yes, this is not always done (some downscalers don't, to save memory), and the dithering when going back to lower precision is a good point, I wasn't doing that yet actually. It might be a bit risky on nonphotographic images though, no?

Are the values 6.5,50% specific to lanczos or is it okay to use them on any other algorithms?

I see some vertical strips and grids on image with this method.

> It might be a bit risky on nonphotographic images though, no? No, why should it?

One is with, the other is without dithering.

Dithering is only not recommended if your "nonphotographic" means images with a small color palette. But there you wouldn't wanna use Lanczos or even linear space.

It's okay if the other algorithms are similar to Lanczos. :D

What do you mean?

If you zoom the image resized with -ordered-dither, there are visible dots in the image on 2x zoom.

Do you have an example image where this happens?

Did you use `o8x8,256`?

Yes

I mean something like a screenshot

Or an illustration with large areas of solid color

Solid colors won't change with dithering since they will always round back to the original color.

http://0x0.st/-vSN.mp4

This looks like it's using a total of 256 colors instead of 256 per channel. What do you use for input/output?

Maybe try `+channel -ordered-dither o8x8,256`.

I used a 16mp 8-bit jpeg input and output a png.

I get error, unrecognised option "+channels"

Sorry, I think it should be channel without s. Otherwise convert to PNG first.

Same patterns / dots with png input Adding +channel also didn't fix it.

magick pexels-lisa-1083822.png -colorspace RGB +sigmoidal-contrast 6.5,50% -filter Lanczos -distort resize 56.25% -crop 200x200+200+200 -sigmoidal-contrast 6.5,50% -colorspace sRGB +channel -ordered-dither o8x8,25 -strip dither.png

Hm, also experimented with scaling modes and got some interesting results

Source images:

Upscale?

In the file names in this sequence: 1. FSR 2x 2. JXL `-s 7 -d 0.1 --resampling=2` <https://github.com/libjxl/libjxl/pull/533> 3. IM Downscale `-colorspace RGB -define filter:window=Quadratic -colorspace sRGB` + Upscale `-colorspace RGB +sigmoidal-contrast 7.5 -define filter:window=Jinc -define filter:lobes=3 -resize 200%% -sigmoidal-contrast 7.5 -colorspace sRGB` 4. IM Downscale `-colorspace RGB -filter Triangle -define filter:blur=.84549061701764 -colorspace sRGB` + Upscale `-colorspace RGB +sigmoidal-contrast 7.5 -define filter:window=Jinc -define filter:lobes=3 -define filter:blur=.88549061701764 -sigmoidal-contrast 7.5 -colorspace sRGB`

- ```Butteraugli: 7.6523346901 3-norm: 2.521169 SSIMULACRA: 0.06312216 DSSIM: 0.00412691 0m8z22tarcu11.FSR.png Butteraugli: 13.6175022125 3-norm: 4.015311 SSIMULACRA: 0.05405400 DSSIM: 0.00434414 0m8z22tarcu11.jxlR2.png Butteraugli: 7.5799150467 3-norm: 2.412462 SSIMULACRA: 0.05904124 DSSIM: 0.00377530 0m8z22tarcu11.Quadratic_Ginseng3lobe.png Butteraugli: 7.8739781380 3-norm: 2.502248 SSIMULACRA: 0.05676201 DSSIM: 0.00292210 0m8z22tarcu11.Triangle_Ginseng3lobe.png ```

- ```Butteraugli: 7.9676017761 3-norm: 2.755792 SSIMULACRA: 0.07913098 DSSIM: 0.00589904 1h1rt.FSR.png Butteraugli: 14.3376636505 3-norm: 4.135510 SSIMULACRA: 0.07626729 DSSIM: 0.00642091 1h1rt.jxlR2.png Butteraugli: 8.1583213806 3-norm: 2.687468 SSIMULACRA: 0.08273491 DSSIM: 0.00552542 1h1rt.Quadratic_Ginseng3lobe.png Butteraugli: 8.1548051834 3-norm: 3.053624 SSIMULACRA: 0.07447507 DSSIM: 0.00490394 1h1rt.Triangle_Ginseng3lobe.png ```

- ```Butteraugli: 6.6735296249 3-norm: 1.567400 SSIMULACRA: 0.02005278 DSSIM: 0.00057343 2048x1320_carli-jeen-431.FSR.png Butteraugli: 6.3593711853 3-norm: 1.481147 SSIMULACRA: 0.01801966 DSSIM: 0.00043071 2048x1320_carli-jeen-431.jxlR2.png Butteraugli: 6.5563468933 3-norm: 1.418699 SSIMULACRA: 0.01828603 DSSIM: 0.00039971 2048x1320_carli-jeen-431.Quadratic_Ginseng3lobe.png Butteraugli: 5.8666715622 3-norm: 1.489459 SSIMULACRA: 0.01838885 DSSIM: 0.00048951 2048x1320_carli-jeen-431.Triangle_Ginseng3lobe.png ```

- ```Butteraugli: 7.3742027283 3-norm: 2.502985 SSIMULACRA: 0.10612870 DSSIM: 0.00516059 2048x1320_cayton-heath-60402.FSR.png Butteraugli: 7.9369306564 3-norm: 2.574979 SSIMULACRA: 0.09597047 DSSIM: 0.00424789 2048x1320_cayton-heath-60402.jxlR2.png Butteraugli: 6.8346881866 3-norm: 2.322578 SSIMULACRA: 0.09891145 DSSIM: 0.00444520 2048x1320_cayton-heath-60402.Quadratic_Ginseng3lobe.png Butteraugli: 6.2368092537 3-norm: 2.140422 SSIMULACRA: 0.09588916 DSSIM: 0.00338383 2048x1320_cayton-heath-60402.Triangle_Ginseng3lobe.png ```

- ```Butteraugli: 6.7863245010 3-norm: 2.206729 SSIMULACRA: 0.06249440 DSSIM: 0.00245042 2048x1320_davey-heuser-696.FSR.png Butteraugli: 10.3410911560 3-norm: 2.722653 SSIMULACRA: 0.05824124 DSSIM: 0.00209300 2048x1320_davey-heuser-696.jxlR2.png Butteraugli: 7.0041656494 3-norm: 2.180330 SSIMULACRA: 0.05992117 DSSIM: 0.00227412 2048x1320_davey-heuser-696.Quadratic_Ginseng3lobe.png Butteraugli: 6.7900328636 3-norm: 2.217274 SSIMULACRA: 0.05718720 DSSIM: 0.00178303 2048x1320_davey-heuser-696.Triangle_Ginseng3lobe.png ```

- ```Butteraugli: 6.0690393448 3-norm: 1.759394 SSIMULACRA: 0.05738130 DSSIM: 0.00163084 2048x1320_jean-lakosnyk-1325.FSR.png Butteraugli: 5.9236259460 3-norm: 1.652864 SSIMULACRA: 0.05371557 DSSIM: 0.00123964 2048x1320_jean-lakosnyk-1325.jxlR2.png Butteraugli: 5.9563336372 3-norm: 1.657374 SSIMULACRA: 0.05391854 DSSIM: 0.00131542 2048x1320_jean-lakosnyk-1325.Quadratic_Ginseng3lobe.png Butteraugli: 5.9652943611 3-norm: 1.927614 SSIMULACRA: 0.05329959 DSSIM: 0.00153713 2048x1320_jean-lakosnyk-1325.Triangle_Ginseng3lobe.png ```

- ```Butteraugli: 8.0101423264 3-norm: 2.390688 SSIMULACRA: 0.07831928 DSSIM: 0.00531854 2048x1320_william-iven-5893.FSR.png Butteraugli: 11.6504716873 3-norm: 3.314981 SSIMULACRA: 0.07232501 DSSIM: 0.00515426 2048x1320_william-iven-5893.jxlR2.png Butteraugli: 7.0145583153 3-norm: 2.245753 SSIMULACRA: 0.07329559 DSSIM: 0.00449057 2048x1320_william-iven-5893.Quadratic_Ginseng3lobe.png Butteraugli: 6.5637097359 3-norm: 2.364674 SSIMULACRA: 0.07382710 DSSIM: 0.00386518 2048x1320_william-iven-5893.Triangle_Ginseng3lobe.png ```

- ```Butteraugli: 8.2909440994 3-norm: 1.939780 SSIMULACRA: 0.02393107 DSSIM: 0.00088207 2048x1320_zugr-108.FSR.png Butteraugli: 8.3663911819 3-norm: 1.940193 SSIMULACRA: 0.02165503 DSSIM: 0.00065602 2048x1320_zugr-108.jxlR2.png Butteraugli: 7.1139197350 3-norm: 1.703904 SSIMULACRA: 0.02179263 DSSIM: 0.00066908 2048x1320_zugr-108.Quadratic_Ginseng3lobe.png Butteraugli: 6.6433234215 3-norm: 1.849612 SSIMULACRA: 0.02218326 DSSIM: 0.00070112 2048x1320_zugr-108.Triangle_Ginseng3lobe.png ```

- ```Butteraugli: 11.6934757233 3-norm: 3.486321 SSIMULACRA: 0.08302297 DSSIM: 0.00834876 zcnvlaon81541.FSR.png Butteraugli: 13.5171709061 3-norm: 4.207612 SSIMULACRA: 0.06727552 DSSIM: 0.00756088 zcnvlaon81541.jxlR2.png Butteraugli: 10.5054244995 3-norm: 3.325153 SSIMULACRA: 0.07742532 DSSIM: 0.00720557 zcnvlaon81541.Quadratic_Ginseng3lobe.png Butteraugli: 9.6023273468 3-norm: 3.450314 SSIMULACRA: 0.07479131 DSSIM: 0.00546741 zcnvlaon81541.Triangle_Ginseng3lobe.png ```

Metrics are also interesting

Quadratic downsampler is sharper, with clearer lines, but makes artifacts on the sharp edges, Triangle is less sharper, the lines are very jagged, but it does not have as noticeable artifacts and in general it seems that it is closer to the original

<@111445179587624960> have you tried this? https://forum.luminous-landscape.com/index.php?topic=91754.0;wap2

No, just personal experiments on the visual result to find something in between that will work for photos as well as art and text

You use 25 and not 256.

so something went wrong during copy paste. sorry lol

unscaled, scaled with no dithering, scaled with 2x2 ordered dithering, 4x4 and 8x8

<@!794205442175402004> Well... are you going to use dithering by default now?

maybe - for rendering I think it's always a good idea, for compression maybe not always

If you are concerned about compression, then your type of downsampling will have a greater impact than dithering.

I do have a random CL for doing ordered dithering at decoding time

it helps

does anyone know if ImageMagick does any dithering when converting its internal 16-bit buffers to 8-bit to encode them?

What's a random CL? Anyway, if you would want to dither at decode time, you would have to store IM's output with more than 8 bpc. But maybe worth testing how much larger an image would get when storing the resized version at 10 or 12 bpc.

It doesn't. And it also doesn't use Lanczos and doesn't rescale in linear space by default. GIMP let's you choose what dithering to use when converting to 8 Bit but I don't remember what it displays as default. Audacity dithers by default though.

"random CL" here means "piece of code that was not submitted nor reviewed nor (I think) is visible in github or publicly anywhere" 😛 anyway, it does ordered dithering when doing the final float to 8bit integer conversion

😮 Oh, so you mean lossy JXL specifically. Why did you do that in secret? And can't you just let that piece of code slip into the main branch with something you are meant to implement? 🤫

in secret: because we didn't switch to github yet 😛

I think it was done before we moved to github

it's not necessarily specific to lossy actually

I saw some WIP merge request on the private gitlab iirc

and I *could* add it to the main branch, but implementing ordered ditherhing is not the hard part... the hard part is figuring out how to ask for it

I would either just always do it when int buffers are returned, or do it by default and have a decode option to disable it

if you open an issue and/or discuss it with Lode... 😛

I'd add it as a pixel format flag

Ah, yes, of course. It would also be nice for >8 bpc lossless. But the main complaint I had was that lossy JXL removed dithering from 8 bpc sources for it's internal representation but it doesn't add it back when decoding to 8 bpc and just strips away that additional info.

<@!179701849576833024> Who is Lode?

we don't remove dithering

Lode is <@!768090355546587137> - aka one of the people that designs the API

Maybe not intentionally but it does happen.

yes, that I totally believe

I don't see the harm in adding it - but again, probably better discussed in an issue or something like that

Ok, I will create an issue for that on GitHub soon.

Mozjpeg q90 jpg to jxl 14-15% savings.

Biggest savings will be with the stupidest jpeg encoders like what cameras or default libjpeg-turbo produce (no huffman optimization, sequential). With encoders like mozjpeg that already do optimized entropy coding, it makes sense that the savings are smaller.

Still 14% savings is better than 7%. Like someone claimed on reddit

ehhh

try q89

I suspect it will be worse

(i.e. on 420)

http://0x0.st/-wze.jpg

We're a bit worse on 420 because chroma from luma cannot be used there, but I don't expect that to make more than 2-3% difference

It would be interesting to make some plots on some corpus of what the savings are (say as a boxplot) w.r.t. different jpeg encoders/settings

(420 vs 444, mozjpeg vs libjpeg-turbo default vs libjpeg-turbo -optimize -progressive, q10 to q100, something like that)

Also, we _could_ try to improve jpeg recompression. Afaik we haven't really done much to try to get its DC to compress better or to tweak the choices in the AC ctx model in the case of jpeg recompression, besides the initial things we did there to get good enough to drop brunsli...

IMO using Jpeg recompression mode for comparing with jpg seems funny. Like the unlord guy on reddit

Ah yes of course that's not how you should compare jxl lossy compression to jpeg lossy compression

<@!768090355546587137> My part of the arrangement is done: https://github.com/libjxl/libjxl/issues/541 ;) ^^

https://res.cloudinary.com/mattgore/064_crop_bad_extra.webp https://res.cloudinary.com/mattgore/064_crop_good_extra.webp

for all that I notice the improvement, there is still a bit of banding 😛

having said that, much harder to notice

but dithering has another issue: it disappears when you zoom...

Zooming is done independent from JXL, so that's nothing libjxl should worry about.

Btw, it also only disappears when zooming out. At least on the web, displaying images with a higher pixel density than what the screen is capable is rather unlikely. Tiny previews will be new and smaller image files. HiDPI screens might get pictures with better resolution but I don't think these would exceed the displays' capabilities.

nah, at least in Chrome it also disappears when zooming in, unfortunately...

Huh, how does that happen?

Ughhh, that's awful, I just checked. But how does Chrome mess that up? Still, I think I heard that Chrome grabs the 32 Bit floats directly for its HDR pipeline or something. So Chrome is responsible for dithering anyways (which it currently doesn't do).

What is the approximate cjxl's -d value for mozjpeg q60?

it would vary between images, but for me it took -d 10.7 to get similar quality

A simpler way is to measure by Butteraugli the average values of the images with mozjpeg q60 and this will roughly be the distance

What do you want to get? Similar quality or similar bitrate?

It's actually 16 bit floats ;) and I agree chrome should do better

Quality

Just want to post some benchmark values whenever I see someone say, jxl is not better than jpeg for webuse.

mhhh... I think we map cjxl's -q 60 to roughly -d 4... but I don't know how well that corresponds to mozjpeg -q 60

but I'd also say -q 60 is pretty much the low end of web use by most accounts

Facebook is interested in -d 3, and facebook (like any social media) is not exactly known for its high-fidelity transcoding

I'd say -d 2 is more or less a reasonable setting for 'median web quality'

Maybe -d 1 for high-fidelity use cases (luxury brands who really don't want to see any artifacts on their expensive products), -d 3 for high-traffic use cases (or developing world use cases) where saving bandwidth is more important than preserving fidelity

Maybe -d 4 for those who really want to risk artifacts to save bandwidth, but I think it's the low end indeed

more like 3.5 - IIRC they use ~ `-q 65` (a random attempt with imagemagick's identify says 71, but...)

Yes, with jpeg now, maybe with jxl they would use a bit higher fidelity than what they do now though, no? If it still gives good density improvements compared to what they do now...

maybe

Anyway, let's say they keep doing ~d3.5, I still consider fb/twitter to be at the lower end of what "web image quality" is, they obviously have lots of traffic and it's all UGC so if it looks like crap it's basically not their problem as long as it doesn't hurt engagement (unlike say brand websites where crappy images directly reflect poorly on the brand)

Companies like Nike (one of our customers) are doing more like ~d1.5, if I have to give a ballpark number for it

thats part of a reason i cant bear going to fb its just too crappy experience

The image quality is not the worst thing on fb imo, the people are often worse 😅

Having original versions of images/videos is actually a really nice feature of Discord

there actually are some p cool people but i didn't find them from my irl connections

so it may b a bit difficult

i prefer vk as site but i don't really browse it much either, other than follow some artists

its got open original function too :>

I take it you haven't seen FB_GENLOSS_DCT_CRUD.jpg.jpg.jpg.jpg

Ah yes, generation loss is a big problem when things travel between social media platforms and they all stupidly recompress from pixels

Some memes get so deep-fried by jpg that the text becomes nearly illegible

tfw deep fried memes are really a cultural relic of FB_jpg.jpg

also you say "they all stupidly recompress from pixels"

but keep in mind that this is largely the fault of browsers rather than users

a user sees and image and right clicks and picks "copy image" and then goes to another tab and pushes Ctrl+V, it's whatever is handling the clipboard that only supports pixel data (or PNG) clipboards doing the decoding

which atm is all major operating systems' UI

you can't expect users to right click save image to hard drive and then upload it

i think more people are hitting save on their phones than right clicking and hitting copy

that might be true, but the point still is there

also how deep fried an image is is a good indication of how much it has been reposted

users aren't recompressing images cause they don't know better, users are doing whatever is convenient for them

so i too find merit in deep fried memes

and it's the responsibility of the software they use to make the convenient thing the correct thing, IMO

like I don't think you can blame users for this

Copy/pasting images is a relatively recent thing though, no?

Before that, it was always download and then reupload

Afaik, fb and twitter etc still recompress anything you throw at them, even if it's a q20 jpeg, even if the recompressed fils is 5x as large as what you uploaded

From what I remember it has been a thing for about a year or 2

Definitely could be wrong

Yes, something like that I think

That's relatively recent - fb and twitter are quite a bit older than that

Heavy png

Thats with the first example image default

17 seconds for the Image

Is jxl wasm snapdragon 780g not really faster than i3 330m maybe on wasm a bit but dont know Just see the screenshots i made

```Lossless recommendations comparison 2021-09-27 g0 = cjxl -d 0 -e 9 -E 3 -I 1 -g 0 g1 = cjxl -d 0 -e 9 -E 3 -I 1 -g 1 g2 = cjxl -d 0 -e 9 -E 3 -I 1 -g 2 g3 = cjxl -d 0 -e 9 -E 3 -I 1 -g 3 P0 = cjxl -d 0 -e 9 -I 0 -P 0 -g 3 --patches 0 P4 = cjxl -d 0 -e 9 -I 0 -P 4 -g 3 --patches 0 WebP = cwebp -z 9 -metadata all PNG = pingo -s9 -nostrip cjxl v0.6.0 0.6~alpha20210820161555-0+gite00ac57 cwebp v1.2.0 pingo v0.99 Total images 222 2D art 42 3D art 18 comic/manga 16 generated 8 graphic 11 misc 11 mixed 23 photo 49 pixel art 23 reduced palette 4 text 17 encoder mean bpp savings wins g0 3.559 31.19% 9 g1 3.475 32.81% 19 g2 3.451 33.28% 59 g3 3.577 30.86% 105 P0 6.302 -21.83% 19 P4 5.469 -5.72% 0 WebP 4.025 22.18% 20 PNG 5.173 0.00% 1 g2/PNG 3.444 33.43% 60 g3/PNG 3.569 31.01% 106 g2/P0/PNG 3.435 33.60% 79 g3/P0/PNG 3.562 31.15% 125 g2/WebP/PNG 3.421 33.87% 80 g3/WebP/PNG 3.531 31.73% 126 g2/g3/PNG 3.427 33.76% 159 smallest 3.386 34.55% 222```

what does g2/PNG mean? smallest of g2 and PNG?

Yes. I figure if you have a bunch of PNGs to start with, it makes sense to compare to their original size and keep the smaller file.

'smallest' takes the smallest file out of all 8 options.

good to know that -I 0 -P 4 is never useful...

funny to me that the P0 has a much worse average than P4 but P4 still has no wins

By bpp, the closest P4 got to a win was on this image: P4 0.139 bpp, WebP 0.127 bpp. P0 was also slightly better than P4.

IT LOOks blurrier than -d 0.843 -s 8 -I 0.881

as the image i'm seeing with jpg there is a tiny difference

that's an original jpg

as you can see is better in some parts

jxl it looks like a 91,8 kb image

i'm trying -q 97.78 -I 0.878 -s 9 --use_new_heuristics

639 kb vs 125 kb vs 284 kb

use -q 91.028 -s 8 for jpg source

if you want to convert

that's original of jpg screenshots of xiaomi 639 kb

so is normal that any encoder can't make miracles

i'm using now HIQ ocr screenshot but the png are 8 bit so don't know is it a problem?

If it is an SDR display that will be fine.

no i 'm talking if i want to re encode those images in jxl s 7 d 1

will they display good

the encoder will do the most optimal conversion

considering they are switching more pipelines to 16 bit

and floats works at 32 bit internally

The 16th bit error on an 8 bit input will be insignificant, so that should be totally fine.

Even less significant for the 32 bit floats.

should i delete HIQ ocr screenshot and try to find another program without ads than can shoot png in 16 bit

maybe in f droid

because i have f droid

Surely for an accurate representation you want to capture the pixels rendered to the screen, which will probably be 8 bit, or if it really is HDR then 10 bit?

HIQ ocr screenshot don't have ADS

i have a 400 euros phone

i feel on those type of image avif is more efficient and if properly tuned and using cpu can re encode those image well

also on those type of image delta palette s 9 is more efficient

for jpg encoding is already the best the build jamaika did

for animation it can be improved currently is only 1:8 compression but the legs are rendered rightly ways

for png is great it has very low bpp and it looks good

it can reduce your image to 85% less from jpg

png not tested but should be higher

is a bit slow 39 minutes to encode 310 images, is right i can duplicate the command

FOR FB PHOTOS THOUGH IT SUCKS

In reencoding

The new algorithm has Better speed 1 mpx s

30.3 kb getting good appeal in cjxl

THOUGH jaimaka encoder was good as s1 d1

D 1 not good for fb photos trying s 8

A bit improved in the -d 0.568 -s 8 -I 0.238 range

but not for fb

`-e 9` is faster now, but compression has suffered. Tried it on one random jpeg:

``` PS > Measure-Command {cjxl 0.jpg 1.jxl -e 9} JPEG XL encoder v0.7.0 c31dca7 [SSE4] Read 4296x2709 image, 38.0 MP/s Encoding [Container | JPEG, lossless transcode, tortoise | JPEG reconstruction data], 4 threads. Compressed to 6131413 bytes (4.215 bpp). 4296 x 2709, 0.06 MP/s [0.06, 0.06], 1 reps, 4 threads. Including container: 6132075 bytes (4.215 bpp). TotalSeconds : 198,4053449 PS > Measure-Command {cjxl 0.jpg 3.jxl -e 9} JPEG XL encoder v0.7.0 0c5cf04 [SSE4] Read 4296x2709 image, 42.1 MP/s Encoding [Container | JPEG, lossless transcode, tortoise | JPEG reconstruction data], 4 threads. Compressed to 6152671 bytes (4.229 bpp). 4296 x 2709, 1.03 MP/s [1.03, 1.03], 1 reps, 4 threads. Including container: 6153333 bytes (4.230 bpp). TotalSeconds : 11,7175869 ```

I think it's because: > don't call ClusterGroups() at -e 9, it makes -e 9 extremely slow for little benefit

Maybe try it on a few more jpegs to get some more data points

I only tried it on a bunch of ImageMagick/libjpeg-turbo encoded q70/q90 jpegs, and there I had one or two that got larger and 20 or so that became smaller

A few images. The changes are confusing:

``` Name Length ---- ------ 1_e8.jxl 6273416 * 1_e9.jxl 6275158 1.jpg 6765844 2_e8.jxl 3962774 * 2_e9.jxl 3964212 2.jpg 4180185 3_e8.jxl 8101448 * 3_e9.jxl 8103363 3.jpg 9316706 4_e8.jxl 6155635 4_e9.jxl 6153333 4.jpg 6866353 5_e8.jxl 2648770 * 5_e9.jxl 2648938 5.jpg 3271338 6_e8.jxl 4775569 * 6_e9.jxl 4777064 6.jpg 5333906 7_e8.jxl 3342097 * 7_e9.jxl 3343268 7.jpg 3958760 8_e8.jxl 4841488 8_e9.jxl 4791002 8.jpg 5939988 9_e8.jxl 3998137 9_e9.jxl 3997743 9.jpg 4763973 ```

I do imagine that not doing ClusterGroups() does come at a cost in density, it's just that it made e9 really, really slow

What are the stars?

It would be useful to have before/after numbers

`-e 8` gives a smaller size than `-e 9`

Ah, interesting

I suppose we're still not really estimating very well what the signaling cost of the MA tree itself is, or something like that.

I don't have the "old" `cjxl` before the commit at the moment, but I'll try to compare later with the encoding time.

``` Old value -> New value Filename - original size Time in seconds Size in bytes Speed 1.jpg - 6765844 1,13 -> 1,53 6277585 -> 6273416 -e 8 545,36 -> 11,17 6241508 -> 6275158 -e 9 2.jpg - 4180185 0,53 -> 0,8 3962310 -> 3962774 -e 8 80,03 -> 6,48 3932227 -> 3964212 -e 9 3.jpg - 9316706 1,86 -> 2,5 8109369 -> 8101448 -e 8 674,61 -> 22,32 8098279 -> 8103363 -e 9 4.jpg - 6866353 1,35 -> 1,69 6165978 -> 6155635 -e 8 207,34 -> 11,79 6132075 -> 6153333 -e 9 5.jpg - 3271338 0,76 -> 1,07 2652490 -> 2648770 -e 8 59,58 -> 7,71 2651724 -> 2648938 -e 9 6.jpg - 5333906 0,92 -> 1,39 4780156 -> 4775569 -e 8 221,03 -> 9,81 4768952 -> 4777064 -e 9 7.jpg - 3958760 1,12 -> 1,6 3345219 -> 3342097 -e 8 240,11 -> 9,11 3339234 -> 3343268 -e 9 8.jpg - 5939988 0,72 -> 1 4846401 -> 4841488 -e 8 275,21 -> 7,41 4785088 -> 4791002 -e 9 9.jpg - 4763973 0,73 -> 0,97 4001580 -> 3998137 -e 8 69,88 -> 6,65 3999953 -> 3997743 -e 9 ```

6 of 9 files are `-e 8` smaller than `-e 9`

That's kind of weird

What's the source encoder of the jpegs? Phone camera?

`1-7` - art and photos from the Web `8,9` - photos taken by GoogleCameraMod with jpeg quality 95 or 97

I can share these images if necessary

is that useful? should I upload more of these for the other images?

at different distances maybe?

Yep, some difference is noticeable, it might also be useful to look additionally at something like -d 8, for extreme cases

There seems to be less ringing artifacts in some places and it even partially helped with the color bleeding/shifting

d8 looks like crap of course, both before and after

overall statistics on this specific test set:

before:

``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm pnorm BPP*pnorm Bugs ------------------------------------------------------------------------------------------------------------ jxl:d0.5 14239 2624388 1.4744184 1.360 21.978 1.76332939 0.35466592 0.522925947102 0 jxl:d1 14239 1852011 1.0404860 1.320 16.866 2.35046148 0.63201660 0.657604433829 0 jxl:d2 14239 1254321 0.7046953 1.420 16.568 3.52525187 1.04249624 0.734642204710 0 jxl:d3 14239 985148 0.5534701 1.288 16.642 4.95267868 1.15051804 0.636777333556 0 jxl:d4 14239 820963 0.4612286 1.033 6.274 6.99091768 1.46571926 0.676031706800 0 jxl:d6 14239 631128 0.3545767 0.997 5.915 8.09897232 1.90482258 0.675405611653 0 jxl:d8 14239 520709 0.2925417 1.030 6.309 11.11856842 2.37287773 0.694165665527 0 Aggregate: 14239 1071385 0.6019191 1.195 11.328 4.62918211 1.08595991 0.653659975689 0 ```

after:

``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm pnorm BPP*pnorm Bugs ------------------------------------------------------------------------------------------------------------ jxl:d0.5 14239 2553538 1.4346138 0.863 16.136 1.57890558 0.36139130 0.518456956764 0 jxl:d1 14239 1790680 1.0060294 0.947 12.760 2.34807730 0.64451073 0.648396741124 0 jxl:d2 14239 1202531 0.6755990 0.985 15.021 3.82520533 1.06690052 0.720796872575 0 jxl:d3 14239 942403 0.5294554 0.948 11.234 6.67540455 1.21610050 0.643870923626 0 jxl:d4 14239 783129 0.4399730 1.014 6.837 7.27154827 1.54661112 0.680467080304 0 jxl:d6 14239 601603 0.3379891 1.025 6.948 11.29334736 2.05752738 0.695421799655 0 jxl:d8 14239 496335 0.2788480 1.028 7.453 11.60211468 2.59731948 0.724257429195 0 Aggregate: 14239 1027817 0.5774423 0.971 10.300 5.10368599 1.13970732 0.658115235775 0 ```

so according to bpp*pnorm, it's an improvement at d0.5, d1 and d2, and a regression at higher distances

(but of course the question is to what extent butteraugli can be trusted for this type of image content at high distance, since that's not really what it was designed for)

Yep, -d 8 is excessive, but a lot of people like to compare at this quality and also the less noticeable artifacts - the more people like the result (on the loss of detail or blurring usually pay less attention) It would also be interesting to see if these changes would help on top, though it would probably require re-tuning 🤔 <https://github.com/libjxl/libjxl/pull/403>

Later I will also look at the difference as soon as I can compile

You will do only for avx2

this i like more as it is

https://sneyers.info/comparison/before/cloth.png.jxl_d2.7_epf0.png

at what distance?

d 4.0 looks good definitely something i would use on new heuristics

if i had same build

i'm also comparing with original

but currently i did the worst settigns

at d 4 this isn't preserved

well it is kind of to be expected at d4 that fidelity is not good

question is if my changes cause it to be worse than it was or not

d1 is underexposed way

underexposed?

not worse on d1 worse

d 2.7 epf 0 i don't like it but not sure if worse because i have problems so i can't judge well

and also not good display

i'm watching on a 15,6 samsung

worse

maybe good for the average user but not for me that i'm used to jxl

though this is good

no problem at d1

this was before

this bother me

too fidelity in there

this looks way saturated

it blinded me

d2 is good

d2 is not bad

d1 compressed

the red looks blurry

on my screen

like too sharp on the greens

like it doesn't look drastically different

like on -d 2.36 -s 9 -I 0.656 --epf=2 --patches=0

sure it looks better

and q76 and up look decent

you should optimize for -d 0.847

this same heuristic

scope what you think

at -d 2.769 -s 6 -I 0.551 --epf=2 --patches=1 --gaborish=0 --intensity_target=282

the problem is this read first 4 lines https://discord.com/channels/794206087879852103/803645746661425173/894975996346912790

Lossy quality

^ Yep, #689 is noticeably better overall, although the images are more blurry, but in my opinion it is much better visually perceived and better to sacrifice sharpness but eliminate artifacts as much as possible (in my experience people really hate artifacts)

Yeah. No need for fidelity on low bpp. Just reduce artifacts.