JPEG XL

these 3 reasons are unavoidable

I recently tested this video and AV1 looks way worse

it's literally 1/3 bitrate

even if you encode with svt-av1 preset 0, and use the real source; this bitrate diff can't be justified

AV1 Live Streaming? That's perfect though.

I guess the question is, why does Google set it as the default? It doesn't even seem ready for production.

Even after the bugs were fixed it just looks bad.

It's easier to get away with it

I downloaded both videos here

and the difference is huge if I do a comparison on `video-compare`

but a casual viewer can miss it because they don't know about the other one

they will slowly remove VP9 streams in my opinion and only keep AV1s

if they used the same bitrate or slightly lower for AV1; it could have been amazing (but only for new videos; not re-encoding the older ones)

they saving original video file for a long time

AFAIK they don't

they save my video for 5 years

youtube does many lossy to lossy conversions

interesting

<:PirateCat:992960743169347644>

we talking about company who provide unlimited google drive account

Mine also had the original files saved for years

google is too poor to compress av1 so well 🥺

I think they have condition

[popular | recent upload | already small] video will preserve source

others will "high-quality transcode"

You can check by https://takeout.google.com/

Lol, google use asic for that

Mine was an unlisted video, from 4 years ago, and was an 9GB MKV So those didn't apply when I did it

does anyone test av1 codecs? variant alternatives? maybe Avif? does anyone really care? i noticed a complete lack of activity in the area of "the best codec is here use it" or something like that. have we reached a technological plateau?

Jpeg xl is 10 thousand times better !!!1 use it!... wait it doesn't... <:pancakexl:1283670260209156128>

*oh, we came up with jpeg li so that everything else doesn't need to be implemented for another 10 years*

Well, couldn't they have come up with webp yuv444 in which Y would be decoded for backward compatibility and CbCr would be another part of the new addition to the codec... <:Thonk:805904896879493180>

why was it necessary to make Jpeg 2 twice, although webp has full support everywhere already, and half of the sites actively use it. Why couldn't they say: jpeg is dead and old and bad, stop using it already. But no, they are extending its life, what for? <:Thonk:805904896879493180>

From the site owner's point of view, from the user's point of view, there is no reason at all not to use WEBP instead of Jpeg+png for literally everything, the encoding and decoding speed is almost the same, the quality is always better. You can even replace GIF with WEBP, because the webp algorithm compresses so much better that even without the interframe compression it will be better than the elephant GIF for all sorts of gifs and animations. Which also kills APNG. But no, they come out with a smart face and say: here is jpeg 2 two, jpeg li. What? Why? Is this a dog bone? <:Thonk:805904896879493180> ☝️ I have absolutely no understanding

more smarter people can't even say their own: oh well, these are patents, there, the complexities of licenses. Yes-yes webp, other arguments?

I disagree on the basis of: most people still hate WebP and only want JPEGs or PNGs.

lol

literally why? because they were using the internet for the first time, not in 1996, when png didn't exist. So they probably don't know what technology adoption is. People who first used the internet at the beginning definitely used ready-made jpeg png that just worked everywhere. And for this reason, webp, which didn't work everywhere even 5-10 years ago, could have reinforced the negative reaction to the innovation. So what can we do about it? Just ask people personally. And then when they say that photoshop can't open their webp, say - well, that was 10 years ago, you know.

The state of adoption doesn't matter at this point – you will not change the general publics perception of WebP

It is too late for WebP

It's fine for web delivery, but people get mad if they download an image and it is a WebP instead of a JPEG or PNG

Also due to the fact that the WebP is lower quality than the source JPEG it is derived from in 90-95% of cases

sounds like an imposed opinion, why would that be, does anyone even understand what file format it is when they look at a picture? what do you think? what do you think about people? I can determine the file format by compression artifacts under a magnifying glass, but it's not worth talking about. For example, Reddit has completely switched to webp, as well as discord for all previews

sounds like a lie

it's more like a meme that was 5 years ago

Discord's previews are flawless in the sense that you still get the source image if you just click on "open with browser". Reddit is more problematic, you have to perform multiple clicks until you get the source file

I still see threads of people raging about WebP from time to time

Wait... there were never any jpeg source files in the reddit, now it's all webp

No, you can still get the source files

oh forget it, i just went to reddit and there is preview jpeg it's all pointless

Also FFmpeg still has no support for decoding animated WebP

and yet all browsers can

true

> Why couldn't they say: jpeg is dead and old and bad, stop using it already. But no, they are extending its life, what for? "They"? The internet as a whole rarely agrees on something 100%. Even inside Google there are two groups of people. One for AVIF and one for JXL. Also, good old JPEG still has progressive which is good.

But

Archiving - jxl, lossless jpeg - jxl, more than 8 bit - jxl, multithreading(big images) - jxl

<:JXL:805850130203934781>

webp also has a progressive, line-by-line decoding. But forgive me, I live in 2025 and have not seen a real progressive multi-scan jpeg display for 5 years, so that it could be shown as an advantage. It's a relic of the Internet 30 years ago.

<:JXL:805850130203934781> Well, I live in a world where jpeg xl is supported by Google, and Google doesn't add support for it.

<:Google:806629068803932281>

but Apple, which has devoured so many patents, adds support for free jpeg xl everywhere. It sounds like a comedy.

native jpeg xl support in android where? That's the whole power of open source, Google makes it, there's no freedom here. <:SadCheems:890866831047417898>

Also, why is it when someone disagrees with you you call them a liar? You said to me as well. The word "lie" doesn't just mean "false", it has a wicked and evil component to it. By saying <@167354761270525953> is a liar, you're implying they know the "truth" but instead choose to intentionally deceive you. I understand if English isn't your first language, but you should try using a different word (Unless you think RaveSteel and I are actually evil). One that is less accusatory. Like "Sounds false", or "I don't think that's true". Or else people will not take you seriously and not listen to what you say.

