JPEG XL

Yes in my opinion is the right balance between fidelity and artifacts

At d1 it look mostrous

Providing good images

For screenshots gonna look good especially at s8

Eh?

I agree with arun

But you need to understand libjxl can't / shouldn't make already compressed / poor quality image to look good.

yes when i use libjxl i think images of this quality should look good

compressed at 0.323 bpp

should look same and with same appeal as original

i assume it

wb can tell me is wrong

but the encoder scope is testing is good

wb changes he did to gain 4, 5% quality on png at least is good

i hope he adds it to libjxl

it has no flaws

Is this tik tok?

yes

naples music

tik tok advices what i look, but i don't look for them

just that i live in a isle in south

and obviously i don't skip their videos

if that image disturbs the dev i can create another thread but the devs are focusing more on png

on raw files

because that interested them in comparisons

I asked because I never used tiktok

even if they are a bit bad

but i don't see english speaking people on my feed

mineimage

to me the commit is very good, commit it

for png it improves all

apart of these things https://discord.com/channels/794206087879852103/895000336325017641/895000687535067136

look fine

it produces all what jon sneyers said on github

i won't upload on mineimage they are 20 kb files

Do you know if there's compression benchmark dataset tested on @2x/200dpi images?

I use old TID2013, but it was done on 1x monitors

And I'd like to tune perceptual quality for hdpi properly

Not afaik

Would you like to participate in the AHG on image quality assessment? this is one of the open questions imo: what's the effect of pixel density

In the past, typically testing was done in labs, on calibrated monitors that have good color reproduction but typically no high pixel density

I don't know of any subjective experiments that were done on, say, phones or tablets

I have a 200+dpi monitor now... 😄

Finally done

Its only 500 iterations tho

I like how webp just goes full green mode

I'm running a new one with 4000 iterations with Q between 70 and 85

<:WhiteFoxSalute:689481667412623385>

webp used to go full pink

then at some point I suppose they decided to round something the other way, and now it goes full green

(pink is maximum value for Cb Cr, green is minimum value for Cb Cr)

increase detail on that

https://jon.lucaversari.it/comparison3/after_adjusted2/index.jxl_d2.html

banding https://mega.nz/file/DAdGDLSI#JU6ttobPWyPhymbJJxqtwJ0FI9YciAuL7FfUiUbyDKE

https://jon.lucaversari.it/comparison3/after_adjusted4/index.jxl_d1.html

overrall i prefer afteradjusted 3 at d3.5

afteradjusted 3 best photographic quality at d2 https://jon.lucaversari.it/comparison3/after_adjusted2/index.jxl_d1.html too white

overrall i would use --epf=0 --gaborish=0 --faster_decoding=2 -q 95.078 -s 8 --use_new_heuristics --dots=0 on At kAcQuant=0.83: https://jon.lucaversari.it/comparison3/after_adjusted2/index.jxl_dX.html

Those are interesting results for jxl. 4000 iterations with Q between 70 and 85

source performs pretty well

I heard its lossless

That looks quite bad for jxl - how many different settings are you using in that interval?

only -q changes

```powershell #mozjpeg cjpeg -outfile "loss3/$j.jpeg" -quality $Q "loss3/$j.jpeg.png" djpeg -outfile "loss3/$i.jpeg.png" "loss3/$j.jpeg" ffmpeg -hide_banner -v error -y -i "loss3/$j.webp" -metadata q=$Q -q:v $Q "loss3/$i.webp" cjxl "loss3/$j.jxl.png" -q $Q -e 4 "loss3/$j.jxl" *>$null djxl "loss3/$j.jxl" "loss3/$i.jxl.png" *>$null $avifQ = [math]::floor([math]::Abs($Q-100)/100*63) avifenc "loss3/$j.avif.png" -c aom --min $avifQ --max $avifQ -s 4 -a color:sharpness=2 -a color:enable-chroma-deltaq=1 -a color:enable-qm=1 -a color:qm-min=0 "loss3/$j.avif" *>$null avifdec "loss3/$j.avif" "loss3/$i.avif.png" *>$null heif-enc -q $Q "loss3/$j.heic.png" -o "loss3/$j.heic" *>$null heif-convert "loss3/$j.heic" "loss3/$i.heic.png" *>$null ```

what language is that?

powershell

The coloring in discord is weird

Its a bit cleaner in a sane editor

Probably some more strong filters are triggered, also from my own experience I would not recommend using Speed/Effort other than 3, 6/7 and probably 8, because they sometimes give strange results and as far as I remember they were not tuned at all

