JPEG XL

likely has very different encoder heuristics

Source

New LP (i0p0 - 137 801)

Old LP (257 112)

VarDCT (175 343)

New LP - VarDCT

But, except that the size of the lossless PNG is 24994

Not sure what you were attempting. With `-s 9 -I 1` I was able to get it to 24654.

-I0 -P0 -s 9

should be strictly better than this

This is only a lossy comparison, new lossy-palette, old lossy-palette and VarDCT (I have no goal to get the smallest size by any means, only to compare the quality of different lossy methods)

but tbh, pixel art is not where I'd use lossy palette

Hm... I get some weird error when I try it lossy.

On most content, lossy-palette efficiency is not yet sufficient to be noticeably better than VarDCT (but if the sizes are even smaller, VarDCT is likely to have noticeable artifacts)

Source

WebP NL 40 <https://files.catbox.moe/9zw3lt.webp> New/Old LP (there are still some problems)

Examples with visible fixes in the New LP

Old

New

Old

New

- Noticeable banding and other things in the new and old LP

Source

New

Old

WebP NL 40 <https://files.catbox.moe/ko86em.webp> - Source

New

Old

WebP NL 40 <https://files.catbox.moe/5q1lgd.webp> <@!532010383041363969> ^

png - 28.5 kb webp - 23.9 jxl - 29.2

```Powershell PS > cwebp -z 9 -mt -m 6 -lossless -o keyboard.webp keyboard.png PS > cjxl keyboard.png keyboard7.jxl -m -e 7 -I 1 PS > cjxl keyboard.png keyboard8.jxl -m -e 8 -I 1 PS > cjxl keyboard.png keyboard9.jxl -m -e 9 -I 1 Name Length ---- ------ keyboard.png 29149 keyboard.webp 24600 keyboard7.jxl 27249 keyboard8.jxl 25923 keyboard9.jxl 22296 ```

but it takes more time than webp

I always test with default flags

`cwebp` has had enough years to get all the optimization it needs.

Wait till <:JXL:805850130203934781> has lossless optimization...

qlic2 is better, but for photographs -- for PNGs in the internet webp lossless is better

This one I know how to fix -- it will be next improvement

This one, too

Yes, but it is also noticeably faster than WebP when encoding, at about the same decoding speed, it is also faster (encoding and decoding) and more efficient than the current JXL `-s 2/1` (although there are still possible optimizations) https://discord.com/channels/794206087879852103/803645746661425173/847570960453730334

This looks like it needs a heuristics fix

It doesn't do LZ77 -- and that is the main slowdown in WebP lossless

However, it would be nice to have a very fast and relatively efficient mode for this speed

The overall time and man power spent with cwebp lossless optimization is much much less than that spent on respective JPEG XL side of things

it is just a simple format that matches the PNG images needs rather well

the first version I wrote in 2011 included optimal parsing, predictor search, entropy clustering and it performed very similar to the current version (in density) but was dead slow at encoding, but relatively fast in decoding (50-600 MB/s back then)

I see lossless webp as png on steroids, basically replacing every ingredient of png with a better one (better entropy coding, better lz77 distance encoding, better variable predictors, etc)

As such, it can reliably do better than png, and also have very attractive speed trade-offs.

Lossless jxl is more radically new, containing most of flif/fuif, the weighted predictor, delta palette, and an entirely new way of combining context modeling with predictor selection, and combining statistical entropy coding (ANS) with dictionary entropy coding (lz77).

Doing encoding fast and reliably dense with such a new beast is not trivial though. We haven't even really figured out yet how to do encoding that really leverages all bitstream possibilities at the same time (e.g. doing tree learning and lz77 optimization at the same time, or learning predictor offsets/multipliers)

Yep, but if Qlic2 doesn't do LZ77 but still remains efficient (except for pixel art) and very fast, is it possible to use other methods?

Jxl at speeds < 8 also doesn't do lz77, but it is spending a lot of time on MA tree learning at speeds > 3

I mean, as far as I understand from the past discussions with `-I 0` modes, theoretically it is possible to achieve better efficiency and speed than the current `-s 3`

-I 0 is closer to png / lossless webp

Likely something like the current -s 2 / -s 3 (fixed MA tree so no learning gets done) but with some kind of cheap lz77 matching enabled could be good for fast encoding of various kinds of images (photo and nonphoto)

I see some improvements in the speed of cwebp in 6 years 😄 ```PowerShell PS > (Measure-Command {.\cwebp044 -mt -m 6 -lossless -o then.webp 0.jpg}).TotalSeconds 29,6634277 PS > (Measure-Command {.\cwebp120 -mt -m 6 -lossless -o now.webp 0.jpg}).TotalSeconds 12,8111611 ```

Kinda noticeable mosquito noise & ringing on `-d 1` orig: https://www.pixiv.net/en/artworks/88346344 up to date cjxl (33a23b3)

crop:

<@!532010383041363969> I get the same issue on gitlab issue 147 https://gitlab.com/wg1/jpeg-xl/-/issues/147 And full version image from https://www.pixiv.net/en/artworks/88346344 original png RGBA32 8bit 12.9MB to jxl lossless -s7 6.93MB

I suspect much of that is just adding multithreading, not fundamental algorithmic optimizations. I fixed a terrible density bug somewhere around 0.5.x that did improve image density, particularly so for gray scale images (a ~40 % improvement in that category). Lode improved WebP lossless by making alpha lossy by default and improved the related algorithms. Both fixes were inspired in my attempt to reach near parity with flif -n for internet content. After these fixes WebP lossless was 2 % more dense than flif in the 16-256 kB category of internet PNGs. Marcin (working on Riegeli) extended the near-lossless to work with spatially predicted images.

