JPEG XL

I guess you would not usually zoom that much overall.....

But.... You know. Still....

The boxes are pretty clear. 90 and it seems to go away.

Tried 87 as well and it was still noticeable.

90 might have a slight hard to see....... It is pretty near gone as far as I can see. Maybe a slight hard to see box.

Now of cause you only see the boxes if you zoom in on 85....

Looks fine zoomed out.

But as you can see zoomed in, is pretty clear we have some boxes.

But around 90, and I find the quality to be acceptable. I could do some more digging around with the images, to see if I can find any boxes.

but it is 1/4 to 1 - so it is still a lot smaller.

actually 1/5 to 1 with 90 - and 1/4 to 1 with 95

So not bad.....

I could still see some boxes at 87..... 90 seems to have it pretty near gone.

I still need to tst AVIF - but it takes a lot longer to make such files 😛

Like the JPEG is made pretty quick on my Crapbar.

but those AVIF takes some time to do.

5 hours or so....

It will be interesting with some results on it.

This was my main photo I used.

I started looking at the text on the book, but found out his mouth was better to use.

With 90, it would press the 40 GB down to 8 I guess.

and 40 to 10GB.

still a lot to save for sure.

thinking.

Like I am looking at this AVIF i have made and some of JPEG....

of the JPEG

well nothing in regards of decoding speed - what really seems to be what is taking the most time is the storrage of the files.

I am lookin at the 50 quality at the moment of the AVIF..... and I feel like they are doing extremely well as well.....

and it is like 16MB For 600 files.

I don't think I can say that JPEG is in anyway competing on these grounds.....

I am not sure how low quality I can go with AVIF....... Would like to try lower then 50. No idea where to really put it. JPEG is around 90 of quality before I am satisfied with the result.

and that is 67MB

I think I used 75 for the AVIF I was looking into where I actually thought they where better then the originals.

and that includes lower size of cause, a lot lower.

Anyway, I will be making some more test, but I think AVIF is the way to go for me.

The JPEG don't look better, they just look the same, and if they look something on lower quality, it is worse.

the boxes thing comes up, you can see those small boxes around here and there, not very nice.

The bad thing about AVIF, is the incoding time for sure.... Takes a lot longer for sure to do.

and with my crap hardware it does surely.... take some time.

but overall, if I can find the right settings I only need to do it once.

Maybe some smoothing might help the JPEGs

on the boxes

If you have full blown AVIF, it actually looks worse then having it lower.......

as it actually end up tuning the image with the compression.

AVIF is the best image format for the highest quality with maximum compression. Especially with 10bit 444 chroma subsampling and with tune=iq from `avifenc/aom`.

The second best is JXL, and JXL surpasses AVIF in the higher quality range. Though JXL is a much better image format in general with lossless conversion from JPEGs to JXL, very good progressive decoding, faster decoding, better bit depth support, better max channel/dimension support. It's a better image format for the future.

Dunno about those settings, GIMP 3 seem to have some of those tuning points, not sure with tune=iq

But there seem to be kinda a sweet spot for making the images better then the original, so I am testing and trying to find something of it.

99 is to close to the original, and it does not do those sweet tuning things to the image.

the compression in itself seems to make things better if you find the hotspot.

it is pretty cool.

> making the images better then the original When you think about that for a few seconds, you realise how wrong that sounds Dx But when you only have low quality input, the smoothing can hide old artifacts that JPEG and JXL tries to preserve as detail, so in this case it's okay

I'll show you one data point I have at hand at the moment.

But yea, many of the photoes are pictures of lower quality stuff I guess, but it actually seems to be helpful to then do this compression and that is pretty neat.

It is like a Photoshop touch up 😛

Not entirely sure where to.... around 75 seems fine.

but what is better or worse.... is kinda hard to really say.

it is not like JPEG where you can see boxes.

What you’re describing is the concept of appeal, which is distinctly different from fidelity

AVIF smooths things out (moreso without Tune IQ) and it can be very appealing because there aren’t any artifacts. Detail is still lost. libjxl tries to preserve these details instead of discarding them, but that means if you zoom in, sometimes u find artifacts

okay, well, trying to find the best setting here.