Ah

-s 3 then

`-e 4` is pretty much uncharted territory

I'd advise against doing this with anything lower than `-e 5`

`-e 3` is ~~ JPEG so I'm not sure it's useful

Oh right its been reversed

I'll do -e 7

I should also try to apply the labels after encoding and not on the sources themselves

But I'm way too lazy and tired

I'll let it run during the night 10000 iterations at Q 90 to 99

I also don't know any x265 options that would make heic suck less

or even jpeg

or jxl

actually I'll replace the source with webp2

`-tile_shape <int> ...... tile shape (0=128, 1=256, 2=512, 3=wide, default = 4)` but there is no 4 <:thinkies:854271204411572236>

If Q is float for cjxl but integer for others, it's not really fair - there are only like 20 different settings of integers while each float is likely different

You lost me there

There are a lot of floats between 70.0 and 85.0

There are only 16 integers between 70 and 85

But the distance should still be the same right? relatively speaking

These values still somewhat seat between 1 and 100

More different settings means more opportunities for generation loss and less opportunities for getting stuck in a fixed point

So should I keep it to one single Q ?

E.g. most codecs will reach some fixed point if you only use a single Q

No, not a single, just same number of different settings per codec would be fair

You lost me again, what different settings?

i think <@!794205442175402004> is trying to say that 100x cjxl -q rand(70.0, 85.0) vs 100x cjpeg -q rand(70, 85) is not fair

But I'm not sure I understand why

the other codecs only have 16 different Q levels within that range while cjxl has a huge number

I got that part, but 87/100 still 87/100 whether its a float or an int

basically you shouldn't give cjxl 70.5 or 71.5 or 72.5 or whatever. it should only be integers between 70 and 85

They are integers

normally the definition of rand(70.0, 85.0) is that it may return 70.0, 70.1, 70.2, etc

The Q is at the top left of the videos

I only give integers

with cjxl there are more unique ways that the image can be encoded so there are more opportunities for variation to be introduced

oh lol

I'm so confused

that probably makes it pretty fair.

You guys though I gave floats

the variable $Q is a random int

well you hadn't told us $Q was an int

I guess it could be inferred from the same variable being used for the other encoders.

the whole script

to get floats with get doubles you'd have to do `Get-Random -Minimum 0.0 -Maximum 100.0`

tbf most codecs will just treat `1.1` as a fancy way of writing `1` 😛

and also I guess we're not super familiar with PowerShell here... or at least Jon isn't

Fair enough

I am 100% not familiar with PowerShell

Ok so the float thing is not an issue - probably still fewer different settings for avif though

Jxl does do quite badly - I wonder if it's because of filtering. What happens if you do the same but with --epf 0?

I'll try with that

Generation 8150 of the run I started yesterday

JXL is making art right there

Heh, quite interesting

That's the B channel getting reduced to three values (blue, neutral, yellow)

ok same test but with epf=0

What happens with luma there is quite funky, I wonder to what extent my recent deadzone quantization changes would change that

With epf 0, at generation 970

It seems fair to say the prior claims about generation loss were not robust. 😕

Yeah, it definitely depends on settings

Maybe try epf 0 gaborish 0? I expect gaborish to also cause some generation loss

Also decoding to 16-bit png might help

The quantization to 8-bit is quite lossy

I think I'll build a pregenerated table of Q values to make the testing comparable between runs

djxl --bits_per_sample 16 iirc

The source is 4:2:2 8 bit

Yes, but color transforms back and forth between rgb8 and xyb are not great (and not what would happen in practice if you would e.g. do repeated encodes with default imagemagick without the intermediate 8-bit png files)

I'm curious if these changes: https://github.com/libjxl/libjxl/pull/691 would improve the situation. I think some of those dct base pattern artifacts might improve

--bits_per_sample doesn't work, I can't find the right flag

There's --override_bitdepth ?

I mean in djxl

djxl internally reconstructs the pixels as 32-bit floats, and can then save them at any bit depth

Ohhh ok

By default it does 8-bit if the original was 8-bit, mostly to avoid saving large png files

But saving as 16-bit png would be closer to the actual decode result, and it would be what you get if you would do `convert foo.jxl -quality bla bar.jxl` with a default imagemagick

Gaborish seems to do it

Makes sense, encoder does an approximation of the inverse of what the decoder will do, so I can see how that would accumulate error over generations

Maybe we should have a cjxl flag --avoid_generation_loss that avoids using stuff that are likely to cause generation loss