It is lie because actual ratio is 99.9%

Hanlon's razor moment

English is really not my native language, I would say more precisely the word "пиздёж" which is a "super-negative word of lie", because the statement that webp has worse quality than the original jpeg depends solely on the compression settings, and not because it is a webp codec. In English it is probably better to say: complete disinformation and deliberate misleading, which puts webp in a negative light. The phrase "sounds like a lie" specifically has a negative connotation, because I have no respect for such a statement.

But you're not just attacking the statement. You're implying that the person making the statement is evil.

"depends solely on the compression settings" And herein lies the issue. Most websites compress their WebPs so severely that they look much worse than the source image

I have seen many such cases of that happening. The bit-rate is too low and companies don't care.

Exactly

Well, since he's sure of what he's saying, maybe yes, it's evil, and it's better to give evil teeth. No one forbids using the q100 webp, but no one does. There's nothing to discuss. Companies and website owners want to compress more and less size, not keep the same quality. I'm not saying that AV1 sucks, because it looks bad, worse than vp9 on YouTube. It's all about the quality parameters, which sets the goal of "Less Size", not better quality for the same weight.

well then what does webp have to do with it if the site owners make the settings, go says that reddit is bad, not webp -- that's fair

That is what I was saying. I was not arguing about WebP being bad. I stated the fact that most people dislike it due to the aforementioned reasons

I have lots of WebPs and created many as well

I don't like your position "most people" who are they? where? research? if this is your personal experience then what argument can there be

Are you seriously asking for a source for a well known fact?

> Well, since he's sure of what he's saying, maybe yes, it's evil, and it's better to give evil teeth. Don't be surprised if people don't want to listen or talk to you then. Because "lie" ≠ "false".

Also *"sure of what he's saying"* is not the same as *"knows the truth but chooses to say otherwise"*. Belief and hard facts are two different things.

Has anyone done research that people prefer jpeg more than webp? You might intuitively say YES jpeg is loved more, but it is absolutely unprovable without a global giant verifiable survey

my answer is no - you are a liar, give me some arguments

but I can't make the statement false because HOW would I know? I don't have the same research, I literally can't say: *well, you know, if you give people a choice of which covers to show them on YouTube Webp or Jpeg, they will choose WEBP* - I have no idea the answer to this question, there is nothing to argue about

Check danbooru (or any artist platform) to look up if any upload source is webp

Provide evidence bro. You don't need to insult people to get your point across. Evidence speaks louder than words.

By the way, this may be some argument, depending on what site is used as a download source, for example reddit. In my archive of art I really have 3845 webp pictures when all pictures are 46 879

Here is some evidence https://w3techs.com/technologies/history_overview/image_format/all.

sites like Newgrounds, for example, or deviantart

Looks like WebP is increasing in adoption but it's definitely not the favorite

Newgrounds is actually great with WebP, since they also serve lossless WebP

It's not bad, but it's too widespread following the global network. In fact, rule34 has a very simple API, I could check it there, I think, in half an hour.

webp is mostly passively served, recompressing png or jpg originals (which for future optimization efficiency need to be kept anyway). cdns and recompression services defaulting to another format would boost it overnight at webp's expense

Also, don't some companies use WebP to boost their SEO?

https://instagram.com/reel/DLjdthIxKNA/

huh

Oh yeah that video of somebody beating up Jyrki for making WebP 😅

That literally showed up on my feed one day

The WebP hate is still strong

Why has every domain embed I try fail today

https://d.ddinstagram.com/reel/DLjdthIxKNA/

There we go

Also memes like this https://fxtwitter.com/ManMilk2/status/1638925702220136450

now everything fell into place. when you go to the jpeg link you get webp. so that no one understands anything <:megapog:816773962884972565>

okk

firefox support jxl

wow, everything was working a couple of days ago, but now he has closed his api for general use. Well, that's a problem. I won't be able to check anything

It's good that I managed to download 300 thousand artworks just a couple of days ago. Hmmmmm...

It's a pity that the days are over when I could download 108,000 videos from YouTube in a week, just because. Eh.This is no longer possible. Very very sad

tbh it makes sense. average user doesnt consume that much content, it could be mirroring being done for commercial purposes like to train llms and ai bots - and the new gold is in imposing limits then demanding a fee to remove them

meh. The videos are just deleted and they disappear YouTube as a whole has a very closed API and in order to interact with it you had to break a lot of things, which most likely the developers themselves don't know about, at least I was the discoverer... Technically, there is no search on YouTube where I could find something like "give me 10,000 videos that contain these words and do not contain these words that were released in 2021" -- well, since they do not provide such functionality, well, I just parsed 1.4 million videos manually and searched among them.

since i got the base, all that was left was to use the fundamental problem of content delivery - The Thumbnails CDN server, which does not require anything, but give 3 frames from all videos on request to ID. So i downloaded 1.4 x 3 million previews for content analysis, and search and what irritates me here is that to get a tiny little preview of AVIF you can't just do a request, because AVIF is given through a jpeg link given by YouTube only when you go to the site, so I had to use webp

but now in the world there is the most powerful neural network for finding Gacha Life in image frame with a correct guess of 97.5% almost instantly - based on MobileNetV3

and it's also a little funny how you defend a company that, without any laws or copyrights, trains its neural network on all YouTube videos to generate videos because can

jpeg is better than webp, you can recompress jpeg.

🤯

jxl > avif > jpeg > webp for lossy now. JXL best by all, avif can extreamly compression & support from browser & standard options (12 bit, hdr), jpeg support everywhere & can be recompressed by jxl and get ~same compression ratio like webp. WEBP too old for internet now, when JPEGXL be fully standard of internet images, webp can't beat him. Speed-size tradeoff? I am confident that corporations can spend a little more time on compression to ensure long-term file weight reduction. It's all