I have not forgotten.

I understand, Thank you for your reply. 🙂

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

to see how images change from video to image

-d 1.159 -s 7 --use_new_heuristics

first video

then converted to image artificially

i tried to simulate a jpeg xl effect

you could like as jpeg xl effect but the best thing is to save the video or the image and use lossless

v0.3.7-125-g9a3fbdd

now i understood why images use more bytes

so using less than distance where's there is a video image it could enlarge the file size

sorry for the trash image but i don't know better scenes

i hope jyri or raysar won't be furious at me

Ah sudwe font

I try to combine some lossy png encoder and jxl lossless, but I get some lossless compress problem on webp near-lossless. original png RGBA32 8bit (650KB) pingo webp near-lossless 40 (202KB) ImageMagick decode to png (414KB) jpeg xl lossless to jxl (304KB) > cjxl -m -q 100 -s 9 -g 3 -E 3 -I 1 How to optimize jxl lossless compressed file size for dwebp near-lossless image?

dwebp near-lossless 40

It's hard to recompress pixels that have been specifically designed to compress well in another codec

For the same reason why taking a jpeg and converting it to png is a bad idea for compression

so better using -j

converting to png is bad?

> // original png > Input file: 002.png | 666361 bytes > Image: 512x480 pixels | 8 bits/sample | RGB & Alpha | 93463 color(s) > Delta filter: None > Filter per scanline: > 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > Chunks: only critical > > // dwebp near-lossless 40 > Input file: 002.png | 424549 bytes > Image: 512x480 pixels | 8 bits/sample | RGB & Alpha | 91584 color(s) > Delta filter: Mixed > Filter per scanline: > 14444444444444444444444444444444111414444141414444244444424444444244444444444444444444111111444442222222222222224442222222222222444222222222222242422224244224221444444444444444444422444444444414444444444444414444444444444444 > Chunks: only critical

I understand, but other lossy png mode, like pingo pngcolor can compress very well on jpeg xl lossless. pingo pngcolor 60 (341KB) jpeg xl lossless to jxl (232KB) > cjxl -m -q 100 -s 9 -g 2 -e 3 -c 1 webp lossless (217KB)

lossy pngcolor mode is a greedy-palettization mode like this https://github.com/chrissimpkins/greedy-palettization

> // pingo pngcolor 60 > Input file: 002.png | 349427 bytes > Image: 512x480 pixels | 8 bits/sample | RGB & Alpha | 18747 color(s) > Delta filter: Mixed > Filter per scanline: > 44444444444444444444444444444444141444444444444444444444444444444442444444444444444444444444444444444222222424444444224424244224444442422224444444444444444444441444444444444444444444444444444414444444444444444444444444444444 > Chunks: only critical

The current jxl encoder does not make an attempt to use delta palette in a lossless way (in cases where because of unusual luck, that can be done). I think for recompression of near-lossless webp that might be needed/useful.

document with good font https://s3.savethechildren.it/public/files/uploads/pubblicazioni/riscriviamo-il-futuro-una-rilevazione-sulla-poverta-educativa-digitale_0.pdf

There were some basic methods for doing near-lossless in JXL. Do any of them prevent generationloss like near-lossless WebP? (i.e. decoding to pixels and recompressing as lossless JXL will result in the same file size)

In principle, Squeeze could be idempotent, I think

I understand, thank you 🙂

I think that is a great idea and could be deployable. I don't think we should prioritize it right now, but I would welcome a bug that proposes this so that we can keep the idea around.

So funny that you bring this algorithm here. I designed it in summer 2007, tuned it's psychovisuals, and it was Zoltan's intern project. It is a great little algorithm that should not have been forgotten 🙂

after Zoltan's intern project Zoltan and me didn't work together again until 2013, when we started with Brotli's precursor -- a LZMA speed class general purpose compressor (that I cancelled in order to start the actual Brotli)

Lee, perhaps you found it because of some marketing I did earlier?

I suspect -near_lossless=40 is only supported on cwebp -- dwebp doesn't need to know what kind of webp image it is, and cannot tell near lossless and true lossless apart

i do not talked about a idea

i noticed only what video was doing

and tried to explain what i noticed

I consider it a plausible idea for better image compression -- it will be not easy to build, but we like challenges

better image compression isn't simply using d 1.2

obviously i was joking

don't take seriously

d 1.0 is still more efficient

no, I like the idea that we detect a video frame or other blurred rectangular areas and spend less precision there, possibly turn on more blurring than we would otherwise

more blurring in a videoframe

in my experience such adjustments need to be very moderate, like 10-20 % in distance

yeah

so like some d 1.0

looks like d 1.2

will be efficient to do

or jpeg xl will lose quality

i don't know i'm not a video compression expert so i don't know how to measure filesize

How about doing it similar to DjVu? Use a low quality lossy layer for the video frame and a high quality/lossless layer for the remaining text.

DjVu was a great idea. It was released in 1998 as a digital document format.

DjVu's main idea (writing out of memory now) is that images are stored at 100 dpi and black/white (or other high contrast) pixels at 300 dpi

documents on paper (such as A4 or letter) are usually read at a specific distance, i.e., they get the pixels/degree specified because of their domain, and can choose reasonable compromises based on the human vision