smothing things out i guess is better then JPEG boxes 🙂

At the same time, input image quality is also important. Transcoding an image/video generally isn't a good idea because of generational loss and less data to make proper decisions to begin with.

transcoding?

👀

Anyone got some side by side comparisons of tune:iq vs whatever the default is/was?

https://svt-av1-psy.com/avif/ these comparisons should suffice. tune iq is essentially enhanced tune 4 from svt-av1-psy

It sounds like they basically fixed the fidelity problems with avif/aom by the sound of it. Now if only someone would patch out the outstanding fidelity errors in libjxl too...

i worked a lot on tune 4 and im pretty proud of the results, and I think AVIF is totally competitive at high fidelity now. that being said, i still use jxl for all of my personal photos

Just check these images, extreme compression but almost indistinguishable especially for normal viewing conditions.

Transcoding means, encoding an already lossy content again. Most JPG/Webp/AVIF/JXL images are lossy, for example.

I also like to use JXL instead of AVIF for various reasons. But yeah, AVIF with its latest form is the best for compression (objectively). I have tried almost all metrics including CVVDP and the results don't change. I am especially waiting for the patch Julio was talking about: *"BTW, once I merge PSY's enhanced SCC to libaom, this can be further compressed from 86 down to 36 KB 😎"*

yeah julio's screen content detection algorithm is really great, and usable in SVT-AV1-PSY right now

avif looks pretty sharp and clear. libjxl softens everything like I'm wearing the wrong glasses, with oil on the lenses distorting the color 😂

jpeg-xl is not competitive in that range though

the images are too small for jxl to shine

there is a lot of room for improvement and the jxl format itself allows for a lot of future breakthroughs

Agreed 100%

It can't happen soon enough either 😂 I feel like some of the most noticeable issues could be low-hanging fruit

Now I wonder what jxl looks like at that size

the webp/avif tech lead unilaterally gutting jxl from chromium to promote his own halfassed throwaway formats is almost enough to never use avif for any reason.

well, webp is terrible

and avif is useable at filesizes more than half as small as JXL

So there are still some situations where it's tempting to use AVIF, like for recompressing very large blurry HEIC images

avif will preserve the color better, the texture and details better in the shadows, and at less than half the size of JXL

i think its very tempting to use avif across a lot of the web

better looking, transparent, and smaller at the same time, frankly humiliating jxl at least at the current state of the encoder

jxl was better if you ask me, for most of the use cases

but avif encoders improved to a huge extent

I dunno, I feel like avif utterly fails at web use since it takes forever for an image to appear.

jxl is much more responsive and less waiting for the decoding to begin

both svt-psy and aom are amazing

though lossjess JPG -> JXL, progressive decoding, faster decoding are very nice features

average internet bandwidth is quite high, so when we're talknig small ~50 to 200kb images, they will load instantly for most people

i think progressive decode is great for when you want to load a massive high fidelity image

Yes, people may think they browser freeze when they want to load a big image

the svt-av1-psy site uses a lot of medium-high fidelity AVIFs encoded with Tune 4 for the banners (sometimes JXL as well) and they look quite good, and load fast

Even without progressive decoding, jxl decoder can begin decoding at the same time as the download. The avif decoder can't even start until much later than the jxl decoder, so there is much higher latency even without taking progressive decode into account

also the VarDCT is just really well suited for high resolution because you can use huuuge blocks

what about av2 though?

this doesn't really have a huge effect on the user experience, because that latency is imperceptible to most people. does the svt-av1-psy site feel stuttery or sluggish?

will the spec include an image format again?

I think avif is extremely ill suited for web use because that latency is palpable and irritating

i don't think it is ... again, maybe with very large images, but generally speaking I would not be able to tell in a blind test with decent internet

You will absolutely be able to feel a 200ms longer delay when loading a web page

It is palpably slower

200 ms?

ive never seen this before, i think this is a strawman

Or however long it takes for both the download and then the decode to sequentially complete since it's too dumb to do both in parallel like jxl

let's test this with throttling in the browser, on a regular 3g connection

Take an avif image, decode it in the terminal with the time command, then add the time It takes to download at a typical speed, plus the round trip latency of the request.

That is easily more than 200ms