Gaborish is off by default at high fidelity settings iirc

So when using -d instead of -q ?

-d or -q doesn't make a difference, -q is just a convenience flag that gets translated to -d

oh

I thought -d was translated to -q with extra sparkly stuff going on

Nah, -q 90 and -d 1 is the same thing

OH

That kills some of the magic of it kekw

The magic is, you can specify -m and get lossy modular.

Ah, that would also be interesting to test with generation loss

Btw thanks for doing this, <@132637059327328256>, it's interesting to see what happens and how different settings affect things

I doubt it would be a practical test though, as your typical image hosting service would likely default to VarDCT.

Are you making a video of this one?

I am

Now I'm curious about -m

Yeah, not for memes and stuff, but maybe if it works better it might be useful for authoring workflows - no idea if it does though

I wonder if there are authoring workflows where lossless is impractical.

Maybe when it's not just local

Here it is

is it with the new ac deadzone

all of them

No gaborish is never disabled

We could do exact gaborish though (or more exact)

Yeah, this is a funny result. 900 generations with default settings and `--gaborish=0`, `-d` random between 0.80 and 1.20

video editing is commonly done with lower-resolution “proxies”: https://opensource.com/life/16/1/offline-editing-kdenlive

(but then the final result is rendered using the original footage)

Usually, they're just done with all-intra coding using a codec like ProRes or whatever proprietary standard is most popular.

Yes, I meant in the context of still images.

Well currently people exchange PSD/PSB files that can be several gigabytes large

Near-lossless versions of that, generation loss resilient, would possibly be nice

Doesn't look like lossy modular is very resilient to generation loss though (maybe at higher Q and staying in rgb instead of converting to xyb it might be better, or if only a fixed Q setting is used)

Except it's disabled at effort lower than 5, right? which is part of the reason for different behavior here: https://discord.com/channels/794206087879852103/803645746661425173/898677423279849504

`-d` random between 0.80 and 1.20

Does -c 1 even work in VarDCT? Didn't know that

I doubt it does anything sensible

One more time, `-q` is random between 90.0 and 99.0

I think for now using `--gaborish=0` is a necessary choice for the case where multiple jxl-jxl reencoding is assumed.

I wonder if doing the inverse gaborish more accurately encode-side would fix it (or if the real issue is the cross-block error propagation that gaborish enables)

it looks p cool tbh

<https://docs.google.com/spreadsheets/d/1Zzm_Kh7EO9t8dHUSwqamg8UWaGY-A2S5y4uz7I_kdfw> Is this a fair comparison? or does the file size disclaimer prevent a valid choice in codec based on the metrics? Is the color formatting too misleading, or is it helpful? Any other criticisms or suggestions for improvement are welcome.

is resize 75% enough?

That's one of my questions too. The JPEGs were likely quality 99/100, so I thought it should be enough.

I wanted to retain as much of the original complexity as possible in the comparison.

id probably use 50% just because cleaner 4 pixels to one mapping

but not telling everyone to do that

butteraugli *really* doesn't like 420, I doubt webp is ever going to win any butteraugli comparison 😛

but yes I'd also rescale 50%

Okay, I'll redo at 50% if it isn't otherwise totally flawed.

--- short fjxl test --- 1 large RGB image (num_reps=50): enc: 194.2 MP/s dec: 24.56 MP/s 1 large RGBA image (num_reps=50): enc: 251.3 MP/s dec: 28.71 MP/s So roughly speaking, encoding an image takes now 12% the time it takes to decode it.

heh not quite surprised

the decoder for modular (and especially lossless modular) is not nearly as optimized as it could be

Which priority does this optimization have?

"not high enough"

more accurately, doing it without creating an unmaintainable mess is gated behind a few other things I'm working on

https://twitter.com/richgel999/status/1473385085789679616

https://twitter.com/sanityenvoy/status/1473461807524491267

https://i.ibb.co/XYRHrcS/kodim34.png

I'm surprised avif does better than webp in that case, every time ive tried it was *very* inefficient for lossless

Gotta post that jxl that destroyed the avif file that "shines" <:KekDog:884736660376535040>

Think that avif file could be 2.187 bytes or smaller if someone with actual knowledge about the format compresses it

fjxl is 22,221 bytes

Lol, webp resulted in a smaller file for me than avif... 1032 bytes

@1950 MP/s

<a:FurretSpeed:832307660035850310>

It feels very strange to see jxl files decode instantly <:KekDog:884736660376535040>