avif is only at 0.8%?? 😭

yeah

Instagram is notoriously unreliable, use ddinstagram anyway (although it may also fail to embed)

ugh no wonder webpages eat data for breakfast, images are very unoptimized one thing that discord got right is their image comoression pipeline

Well... They obliterate JPEG and WebP previews, and uploading on mobile uses quality 40... But other than that they're doing alright

annoying for quality comparisons but excellent for mobile/metered data

although still not perfect, it would be nice if there was an option to only load images of a certain size on mobile like telegram

constant 3+ mb screenshots are draining

last month (sg is a specialized app for a website, shows steam game banners and screenshots)

i might've messed up this month trying to circumvent social data not including discord by using telegram's browser, but it uses much more data and i think it might've been using from my regular data, kinda explains how i went down 500 mb in one day

Diminishing returns means they could probably use quality 70 for drastically better quality and only moderately larger files. They'd save more by not loading the original file when you zoom in on mobile, since you tend to hit a limit before actually getting very far

the size changes would depend on the original file but that's fair enough, the fact that they're compressing in the first place is appreciated, also yeah not loading the original when you focus the image would help

you could always tell this to \@scott.kidder if you want

I've pinged him twice in the past, never got a response

and JPEG just got some tricks from JXL

Telegram does quality 86 4:4:4 progressive, Discord does quality 40 4:2:0 sequential 💀

Difference being Telegram also resizes to 720p by default, so it's only around 130KB. Discord keeps it at the original res and just crushes it down to 130KB

huh, interesting

Do you mean the compressed images on Telegram?

Yes

There's now an HD option that supports up to 2,560 * 2560 pixels

but it doesn't keep the original

It's been around for years on desktop, mobile got 2048 * 2048 an update or two ago It keeps the original if you encode the JPEG yourself

Mobile Discord (494,942 Bytes, 5120 x 3840, Quality 40, 4:2:0, Baseline), Mobile Telegram (119,950 Bytes, 1280 x 960, Quality 87, 4:2:0, Progressive) Desktop Telegram (127,111 Bytes, 1280 x 960, Quality 85Y 90C, 4:4:4, Progressive), Desktop 'Large Photos' Telegram (415,974 Bytes, 2560 x 1920, Quality Y85 C90, 4:4:4, Progressive)

Uploaded on desktop to avoid recompression, but naturally the previews will be wrong

when does discord transcode to jpeg and when webp? Webp is used for avif and Webp

WebP is always used for previews

My client got a 51KB WebP <https://media.discordapp.net/attachments/805176455658733570/1407597581432918107/TgPhone.jpg?ex=68a6aee7&is=68a55d67&hm=d59e4938e167a006f85b97d692fee1723a5fbd9ce35c4ed8ec0071947b3b1f54&=&format=webp&width=1108&height=831>

The large Telegram image is both smaller and much higher quality than what Discord mobile uploads, with the other telegram encodes being 3x smaller and still looking better

Not to mention Discord could just load the resized images instead of spending an extra 50% sending a WebP preview that looks even worse

*Plus that would do real progressive loading instead of a blurhash*

<@1156997134445461574> what are your thoughts on this finding? also would it be possible to have discord mobile only load images of a certain size? like <1mb?

Not to mention the Discord mobile compression is forced, there's no way to turn it off or just upload the file without workarounds

isn't this the option?

No, that's specifically on mobile data, and I have it disabled anyway. You can see it was still quality 40

Can you share the statistics of the image formats in your archive? It would be interesting to compare them to global web numbers. Also, sorry if I talked too much about the word 'lie'.

unfortunately no, I deleted the xml api data after I downloaded everything. and I downloaded not the originals, but the sample-version, which are all jpeg or png if the original is png. so I can't provide anything, but as I said earlier, in my personal collection for 4 years of saving, webp is about 5%, which is really not much

the thing about the liar was that no one checked whether society really doesn't like webp. people surrounded themselves with memes and a few dissatisfied people, being in an information bubble, although 90% of users on the internet don't even know that images have some format. this is an image and it just opens. apple uses heif and no one notices it. saying that people don't like WebP is just because it's neither true nor false, it's a lie

"The liar". Right, and most regular people that are aware dislike it. You are the one living in a bubble if you have not seen the widespread WebP hate

I am talking against a wall here

If I haven't seen it, then it's not regular, and most people don't exist. Let's assume you're right. Where are the protests to remove webp? Where are the calls to remove all webp and bring back jpeg? What kind of hate is this, where in the end everyone is true happy that their sites use webp.

<:Thonk:805904896879493180> is there any movement to cancel webp? how to join it?

telegram is a bit of a liar. It depends on how you compare. There are 2 stages, you compress and send the picture to telegram. It is displayed "as is" in the PC version, but then it is compressed again on the server, and this will be the original. So for a real comparison of telegram pictures you need to upload to your PC, then download to your smartphone, and only then compare...

Since I don't want to spam dozens of links and images in this channel: use the LLM or search engine of your choice and query it for whether people dislike webp

I think it's a waste of time to prove to me that people hate webp. Because nothing is stopping its implementation. You won't be asked by companies and you won't notice when webp comes. This hate is only in your heads, and I don't know why you talk about it so much, I don't think it's true, and I don't think it's important. It's just a funny meme

If it's such a waste then why did you argue so much about it and call me a liar? I don't care what websites deliver, as long as I am still able to get the source file. Most people don't care either, as I said previously. If the hate were in "my" head I wouldn't be using WebP, yet I am. It doesn't matter whether you think the hate is not real, it is. You arguing about it doesnt change that fact

~ i have hate, and i must to use webp ~

https://addons.mozilla.org/en-US/firefox/addon/dont-accept-webp/