300 dpi was matching the resolution of many laser printers at that time (or possibly the lasers from 1995), it wasn't necessary to go higher in their design

JPEG XL allows such a decomposition by layering -- you can have a layer subsampled 2x or 4x, and have black-and-white geometry stored at higher resolution, and photographs at a lower resolution

JPEG XL specifies an extremely high quality upsampling method (non-separable) for layers that in my viewing works significantly better than bicubic or lanczos

I forgot where I found it, I think probably on encode forum or other compress forum. 🙂

Sorry, I'm not clear enough my word, I use webp near-lossless like this, pingo webp near-lossless 40 => dwebp to pixel(png) => jxl lossless compress png. For current jxl implement, only lossy palette can do some lossy thing without DCT, but lossy palette still a experiment option, So I plan use some lossy png tools combine jxl lossless, but look like webp near-lossless decode pixel(png) can't get great compress on jxl lossless compress.

lossy palette will eventually (hopefully soon) be far better than a process with cwebp near-lossless 40, I believe

even when both have the average predictor and the select predictor, it is unlikely that they will be controlled similarly

in webp lossless I decided the predictor for a square, i.e., there is a 4x, 8x, 16x or whaever subresolution image deciding the predictor

in jpeg xl a predictor is decided for a context -- it is different and way more complicated

I am not expecting jpeg xl lossless encoder to do a great job trying to do decisions that were optimal for webp lossless

that's the bad news

the good news is that jpeg xl lossless has a lot of potential that is not yet experimented, I anticipate 2x improvements in many domains

particularly noiseless graphics with gradients through delta palette

but also in pixel graphics we should be able to use the combo of LZ77 and context modeling more elegantly

for example, the palette and the context modeling are so powerful that they allow a 'sprite' to be triggered as a palette entry, and it can be a sprite with some internal conditionals

of course we have nothing like this in the lossless encoder yet, and likely it takes 3-5 years before such things emerge

but the format is really pretty amazing for "near lossless" use

I don't think it's really worth doing, but you could make an encoder that takes into account that the source was optimized/near-lossless webp. E.g. the predictor image could be converted to an equivalent MA tree...

Could do similar things for the tricks various (lossy) GIF and PNG optimizers apply

But I think effort is better spent on making original inputs compress better, than on mimicking various near-lossless things from different formats...

and then the decoder could turn it back into a 2d array so that decoding would be fast ...

We are in total agreement on this 😄

Did some of you find the max visual quality for the same file size compare to the same file size with a lower resolution? For example considering than for the same file size 1420x800 -d 3 is better than 1920x1080 -d 5 I know it's subjective and vary between pictures, but i think it's a great idea to know the max d value before resizing especially for full resolution camera. Exemple here, for me d 3 is the max visual acceptable, for low file size i reduce the resolution. Here 1080p= -d 5 800p= -d 3

https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#2011-03-05-03-13-madeira-159-funchal-mercado-dos-lavradores*3:1&AVIF-AOM=b&JXL=b&subset1 The pillars and the gray wall in the passageway in the center become smooth in AVIF. https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#205-vallee-de-colca-panorama-juin-2010-5-de-6*3:1&AVIF-AOM=m&JXL=m&subset1 The steep rocky part in the shadow in the middle of the image gets thrashed by AVIF. https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#abandoned-packard-automobile-factory-detroit-200*3:1&AVIF-AOM=m&JXL=m&subset1 AVIF has less ringing in the roof lines, but the brick walls of the further away buildings get smoothed. https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#bath-from-alexandra-park*3:1&AVIF-AOM=m&JXL=m&subset1 AVIF ruins the clouds. https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#buenos-aires-cityline-at-night-irargerich*3:1&AVIF-AOM=l&JXL=l&subset1 AVIF has color banding in the sky and turns the water surface into a glossy plastic. https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#cecret-lake-panorama-albion-basin-alta-utah-july-2009*3:1&AVIF-AOM=s&JXL=s&subset1 AVIF destroys the clouds and the lake. Lake gets smoothed a lot yet has visible macroblock edges. https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#citroen-c4f*3:1&AVIF-AOM=l&JXL=l&subset1 AVIF smooths the metal above the wheels. https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#clovisfest*3:1&AVIF-AOM=b&JXL=b&subset1 JXL has more DCT artifacts around the edges, AVIF smooths the clouds and thin lines on the balloons

https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#crepuscular-rays-at-sunset-near-waterberg-plateau*3:1&AVIF-AOM=m&JXL=m&subset1 AVIF makes the top branches disappear against the dark cloud background, sand loses detail, clouds get smoothed, rays of light get blurred https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#eaglefairy-hst-big*3:1&AVIF-AOM=b&JXL=b&subset1 AVIF smoothes everything. https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#end-of-show-3*3:1&AVIF-AOM=b&JXL=b&subset1 AVIF removes texture and detail from the dresses. https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#endeavour-with-columbia-ferry-flyby-gpn-2000-001996*3:1&AVIF-AOM=b&JXL=b&subset1 Visible blocks in the sky in AVIF, also dark parts become a bit too bright (colorspace issue? even lossless AVIF looks different from original here...) https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#florac-le-vibron-source-du-pecher*3:1&AVIF-AOM=m&JXL=m&subset1 AVIF destroys the wall and windows on the top left, also blurs water surface below. https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#grimburgwalamsterdam*3:1&AVIF-AOM=m&JXL=m&subset1 AVIF flattens most of the brick walls, also removes detail in the bottom left part https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#iena-avenches-6*3:1&AVIF-AOM=m&JXL=m&subset1 Horse becomes plasticky. https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#kopenhagen-tivoli-9120*3:1&AVIF-AOM=m&JXL=m&subset1 Diagonal blue/white stripes at the top look cleaner in AVIF, but black whale building gets smoothed in AVIF, bolts on the lighthouse disappear, scales of the green fish in the front disappear.