decode is still only 37 MP/s for me.

Kinda wonder how they got these results: "WEBP: 46 740 bytes JPEG XL: 41 169 bytes"

Sadge, when I opened a fast encoded image that was sent here I couldn't even see it load... which is very unusual and even used Chrome to open it

Maybe is was just small or a PNG preview. <:kekw:808717074305122316>

I think because it's an online converter with unknown default settings

I guess, but the difference seems to be... extreme

For me webp was way smaller than avif

46.740 bytes vs 1.032 bytes (their webp, my webp)

AVIF shines when using avif.io

does avif.io even have a lossless option?

Yes

wait, he said those are non-alpha versions of the original?

Hm, 24 bit, so seems like it...

Wonder if he meant 32, since removing transparency isn't really proper testing tbh

so fjxl uses just a color transform and RLE, no ctx modeling (... for now ...), and that's a lot faster to decode than your typical lossless JXL file

ah ok, Scope's JXL decodes at 3.5 MP/s so 37 should pretty much feel like lightspeed.

I'm used to ``-e 9 -q 100 -I 1 -E 3 -g 3``, so guess a lot feels fast to me <:KekDog:884736660376535040>

~~Also used to waiting for 10b cpu0 AV1 encodes <:KekDog:884736660376535040>~~

yeah with those settings it takes *a while* to decode

also to encode

that's with multithreading, right?

Tbh, feels very fast for me, because... AV1 encoding, so have had cases where I waited for hours... days or even up to 2 weeks for test/meme encodes <:KekDog:884736660376535040>

I don't think so or is this done automatically?

it is

... at least on Linux

it's https://i.ibb.co/XYRHrcS/kodim34.png right?

yup, I get 700-800 MP/s single thread on my laptop and 3557.614 MP/s with 8

... curious about my desktop now...

heh, ~1GP/s 1 thread, ~9GP/s 32 threads

not bad

I assume YCoCg is a particularly good idea on that image

and clamped gradient works particularly well on it

so you get exceptionally many RLE cases

on my laptop, the fast-jxl file decodes at 65 MP/s while the e9E3 one decodes at 6.8 MP/s

both could probably be sped up quite a bit with more special casing in the decoder, but you can clearly see the difference already between no-tree RLE-heavy decoding and the general case of an arbitrary tree

~2GP/s FPNG https://twitter.com/richgel999/status/1473392160053551107

No Copy paste

https://i.ibb.co/RCDwxZs/kodim54.png

Damn, pretty sad if people's laptops are faster than your desktop CPU. ^^

`-m -e 9 -g 3 --palette 0` is 40 bytes 😉

<@!179701849576833024> fjxl doesn't optimize pixels with fully transparent alpha.

yup, true

I *could* just zero them out

Opinions are divided on whether that is lossless or not

It depends on whether you view alpha as a mask (that you may want to modify later, making invisible pixels visible again), or as a part of the description of the visual behavior of the pixel (so invisible pixels have irrelevant RGB values)

Both views have use cases

an option for that would still be nice though 😄

Yes, should be cheap enough to do that while deinterleaving

Could also detect some special cases like whole group transparent and whole group opaque; if that can be detected without noticeable overhead, it can be special-cased and in the first case you can skip the whole group (just dump one long rle) and in the second you can skip the alpha channel

Doing `all_opaque &= alpha; all_invisible |= alpha;` should be cheap enough, right <@179701849576833024> ?

And maybe `not_grayscale |= Yo & Yg`

Yep, cheap enough

At the group level, such special cases might occur often enough to make it worth it, speed-wise

As for detecting all opaque or all gray-scale... I don't think it would work

Why not?

Ah because you encode rows while deinterleaving

Probably a quick scan over the rgba of the group to check grayscale / all opaque / all invisible cases wouldn't be too bad? Before any ycocg is done

If you're lucky and you have an all-opaque grayscale group (which I suspect does happen quite often in screenshots, and bw photography is also a thing), you can have a special case where only 1 channel needs to be actually encoded (you can just take the red values, no need to do actual ycocg either)

`not_grayscale |= (red ^ green) & (green ^ blue) & (red ^ blue)` or something like that

Are channels encoded completely independently in <:JXL:805850130203934781>, or are they compressed together? I would imagine that there would be a strong relation between the channels in most images.

ycocg is a color transform that is exactly meant to exploit that correlation

tbh, RLEing residuals of an all-0 channel is not that much slower than detecting gray / alpha - I strongly suspect that scanning the group will end up being slower, but I might be proven wrong