is there a version except for jpg and png <:kekw:808717074305122316>

<:Poggers:805392625934663710>

~8 years ago on a weak laptop I used something similar to watch AVC on YouTube instead of vp9 because vp9 was lagging. But why cancel webp is not entirely clear, well, 22 thousand out of... how many people use firefox? I don't know <:VP8:973222137202610226>

people want to be served the real png and jpegs, not webps with .jpg and .png extensions

i presume faked images would fail to open in software that does not support webp in the first place, much less ones identifying as "png"

net connections got like 10000x faster since the dialup era, file sizes of everything except images have ballooned up - enough with the images with ludicrously low simmu scores and filesizes, their visual lack of quality wasnt acceptable even 15 years ago

download* people rarely care what they are served

nah, there are still tons of people with really low speeds, anyone with a poor cellular connection can attest to that

https://www.androidauthority.com/pixel-10-video-recording-av1-vp9-3586429/

data plans can still be limited, and mobile internet speed aren't always so consistent

plus you might be loading tens if not hundreds of images at once

data plans are the biggest scam in history, because the "amount of gigabytes" of traffic does not really exist, there is only speed. And when the network is not loaded, the provider does not lose anything.

<:Thonk:805904896879493180> I find it hard to understand why people don't go on strike about this, really. I can't understand, it doesn't work, I have unlimited mobile internet for $2 a month, where I download terabytes a month

Oh, I didn't know the bot was posting here too

hey hey, sorry for the late ack

was that Mobile Discord from iOS or Android?

we're using a JPEG compression quality setting adapted for the source image resolution; I can tell you that we intend to improve the quality setting for images > 1440p

Android, though wouldn't it be better to resize the image than just lowering the quality? There's certainly thresholds where different options are best, we did it for jpegli a while back