I was looking at this again yesterday, sounds like a good spot for that algorithm https://github.com/libjxl/libjxl/pull/1395

Also where I found this https://discord.com/channels/794206087879852103/804324493420920833/1367725140959301722

Every other codec, even webp, can decode in parallel

this is on a "regular 3G" connection, so significantly worse than most of the world's internet. I don't see a huge issue here; the image is faster than the fonts

oh that'd be great; the algorithm is nice too because it won't just tell you whether a photo is photographic or not, but also how it has classified the photo's characteristics

That's because those are JXL images...

the banner is AVIF here

lmao

the jxls are further down, and i cannot tell the difference

Are you sure? I didn't see any avif images in the thing below, unless it flashed by too quickly

if you're interested, I wrote a "reference implementation" for julio a couple of days ago that he said he's gonna publish on github soon (if it is correct) – i can link it when the time comes

yes, i wrote the site

I guess it is good I only have "low" resolution photos 😛

The video is corrupted for me, shows the first frame then goes grey

it is 4:2:2 HEVC – what browser/platform are you on?

Tried in the Discord client and downloading to open it in VLC, same result

huh, even vlc? that's odd

it works with MPV for me

I don't know why but JXL doesn't encode this image properly. Colors are dark.

Maybe a decoding related problem?

are you on Windows by chance?

what is this Subsample chroma thing?

you separate the chrominance from the luminance, and you lower the resolution of the chrominance

aha.....

and what does that do

or in another way, what is the best setting?

so if I have RGB, I can turn this into YUV (for example), and then I can make U & V 1/4 of the resolution. so if I have a 1080p image, U & V would be 540p

Y is luma, U & V are color

for low fidelity, usually 4:2:0 for JPEG. for high fidelity, it'd probably go to 4:4:4. AVIF & JXL are a bit different

WebP tragically only supports 420

For AVIF