It might also be worth exploiting that Y and A are 8-bit, maybe?

I suppose scanning for gray / all invisible can be worth it if it happens enough in practice; you can also skip ycocg and clampedgradient in those cases so I would expect it to be faster if it can be done — but of course the scan is wasted if it only leads to the general case...

so I fiddled a bit with fjxl's huffman tables, and I got ~3% better density on the QOI test set at same speed

next step: trying to adapt those tables per-image...

Hmm, but these changes are somehow worse for Emoji, Fractals, GameSets, Manga and PixelArt sets, but better for all others

makes sense, it's a bit more skewed towards photo content

but with per-image tables, I think I can default to non-photo huffman and correct it for photo, since they're usually bigger

Also, what improvements can context modeling bring?

It would get things closer to -e 2

Or rather -e 2 plus rle

Hmm, that's pretty cool if it doesn't get much slower (because even -e 1 is often noticeably better)

I think it shouldn't be slower

but I won't know till I try

And -e 3 is efficient for a photo because of the special predictor?

yup

I suppose you could make a huffman version of e3 that would be faster (but WP instead of ClampedGradient is going to be quite a lot slower, especially since it cannot be vectorized)

another 4% 😄

btw now those sets should be significantly better (I think)

It is strange, but Emoji set is worse, 186 MB - first build, 189 MB - previous build, 191 MB - current build

But, in other sets there is a noticeable improvement, sometimes better than `-e 1`

emojis are tiny, right?

in general the last one should be better for things bigger than 272x16

ideally once I'm done with everything else I'll get a big corpus (from you? ;)) of smaller images and use them to tweak the histogram for small imgs

Yes, Emojis is something like 32x32 and 128x128 or less if the images are not square

that explains it

if you can collect those small images in a zip file or something I can tweak things for them later 🙂

Yes, I uploaded all the sets from the comparison Perhaps the tweaks on all the other sets would also be useful, together with the QOI set, or could it make things worse? <@!179701849576833024> <https://drive.google.com/drive/u/2/folders/1X_F_vhNwJFhPWSW3EeSa-gGhhikkOoYd>

probably not

there's not a lot to tweak on larger images

(I use statistics from a random sample of the image for those)

Mostly Pixel Art images don't compress well, but that's probably because they need to use some other method that's more efficient for that content

yeah gradient predictor probably not helping that much there

Pixel art that is NN upsampled limited-color stuff probably would benefit from Palette and the Select predictor

Detecting local palette cases might be useful - if it can be done efficiently

Say cases where the group has no more than 16 different rgba colors, or something like that

(and more than 1)

Cannot detect without an extra pass though

Unless you cheat and use the png metadata as info

Trying other predictors than clampedgradient might be doable - again doing a random sample to try others to see if they are better

WebP, even with `-z 0`, compresses Pixel art quite well Also, is the gradient predictor used because it's reasonably optimal in efficiency and fast?

Gradient is the best general-purpose predictor in my experience

WP is better for photo but it is a lot more complicated

Select can be better for nonphoto

I dunno what webp does but it probably does the extra scan to check palette

(note: it's not a full scan in case there are more than 256 colors, so it's not _that_ expensive)

Also, is it possible to auto-model or train some kind of optimal fixed predictor on a large amount of content, like training neural networks, or is that useless/impossible?

It's in principle possible to do basically -e9 on a large corpus, record all the trees (including distributions), and somehow average them into a fixed ctx model with fixed huffman codes that can be encoded quickly

Although it may be faster and more efficient to switch between the few that are best for certain content 🤔

If you have a large enough corpus of images with similar characteristics, I imagine it could be possible to make something like a `cjxl -m -e 9 --dump_tree_data` that produces output that some tool can process and then you can do `fjxl2 --use_data` to do fast encodes that are somewhat tuned to the corpus characteristics

That would be quite cool actually

Hmm, yeah, especially since very fast encoding/decoding is usually needed for certain content images

Would something like fjxl have a place in high speed cameras and such?

I think this is the lossy field

Ye, but dedicated HW like ASICs and DSPs would be more suited for that purpose.

fair.

A very fast and simple lossy JXL encoder would also be cool, but at the moment it is better not to waste resources on it and so far there is not much demand and hype for it, as for something like QOI

Except maybe as some sort of Rust implementation, as an example of a JXL encoder, because many devs love Rust

Hmm, a LZ4 QOI is a slightly more interesting 🤔