also, we began computing full-reference PSNR and SSIM metrics for iOS and Android uploads around two months ago; those metrics indicate some areas for improvement on images above 1440p (which is most photos taken with the device camera, I'd imagine)

sorry to partially interrupt but I have a random'ish but still related question. Is there a check in place to upload the original (with metadata stripped as usual of course) if the recompressed version ends up being larger then the original in file size? (this is something that can very much happen in the wild)

PSNR is purely based on pixel values, not actual visual quality. SSIM is usually colorblind, only running on the Luma channel instead of color. We've had extensive discussions here around similar situations, we'd be happy to give our input here too

yeah, so long as the source is a JPEG

metrics like PSNR and SSIM map poorly to the human visual system as they try to measure the mathematical difference between results (treating image data like untransformed raw information) without taking into account any of the various intricacies inherent to image data (such as gamma, colorspace, etc). A much better option for checking the visual quality of images would be something such as [SSIMULACRA 2](https://github.com/cloudinary/ssimulacra2)

No worries, I know you're probably pretty busy. My old pings were a question and a suggestion. Is there a reason for the blank EXIF entry added to all uploads? I know you strip metadata for privacy, but it also gets added to already blank images, causing errors when some programs try to load it. What about tonemapping to sRGB before encoding WebP previews? IIRC HDR images were getting WebP thumbnails still with the HDR profile, causing large banding issues or wrong brightness. XYB JPEGs from jpegli get their Luma subsampled by WebP, causing very blurry images.

a couple things to dig into there 🙂

> Is there a reason for the blank EXIF entry added to all uploads? I know you strip metadata for privacy, but it also gets added to already blank images, causing errors when some programs try to load it. can you give an example? that'd help us put together a fix

my theory for the weird blank metadata that gets added to every image is that it's a subtle sneaky way of indicating that a image was downloaded from Discord. Though of course it could just be a simple mistake somewhere in Discord's media handling backend

Before uploading

understood and agreed; we needed metrics we could quickly implement for both iOS and Android that could be calculated during the upload. I'd like to add ssimulacra2 in the future

Test image

After uploading

An empty EXIF is always added, and in the wrong place too. ExifTool prints this `Warning: [minor] Text/EXIF chunk(s) found after PNG IDAT (may be ignored by some readers)`

gotcha, I'm investigating this now

Thanks, no more will be the days of uploading PNGs in a ZIP file 😅

iirc it happens with JPEG uploads as well

I see the bug

easy fix

Perfect

oh damn that quick lol. for context Discord has been doing this for years iirc

we're calling [piexif insert](https://piexif.readthedocs.io/en/latest/functions.html#insert) even when the EXIF data is empty

There's cases where it isn't empty? Or was it just leftover code

it was just blindly inserting an EXIF chunk, even when the source image had none

BTW, I'd be careful with deriving insights from PSNR scores, as it's one of the poorest correlating metrics in existence. It's actually trivial to *improve* PSNR under some circumstances, yet *decrease* perceived quality. Speaking from experience while I was working on still image AVIF tuning. SSIM is the more robust metric of the two, so it's likely a good-enough heuristic could be derived. Ideally you'd use one of the new-gen image metrics, but they do run much slower.

If you haven't talked to <@703028154431832094> yet, he might help with picture quality issues, specifically for webp.

I'd still argue that for Discord's case, WebP could be removed entirely and progressive JPEG be used instead for small/resized images. More responsive loading and no need for the extra cost of the WebP preview

If you’re computing the metric on the client’s device, SSIMULACRA2 is probably very doable

you could do a fast one, probably wouldn't want to do upstream ssimu2 or ssimu2rs

meh i use butteraugli

Considering Discord mobile doesn't downscale images, which is what I'm suggesting instead of just lowering quality, that could easily cause memory problems. SSIMU2 already uses a fair amount of memory, but comparing a 50MP or 100MP photo from newer phones would easily cause it to run out

The first time I really noticed the compression was my friend sending one of those large photos. The quality was so low that it could've just been the 1:8 DC downscale and it would've looked better

SSIMULACRA2 will most likely be too slow for low-end mobile devices though

That too, along with the RAM issue I mentioned

RAM can prob be worked around though (just tile the image in 512x512 squares or somthing)

It does seem a little strange to be running and collecting quality metrics on *every* device. Yes, image content is different and gives different results, but it feels like using a sledgehammer when you just need to run a few benchmarks instead

Actually, are you targeting filesize or quality? I'd assume filesize, because quality should be fixed regardless of resolution otherwise, but now you seem to be doing quality comparisons too, so I'm not sure if we should be advising towards one or the other

Resizing should make a lot of sense here, I agree completely

It is supported by Rachel’s multi-resolution scaling blog post: https://www.rachelplusplus.me.uk/blog/2025/06/evaluating-image-compression-tools/

You can use the most efficient encoder setting far more often, depending on what the quality target is

We've done our own testing too, tuning JPEG XL and jpegli to use resampling and 4:2:0 respectively at certain quality targets. It's a well known fact that resizing is more efficient than quantizing after a point, with Discord using q40 it could probably do 4x or even 8x downscaling for smaller files at higher quality

It s just badly implemented to my opinion

I managed to restict vram usage typically to `12*width*height*4 instead of 32*width*height*4` of ram as in vszip

There are ways even without tiling

I was able to run ssimu2 on a 21000x21000 image on a 24GB gpu

So on 1 GB you can perfectly have 4000x4000 for example

But it needs some work it s not a *free* upgrade

Could be further reduced to around ~6\*width*height\*4 on cpu by removing some gpu useful caching (this is litteraly just storing both images)

But there is a time penality on cpu

lol what

WEBP - 39 632 914 JPEG-XL - 40 193 530 (effort 9) PNG - 43 488 995 <:NotLikeThis:805132742819053610> <:NotLikeThis:805132742819053610> <:NotLikeThis:805132742819053610>

scan beat jpegxl

Lossless? WebP is still very good for that

lossless.

when lossless webp to jxl transcoding plox

https://tenor.com/view/feels-crying-will-smith-sad-gif-14770497

try libjxl 0.7.0 or 0.8.0

2030: hooray, google added jxl support to the browser! —I present to you this jpeg xl and it can transcode your jpegs! —why do we need this, the entire internet uses webp <:tfw:843857104439607327>

Eww, ram leak

<:WTF:805391680538148936>

<:WhatThe:806133036059197491>

Bunk

What

Do you think I understood what you wrote?

Ram is leaking

No

In old version

Yes!

this is not true

That only fixed in ~10-11

I see issues on github too

what does this expression mean? you say this as an argument not to use old versions. Its don't work for you because of this?

Yes

No

Yes

<:BanHammer:805396864639565834>

<:AngryCry:805396146322145301>

It's literally creating a rollercoaster of used RAM, and you say thay not leak. And i don't see a much difference between old and new jpegxl compression ratio

I literally compressed 100 thousand images 0.7.1 with 3 gigabytes of free memory

Effort?

Size

In megapixel

d 0 e 9

1 mp

That it

Try compress a big image

large images are a waste of pixels

No

What resolution display are you using?

1 MP?

Or waste of pixels

does this make sense? I downscale all photos by 4 times without interpolation artifacts and compress, approximate size is 1 megapixel. And loseless compress

What the fuck

well you know, 4000x3000 photos don't make any sense if your camera is a smartphone

Make

Details

look at noise smoothing artifacts?

😑

<:SadCheems:890866831047417898>

What wrong with noise artifact?

When you coding downscaled noise in lossless you oversize it

4² data downscale

No thanks.

But lossless noise

"adding" all pixels together during interpolation removes noise

I get the pixel, 24 bits, the value of which is extremely important

It's not a leak, but it is very intensive

use in effort 9 more than effort 10 in fixed version it's a leak

Can you give numbers? Like resolution of the image and memory used would be helpful.

Also maybe this conversation be in <#804324493420920833>

4k+ resolution

https://forums.macrumors.com/threads/ios-26-capture-iphone-screen-content-in-hdr.2464071/

in the database there are only 15 **webp **out of 732363 images found my 2024 base that I didn't delete

373 webp files for 12 million posts ☝️ I dumped it all

<:BlobYay:806132268186861619>

A photo my friend just uploaded from their Android phone, no kidding when you said "some areas for improvement" xD https://cdn.discordapp.com/attachments/776061344071942154/1410730640545939486/20250828_211624.jpg?ex=68b214ca&is=68b0c34a&hm=3844e5907dd3aaed9284c6c689a5231c1e39b747842f61c06ea801c84ecf260f&

It's even more horrifying that it still has a gainmap, so it's technically HDR too

what game is this?

Garry's Mod, we were playing with a few friends. That was their current setup while they're away from home

fyi we deployed the fix for the empty EXIF entry being added, please let me know if you see anything whack

Seems to be working perfectly, thanks for getting round to it so quickly

https://github.blog/changelog/2025-08-28-added-support-for-webp-images/

so actual ahahah

<@1156997134445461574> might have another bug for you. Seems like the ICC profile on the main image is being stripped, but the WebP preview still has it I noticed when clicking on my friend's photos, yellows would become desaturated because it looses the P3 profile (It was shot on iPhone) I also noticed it's a quality 100 JPEG, which is unheard of on phones and highly inefficient, but I don't know if that's Discord or IOS causing it

What's the audiophile way to do portable lossy encoding? <@604964375924834314>

I've seen people swear by Vorbis encoded using aoTuV (https://ao-yumi.github.io/aotuv_web/)

if encoding for something that doesn't support Vorbis, but does support AAC, Apple's encoder is usually considered the best, and fdk-aac, second best

It is possible to encode Apple AAC with qaac https://github.com/nu774/qaac

back in the day yes but now, is it really different? they say > The latest aoTuV beta6.03 was unified with Xiph.Org's libvorbis1.3.7

that isn't what that means

I think it's just saying that the latest aoTuV patch has been applied to the latest version of libvorbis unofficially

also this is where i'd recommend getting or looking at the patch from here: https://github.com/enzo1982/vorbis-aotuv-lancer/

oohhhhh

https://blog.quarkslab.com/patch-analysis-of-Apple-iOS-CVE-2025-43300.html

<@532010383041363969> I'm curious, did you ever explore Sharp YUV for jpegli? We noticed it was already implemented for sjpeg, which jpegli has as a dependancy, but not reused. We were trying to implement it ourselves to get much better subsampling performance

Thanks!

https://www.youtube.com/watch?v=_WjU5d26Cc4

lol

jxl beat it so easy

I said it in the comments that it's a very unfair to compare it to jpeg

and JXL is **JPEG** XL

<:kekw:808717074305122316>

meanwhile jxl/avif at q80 roughly 3.10mb to 150/210kb ```jxl PSNR(43.466), SSIM(0.97573), VMAF(96.056522) avif PSNR(45.769), SSIM(0.98371), VMAF(96.244875)```

roughly the same for stupid high res images as well xD

so for imgs def not, computer graphics/rendering/3d mmm maybe

Its functionally similar to vectors, so where vector art can work it would too

It's been harder and harder to build jpegli

So this page still works for `google/jpegli` repo

https://github.com/libjxl/libjxl/blob/main/BUILDING.md

https://encode.su/threads/4407-SIC-%28Structured-Image-Compression%29/

I ask GPT to draw the DChT basis

Would this improve AVIF?

probly

tho avif is already fantastic so idk how they can improve much

ITS OVER .

End of technological development. This codec will come out dead, like vvc

Releasing a new codec every ~5 years. Not a good idea.

At least the Chrome Team would be happy

No

They come like h264, be new standard

No

They come dead whoask codec

there is not even any implementation of hardware decoders. and this announcement will do a disgusting thing: why should we use av1 if there is already av2. besides, there is no reason for optimism, if we take platform number 1 on av1, it is YouTube. then it does not use all the technologies that av1 has to encode good video. because they do not have Power, and they cut their encoders. and av2 will not fix the situation in any way. perhaps only 1 company will benefit from av2 - Netflix. which has time to encode its films on the maximum preset.

1080p av1 ​​playback on smartphones is still impossible. absolutely statistically. maybe you personally have a good expensive smartphone, but you are not all people.

10 bit decoding is broken on iPhones, on video which plays perfectly everywhere for everyone. What a joke of HW standardization main 10 bit.

Mine crashes trying to play an AV1 video on Discord

Think it was 720p too

my telegram group has 1900 people, I re-upload streams, or at least that was my hobby a year ago. not now. the technological limit for smartphones, av1, is 960x540 60 fps 8 bit or 1280x720 30 fps 8 bit. 10 bit is technically dead, despite the fact that it must have support, according to the main av1 standard, some manufacturers of HW decoders apparently don't give a damn as long as it plays back any way, but to write that av1 support exists. I have a redmi 9a smartphone that I got for free just like that, it has a built-in av1 decoder. it can't even play 720p. it can not, it doesn't have enough power. what the hell are they counting on releasing av2

if you are on any imageboards other than 4chan, there is a real funny collapse about this, because when people post webm av1 the chance that they will write a response "well, this crap doesn't play for me" or "how does it lag, dude" the chance of these messages is 100%<:FeelsAmazingMan:808826295768449054>

so at the moment, despite everything, I use hevc. in my own key parameters "easyhevc", the essence of which is to achieve the decoding speed of vp9. Discord, telegram. enough

the world is not ready, no one is ready, there is no problem to watch 360p av1 ​​- this is what you really can. but not everyone needs 360p.

Av2 is buffed av1, with hardware support

<:This:805404376658739230> 🥱

Wtf

Buy new smartphone

Never

Your problems

AV1 have good support on android

Not you

Give me free pixel

Now

Pixel shit

Meh

Get a job

Never

https://discord.com/channels/794206087879852103/803950138795622455/1417408347711340585

AHHAHAHAHAH

need to find the source again, but iirc one of the reasons for slow av1 adoption was that the hardware decoder developed by aom was ass, and supposedly they'll make a better one for av2 that vendors might actually use <https://www.reddit.com/r/AV1/comments/ks7qfu/comment/giegmss/>

also, (high end) lg tvs actually support av1 since 2020, idk about other manufacturers

AV2 will support 512*512 superblock<:FeelsAmazingMan:808826295768449054>

what exactly does a superblock size that large get you? i know that av1 has 128x128 superblocks but the transform size only goes up to 64x64

i guess it's for inter and intra prediction?

looks to be the same for av2? or is that just actual av1 code left in the repo. idk <https://gitlab.com/AOMediaCodec/avm/-/blob/main/av1/common/enums.h?ref_type=heads#L490>

only seeing up to 256x256 in there

mediatek had av1 hardware decoders in 2020

meh https://encode.su/attachment.php?attachmentid=12233&stc=1&thumb=0&d=1749760462

Wonder what `FFmpeg` means

the block size of 128x128 is already uselessly huge. do you watch 16k video in av1?

the fact that support "exists" does not mean that the smartphone will be able to play even 720p video normally

it's amazing how many technologies aom used. which can be just thrown out, and improve what is there, having received an excellent svt-av1. well, probably in aomedia were proud of the number of innovations, although it was necessary to take an example from an empty vp9. I hope this is the main thing that will be taken into account in av2. if it will be slower both in encoding and decoding than the current av1. it's death.

<:AV1:805851461774475316> ⚰️

Now there is the dead end of DCT-based codec No substantial new thing, "more big block, more prediction angle, vary DCT to DST, more context for arithmetic coding..."

In general, technology has run out. No innovations are expected.

Just use webp For ever.

<:monkaMega:809252622900789269>

video is pretty much done and highly efficient for all targets. a higher bitrate or switching to a software version of the codec solves every quality concern

tv, iptv and physical will keep needing their own solution that will never show up in aomedia's flaunted support percentage %

in 20 years, videos have massively grown in filesize and bitrates but images were barely given any higher despite storage media and networks being like 500x faster/larger since

at this point intentional bit starving is a more deeply rooted issue that compression efficiency cant solve. even og jpeg should have consistently high visual quality, whats the excuse for images generated in 2025 ?

I wish `jpegtran` could be used to only delete metadata, without recompressing the JPEG "stream" <:PepeHands:808829977608323112>

I do expect that AI-based codecs will open up new possibilities for low-bitrate coding, if it can be made to work well enough in terms of speed/energy for video. But I think the desire for further compression improvements will also be balanced out a bit by the desire for authenticity and fidelity — so I think classical approaches will remain the best choice for most use cases.

At the moment I absolutely do not believe in AI codecs. Revolutionary encodec that compresses stereo music in 12 kbit is absolutely useless to anyone. And the theoretical costs of encoding and decoding pictures and videos are so big, so inefficiently using everything. Neural networks are not about this, I do not believe that this will happen at least in the next 10 years. The growth of technology also shows that sometimes "you don't need to make compression better, just make more storage and store the same jpeg at 20 megabytes per photo"

No

Support av1 MEAN you can play av1 like another codec

I can play anything on anything because I have a processor. That doesn't mean hardware decoding is much better. For example, on my smartphone, the hardware decoder is about 80% faster than the CPU for HEVC. That's not 10x. And that's still not enough for 4K playback if your processor can natively handle 1080p. Hardware decoders are designed to offload the load and reduce power consumption. No one makes them to play video at much higher resolutions than the processor can natively handle. This is the world of smartphones; everything here works differently than on a PC, where you CAN buy a 5070 for a 10-year-old processor.

If your processor specification have 60 fps FHD, and support h264, h265, av1, that mean hardware decoder support fhd60 for it. That work for smartphone, for gpu, for anything. Specification is created for it

It sounds reasonable, but even that's not always true when the goal is to reduce battery drain, and a boosted processor can be significantly faster.

They are developed separately, and the efficiency of video cards in mass media encoding is unmatched. What idiot told you that a video card will only be able to handle what the processor can encode programmatically? I want to see how you run AV1 in 4K120 on an 8-watt ARM, while the hardware handles it with ease.

What does the battery have to do with it, what does the processor have to do with it, we transfer the entire load to the GPU.

This is just wishful thinking. This can only be think if you don't use av1 and only read the news. Your statements are meaningless. <@456181666340405249>

I everyday use it

It's you don't use it

Never read documentation

In reality, you buy an iPhone for $1,000 and see this instead of a video. End of story.

Iphone)

Suck

with HW decoders, the max supported resolution and what resolution they can decode at reasonable framerates can be two entirely different things

This is bunk. There is no "maximum supported" resolution

People don't understand that resolution isn't a limitation at all. It's not about resolution, but about how much movement is in a frame, how many blocks are divided, how many are transformed, how many are converted. The actual number of operations during decoding. You can have static anime running perfectly at 4K, but the active gameplay lags even at 1080p. Resolution as a limitation is just "numbers in a labaratory" that don't mean anything anymore, just very, very roughly

global world decoding limit 2025 (only for 8 bit) 1080p 60 fps — avc only 720p 60 or 1080p 30/24 fps — vp9 | hevc 540p/480p 60 or 720p 30/24 — av1

There's some good news: increasing the bitrate has a smaller impact on decoding complexity, but it's still there, around 20-50%. But it would still be better to do this: make 720p HEVC the same bitrate as 1080p AVC to get better pixels without any artifacts. That would be the best solution.

ah, well, and you can kill the video if you encode svt-av1 on preset 0 or 1. Just because an algorithm is activated there that kills the decoder, and I spent 1 day looking for this in my svt-av1 fork, going through all the parameters

This is true for both vp9 libvpx preset best, which complicates decoding by ~40%, and hevc x265 placebo, which complicates decoding by ~100%.

<:Android:806136610642853898> ¿ What does this text mean: «This chip in a smartphone supports AV1 1080p 60 fps» ? I know—it's nonsense.

link

here: @DZgas

"trust me bro"

trust self

self i can decode 4k120

on PC CPU, and mobile GPU

k

Kind of. In the end, if the hw decoder was only wired in with a certain amount of bandwidth, having a high enough resolution frame won't fit anymore, regardless of how simple it is

there is too

codec have standards, and can't be non standard (specially for HW)

Honestly, these are outdated concepts. Back in the day, during the DIVX era, bandwidth was truly important. Now you can create an AV1 4K with a 500 bitrate that will lag everywhere, and the numbers mean nothing.

It's funny that after svt-av1 2.0, the code responsible for the av1 level numbering standard in the output video was completely cut out.

<:AV1:805851461774475316>

No more standards. the standards you are talking about are when netflix releases their own set-top box for watching netflix, which has its own av1 decoder built in. and they encode their movies and series with their own proprietary av1 encoder - that is the standard. and the same standard is in all digital TVs, satellite TV and the rest. there is a standard on blu-ray so that every other blu-ray can play it. that is the standard. you are on the internet, it is not here. and smartphones do not have it either, will play as much as can. that is all.

proprietary modification is under standard

Open source things can't have such standards because of how they work. It's a form of freedom; you have to pay for freedom.

stop hate speech to AV1, you don't understand the topic

you're trolling

W3C <:kekw:808717074305122316>

you're trolling

🙄

Searching for some help with removing metadata from JPEG files. If I use `exiv2 rm in.jpg`, it does not remove everything: - APP2, ICC profile is still there (which is good) - APP1 XMP, some tags were removed but then there is some left: ```305DFD2D70D05A5C1FD59C8F02728B7D�#<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.1.0-jc003"> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:GCamera="http://ns.google.com/photos/1.0/camera/" GCamera:hdrp_makernote="..." GCamera:shot_log_data="..."/> </rdf:RDF> </x:xmpmeta>```Is `GCamera:hdrp_makernote` needed for a proper decode (and to handle that HDR+ JPG) ? Or can I remove that XMP entirely ?

go and try decode 16K AV1 on HW decoders - wast majority will either outright reject or crash (or fallback to SW decode). It's very useful from HW perspective to place limits on what you can decode

For my phone's HW decoder, the max resolution is like 4k, so yes resolution does matter

lol my 14-year-old CPU can decode AV1 at 1080p60

sure, things are different on a phone

My 10 year old CPU can only do 1080p with dav1d

my first gen ryzen quad core apu with no hyperthreading can do 4k60 av1 sw decode (0 dropped frames), but ey i get it lads wanna have it on their ancient smartphones, therefore read this https://wiki.x266.mov/blog/svt-av1-fourth-deep-dive-p2#tiles

or if u want the tldr: > --tile-columns 1 --tile-rows 0: for 1080p and above > --tile-columns 2 --tile-rows 0: for 4K and above fast decode 1 with those if u really really need it

ah and if u don't wanna learn how to encode on av1 use this https://github.com/nekotrix/SVT-AV1-Essential

> SVT-AV1-Essential sports different defaults from mainline SVT-AV1 in order to provide a better out-of-the-box experience. They include: > > Forced 10-bit color depth and HBD mode, for higher internal precision and thus higher quality visuals and efficiency. > --speed set to slow by default at 1080p and below, and medium above. > --quality set to medium by default. > --enable-dlf set to 2 by default. > --enable-variance-boost set to 1 by default. > --variance-boost-strength set to 1 by default. > --variance-octile set to 4 by default. > --tf-strength (temporal filtering) set to 1 by default. > --luminance-qp-bias set to 10 by default. > --sharpness set to 1 by default. > --qp-scale-compress-strength set to 1 by default. > --enable-qm set to 1 by default. > --qm-min set to 0 by default. > --chroma-qm-min set to 0 by default. > --enable-dg (dynamic gop) set to 0 by default.

it will do it all for you kek

according to codec info, here are the decoding capabilities of dav1d and the mediatek decoder

<:AV1:805851461774475316>

and those are before --tile-columns 1 or 2 / --fast-decode 1

Why not 128k?

👍

a powerful expensive smartphone👍

get a job

use 960x540

250$ is not expensive

16K is still somewhat reasonable to have. And tbh even 8K will give some HW decoders problems

shut up

It's not 2005 anymore and I don't need to buy a new console to play console games (or pay for them at all lol)

No, this is absolute maximalism. An example that has no connection to real life. What 16K AV1? It's just a joke. There aren't even any monitors like that, not even movies or content.

c2android max features are not real

fwiw, 8k isn't selectable on the YouTube app but when played 8k60 through a browser i only have single digit frame drops

Is the hardware AV1 encoder important? Apple still refuses to include

Apple have hardware decoder

Sure but that's a decoder

Google add hardware encoder only on latest pixel

you need to spoof app dimensions

revanced can do this easily, otherwise I just use mpv-android with yt-dlp

Does anyone know of a JPEG viewer for images like 65535x? I mean, since JPEG is block-based, it can be decoded and displayed block-by-block, and it can also decode and display different layers of progressive scans. <:Thonk:805904896879493180>

Android Dev linking packJPG to compress JPG to "reduce the APK size" 💀 https://developer.android.com/topic/performance/reduce-apk-size#compress I understand the others (pngcrush, guetzli, ...) because they produce a PNG/JPG But packJPG would require to have the decoder embedded in the APK, increasing the size (which is the opposite of what they try to do)

Recommending quantpng and zopfli as 'lossless options', one is not like the other 💀

I was actually just thinking of making a post on the JXL subreddit, asking developers to come to us for help with integration and settings, to avoid things like DNG and the spectral compression paper, both of which have restrictions due to not knowing the format

oh right I missed that one <:KekDog:805390049033191445>

https://support.thinklucid.com/knowledgebase/using_qoi_with_lucid_cameras/

So JXL's another great competitor is QOI

Only 8bit and mediocre compression. JXL fast/simple lossless is much more efficient

At least it's much faster than lossless AVIF

If anyone's using lossless AVIF they should see a doctor immediately

Because Google never care lossless AV1

Did you know that if you wake up at 3AM and scream " I hate AV1" 1000 times, a mysterious figure called BlueSwordM will absolutely beat the shit out of you?

How did you know about this fact

is av1 bad? the only thing i heard it has very slow encoding

avif is the current best lossy, av1 is a bit painful but it's great

Av1 best video codec

av1 is very good, high quality and low file size it can be slow, but it can also be fast depending on what preset you use

so if fastest av1 gives better results than slowest h264, then it is cool?

hi10 for life

current av1 encoders are super inconsistent at faster speeds they can usually do better then h264 but sometimes just flop so hard the video looks intentionally censored

the fastest av1 presets arent the best, but if you go even a little slower quality improves massively

I get about 0.3x encoding speed at 1080p, so I only use AV1 for long, low resolution Discord uploads

https://www.mdpi.com/2079-9292/13/5/953 It's basically always h264 < h265 < av1 < h266

(according to PSNR/SSIM/VMAF)

You can share direct link in discord

ok

meh h266 is shit. It only has an advantage with extremely strong compression, like CRF 50-60. For the same encoding time (av1) it's a frankly useless codec.