https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#kryer-ps*3:1&AVIF-AOM=m&JXL=m&subset1 AVIF removes a lot of brushstrokes. https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#lufthansa-aviation-center-after-sunset-frankfurt-germany-near-airport-frankfurt-fraport-03*3:1&AVIF-AOM=m&JXL=m&subset1 AVIF has cleaner edges, but removes a lot of the palm tree detail, and in the side wall on the right, it removes some of the detail (mostly the horizontal features disappearing, keeping only the vertical ones). https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#meg-20110701-japan-expo-02*3:1&AVIF-AOM=m&JXL=m&subset1 AVIF turns the skin (arms, face) into plastic. https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#moscow-july-2011-4a*3:1&AVIF-AOM=l&JXL=l&subset1 AVIF has banding in the sky and blurs the cloud. https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#nymphe-et-amour-tenant-une-guirlande-statues-du-parterre-deau-chateau-de-versailles-p1050390-p1050394-rectilinear*3:1&AVIF-AOM=l&JXL=l&subset1 AVIF smooths the texture of both the statue itself and the stone it is on. https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#ohashi0806shield*3:1&AVIF-AOM=s&JXL=s&subset1 AVIF is way better at preserving nice clean lines at low fidelity bitrates like this (JXL tries to preserve more details but gets nasty artifacts at hard edges). At high fidelity targets (e.g. https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#ohashi0806shield*3:1&AVIF-AOM=b&JXL=b&subset1), JXL becomes indistinguishable from original while AVIF still has noticeable blur.

https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#washington-monument-washington-dc-04037u-original*3:1&AVIF-AOM=m&JXL=m&subset1 AVIF blurs the monument and the clouds a lot, JXL has some ringing around the monument. https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#wasserfassstelle-von-1898-im-schanerloch*3:1&AVIF-AOM=m&JXL=m&subset1 AVIF blurs the waterfall, also at the bottom of the image.

In other words: after spending ~80 minutes on reviewing carefully (putting my BenQ calibrated monitor to good use), in my opinion, the June 8th situation is still similar to what it was in the past: AVIF does a better job at high-appeal, low-fidelity (keeping nice and clean lines even at very bitrates), but is consistently worse than JXL at medium to high fidelity. AVIF especially has a problem in the darks (shadowy regions) and with subtle (low contrast) textures, which systematically get erased, turning all materials into glossy plastic. Even at high bitrates this remains a problem.

this was copied by notepad?

or you used discord for an hour

I just went over the images, typed my remarks in discord, until the message got too long and then I pressed enter 🙂

You've just said that you can apply resampling separately to every layer. Can the same be done with noise synthesis? For example: a screenshot with main Modular layer with text+graphics and separate VarDCT layers for every photo. If those images are noisy, I don't want grain synthesis to be applied to text, it'd ruin the screenshot...

you can

with some limitations, I think you need to either apply noise to the first K layers or to have an extra "put it together" layer

Related question: would it be possible to apply different amount of noise synthesis to different VarDCT layers?

yep, but that likely needs a "put it together" layer

"Put it together" layer? How would it work?

you have 2-3 "pictures" layers that have their own noise levels, and then you paste them with patches on top of a final layer

(possibly a layer with the screenshot parts)

Ok, one last question: Modular and noise synthesis?

Modular can do all the stuff VarDCT can: patches, splines, noise, filters.

(usually only patches would be used though, for lossless. But the bitstream allows it all)

Thank you everyone for answers! 😃

I'm too stupid to understand such an advanced codebase, but I hope I'll ever be able to contribute and make some useful patches...

I did like jxl more than avif even at low bpp on some of the more detailed images

At the lowest settings it retained detail with artifacting while avif just blurred everything

From what I hear both teams are making improvements to quality now

great times for image quality enthusiasts 🙂

I believe I will be able to reduce JXL artifacting 3x as complex consequences of the decision tree reversal in the next three weeks

particularly excited I am about the improvements with d1 (d0.8 - d1.5) category, to get more robustness there, although the biggest improvements I observed in d3-d8 (especially with no or little filtering)

I'd like a fire-and-forget system, where people can just do jxl:d1 and not to think about it, not to review the images if they actually worked (because "it just works")

in the current head there are situations where d1 is not yet visually lossless in many situations (particularly so in some anime), and I am hoping to change that (or at least make a significant improvement)

It already works waaaaay better than JPEG 😃

thank you!! 😄

For most people in regular jpeg q95-98 is the "fire and forget" option I think

Having 1 be agreed on perceptual lossless is nice

I agree with that -- when I reviewed normal jpeg results, I found out that 1 image out of 1000 was not perceptually lossless until I used q98

q94 or q93 yuv444 seemed like the perfect compromise for me

Google+ used to serve q93, while Facebook was serving the other end of quality at 72 and 73 (as identified by 'identify')

that didn't help Google+ 😄

Wow 73 is pretty low

I think Facebook has upgraded their quality from those times (not sure)

Maybe they at least use something like mozjpeg

Though I doubt it