Where is AVIF? I thought it's the best format in the universe!?

Also, JXL 0 might be a bit misleading since -e 0 doesn't launch fjxl.

Yep, it's simpler and it can be explained in the description later (and this is just a draft comparison, maybe I will remove or add some formats)

Like QLIC2 is a speed-optimized equivalent of PIK or JXL `-e 3`, I also wanted to add GFWX, but it is not that good, especially on fast modes and very bad on non-photo content

And also another fast codec, but: `ImageZero is not suited for "flat" (computer generated) graphics or grayscale images`

interesting results 😄

I'll probably have another version of fjxl ready soon, should be way more dense

^ I have updated the sets to more relevant ones

There are interesting examples with a big difference, but on which QOI-LZ4 significantly improves the results (with very small speed loss) ``` FJXL - 443,089 QOI - 488,563 QOI-LZ4 - 75,950``` https://i.redd.it/5xx5ebs204f41.png

Like, the speed difference is small between QOI and QOI-LZ4 `decode ms encode ms decode mpps encode mpps size kb rate`

And many other similar images with flat solid areas and pixel art

fast lossless is better than e1 on average? 🤔

On some sets, yes, but on average, no, a higher percentage is a larger size compared to LibPNG

ah i thought it said -5.9% and -5.1%

The main problems with large flat areas and transparency, as far as I noticed

e3 does especially bad on pixel art <:woag:852007419474608208>

Yeah, because this mode is purely for photos

``` FJXL - 13,832 QOI - 33,761 QOI-LZ4 - 1,043``` https://de.catbox.moe/goyb5o.png

``` FJXL - 448,136 QOI - 760,029 QOI-LZ4 - 6,502``` https://i.redd.it/w4qm60q2obh61.png

I suspect that a big part of the pixel art compression depends on doing palette or not

Detecting palette cases and doing fjxl on the index channel (with zero predictor instead of clampedgradient) would likely be overall faster for such images, and denser

Rescaling to 1/28th of the image size results in 1.044 Bytes. How much would signalling NN cost?

Upsampling can only be 2x, 4x or 8x

Signaling cost would be a 150 bytes or so? Dunno have to check spec

For manual encoding it could be worth doing, but I don't think the general encoder is ever going to check that the image happens to be NN upsampled and then use that trick

1/4th is at least just 17.613 Bytes.

Why not? Start checking the 8x8 pixels to the bottom left of the center for equality. On most images this will fail. Now check 4x4 or 2x2. Continue with the rest if one check succeeds.

Yes, I guess it could be done cheaply enough

Is this common enough?

Why do people not just use native resolution? In css you can say the browser has to use NN

Sometimes it's game screenshots, sometimes it's just art style, although this kind of content is pretty well compressed by WebP even at the fastest speeds without resize (probably a bit worse than without it, but still)

With proper use of lz77 we could probably also compress it well without resize

Also, just for the sake of interest, what special features does JXL have for such a fast encoder or, for example, can WebP's implementation be exactly the same (except for tiles/groups)?

Most places that allow for sharing of images don't support adding your own css. ;)

Fair enough

WebP could probably also have fjxl style fast encoding - it wouldn't benefit from some of the advantages of jxl though so no idea where it would land in density

YCoCg is something WebP doesn't quite have - it only has color transforms that keep everything 8-bit

And WebP isn't planar but interleaved, so cannot exploit things like alpha runs or cocg runs as effectively

So, fjxl does have its uniqueness 🤔

Nice tweak, fjxl converts RGB PNGs to RGB**A** JXLs so that the MP/s score will be 33% higher. :)

so in the end it was just a 2.5% size decrease and I decided it wasn't worth the effort 😛 I pushed some tweaks for emoji sets & the like (~0.5% decrease on the qoi test set) and I think I'll stop here

I recorded a few lossless x264 seconds of just standing around in Dishonored. Big surprise, fjxl produces better compression (>20% denser) even for that content (when *not* using delta frames). The screen changes ever so slightly from frame to frame, thus x264 ultrafast only gains 10-15% compression strength by using P vs I frames. Both are not really feasible when considering storage limitations but still nice to see those results. Short screenshot bursts would be nice to do with fjxl or even screenshots in general so that games doesn't hang for one second while waiting for the PNG conversion.

Is this without trying context modeling? Because something with a density close to `-e 2` at fast speeds would be cool and maybe that would be a candidate to replace `-e 1`, I don't think the extra `-e 0` is worth it, and also `-e 1` should match its name - lightning