I'd say post it here for the other devs to look at when it's ready, since I have no doubt <@794205442175402004> will be interested in using it to revive the [old PR](<https://github.com/libjxl/libjxl/pull/1395>)

Yeah

maybe it is falling back to hwdec because it sees HEVC, but you can't decode non-420 streams?

Says the transfer takes 190ms and because it's avif, the decoding can only happen after it's complete, not during, like all other image formats.

On my PC anyways

Judging by CPU usage, it wasn't using hwdec

the fact that my user experience is flawless on a 3g connection leads me to believe it is a non issue, not sure what else to say here

My test folder: https://jesusgod-pope666.info/images.php#(grid|album)=/test; copy paste the whole thing, it needs the ; at the end

Maybe in that particular example, it looks flawless, but we did not do a proper comparison. Humans can definitely notice if something reacts 1/5th of a second faster to their input

yes, but there are so many other elements of a website that have to load, including fonts, other images, etc ... it doesn't practically matter in any real world scenario

notice that a lot of the other elements of the site took time to load as well. this is a specious argument

Thanks to Emre, we discovered Quality 80 or lower it's better to use 4:2:0 in jpegli https://github.com/google/jpegli/pull/130

oh wow, that's very good to know – so will this happen with jpegli by default now?

Exactly. This is a bad example to use, then. A better example would be a website where the other page elements load faster, and the image load time is the most noticeable factor.

Could try decoding with djxl to check. Also build from main if you can, as my PR to improve the low quality range got merged not too long ago (Resampling)

I just don't believe you can come up with a use case where user engagement is harmed by this very specific nitpick – a lot of sites animate the entrance of their UI elements and people do not really care

caring about 200ms of load time assumes that *everything else* on the site has loaded in <200ms, which is totally impractical. the PSY site is a perfect example, because it is an *extremely light* site where we *still* don't see any issues whatsoever

to me it feels like the way you are entertaining this hypothetical is as if the rest of the site has loaded in 0ms, and users are left waiting for 200ms while an image is clearly absent. this is a specious argument

> The APP14 tag is now added to RGB(XYB), CMYK and YCCK JPEGs, as it is required in some decoders. > Using --chroma_subsampling will now correctly subsample XYB's Blue channel. > XYB is now 444 by default to allow JPEG XL Transcoding. > YCbCr now uses 444 by default and 420 at Quality 80/Distance 1.9 or lower. > Adaptive Quantization is disabled at Quality 90/Distance 1 or lower for non-XYB. > RGB is now used at Quality 100/Distance 0 for RGB input (PNG), overridden by XYB. So better low quality, much better high quality, and no more very broken XYB files

wow that's very nice, once that's merged I'll have to re-test jpegli's BD-rate

jpegli with XYB is very different

Pretty much 444 is better

yeah true, maybe i should have specified YCbCr

It is very interesting that up until quality 76 or so, 420 is better

but it is low quality

and it is equal to q ~20 with 444

that's super great that you tested it to help the devs out, good stuff

I've said it a few times, but that was the broken 420, subsampling Luma instead of Chroma

Though it has made me consider subsampling all channels, simply halving the resolution when the quality gets so low

Yeah, it's very obvious but why was 420 the default though?

That's where it gets even weirder

Default 420 was correct, subsampling B. `--chroma_subsampling 420` was broken, and would subsample Y and B

In that PR, XYB is always 444 unless overridden by `--chroma_subsampling`, with the values being fixed to not subsample Y

that is more intuitive

Also has the benefit of allowing JXL transcoding by default, and improving decoder compatibility since subsampled RGB is... Strange...

It's not a typical site, if the text takes longer to load than the images...

Of course it's harder to notice the delay or sluggishness if the most sluggish feeling thing is how long it takes for the text to appear

Yes, `djxl` fixes the problem

But what does FF based browsers use to decode the image?

`imv` on Wayland, also displayed it very dark (it should use my system libjxl)

at 3G speeds, because everything is loading extremely fast anyway, even at 3G

again, the PSY site is extremely light, part of the point

you clearly harbor some real resentment of AVIF to the point that you seriously consider impractical concerns. there are other reasons to like JPEG XL more, this one feels like a massive reach

if you want to help JPEG XL, I think these kinds of conversations are unproductive – it may be worth looking into contributing to libjxl

IIRC 420 was default for YCbCr, but there was no check added for XYB. Eventually it was changed to be 444 by default, but only in the API, so in the past few days we stripped out the CLI overrides so it uses the API defaults instead (I forgor to press send)

Like I said earlier, I definitely harbor resentment for avif. But I don't think it's impractical to consider the latency. I also don't think the site is that lightweight if it takes so long for the text to appear.

i was testing at 3G; try on your current connection and let me know how that goes

I think avif is more suited for offline use because of the lack of streaming decode

we are back to the beginning of our conversation. i think this is irrelevant in practice and i strongly disagree

Yes. Ah well, that's just my opinion.

As the user of an 8 year old phone who frequently goes on multi-hour long train journeys though the countryside, there's certainly been many times I wished I had the progressiveness of JPEG XL. However, when you're only loading a few images, and size is priority, AVIF will do just fine too

my point here still stands

yeah progressive decode is objectively a win; streaming decode is not. dav1d is also really, really fast

also, in a lot of cases, we can genuinely be talking 50kb of AVIF vs 100kb of JXL

Also yes, Foxless is quite... Persistent, about their stance on things, but there are usually still valid criticisms inside it all

i agree with the base criticism on a theoretical level, but my only point is I fail to see where it is a practical consideration that anyone needs to care about

Can't the latency be mitigated?

with a faster internet connection probably

that's the basis of the conversation; at standard 3G on a very light website, it ceases to matter, so how slow are we talking?

oh, so the problem is solely related to downloading and then starting to decode the image

I don't think that's a huge problem. This is only the lack of progressive decoding, not actual latency.

Both images would be shown fully when completely downloaded and decoded

and the smaller avif in this case would load faster

I think it would only matter on websites where large-ish images are the last thing to finish loading. Like an image gallery.

It can be important when you scroll image only web pages with many images

so you would understand what's underneath and skip faster

Otherwise, for small images, the decoding will happen fast enough that the latency will not be noticeable or make a meaningfull difference, like you say.

Progressive decoding, on the other hand, definitely makes a big and meaningful difference on perceived responsiveness

Again, like you said.

This isn't PSY AVIF, but they are the same filesize using my merged PR. Not *far* off, but AVIF is still better in the very low range, Quality 38 here

AVIF on the left, JXL on the right 37.5 KB

Yt still beats even jxl

Dday is enough good to be considered av2 I imported code from av2

Sorry but the vido is all bourrée is 240p

But you see the sharpness for 240p is crazy

How do I do it without xyb ? for i in *.{jpg,png,jpeg}; do cjpegli "${i}" "new_${i}" -q "90" -p "2" --xyb -v --chroma_subsampling=444 done

jxl would look a lot better if it didn't have extreme chroma ringing, and retained more sharpness instead of blurring

Delete the `--xyb` setting

The main problem at low quality settings with libjxl is some really extreme chroma ringing artifacts

In the past people like <@226977230121598977> have complained many times about strange new colors appearing that aren't in the original image and I think this extreme chroma ringing is the reason, and it was never completely fixed

https://www.dday.it/redazione/48488/redmi-note-13-pro-5g-in-prova-il-top-dei-top-economici-vale-quanto-costa

Look at avif with same compression of avif2

Yes is possible with a similar range

The image in this site are rrally Sharp avif

<@1028567873007927297>

How to force the mobile to download avif from this site

You need to send the HTTP Accept header it's expecting

Yea did that but then it faultered.

Failed to decode input image Screenshot 2014-06-26 23.58.25.png Failed to decode input image Screenshot 2014-06-26 23.59.26.png Failed to decode input image Screenshot 2014-06-26 23.59.28.png Failed to read input image *.jpeg darkijah<@892795132531838997>-USBSSD:~/downloads/test/0-Original-SS600-367MB (copy 1)$ for i in *.{jpg,png,jpeg}; do cjpegli "${i}" "new_${i}" -q "90" -p "2" -v --chroma_subsampling=444; done

What's julio's SCC algorithm?

Sounds cool

Oh well....

I will hazard a guess here. I don't think `Failed to decode input image` has anything to do with the presence or absence of `--xyb` on the command line.

You can try running `file example.png` to read the file and determine what type it is.

Yea... apparently something is going on here.

Not entirely sure what is going on here.

apparently have some issues all of a sudden on it not working

Maybe because I am incoding something else, just weird.

Maybe linux can only do 1 thing at a time with this as well.

dunno, all sorts of rubbish with linux.

So whats the point of these bits 8 10 12?

how many colors it can do or something?

original

Quality 50

Can you see any difference?

I would not be able to pick out the one that has been compress with 50 compared to the original.

Actually, I'm really tired of this. These artifacts are present even at very high presets. This is especially noticeable when extracting the CbCr components in the YCbCr model. There are very severe color artifacts—even after all the fixes, it's still a huge problem. • Colors don’t compress well • Non-existent colors appear • Artifacts extend far beyond the block boundaries This issue is so significant that there comes a point where JPEG produces fewer color artifacts than JPEG XL at the same file size. Due to problems with Internet propagation and the lack of billion-human debugging resources—and because of the issues I've discovered—I, as a consumer, can say something quite grim: as of 2025, VarDct (the JPEG XL compression method) is not ready for release. What’s even scarier is that, due to the slowdown in progress and despite JPEG XL’s powerful decoding performance thanks to parallelization, this codec is not ready for a future where a 4000x4000 image is used for every meme. For that, WebP is more suitable. This all sits at the intersection of the collapse of the capitalist system. If you read the news, you'll know that those who released 8K TVs have now backed off—not only TVs but also new 8K camera development. This is an unimaginable breakdown that turned out to be unprofitable everywhere. Even YouTube banned 8K after a couple of years of testing. I say this with certainty because AVIF is available. It's almost laughable; it got full Internet support, but Google itself refused to use it, switching back to WebP for YouTube previews and Google Images. Has anyone noticed this? Finding AVIF on websites is like a quest, yet it exists. But if JPEG XL were to be added right now, it would likely face the same fate.

My recent research on modular compression showed that modular compression around versions 0.6.1 and 0.7.0 performed better on specific images than the very latest version. This only demonstrates a lack of direct progress. I’ve lost faith in this codec—even after such long and relentless development. Looking at four years of updates, I see the same bugs, the same problems, though just a little less than before. Maybe this is its inherent structural failure? Perhaps they should release a "JPEG Lite" that includes far fewer technologies and offers significantly faster decoding. I use JPEG XL as a replacement for PNG simply because PNG is outdated, but with JPEG XL, I see a labyrinth whose exit, at the current pace of development, might not be reached for another 20 years.

and look this shit av1 / vp9 youtube same video size it's over In the last few months, I've personally noticed that Google has completely ruined the AV1 encoding settings, possibly due to the increasing amount of content that isn’t being re-encoded fast enough. In most scenes, VP9 outperforms AV1. It’s best not to watch YouTube videos encoded in AV1 because of the extremely low encoding preset—in the development of Google’s hardware implementations, VP9 simply performs better. However, this applies only to resolutions of 720p and above. For quality at 480p and below, VP9 is technically even worse than AVC. Therefore, it’s better to choose the compromise settings provided by Google in Settings → Playback.

AV1, JPEG XL, AVIF, VVC They all show—and prove—that the concept of “improving” by increasing encoding and decoding complexity is dead. It doesn’t work. This is the end. Just look at LZMA2 (7z), zstd, FLAC, WebP, and good old JPEG (JFIF), which are all at the peak right now. It's unimaginable. Any AV1 stream? Where can I watch one? Twitch promised it in 2023, but it's not available. YouTube supposedly added it, but personally I've only seen VP9 streams at maximum

But specifically, it looks like really big ringing waves of color distortion across the image, in libjxl

The most annoying thing about all this is that this discussion is so global and fundamental that no one can even maintain a dialogue in this direction or express their opinion. unless one of the main developers of jpeg xl can at least understand the meaning of the written text. otherwise, no one cares. it all sounds like a movement against progress.

no more money <:Stonks:806137886726553651>

Conceptually, everything is simple. how do I enable psnr for encoding? There's no way to do it. how do I increase -d for separate colors? There's no way to do it. there is nothing to discuss here, the problem has not been solved, and there are no tools to sloved it manually

The most recent encoder improvements are the addition of the streaming encode/decode api, and fast-lossless before that. There have not been any significant rdo improvements. Not since PIK and FUIF were merged together.

There has been some extremely minor tweaks and tuning but not any significant changes.

I think the devs might be afraid of radical changes to the quantization.

I am frustrated about it too, hopefully it doesn't take 20 years for that to change.

AV1 files are clearly on Youtube, one of the reasons why I found out was because VLC could not play the video on some of mp4 files downloaded - which where AV1 and I have hit into a good amount of them

Yeah, a good amount of YouTube videos I watch nowadays are served with AV1

It typically does look worse than VP9 though 😅

Jup, I was very anoyed about the files breaking in my VLC, and was like WHY - actually why I ended up here and looking into formats.

The original has darker more detailed shading.

libjxl has that tendency of a lot of bad youtube video encoders to crap itself whenever there's dark shadows or a dark scene

I think I will go with 50 for AVIF, what is the best and hardest settings for this?

I can use Gimp or XnConvert is the 2 I have that can do AVIF files.

Gimp 3

Basically if jxl fixes the chroma desaturation problem, the shading problem, and the chroma ripple artifacts, it will be the perfect lossy image codec finally

Those are the 3 issues holding it back

Easier said then done 😩

I think they are 3 separate issues that need to be tackled and fixed individually

Maybe the 2 chroma related issues are related, I don't know without investigating

You can stream av1 to YouTube, bit they will transcode to vp9. No viewer receives an av1 stream at source resolution

issues are often the result of poor integrations of a library that otherwise works well

take zoner for example. all its LOSSY encoding of jxl is really bad (bad color warp for certain quantizers - LOSSLESS is fine). its not clear how they support jxl but they had it with the same artefact since around libjxl 0.6 - almost all such issues couldve been resolved with access to professional ressources that guarantee flawless implementations. after all any glaring issues hurt jxl itself

Could start by reverting or tweaking the AC strategy PR, that was yet another thing I wanted to try with you when we have braincells to spare

I have a couple ideas myself but it would be funny if the major issues plaguing lossy JXL can be fixed by simply tweaking a few floats. 😂

subsampling 444 is the best?

For AVIF?

Yea

By the way, homosapien, you where made in the image of the Living Gods 😉

We are all made in the image of God. 😄

Anyways, I would agree 444 is generally good to use for AVIF.

So 444 is the best?

I just need the best settings.

I am trying out things here, I can't even seem to see any difference with time on 0 compared to 10 - I don't get it.

I guess I need some kind of better test images for this.

For best settings, I would recommend using libavif, specifically `avifenc` because it comes with a special tune just for photos.

and where do one get avifenc?

is it in Gimp 3 or XnConvert

I don't get this....

Unfortunately, I don't think it's in either of those programs.

It's command line interface, similar to jpegli

I mean, progressive was a one line fix for both lossy and lossless

So some kind of Github stuff again?

Yes, but you don't have to compile it. There are pre-built Linux and Windows binaries here.

https://github.com/AOMediaCodec/libavif/releases/latest

So 440 422 and 420 what exactly is it, less colors something? I can see the files gets smaller from 440 to 422 to 420 but....

what?

does it have less color information?

Yes

444 = full color resolution 422 = half color resolution 420 = quarter color resolution

It describes colour subsampling

so how much is less color information.... ahh okay....

aha....

how does that work :S

half color resolution, like.... or 1/4 color resolutionen.

like..... it finds the most near color it can then use?

So what is the standard full color resolution one have?

is this like miniJPEG tech where they just removes a lot of colors.

TinyJPG

my bad, Tiny.

420 means full res for gree n, half res for blue and 1/4 res for red

Encode an image yourself using chroma subsampling and observe the difference

Well, in the context of AVIF it's YCbCr right?

Should be, yes

https://upload.wikimedia.org/wikipedia/commons/0/06/Colorcomp.jpg

GBR instead of RGB

So what exactly is the point of it?

Like what is its usage?

Less information to encode -> smaller filesize

Since the colour information is discarded

420 is fine for photos and Video since red is not as prevalent in real life for the most part, but really noticeable with digitally created assets since red is used more often there

Although I prefer full RGB in any case

In particular screenshots and artwork suffer from 420, so I would recommend using 444 for those.

I'll think I will stay with 444 then

I thought it might be something like https://tinyjpg.com/

Okay, I think I will start with 50 444 and fast.

it seems the slow is just packeging it further down and lower size.

which of cause is great, but I can always run that while sleeping or something 😛

to get some extra juice out of it.

Vp9 isn't encoded well to begin. It isn't in good mode

Jxl 0.6 is a masterpiece

hmm Gimp 3 have a RGB setting.... so what is the difference between that and the 444?

Are you asking In General or just for AVIF?

Gimp 3

Those are the settings in it.

AVIF supports RGB but it is more ineffizient in terms of filesize

Encode yourself if you want to compare

Vp9 After correction by dzgas

Av1 after correction by dzgas

aha

Lossless avif is very bad. File sizes are huge and color shift also happens.

I did another re encoding

Expect miracles

Vp9

Av1

No

No what?

color shift in lossless? how/why?

May they fixed it in recent releases but a few years ago it converts everything to ycbcr or ycocg even on lossless encodes

you can just set the matrix to identity and then it's rgb

but that compresses terribly since av1 is designed for yuv

https://youtu.be/E4YJTgm3i0Q?si=WUtKxuLV5nk0yRfN

I've encoded a full video with my favourite settings

Please judge the quality

Of the colors and artifacts

Did i improved av1 or vp9 encoder or i only caused the envinromental damage?

Keep in mind that I used severe script in

Wow.... had to push the JPEG to the lowest point to near reach the AVIF 50 Quality.

The more unnatural a woman makes herself the less one wanna be with her. Sickening.

disgusting.

like how much botex did she fill those lips with.....

LOL the JPEG is even bigger.

But sure is a lot of difference.

can anyone guess which one is JPEG and which one is AVIF......

😄 It might be a very hard one to break.

Sarcasm, anyway, kinda somewhat close to a lie. So.... Anyway.... What a difference.

Had to try it out.

the JPG folder is around 100KB bigger.

Had to press to the very buttom of quality in the JPG to reach 16.3MB

the AVIF is 16.2 at 50 Quality.

for 600 Pictures.

But what a difference in quality.

It is hard to fathom how it can really get so much information into so small a file or files.

Original file.

And nearly impossible to see any difference betewen the original and the 50 Quality AVIF

I think I made the 50 Quality with Gimp.

the settings for the JPEG

It does remind me of the 90's

Avif looks blacked

Yes it compress but whats the point

Anyway i can't, download nomore on YouTube

Your observation helped become avif2 what is it, but sure Jxl doesnt need to work on that feature

Sure you can download on youtube.

AVIF2?

I have been silenced

silenced?

Avm

dunno what that is.

Tommy carrot shared a build

for what....

You need to disable the uneven partitioning

Av2 AOMedia

no idea what you are talking about.

But if you wanna download youtube videos check out yt-dlp

You can download whole playlist and videos with that.

Apparently he got bannrd

And whole comments deleted on doom9

But I have the build with the commandline

Just isn't ready

It Hasbro BRu lookead

What is this guy blabbering about - like he is all over and everywhere.

It hadnt Antey

9 days ago,500 commits ahead

Sorry av2 Is different from jxl

I performed optimizations on most of the sites but not only cloudinary by using bots

I'm a bot myself i touchscreen my phone and i ll murder it

I know gemini like better than google

Jon 5 months feared me but know i achieved

I have asperger and adhd is strange. Nobody want to deal with me at desk

So are you a bot or a real person

Real person 24 years old

With iq 70

okay

Though yt isn't a my passion i lke codecs in general but i didn't buy a New pc to do encoded

I did feel exhausted reading, like you where like all over and around on your writing. Anyway, we all have our own issues to battle with.

you can use the yt-dlp for downloading youtube videos's

they have a Discord channel for help on commands and such.

Yes today i deleted 3 times cookies on Firefox and Chrome mobile

Because they can get mad if I do that kind of stuff

But I succeeded and did great study at least the dafina zefiri video

Just export the cookies from an incognito window, then close the window

No sorry I didn't Watch it

So the cookies won’t refresh

Maybe on the pc with Kodi

How it seems to you

Sorry if I talked about piratery

I’m talking about yt-dlp

the 3 major issues all probably have something to do with how the quantization error is rounded or diffused.

Like really, I am amazed at what AVIF can do and how small files can be made and still keep quality.

The video is improved on yt, it has already banding

Vp9 seems great i'll rate 7,6/10

YouTube uses pretty low bitrate

Av1 i didn't Watch ed

I don't even know who are bots and real people anymore.

For dafina zefiri tranquilo it says language is romana but isn't true because is albanian

What's the name of God? "I am." ;)

But bitrate is 9,36mbps

Jehovah

What resolution ?

And is very high for that type of stuff

5,6mbps av2 10.0 is sufficient for that video

Who is God? "I am."

Jayshua, who was, i and is to come.

The highest

I can confirm he is not a bot, English isn’t his first language though

4K? 1080p?

Hajah, Hoveh, Jihejeh, Jehovah - he who exist.

30 or 60 fps?

No the problem is the autism

roger.

Ah full 4k i think

to many vaccines maybe, we get lots of those these days from childhood.

they sure do a lot of damage to us.

We need to be very high indeed to understand what Fab is saying

I can just about (with the help of DeepSeek r1)

Yea, I surely had some issues following him as he went all over the spectrum 😛

Based on intra I do not see improvements I can confirm what dzgas is saying

Av1 really s...

May Jehovah Jayshua help you with your Autism Fab.

Who?

Inter I do not want to waste my time

Jesus.

Jayshua is the Hebrew name.

Yt isn't encoding well, maybe it needs more time

Though the resolution is ok

Maybe upscaling

Don’t upload to YouTube if demonstrating codecs, it re encodes

I do not understand i need to watch on pc

It is hard to believe AVIF can do what it does.... amazing.

VLC media player has AV1 Decode

like 600 files, 16.1MB and the quality pretty good.

not the official debian version I have.

Technically it would be Yehoshua

For Jesus

MPV?

This is more of an <#806898911091753051> activity though lol

Not the name that was given to him. But overall, Jehoshua, Joshua and Jayshua means the same thing - but he was named Jayshua.

MPV?

This conversation I admit is slightly hard to follow at times