> JPEG XL encoding at speed/effort 6 is as fast as JPEG encoding (using MozJpeg with Trellis encoding enabled). If they reference mozjpeg in speed comparisons, they're probably using it.

mozjpeg can have various speeds depending on encode options

https://www.instagram.com/p/CQG9egMFCuE/

obviously fb uses mozjpeg

i think fb not

but instagram yes

this photo is encoded with mozjpeg

mozjpeg looks like a bit modular lossy jxl

i made the error to sharpen some photo of this

mozjpeg images are already pretty sharp even if they don't present detail

Here's a direct link to a 1080p photo (hosted on Discord):

ahahah

hhahah

however jpeg xl can be a bit improvement for this type of photo and similar to AVIF

building still i don't still particularly the grey grainy and noisy buildings

Wonder if FB and Instagram actually use mozjpeg. When I drop any mozjpeg encoded files in a program like FileOptimizer it can't reduce the file size at all, but with FB and Insta it always reduces it with 1% - 5% (without removing metadata)<a:ThinkingSphere:821038590091329557>

~~Or they use some fast settings at the cost of efficiency~~

Similar for me for Twitter (usually around 2% reduction)

fb uses libjpeg

instagram mozjpeg

but fb images are smaller

instagram images weight a lot

like 190 kb - 340 kb

rarely 182 - 92 kb

yes but instagram images look sharper

i think also fb uses mozjpeg

there is a ringing effect 2:1:0 around q 78

i'm installing xnview

to see estimated quality