Hmm, yes, Emoji is better, the other sets so far are the same or slightly better

`-e 0` is worth it.

Just make it the instant transmission preset.

where is fast djxl

Perhaps there will also be here <https://github.com/libjxl/libjxl/pull/1032>

Or maybe not, so that people use a full decoder

But, having a fast limited decoder would also be cool, I don't think it would be dangerous to adopt and use the full format, since it is mostly needed for very specific uses and comparisons (for now, there is an encoder that can beat everyone, but not the decoder) And in the future, integrate fast encoder/decoder paths into libjxl

`-e 1` can also be instant, but for those images on which fast-encoder works and use normal and slower encoding for all other cases where images do not fit the limits

fjxl would be great if it can be as dense as lossless x264 faster and be as fast as ffv1

as in i would definitely use it

I think it is already faster and denser (at least not for the slowest x264 modes), but for individual frames, video formats have advantages in inter-frame compression

There are times you don't want interframe compression (Like archival reasons), iirc that's the intended usecase for FFV1, A JXL "video stream" in MKV could be a nice replacement

i want to know if delta encoding can beat the interframe compression of x264

Subtracting the previous frame should help, even without cropping

Is there a format for uncompressed rgba video?

NUT container can hold it

That looks a bit complicated to deal with

Something like PAM but with multiple frames would be nice

Little-endian and with a simpler header

4 bytes magic, uint32 width, uint32 height, uint16 nb_frames, uint16 fps, and then just 8-bit RGBA dumps of every frame

That would be super easy to plug into fjxl and then with some extra lines of code it could subtract the previous frame and emit an animated jxl

If we are talking about a simple translation where pixels stay exactly the same just at different position, then interframe x264 shines. Every other case like small dynamic noise on a static image or turning/moving in a 3D game don't really work for lossless interframes. So from my limited test recordings I would conclude: fjxl is faster than x264 ultrafast, especially for higher bitrates, fjxl wins at 3D game recordings when not using delta frames, fjxl wins at desktop (or 2D game) recordings with delta frames, except for 2D side scroller, x264 should win here but I haven't tested.

my use case would be anime with noise

it'd be a huge win if it can be < 13mb/s and be faster

this is similar to the 3d game with slight movement case i think

Is this anime you made yourself or where does one get lossless anime?

filtering/encoding

just keep in mind that playbck wouldn't be possible with the current JXL decoder.

https://ffmpeg.org/ffmpeg-formats.html#rawvideo

time to try to make a video encoder/decoder i guess

So, is 2.5% a specific tuning that's not worth it because it makes the code less simple or is it some new methods and added context model? If the second, then why is `-e 2` noticeably better, because of ANS?

it's ANS and a better ctx model 🙂

also better entropy coding in general

Hmm, so adding some ctx model isn't worth it?

Perhaps it is, but it doesn't appear to be a very juicy low hanging fruit in terms of speed and implementation effort cost vs density gain.

Yep, I meant without a noticeable speed loss, sad that some simple ways are not as efficient, except that there may be, as already mentioned, a separate mode for the palette images

Getting ready to leave on family holidays right now, but when kids are back in school I'll play a bit with palette

im getting fjxl ~3x larger than x264 faster without delta frames fjxl ~2x larger than x264 faster with delta frames

I think because video is usually YUV420 content

for 444 8 bit i get those results

I mean this content is not RGB originally and it is also not x264-RGB, btw, if having a 420 or 444 mode for fjxl, it is likely to be noticeably faster and more efficient, even for QOI there is a YUV420 variation (because most video sources are still YUV420) https://github.com/Chainfire/qoy

well the fjxl is already yuv

and i dont think doing 420 benefits from much in terms of efficiency for jxl

and my results were for x264 yuv444p8 vs fjxl

You are giving yuv data to fjxl?

Then it will apply ycocg to ycbcr data, which is... not a good idea

it was better compression than converting it to rgb then ycocg

Can you hack the code to make it skip the ycocg conversion?

yeah i just fed 3 separate yuv planes into here <https://github.com/veluca93/libjxl/blob/fast_ll/experimental/fast_lossless/fast_lossless.cc#L798>

Ok 👌

i want to test this for fjxl though

where in ImageMetadata or the frame header does it say that an image is grayscale? (what bit(s))

I think it's around here: https://github.com/veluca93/libjxl/blob/fast_ll/experimental/fast_lossless/fast_lossless.cc#L350

now, what's the serialized version of a grayscale ColorEncoding, that's a good question