Cloudinary uses mozjpeg, but not default mozjpeg (it's a bit too slow). I can imagine facebook does something similar.

xnview lacks estimated quality in the version i installed xnviewmp

the second is estimated 63

the first 80

Note that estimating quality in jpeg is not necessarily very accurate. You can have quantization tables of all ones (the most lossless thing jpeg can do, libjpeg -quality 100) but still do lossy trickery that makes it a much lower quality image.

E.g. guetzli kind of works that way, and you cannot really estimate its quality (because it doesn't really _have_ a libjpeg-style uniform quantization)

`-d 1` on "Reversing the decision tree" pull request. size: 1,237,529 -> 1,221,946 webp animation: old -> Jyrki patch -> original <https://cdn.discordapp.com/attachments/852294618694942750/854459641056722944/jxl_patch_cmp_d1.webp>

Anime fixed

Eugene, thank you!!! 😄

I'll try to make a similar further improvement by adjusting the heuristics to benefit from this change more 😄

Can you spot which is the new Jyrki commit?

tbh both look bad but first one looks less bad in some places

new commit is right

is -d 6, to me new commit is a LOT better, no random colourful noise on flat area

and smoother borders

i see random colorful noise in both sides

is new encode smaller? or is it the same size?

113 KB (old) vs 110 KB (new)

some rose petals look better on the right, some green leaves look better on the left

if it ends up smaller that explains why its not superior

-d 4

could you try adjusting quality a bit so that they end up matching in size?

They both have their own kind of artifacts

Could you upload them as separate images? It'd be waaaay easier to flick between them.

Original

old

new

Right image have less visual artifacts 😍

new image does have noticeably less ringing even though it's almost 3% smaller

this better for some jpgs

it introduces more distortions

it prettify

new encoder you can make finetuning of quality and better standard quality at s 7 and d 1

it's designed for that use

but i think it's designed for png at -d 4r

and not for lossy jpg

although you can do lossy jpg but is way less efficient

v0.3.7-157-gf6d3a89 win_x64 sse4 2021.06.19

if you want less distortions so you want a natural image

and compression

and not great edge compression

you can use

i think best compromise is a raw image with -d 4 -s 8

though the jxl looks like a different resolution

i see only her chin a bit lower in jxl photos

but is a good compromise to me

she looks a bit different like maria elena boschi, a president in jxl, in jpg it looks like a south compain worker

a lot of DCT coefficient DCT

I have to say it looks better than webp and jpg together

good compression

that's a particular of jpg image

you can see her skin ceading

like her nose remain still behind and the cheeks on the right looks very off

in the jpg you can see her becoming older

in the jxl there isn't nothing of this

probably jxl in the new heuristics tries to deblock harder and not guess the intensity of deblock

that's what i hate about new heuristics but for other encoder is transparent on photos with no super great color range

original looks better

obviously the jxl looks sharpened

but is a good compromise

I don't understand your comparison. Why are using a compressed jpg as source?

Just use lossless recompression jpg mode.

this is case when even ewp2 can't encode good

jxl can but at cost of some distortion

this two are all settings for jpg

before i used worse encoders

there is th generation loss problem

that has to be considered

i agree that is loss of details, jxl image looks plasticky and artificial. also new encoder is meant to generate more distortions obviously if you have a raw it will happen less

You could just download raw photos from internet and develop them and use them as source for comparison.

Hello, is there an easy soft to mesure "picture entropy"? i think it's better to use it against bit per pixel. Bit per pixel divided by entropy level could be better 😄

Could use png size as a proxy I guess

I understand that there is: shannon entropy Spatial Disorder Entropy Generalized Ising Entropy Monkey Model Entropy Aura Matrix Entropy But don't know where i can use it ^^ Ok ratio bmp vs png could aproxymate entropy? ^^

For lossless, whatever gives the best lossless compression is the best upper bound available for the actual Kolmogorov complexity

For lossy, it's... complicated

i'm only interested to "estimate" the visual complexity for comparing images with same "complexity".

This issue sample from av1 server Just MPEG-LAlena(Tim's Mom)™, cjxl -d 1.0 -s 8 have some ringing issue on dark red floor for anime content image, (I still can see some tiny noticeable ringing on cjxl -d 0.5). > original-full jpeg q100 444 to floor-original-cut png rgb24

floor-original-cut

floor-original-cut_d1.0_s8

floor-original-cut_d1.45_s8

floor-original-cut_d1.9_s8

floor-original-cut_d0.5_s8

Still waiting for JXL to be good on comicbook images. ```PowerShell PS > avifenc 0.png 1.avif -j 4 -r f -y 444 --min 12 --max 12 -s 4; avifdec 1.avif 1.png PS > (ls 1.avif).Length 57875 PS > cjxl 0.png 2.jxl -e 8 -I 1 --target_size=57875; djxl 2.jxl 2.png PS > ssimulacra 0.png 1.png; ssimulacra 0.png 2.png 0.00605603 0.01064027 ```

Original enlarged crop

AVIF

JXL. Notice how the image has lost the white in the hair.

oof

JXL is a lot noisier too, notice teal artifacts in the bottom right

what did the file size of the jxl end up being?

It's possible that -e 8 does worse than -e 7 on these images

oh wow i have old libjxl, missed that the aur package got renamed

The size is the same. I used `--target_size` to match the AVIF file size and to compare quality only.

interesting

my cjxl doesn't have `--target_size`, does that tune `-d` until the size matches or use some other method? targeting a specific size isn't always the best for efficiency

Yeah, it tries several times with different `-d`.

nice

ooh the code to do that must be interesting, you could probably binary search or something

that's what it does — until the size is close enough. It's a slow way to encode but practical for benchmarking (comparing at same bpp is the fairest thing to do)

for lossy illustrations of the "ligne claire" type, AVIF does get nicer looking results still. There has been progress on improving jxl on these type of images, and there's likely still a lot of room for encoder improvements (especially if we would find ways to actually use splines in an encoder), but the current situation is that avif encoders can go to lower bpp while looking good on these images

In my opinion the main problem with low bpp AVIF are the smearing/smudging/smoothing artifacts that make a photo look like a bit like an illustration of the "ligne claire" type. These artifacts are perfect if that's the style anyway 🙂

Am I understanding it correctly: splines are like brush strokes, and in theory it would be possible for painter program to directly convert brush strokes from a tablet to splines when saving?

AVIF is slower and loses some detail because of its excessive smoothness. In this case, I think we need something in between AVIF and the current JXL.

Something interesting comment from Hacker News, > https://news.ycombinator.com/item?id=27577328 > pavon > Yeah, I agree that webp looks better for many of the images. For most of them it comes back to the subjective issue that webp (and VP9) choose to err on the side of blurring detail they can't encode, while jpeg XL (and x264, etc) try to keep all the detail they can at the expense of more artifacts. There are very vocal proponents of both approaches, and personally I think it varies by the image content. > For all these examples, I was comparing at Small (as with Tiny they were both bad enough but in different ways that I often couldn't decide which was least bad). For the Abandoned Factory and Panthera Tigres, I think the extra detail of JXL looks better than the blurring of WEBP. On the otherhand, I think WEBP looks cleaner than JXL for Buenos Aires, Reykjavik, B-24 Bombers without loosing significant detail. And Avenches is a mix as JXL looks much better than WEBP for the trees and tile roof, but has worse chroma artifacts near the edges of the hat and clothing. > But that isn't the whole story, as for some of the images WEBP seems to both preserve more detail, and have fewer artifacts, such as Air Force Academy Chapel, Pont de Quebec, Steinway and White Dunes. What all these cases seem to have in common is a smooth gradient adjacent to sharp detail. WEBP seems to do a much better job of dealing with that boundary by blurring the smooth part, put preserving the sharp lines. > And if you bump up to WEBP2, the number of cases where it both preserves more detail and has fewer artifacts than JXL increases significantly. I think for current jxl can't work very well on smooth gradient and sharp lines detail area(anime content), probably vardct improve from Jyrki Alakuijala can solve this issue?

Yes, that should be possible in principle. The strokes can vary in thickness and color along the path too. If I'm not mistaken (<@!604964375924834314> correct me if I'm wrong) they are centripetal Catmull-Rom splines (https://en.wikipedia.org/wiki/Centripetal_Catmull%E2%80%93Rom_spline) with an arbitrary number of control points. The thickness and color are (unfortunately) not entropy coded (it's a fixed cost per spline), the control points themselves are compressed though, so you can have quite complex shapes without necessarily needing a lot of bytes.

VarDCT block selection improvements can also help a lot — e.g. we're at the moment only doing naturally aligned blocks that don't cross the 64x64 grid, while potentially the bitstream allows floating blocks (non-naturally aligned) that could move freely within the 256x256 grid.

Another thing that might be worth doing is to use patches as a way to emulate AVIF's palette blocks. In jxl, such 'palette blocks' can have any rectangular shape and positioning, aren't restricted to 8 shades per component, and they can benefit from better lossless entropy coding, so it's in principle strictly more powerful than what AVIF can do — except the jxl encoder isn't trying to do it (and it's not easy to come up with a good way to do it either, in general, without making a very slow encoder).

> a very slow encoder Will it affect the decoding speed?

Splines and patches a bit yes, depending on how many of those have to be drawn.

Though if they reduce entropy of the dct part, it may not be much of a net speed penalty

I've been testing several comic books. Converted them to JXL and AVIF. AVIF's decoding speed in its current state is some pain when you need to scroll through a book quickly. For my purpose, I need JXL to be just a little better in quality for "ligne claire" (need to remember 😄) type images.

we're getting there, Jyrki's recent and upcoming improvements in block selection are helping a lot for those

quick test on a screen shot where quite a bit of patches are used: with patches: 564806 bytes, 3-norm: 0.630946 2560 x 1440, geomean: 70.02 MP/s [35.12, 80.49], 30 reps, 4 threads. without patches: 627161 bytes, 3-norm: 0.677592 2560 x 1440, geomean: 76.06 MP/s [35.87, 88.73], 30 reps, 4 threads.

so there is some decode speed penalty but it's worth it

for VarDCT, not quite binary search — the target butteraugli distance is multiplied by the ratio “actual size ÷ target size”, for 7 iterations

it tends to work quite well: ``` $ tools/cjxl --target_bpp=0.7 _12A2284.png out.jxl JPEG XL encoder v0.3.7 [AVX2,SSE4,Scalar] Butteraugli distance 2.270 yields 1383878 bytes, 0.546 bpp. Butteraugli distance 1.772 yields 1612165 bytes, 0.637 bpp. Butteraugli distance 1.611 yields 1736309 bytes, 0.686 bpp. Butteraugli distance 1.578 yields 1764706 bytes, 0.697 bpp. Butteraugli distance 1.571 yields 1770677 bytes, 0.699 bpp. Butteraugli distance 1.569 yields 1772407 bytes, 0.700 bpp. Butteraugli distance 1.569 yields 1772928 bytes, 0.700 bpp. Read 5554x3648 image, 17.5 MP/s Encoding [VarDCT, d1.569, squirrel], 16 threads. Compressed to 1772928 bytes (0.700 bpp). 5554 x 3648, 20.33 MP/s [20.33, 20.33], 1 reps, 16 threads. ```

flipping thru them, i can say that with inversion it is more better than worse, but there are still locations where it IS worse. encodes with more equal filesize would probably help either confirming or eliminating doubts why that happens

without inversion

with inversion

without inversion is clearly more close to original and artifact is overall less noticeable in this case

I see a lot more rigging on this

I see red color alteration near the line in inversion version

which is more noticeable to me

non-inversion

with inversion

there is noise in both but without inversion one looks smoother from a bit further

I'm just pointing out areas where i find new version to be worse -- it looks better in most cases

in general I see the ringing getting less far away from the hard edge - there is still ringing, but it is closer to the edge itself

those distant haloes/ripples are likely caused by doing dct on a too big block around the edge, better block fitting can avoid that

i just want jxl to do good when the encoded is all blurred

like avif

is because isn't based off video

so it tries to guess quantization

based on your input

I want to preserve low-contrast texture too, not basically vectorize the image into clean hard lines and smooth regions

youtube use hw av1

and is even worse

less blocking in dark areas

but worse quality

in general hw encoders tend to be worse than sw encoders for any codec, they're aimed at fast and cheap encode but typically make compromises in what bitstream features get used and how

the hardware jpeg encode in your camera is very stupid compared to mozjpeg

In this also I like more the not inversion mode, same level of rigging but little more precise color, but not a big deal for me

Tables w/ results `cjxl -m` (v0.3.7 409efe0) Set 1: https://docs.google.com/spreadsheets/d/1zpdrQdr-Gd8FqQxhEi2FSrpd9TeC39YD0uwLxaO6xzM/edit?usp=sharing Set 2: https://docs.google.com/spreadsheets/d/1lgLTP07g-EQQSWOWKEvpxmYAhS5EIujsEcvqJQDglFI/edit?usp=sharing

Look like sometime lossless modular can't choose best method for png pal8 image, need specify some modular option.

we need to find better ways to do lossless at -e 4 to -e 8, it's currently spending a lot of time on tree learning and not enough time on trying different predictors etc

Which ones does it try now?

IIRC best of gradient and weighted, not trying the rest at all

You've just reminded me of an issue with cjxl... https://discord.com/channels/794206087879852103/804324493420920833/852136639546523668

"Tuning ac strategy heuristics 4569267" vs "Reversing the decision tree 3259467" `cjxl -d 1` size: 1221915 -> 1216365 webp animation: `3x zoom` old -> new -> original <https://cdn.discordapp.com/attachments/852294618694942750/857352535894261770/4569267_d1.webp>

why bigger file size

It's commit hashes) upd: Added file-sizes

I'd say it does look better, less ringing overall. Sometimes the ringing just moves position, but often it gets better.

It's also slightly lower bpp so overall that's a win

Some tests with images I already compared some time ago: Source

AVIF

JXL old (2fc78ac54fc3d4f6bc8adf626c9216a5ed8a8ad1, before "Reversing the decision tree")

JXL new

(there is more noticeable ringing with the new build)

Source

AVIF

JXL old

JXL new

Source

AVIF

JXL old

JXL new

Source

AVIF

JXL old

JXL new

Source

AVIF

JXL old

JXL new

Source

AVIF

JXL old

JXL new

In general on medium-low bpp the latest changes are mostly better, except this image

Are you sure you didn't mix them up?

Yep

Source

AVIF

JXL old

JXL new

What arguments did you use? I can't get similar-looking results by using distances from `-d 1` to `-d 5` (old cjxl from april)

`-s 8 --target_size=` Where the size is taken from the AVIF size

All images from the comparison are the same size (I did not compare the same `-d`)

Found it, it's near `-d 3.8` (new cjxl) size: 79085 (0.55 bpp)

btw `-d 3.5` and `-d 4` artifacts are not that noticeable

But yep, AVIF did very well for such bpp (Any low-contrast details is wiped out, but image appeal is there)

the one with hat is no win, th one with dark hair avif wins, the female looks better in jxl (I prefer jxl); the one with flowers i hate avif, bulma looks hanced with AVIF, it's a big no; last one both looks bad;

compare with cavif rs 1.3.0 at similar size using q

start from first image

then do same q for every image, do not change it

Thank you for your work <@!111445179587624960> 🙂

i'm doing new encoding at lower settings

the files are big with progressive

there is now the same bug

the color was encoded wrong

for %i in (C:\Users\User\Documents\source\*.png) do cjxl -q 58.59 -s 7 -p %i %i.jxl

source.zip are encoded jxl files with q 58.59

distance is d 3.827

the mainly improvement is the compression that now at speed 7 it can reach 0.275 bpp more easily

mostly in the 0.414 bpp 0.629 bpp range you'll notice the improvements and with cartoons/ anime drawings and solid objects/screenshots

the mouth can looks less oriented in right and more oriented at left but you gain compression

-d 3.35613 -s 2 --use_new_heuristics

does anyone have a recent PC to run some speed comparisons? I would like to see timings for cjxl (at various speed settings) compared to aom, rav1e, svt avif encoding

(let's say at a few different bpp ranges, because things are different for -d 1 than for -d 4, also between different q settings in avif)

aom is about 8 seconds a image, cavif rs is 5x slower, svt don't know

VPS are affected by literally all the other VPSes running on the same hardware

I've done comparisons but they're all only for lossless (and only vs webp)

main issue with doing lossy comparisons is it inevitably ends with people arguing about what metric you used, how you applied the metric, etc.

Thank you, this is very useful for me.

It looks to me that AVIF is still much better for this content at these bitrates, but the reversal of decision tree reduced the gap by 15 % or so

Yes, because AVIF is very good at maintaining clarity and structure of lines and contours, and they are most noticeable in images like this

The same images size with: <https://github.com/libjxl/libjxl/pull/221>

All images have less ringing (maybe not in all areas, but overall better)

thank you 😄

I will be able to make a similar or slightly better improvement next

likely tomorrow

Scope, did you ever try delta palette?

Other than last time, no, I think there still need some fixes

it might work well for the three girls anime picture

At higher quality, maybe, but these comparisons are mostly at medium and low bpp

The lossy-palette images are 2-5 times larger than these examples, perhaps if there was a choice of modes like in WebP, some might be of comparable size with better quality than VarDCT

It is surprising that a 0.14 % improvement can be so clearly visible -- of course it is not a day-and-night kind of difference, but this is indeed a change for the better

I think if there was a metric only for ringing artifacts, the difference would be higher

I don't understand what is the "pnorm" metric.

'pnorm' is a p-norm of the butteraugli field, almost

'a 3-norm' is actually an average of 3 norm, 6 norm and 12 norm

psnr, ssim, and most other metrics use a 2 norm

they allow a lot of error somewhere if the image is mostly good

a higher norm penalises a higher amount of error more

infinity norm woult be just taking the maximum error

https://en.wikipedia.org/wiki/Lp_space

I share that sentiment and I consider that it has been a mistake from my side not to have a separate approach to emphasize ringing -- it's impact seems to much higher at lower quality than just linearly scaling from the just-noticeable-error boundary

also it is more prominent on artificial images than on photographs, and butteraugli was mostly tuned for photographs

I'm thinking of fixing that mistake and introducing a ringing part into a quality metric once there is small enough quantity of ringing appearing

then we can use adaptive quantization more effectively to suppress the ringing

... currently I believe that often the 8 and 9 speed modes ring more than the 7 mode

... at least I had to try to put 'breaks' on the 8 and 9 speeds to avoid it going too far from the 7 mode because of that problem

when ringing is present in less than 1-2 % of the surface area then we can relatively cheaply just ramp up the adaptive quantization ~50 % in those areas, possibly also put some more smoothing there (yikes!)

Scope, I mentioned your anime verification work in https://github.com/libjxl/libjxl/pull/221 😄

it is inspiring and most helpful to see what happens with this material -- thank you for running these, especially when it comes with opinions on what is going wrong

Tried `cjxl` with the `ea8926c` commit. Dunno if this is worse or better. It just looks different. `ssimulacra` says it is slightly better. The previous version without the last two improvements along with the original and avif is here https://discord.com/channels/794206087879852103/803645746661425173/856777833627123763

Hey, the white in hair almost came back.

Ok, it's certainly better.

that's a big improvement -- thank you for showing, it gives me motivation to do more of such improvements!

I like how it has somehow now more contrast and vividness, too (in addition to more precision)

https://github.com/kornelski/dssim/issues/102 is interesting

to me cavif rs 1.3.0 would look more natural

and better

drag and drop the imaged

ah i don't have the original image

it is an approximate newton's method, far better than just binary search

Getting there

I can't make clear this error, probably like a ringing issue?

i see blocking

if you use libjxl v0.3.7-169-g1f7445a and especially with new heuristics and gaborish 0 as jon said you'll get blocking

jpeg xl is too early to use, like it got adopted to cloudinary auto q today

give them at least 6 months