Yes, x264 profits quite a bit when going from RGB to YUV and from ultrafast to faster.

with 2 of the 3 planes being 1/4 the size, im getting ~2x smaller than x264, but i can't verify if it is valid as i cant figure out the header for grayscale

``` output->Write(1, 0); // color_encoding.all_default (sRGB) output->Write(1, 0); // want_icc output->Write(2, 0b01); // color_space kGray output->Write(2, 0b01); // white point kD65 output->Write(2, 0b01); // primaries kSRGB output->Write(1, 0); // no gamma output->Write(6, 0b101011); // transfer kSRGB output->Write(2, 0b01); // kRelative``` close but not quite right

is chroma subsampling a thing in jxl modular?

Only for frames that are YCbCr

In RGB and XYB it does not exist

<@!111445179587624960> how willing are you to add https://github.com/caoscott/SReC to your lossless compression benchmark?

I've seen this encoder, but I need a Windows binary and it's also not clear how much compression depends on the trained data

Like, it can be universal or only good if it is trained only on similar images

Something like this might be good for pixel art, but the problem is that these are not just typical algorithms, they are more heavy neural networks that require trained model data

yeah hard for me to say how much you'd need to train it on specific models

anyway it's python so running on windows shouldn't be hard

Yes, but it needs various dependencies and also I don't have an NVIDIA GPU at the moment

IIRC it does run on CPU, although it's a huge pain

try it on colab. may be. Oh cpu 😦

you can do it with y4m but it's "nonstandard"

intermediary, doesn't seem worth it

since ffv1 is much faster than libjxl modular

but if it can be faster

if modular can be made faster (which I hear it can be) then sure

VarDCT is very fast but I figure you're not interested in a lossy intermediary

also, are you looking at signed delta, how do you plan on implementing that? lossless delta in libjxl I don't believe has a significant ratio improvement over lossless I-frames

the fjxl used signed ycocg

oh you're talking about JpegXL aminated

well it doesnt even need to be a real format

as a curiosity experiment I tried taking JpegXL vardct and subtracting the original, and then encoding the difference between the original and the quantized as lossless, so I could perfectly reconstruct the original with a lossy backdrop

but I discovered that the lossless difference is almost always just, the same size as the original when there was grain

I wonder if you consider it worth it

it might actually be seriously worth looking at vardct with d=0.1 or something very low

since it's *far* faster and it preserves grain at distances that low

isnt vardct lossless possible

No

it's only lossy

I've found that d=LOW is almost good enough though, like x264 crf=4

it's not lossless, but you wouldn't be able to tell

either way, once my patch for libjxl ffmpeg encoder gets merged this might get a lot easier to test

since you'll be able to pipe into ffmpeg

epic

it's sitting on the ML but I think it's being delayed because they're scrambling about 5.0 release and didn't want it in there

is 4.4 still a mess

idk ¯\_(ツ)_/¯

they're also waiting for me to add a fate test but I already did, just haven't sent that patch to the list yet. it's on my laptop I used on vacation which doesn't have my private key on it cause I forgot to put it there

https://twitter.com/_michaeldsmith_/status/1478414688325046275?t=m51r3p8qq1YSc7a0ld9M9g&s=19

Yeah, as I said before it would be good to have some kind of benchmark utility or at least integrate different codecs into qoibench, because many people will compare total time combined with different PNG decoders

Also not quite clear what options were used for compression, was it default and `-qstep 0` (or with what option can I get lossless?) for OpenJPH? Because there are different options to improve compression, also the default compression is a bit lossy as I remember and it's strange that kakadu compressor is the same as OpenJPH, but much faster 🤔

And since the speed difference between JXL `-e 1` and FJXL is not that big, it is noticeable that PNG decoding takes significant time

Yes, the speed measurements are not very accurate

I dunno about htj2k, but I think j2k only really has one way to do lossless (besides bitstream reorderings)

``` -qstep (0.00001...0.5) quantization step size for lossy compression; quantization steps size for all subbands are derived from this value. {The default value for 8bit images is 0.0039}```

That value is just below 1/255, which is presumably enough to make it lossless?

🤔 https://github.com/aous72/OpenJPH/issues/68

```With this image, -qstep 0.03, the JPEG image and HTJ2K image look roughly the same. Values > 0.03 produces worst quality, and smaller values produces better quality. Qstep should be 0.5 or smaller, and for 8 bit images, it not useful to be smaller than 1/256 = 0.0039.```

But, is it true lossless or not?

It can do true lossless, yes